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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Re: [ebxml-msg] Groups - Multi-hop Section Draft 0.3 (ebMS3-Multihop.doc) uploaded

My comments so far:

- Would it be a good idea to define the term addressing information? Suggestion: Address information is the set of meta data information of messages used by the I-Cloud to route message to their destination endpoint. 
This definition allows different I-Clouds to use different address information, for example one I-Cloud may only use PartyId where another one also uses Service and Action values for routing. I think that we shouldn't allow such an open definition and fix the address information to the meta-data that is available in ebMS user messages.

- Line 89-90: "although in some limited cases an Intermediary may add WS-Addressing headers".  Do we foresee intermediaries adding headers or is this considered out of scope? (I would think last)

- Line 93: "an Intermediary must be able to use streaming to forward a message Do we need to require streaming support? I think SHOULD or MAY is more appropriate.

- Line 101-103: "An Endpoint MSH must not need to be aware of the I-Cloud. In particular, no change in its configuration or PMode is needed when sending a User message to the same destination either in point-to-point mode or in multi-hop mode" In most situations I think it is impossible to go from P-2-P to multi-hop without changing the configuration of the endpoint MSH's because the URL will change. Beside that we will need some special handling from the endpoints on non user messages so this requirement can't be satisfied. 

- Line 141: "This functionality is referred to as a “table” mapping ebMS metadata to next hop" When using the term addressing information this could be changed to a mapping of address information to a next hop. 

Section 1.7.1:

- Step 5:
It is unclear to me whether the functionality for the pulling endpoint as it is described here is in accordance with the core spec. This because the core spec says that a pulling endpoint  MUST include a wsrm:Offer in the PullRequest and the responder should use the offered sequence. The core spec doesn't mention the case when the responder doesn't accept the offered sequence, so I might assume the Initiator must be able to handle CreateSequence signals that are sent to it in response to the CreateSequence for the  PullRequest signal. If this assumption is correct it might not be needed to add the dummy eb-header as the Initiator already has to accept a CreateSequence signal.

- Step 7:
Again it I'm not sure if this complies with the core spec and the need for the dummy eb:header.


On 28 mei 2008, at 08:05, jdurand@us.fujitsu.com wrote:
- a few updates in the definition section (editorial)
- added a commented Flow diagram (section 1.7.1) on RM sequence
establishment. To review.
NOTE: suggest to first focus on and finalize such diagrams before drafting
detail of spec content.

-- Mr Jacques Durand

The document revision named Multi-hop Section Draft 0.3
(ebMS3-Multihop.doc) has been submitted by Mr Jacques Durand to the OASIS
ebXML Messaging Services TC document repository.  This document is revision
#1 of ebMS3-Multihop.doc.

Document Description:
Draft of the multi-hop section.
- a few updates in the definition section (editorial)
- added a commented Flow diagram (section 1.7.1) on RM sequence
establishment. To review.

View Document Details:

Download Document:  

This document is revision #1 of ebMS3-Multihop.doc.  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]