Re: Comment on section 3.3.4, Messaging Service Spec v0-1

[Jim Hughes <jfh@fs.fujitsu.com>]

Gordon -

I have no disagreement with your two conclusions. [except maybe the field 
should be named MSHack? :-) ]

Much of our precious discussion time and mental bandwidth is being taken up 
due to imprecise and varying requirements, as well as some imprecision in 
the written words. My $0.02 worth...

Jim

At 09:59 AM 8/31/2000 -0700, Gordon van Huizen wrote:
>I think that there are two issues here and that they need to be
>decoupled:
>
>1) Whether or not the messaging service is to provide ebXML positive
>acknowledgments or not. I'd prefer to see this called "MSAck",
>"MessagingServiceAcknowledgement" or some such. "AtMostOnce" has a
>number of additional connotations that don't apply here, and it really
>blurs the line between what the transport and the message service.
>
>2) Whether or not the underlying protocol is to employ its own QoS for
>reliable messaging. This could certainly be dealt with in the TPA, as
>previously discussed. Note that we're pushing QoS normalization issues
>off to the TPA discussion if we do this (not that doing so would be
>inappropriate).
>
>WRT the reliability of the RM spec, I don't mean to discredit the work
>that's been done. My point is that I believe that we as a group are not
>clearly targeting the same scope for this work. If our goal is to
>provide ExactlyOnce semantics over HTTP, we need to do a lot more
>work--and be clear that this is our intention (the current naming of the
>flag points out that we are not all thinking the same thing).
>
>-gvh-
>
>
>
>Jim Hughes wrote:
> >
> > Rather than have an extended discussion now on the contents of the "RM
> > Spec" (even if it isn't 'reliable', according to individual
> > interpretations!), I think the proper conclusion to Change Request 137 is
> > to have three values for the ReliableMessagingInfo element:
> >
> > 1) "None" - meaning, ebXML semantics are silent
> >
> > 2) "AtMostOnce" - meaning, refer to the "reliable messaging spec" for what
> > the Sending MSH and Receiving MSH will do. Yes, there are overtones to the
> > term "AtMostOnce", but as opposed to "SeeRMSpec", "AtMostOnce" is a better
> > value, IMHO. I think we can require that all compliant MSHs must support
> > this value for interoperability.
> >
> > 3) "TPAdefined" - (or similar) meaning, through the TPA or some other
> > means, the two MSHs will agree to use some underlying transport's
> > reliability semantics, whether or not some kind of ACK is expected. Support
> > of this value is obviously MSH-implementation dependent.
> >
> > Comments?
> >
> > Jim