[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. Sander On 28 mei 2008, at 08:05, jdurand@us.fujitsu.com wrote: - a few updates in the definition section (editorial) |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]