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

Sander:

inline

From: Sander Fieten 
[mailto:] 
Sent: Wednesday, May 28, 2008 2:19 
PM
To: Durand, Jacques R.
Cc: 

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.  

<JD> we want that indeed.

 

 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) 

<JD> the only reason for an intermediary to add such wsa headers, 
is to relieve an endpoint from doing it - if we provide such option. 
 Agree that we don't have to, 
especially if we decide that all "RM signal responses" will use AcksTo EPR, 
which is always known from the endpoint. The other corner case, is if an 
Intermediary can generate eb:Errors that need be routed back. But this is a case 
where the Intermediary itself is generating the message. So overall, 
agree.

- 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. 

<JD> possibly. Coming from our engineering as a 
scalability necessity... Let us just say thet the design must not preclude this 
- we don't need to state it in the specification.

- 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.  

<JD> I think that statement should be read as 
restricted to User Message sending. But indeed it is premature to say the PMode 
needs no change (besides the URL of next 
destination). 

- 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.  

<JD> 
right. 

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. 

<JD> in a multihop  context, it appears we may have to pull more than just eb User messages 
(i.e. RM signals, and eb signals). It also appears that an Intermediary may not 
be able to act as an RM node itself (so in that case the requirement needs be 
relaxed: PullRequests should not need be sent reliably, while pulled User 
Messages may use RM. This is OK as the Intermediary never does resending itself. 
Only the endpoint MSHs do). We have to look more into 
this.

- Step 7:

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

<JD> right, although dummy eb:headers are added here 
by Intermediaries , not by endpoint MSHs. 
 

Sander

On 28 mei 2008, at 08:05,  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.
V0.3:
- 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:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=28415

Download 
  Document: 
   
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/28415/ebMS3-Multihop.doc

Revision:
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