Comments on section 1.6 of Multi-hop Section Draft 0.11 (ebMS3-Multihop V11-SF.doc) uploaded

["Pim van der Eijk" <pim.vandereijk@oasis-open.org>]

Lines 299 - 314, for forward routing, why do we need this new Refparam
Pmode?  

When there is a need to create a WS-A reference parameter to route e.g. a
wsrm:CreateSequence message, the content of the parameter could be a copy of
the first eb3:UserMessage that wants to use the reliable sequence that is to
be established.   This works both in situations where these sequences are
created "just-in-time" and where they are created "ahead-of-time":  
- In the "just-in-time" case, the MSH is creating this UserMessage anyway.
If there is no(t yet or no longer any) sequence that the message can use, a
wsrm:CreateSequence can be sent with the UserMessage stored in the reference
parameters.
- In the "ahead-of-time" case, the MSH could create sequences for all Pmodes
that require reliability, using the regular Pmode parameter values.  

If the values for Party, Role, Service, Action etc. that would be used in
the reference parameter are specified separately from the values for the
UserMessage element,  we also suggest that (or have to explain the meaning
of situations where) the values can be inconsistent, which I think is
undesirable. 

For reverse routing, there is a valid question how the content of the
reference parameter in the wsa:AcksTo element is set. In a Two-Way MEP, it
could use the values for From, To, Service, Action etc. that would be used
in a business response message. When using ebBP, such values can be taken
from the RespondingBusinessActivity definition.  In many cases the values
are predictable e.g. the From/PartyId becomes the To/PartyId (see section
1.5 of
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document
_id=28337 for discussion), but the value of eb:Action depends on the
business collaboration.  It also does not work for collaborations that are
always One Way from one party to the other (i.e. where there never is a
response business message that we could the header metadata values from).

Line 323-325

The text refers to the "RefToMessageId" attribute, for ebMS errors this
should be "RefToMessageInError". For eb:Receipt, presumably the
ebbp:OriginalMessageIdentifier if using ebBP receipts.