[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - ebms_core-3.0-spec-wd-21.pdf (ebms_core-3.0-spec-wd-21.pdf) uploaded
Hello, I know there will be a second public review in some time, but I read some parts, in particular chapter 8 and appendix B and thought I might share some comments on them already. Line 2875: Typo: line has two commas. Line 2895-2898: "This response is sent back reliably over the response leg of the same SOAP Request-response MEP instance that carried the previous message." This seems to be refer to the specific case of an ebMS Transport Channel Binding of type "Sync"? Request and response messages in a Push-and-Push message exchange can also both be sent reliably. If the assumption is that sending an asynchronous response message reliably is like sending an asynchronous request or one way message reliably and needs no special discussion, then it would be useful to state this explicitly at this point. If RM-SubmitResponse is not used for asynchronous ebMS response messages, then its name is too general, something like RM-SubmitSyncResponse would be more accurate. Line 2908: Related to earlier comment. Does this diagram also cover the second leg in a Request-Reply MEP with a channel binding Two Way/Push-and-Push and Two Way/Pull-and-Push? Line 2966 "the MSH" -> "the sending MSH" Line 2971: "generatedand" -> "generated and" Line 2982: "a failure do deliver must cause" -> "a failure to deliver MUST cause" Line 2984: "may be notified" -> "MAY be notified" Line 3025-3027: This will not work in case of multi-hop messaging, where the SOAP fault or HTTP response failure is received by an intermediary, which will often not have enough information or no channel to propagate this error back to the original ebMS sender. Line 3042: "periodic sending of status request ebMS signal (defined in Part 2 of this specification)" -> "periodic sending of status request signals (as may be defined in a future Part 2 of this specification)" Reason: Part 2 does not yet exist, so some caution is good when referring to it. Line 3045: There is no section on reliability of the Two Way Push-and-Push and Two Way Pull-and-Push. If they are covered by section 8.3.1, a sentence stating this could be added at line 3048. Similarly, there is no section on the Two-Way Push-and-Pull and Two-Way Pull-and-Pull. If these are covered by section 8.3.2, a similar textual addition would be useful. Line 3062 "workflow": confusing term perhaps. Line 3115: Formatting issue (should not be bullet) Line 3065, Figure 12, Reliability Ack Would this reliability Ack be a standalone message? Some explanation might be useful. Figure 13/14, second Reliability Ack. Idem. Line 3433, "OrderedDelivery: No Restriction". Should there be some text here about a restriction among ConversationId and Group membership? It seems okay to reuse a group for multiple conversations, but messages that are part of a single conversation should not be in multiple groups (or rather concurrently active groups: a conversation could start in one group, and continue in later one if that group is terminated). Line 3559-3561: "Any pair of sequence lifecycle message (CreateSequence/CreataSequenceResponse, CloseSequence/CloseSequenceResponse, TerminateSequence/ TerminateSequenceResponse ) MUST be exchanged over a single HTTP request-response." Does this mean that any use of WS-ReliableMessaging (in ebMS3) is tied to the HTTP protocol? Can this MUST be relaxed to a SHOULD? Some ebMS end users have and prefer an all-asynchronous setup for their messaging (today ebMS2), is this not possible with ebMS3? Line 3458, section B.2 Should there be some text here about correlation of use of ConversationId and Sequences? It seems okay to reuse a sequence for multiple conversations, but messages that are part of a single conversation should not be in different sequences (or rather concurrently active sequences: a conversation could start in one group, and continue in later one if that group is terminated). Line 3865, figure 15. This is an example of a Two-Way MEP, but the PMode.MEP in the figure says "200704/oneWay". -----Original Message----- From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: 25 April 2007 03:14 To: pete.wenzel@sun.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Groups - ebms_core-3.0-spec-wd-21.pdf (ebms_core-3.0-spec-wd-21.pdf) uploaded Thanks Pete: A substitution that we missed: - 2.2.6: the error "EmptyMessagePartitionFlow" should be renamed: EmptyMessagePartitionChannel - same in 3.2 (L727) - same in table 6.7.1 - same in B.2.3 (L3591) - same in F.2.5.2 (L4346) Quite benign edit, and pretty straightforward... - Jacques -----Original Message----- From: pete.wenzel@sun.com [mailto:pete.wenzel@sun.com] Sent: Tuesday, April 24, 2007 3:41 PM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Groups - ebms_core-3.0-spec-wd-21.pdf (ebms_core-3.0-spec-wd-21.pdf) uploaded The document revision named ebms_core-3.0-spec-wd-21.pdf (ebms_core-3.0-spec-wd-21.pdf) has been submitted by Pete Wenzel to the OASIS ebXML Messaging Services TC document repository. This document is revision #21 of ebms-3.0-spec-wd-04.pdf. Document Description: This is Working Draft 21 of OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features. Changes since WD 20: * CORE-121: Corrected element/attribute capitalization, cardinality and qualification in schema, Section 5 and Examples. A "diff" marked version is also available in the document repository. View Document Details: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?docu ment_id=23729 Download Document: http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/2372 9/ebms_core-3.0-spec-wd-21.pdf Revision: This document is revision #21 of ebms-3.0-spec-wd-04.pdf. The document details page referenced above will show the complete revision history. PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]