[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] A few editorial comments
<<comments in-line>> Regards, David Fischer Drummond Group. -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Tuesday, October 23, 2001 10:16 PM To: david@drummondgroup.com; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] A few editorial comments Re version 1.05 of 15 October 2001: Line 375: "allows for the final destination of the message to be an intermediary MSH other than the 'receiving MSH'": I think the word "final" should be struck, since the intermediary isn't the "final" destination. <<agreed>> Line 380: talks about an "ordered-set of discrete parties". I don't understand what this is talking about. Since when do we route messages to a set of parties? <<agreed, actually the rest of the paragraph is no longer true.>> Line 469: "There are two logical MIME parts": I think this wording could be confusing, since it seems to suggest that there are exactly two MIME parts. I'm not sure exactly what "logical" means here. Perhaps the intent was to say that there are two KINDS of MIME part, the Header Container kind and the Payload Container kind. But I think it would be better to just replace the whole line with something like "The Message Package contains MIME parts:". <<I think this is right the way it is. There are two parts even though the second part can appear multiple times. or it might be a single MIME container which contains multiple parts. This is already correct.>> Line 496 uses the term "root part" as if it had already been defined; in fact it has never been used up to this point. It sort of gets defined on line 507. In my opinion, we have the term "Header Container" and we don't need another synonymous term for the same thing. Can we say "The fist MIME part of the Message Package is referred to..."? <<agreed>> Line 910: Refers to section 11.1, which doesn't seem to be right. Perhaps 7.4.5? <<agreed>> Lines 929-930, section 3.1.7.2: this isn't right. duplicateElimination being true means *either* at-most-once or once-and-only-once semantics depending on whether ack/retry is happening. duplicateelimination being false means *either* best-effort or at-least-once semantics depending on whether ack/retry is happening. This is all laid out clearly in section 11.5's table. <<agreed>> Line 2276, section 11.5: in the row of the table labelled "4" (duplicate elimination yes, acks no), "Essentially best effort" should be "at-most-once". <<agreed>> -- Dan ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC