OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Can we omit the multi-hop reliable messaging section from the spe c??

I'm not suggesting that we do not do multi-hop reliable messaging. I am
suggesting that we can remove the multi-hop section from the spec.

I came to this conclusion by carefully analyzing Chris's Reliable Messaging
and realizing that it contained, IMO, many gaps and inconsistencies.

There were too many gaps/problems in Chris's spec to be able to suggest
changes on an item by item basis. So, as we have only next week to get this
spec finalized I decided to:
1. Produce another version of the Reliable Messaging section but base it on
version 0.93
2. Structured and sequenced it so that it followed Chris's structure
closely. Chris's structure was OK and it thought it would be simpler to
compare Chris and my versions if the structure was very similar (probably
this is the only way to do it!!)
3. Cut out most of the items that Chris had cut out but left in some that I
thought essential and highlighted those where there has been no discussion
so that we can review them. Included in this is removing Delivery Receipts.
4. Added at the end of my re-worked version, several sections that should
not to go in the spec but should be useful in rapidly finalizing the TRP and
CPA specs. These include:
  a) parameters that were removed from the Reliable Messaging section that
need to go in the CPA (we don't want to lose them)
  b) an updated Schema and changed wording for the Acknowledgement element
  c) some sample multi-hop message flows that illustrate why I think we can
remove the multi-hop section.
5. The result is a spec that is just about eactly the same length as

So why can we remove multi-hop? In short it is because we have removed
Delivery Receipts. This means that you can now treat the MSH you send a
message to as a proxy for the To Party even if it is an intermediary and not
actually the To party.

Anyway the details are in the attached zip file that contains the following
*	"Reliable Messaging Chris Ferris _DB Comments_.pdf" - which contains
my comments on Chris's spec
*	"Reliable Messaging David B version.pdf" - which is my re-worked
version in a similar structure to Chris's
I suggest that you compare these files to see the difference .

There are also another two files that you might want to look at:
*	"Reliable Messaging Chris Ferris _DB Comments (changes
highloighted).pdf" - which is the same as the first file above but with
changes highlighed
*	"Reliable Messaging David B version (changes highlighted).pdf" -
which shows the changes from version 0.93 of the original Reliable Messaging

Finally, I will move at the meeting tomorrow that we do not start to review
Reliable Messaging until people have read both Chris's and my versions
specs. I do not like having to issue a new spec in response to an earlier
one at such short notice, but there have been very few substantive written
suggested changes to the version published after the London F2F.


 <<ebXML Reliable Messaging.zip>> 

Solution Strategy, Commerce One
4400 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704; Pager: +1 (888) 936
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com

ebXML Reliable Messaging.zip

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC