Re: MAJOR TECNICAL comments on v0.98

[christopher ferris <chris.ferris@east.sun.com>]

Correct!

Cheers,

Chris

SHIMAMURA Masayoshi wrote:
> 
> Mr. Christopher Ferris,
> 
> Let me confirm your idea. You mean that
> 
>     - When OnceAndOnlyOnce is specified and messageOrderSemantics is set
>       to "Guaranteed", SequenceNumber MUST be present. In this case,
>       receiving MSH MUST guarantee message order.
>     - When OnceAndOnlyOnce is specified and messageOrderSemantics is set
>       to "NotGuaranteed", SequenceNumber MAY be present. In this case,
>       receiving Application MAY guarantee message order by itself using
>       SequenceNumber.
>     - When OnceAndOnlyOnce is specified and messageOrderSemantics is not
>       specified, SequenceNumber MAY be present. In this case,
>       receiving Application MAY guarantee message order by itself using
>       SequenceNumber.
> 
> Is that correct?
> 
> Regards,
> 
> --
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
> Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
> 
> On Mon, 12 Mar 2001 09:52:43 -0500
> christopher ferris <chris.ferris@east.sun.com> wrote:
> > Shimamura-san,
> >
> > No, it MAY be present ONLY when OnceAndOnlyOnce is
> > specified, not always present. What this means is
> > that SequenceNumber MAY be used to effect RM (recipient
> > MSH uses it to determine if all messages have been
> > received in window) without requiring the receiving
> > MSH to impose ordering of delivery to "application"
> > unless messageOrderSemantics is set to "Guaranteed".
> >
> > Cheers,
> >
> > Chris
> >
> > SHIMAMURA Masayoshi wrote:
> > >
> > > Mr. Christopher Ferris,
> > >
> > > On Fri, 09 Mar 2001 14:03:03 -0500
> > > christopher ferris <chris.ferris@east.sun.com> wrote:
> > > ...
> > > > MAJOR TECHNICAL
> > > >
> > > > section 8.5.8
> > > >
> > > > 1 - line 574 - Requiring that SequenceNumber ONLY be present with
> > > >       OnceAndOnlyOnce and Guaranteed seems to me to be a limitation
> > > >       that could constrain an implementation from using SequenceNumber
> > > >       as a means of enforcing RM when the SequenceNumber is
> > > >       applied by the MSH and NOT by the Application (From Party).
> > > >
> > > >       I would much prefer that SequenceNumber ONLY be present
> > > >       when OnceAndOnlyOnce is specified, and that the semantics
> > > >       of messageOrderSemantics MAY be used to instruct the receiving
> > > >       MSH to deliver the messages in the order in which the Application
> > > >       determines by virtue of the SequenceNumber.
> > >
> > > I'm not sure if I understand your suggestion correctly. Do you mean
> > > following?
> > >
> > >     - When BestEffort is specified, SequenceNumber is never present
> > >     - When OnceAndOnlyOnce is specified, SequenceNumber is *always*
> > >       present, even if messageOrderSemantics is not specified
> > >
> > > If so, I agree to this change.
> > >
> > > Regards,
> > >
> > > --
> > > SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> > > TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
> > > Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org