some preliminary comments on the draft

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: some preliminary comments on the draft

Mostly editorial, but not only...

Jacques

5.2:

- "However, it MUST be assumed the original sender has knowledge of the final recipient of the message and the first of one or more intermediary hops."

Would remove that sentence. MUST on an "assumption" does not sound right, but also: The "ToParty" header element is the only required knowledge of the final destination:

We don't know yet what the final multihop design will be: it could be that the routing info does not need to appear in the message, as it can be configured in the MSH. 

- About the Agreements: we seem to suggest there are three different agreements. Can we assume a single end-to-end agreement?

We probably do not want to have different agreements for intermediaries?

6: Abstract MEPs:

Definitions of Unidirectional / Bidirectional:
the notion of "expectation " used in the definition is too vague: we can't base such definitions on "expectations"...
Propose:
- Bidirectional: an exchange that involves a Request message and a Response message going back to the sender of the Request.

These two messages are correlated in the ebMS headers (RefToMessageId). These two messages are initiated outside the MSH, i.e. both have business relevance.

(the Request payload is provided by the Producer of the Request, and teh Response payload is provided by the Consumer of the Request)

- Unidirectional: an exchange that involves a single message, initiated outside the MSH, i.e. with business relevance (or payload?).

 Such a message is not correlated with any other message with business relevance.

6.2.1 and 6.2.2
: "Push MEP": (editorial) the transfer mode in itself should not define an MEP: we should say "unidirectional Push MEP" and "unidirectional Pull" MEP.

6.4. Aggregate MEPs
Besides the fact that these are exchanges that are correlated with RefToMessageId, they really distinguish themselves from the previous ones

(unidirectional push, unidirectional pull, synchronous bidirectionsl) by the fact that they involve more than one SOAP MEP.

I think we should mention this (this gives its meaning to "aggregate", as I believe that what is aggregated in order to create these new ebMS MEPs,

are SOAP MEP, not previous ebMS MEPs, see my point below).

6.4.1.
The sentence: "The following are possible combinations of the unidirectional and bidirectional patterns described earlier."

is probably not accurate, as unidirectional is no longer "unidirectional" if correlated with other messages (because then other

messages related to this one-way are "expected", even if they are not "responses"). Same for bidirectional: I think it is confusing

to say that an ebMS MEP can be composed of other ebMS MEPs. We don't need to assume this:
I think it is enough to just say that aggregates are patterns of  message exchanges correlated by RefToMessageId, and that they are DIFFERENT from the

bidirectional pattern (and from unidirectional of course). An "aggregate ebMS MEP" just aggregates several SOAP MEPs.

10.4:
I believe we also talked of "MSH status" in addition to Message status:
an MSH could be:
- not available (in which case it cannot even say so)
- available, but no outgoing messages (MSH cannot initiate the sending of messages: other parties need to pull.)
- available, but no incoming messages (MSH cannot accept external messages that it has not asked for:
it will pull them, and can send messages.)
Also, an availability status may be at ToParty level.

10.5.1:
split the 3rd bullet: "may contain To", and "may contain RefToMessageId" (does not hav eto be both)

10.6.4: (reliability of Pull): This section should also apply to the "Synchronous bidirectional MEP" (response leg)
Also, since we mention the PullAcknowledgement signal, we need to say that, in case a Response has been sent
but no Ack received, the Responder MUST (SHOULD?) notify a response delivery failure to its Consumer.