Re: Review of Reliable Messaging Spec v0-074

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

Gordon, I'm also enmeshed this week in 'day job' work, which is making it 
hard to keep up with the volumes of email. A hotel room with no telephone 
doesn't help! Comments below.

Jim

At 02:54 PM 8/21/00 -0700, Gordon van Huizen wrote:
>Jim,
>
>I'm on a plane at the moment, and hence am out of list contact, so
>forgive me if I'm out of order with the following observations. I
>believe there are two issues to resolve regarding requirements for ebXML
>reliable messaging prior to converging on comments to be addressed in
>the spec:
>
>1) The "level" of the messaging service that the reliability spec
>addresses, particularly WRT to RM-GROUP semantics.

As I said in another email, I think the best procedural way to deal with 
this point is for you or someone to make a specific proposal for a change 
(addition?) to the appropriate requirements document. We need to get the 
requirements correctly written down.

I am very sympathetic to the statements that the Messaging Service might be 
transport-aware, and therefore be able to make reasonable choices for 
real-world solutions. For interoperability, however, there must be a 
transport-agnostic (there, I've said it again!) solution possible.

>2) Whether the reliability requirement is truly for AtMostOnce
>semantics or for something more. An amount of the reliable messaging
>spec goes well above the strict interpretation of AtMostOnce, with no
>way to specify through the message header whether this is desired or
>not. I have a longer diatribe about this in my Messaging Service spec
>comments.

Fujitsu wrote a definition of 'RM' in the latest draft: AtMostOnce with 
timeout. Again, requesting other semantics (which are, of course, defined) 
is useful (and maybe mandatory) in the real world, but we should allow for 
a simple solution that will meet minimum needs.

>We've been discussing issue 1 for awhile, but I'd like to see
>us come to closure on both these of these issues ASAP so we can move
>forward.
>
>-gvh-


Jim Hughes
Fujitsu