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

[Gordon van Huizen <gvanhuiz@progress.com>]

In case I didn't make this clear (and I didn't!), I think these two
properties are orthogonal, and shouldn't overload the same data element.

I'm also unclear as to why we would specify the transport-level QoS in
the TPA, but specify ebXML reliability/ack-mode/whatever in the message
header on a message-by-message basis.

-gvh-



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
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard