Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

[Sander Fieten <sander@fieten-it.com>]

Title: Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

Team,

I probably don't have time to edit the current draft and process my earlier comments. I did manage to review section 2.6.6 and 2.7. One  general remark after reading the draft is that to me it seems more descriptive rather than directive. 

Comments on sections 2.6.6 and 2.7:

L913-917: This paragraph is about routing Error signal messages where the section itself is on the reporting of routing failures. Routing Error messages is already covered in section 2.6.5 (as the routing of an ebMS signal message). The requirements on endpoints is covered in 2.7.3. So I propose to remove this paragraph.
L934: Add sentence “If both headers are available the error MUST be sent to the URL given by the wsa:FaultTo header.” to make error reporting by intermediaries and endpoints consistent (see also section 2.7.3)
L938: Add sentence “Again when both headers are available the EPR from the wsa:FaultTo header MUST be used.”
L943-945: This option requires an intermediary to execute the routing function for a message as soon as it is received on the transport level, even before it is acknowledged [on the transport level]. Otherwise the error cannot be reported back on http response.
I would assume that an Intermediary must always support the default option, so Intermediaries are not allowed to just store and acknowledge the message on the transport level and than process it further. Do we want such a requirement? I would propose to rename this option to something like “Synchronous reporting”
§2.7.1: This section is more general than the endpoint MSH as it defines the WS-A EPR which is also relevant to the intermediary MSH. I propose to promote this section to a higher level and make this a new section 2.8 and renumber current sections 2.8 and up.
Reading this section I would also think that L880-888 should be moved to this section and in their place a reference should be made to this section.
L965: Insert sentence "WS-A EPR's primarily use URL's to identity endpoints."
L967-969: Text here is unclear and suggests that WS-A Action is used by the routing function. Section 2.6.5 however does not specify this. Propose to rephrase text to: "Consequently a WS-A reference parameter is used to allow the routing of messages through the I-Cloud as defined in section 2.6.5."
L1042: Change text to: “The Initiating message is defined as the first message sent by the Initiating MSH as defined in section 2.2.3 of the Core specification. As shown in section 2.5.2.2, in a multi-hop configuration both an endpoint MSH (cases 3a) and an Intermediairy MSH (case 3b and 4) can be the initiator of a message exchange. Three kinds of initiating messages can be distinguished:”.
L1045: Change “these headers” to “this header”
L1046: Add option to add an EPR and add reference to section 4.1 on how to configure EPR in Pmode?
L1047: Change first sentence to: “The most common case of an initiating ebMS Signal messages is the eb3:PullRequest message sent by an Intermediary to pull message from the endpoint (see case 3b and 4 in section 2.5.2.2]”
Add after “... to faulty messages.”: “When these signals are sent by the Intermediairy directly to the Endpoint and therefor don’t need to be routed and no routing info is needed. When the messages are sent by an Endpoint and need to be routed to another endpoint they should contain routing information.”  
L1048: Reference [to 2.5.2.2] is missing. Remove when accepting proposed change above.
L1048: Which ebMS error messages can be sent by the initiating MSH? If they can be initiating messages requirements should also be described here. Now only PullRequest messages are described.
L1050: After “.. eb3:UserMessage element” add: “Therefor a WS-A EPR as defined in section 2.7.1 (current section, may need change depending on approval of proposal above) MUST be added to the message.”
L1062-1066: Change first part of paragraph up to the sentence starting with “The content of ...”  to:  “These messages will not contain an eb3:Messaging header unless they are piggybacked on an ebMS message. Therefor a WS-A EPR MUST be added to these messages when not piggybacked on an ebMS message. In the latter case the routing information from the ebMS message is applied. A WS-A replyTo header MAY be added to these messages.”
L1064: Here it is stated that non ebMS messsage may contain an WS-A replyTo header. But isn’t that allowed for all messages, including ebMS User and Signal messages?
L1077: Isn’t there another possibility that an ebMS User message is a response to a PullRequest?
L1086: Add sentence to end of line “An Endpoint MSH MUST use one of these option to ensure that the response message can be routed to its destination.”

L1088: Insert at the end of sentence (after "... User messages") " by the PMode configuration of the Responding endpoint and/or by the submitting message Producer"

L1088: Why only use the reference parameter from the wsa:ReplyTo ? Line 1092-93 also seems to suggest that other information from the EPR can be used. 

L1092-1093: Unclear how wsa:To will be derived from wsa:Action in wsa:ReplyTo. 

L1096: Add after "... eb3:userMessage element" : ", unless the signals are piggybacked to en ebMS User Message."

L1096: Change "However, either one these" to "Therefor, when an ebMS Signal message is not piggybacked to an ebMS User Message, either one the following"

L1098-1102: Change text to: "the wsa:ReplyTo header was present in the request message. If it contains a reference parameter as defined in section 2.7.1 this reference parameter MUST be used in the response message. When the wsa:ReplyTo header in the request message contains a reachable URI the response message MAY be sent directly to that URI. 

When the response message is an eb3:Error, the wsa:FaultTo if present MUST take precedence over wsa:ReplyTo."

L1107-1123: Unclear to me what the requirements are on the sender of the response message and for which message the requirements  

 







On 21/10/2009 00:35, "Sander Fieten" <sander@fieten-it.com> wrote:

Below are my comments after reviewing version 0.43 of the part 2 draft.

Sander

L45: Insert TC name
L220: specifications should be specification
L289: As there’s a new version of the AS4 profile I think this reference must be corrected
L341-L345: IN the description / definition of the intermediary it is stated that routing is based on patterns and that the routing function should use ebMS meta data for interoperability. This is much more general than what is specified and an earlier text in this paragraph. I would prefer to have a more strict definition.
§2.3.3: As mentioned some time ago I think the Bridged Domains topology as currently described is not supported by this profile as it allows for different protocols in de domains. The profile however requires end-to-end ebMS messaging. Removing the different  protocol usage from the bridge domains description leaves nothing more than another instance of the interconnected hubs topology. I can’t create a useful description, maybe one of you can? If not, I would prefer to remove this topology from the document.
§2.3.4: Should this section not precede 2.3.3 ?
L417-421: Remove last sentence from paragraph as it not really related to the transparency feature.
L456-457: Change “... including Reliable Messaging ... signed.” to “... including WS-ReliableMessaging and WS-Addressing header elements where used within WS-ReliableMessaging to be signed.”
L460: Insert “see section 2.6.2 on forwarding models” after “... subsequent forwarding”
L464: Change “P-Modes” to “P-Mode features”
L472-475: Text unclear, remove?
L540-541: Last sentence is incomplete.
L665: Change the name to “Request-push-last-sync and Reply-sync-last-pull”
L851: Remove missing reference or refer to section on sub-channels and/or core spec on MPC.
L862: Remove “empty bullit”
L871: Here it is stated that routing of PullRequests can be done on MPC alone. It’s unclear to me which routing is meant here, because in most situation I expect PullRequests not to be routed but directly processed by the Intermediary. If the request is routed I assume it is routed to the Sending endpoint. And in such situation I would expect that more information than only the MPC is needed for routing.
L873: Reference to message (a) and (b) should be reference to message 1 and 2
L883-888: Several element names not formatted as such
L893-894: See earlier remark on which message is routed here, the PullRequest or an User Message waiting at the intermediairy to be pulled?
    



On 20/10/2009 14:18, "ian.c.jones@bt.com" <ian.c.jones@bt.com> wrote:

Team,

     sorry for the late notice - details as usual.

     Please review Part 2 draft - I have seen no comments on the list.

Thanks,
Ian

 -- Mr. Ian Jones


ebXML Messaging TC weekly call has been added by Mr. Ian Jones

Date:  Wednesday, 21 October 2009
Time:  11:30am - 01:00pm PT

Event Description:
ebXML Messaging TC weekly call

Tel: +1-218-486-8700
Pass code 120905

Agenda:
1. Role
2. Approval of previous minutes
3. V3 Advanced features - bundling
4. V3 Final review
5. AS4 - Updates
6. A.O.B.

Minutes:


View event details:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/event.php?event_id=25670

PLEASE NOTE:  If the above link does 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.

Referenced Items
Date            Name                             Type
----            ----                             ----
2009-10-20      MessagingTC101409.htm            Minutes
2009-09-28      ebMS3-part2-V43.odt              Reference Document