RE: [ebxml-msg] eb:RefToMessageId in one-way pull request responses

Indeed refToMessageId should not be used in User messages from One-Way MEPs as it is supposed to always refer to User messages, and One-Ways are by definition not referring to other MEP instances (though they could share a same conversation with other MEPs).

Now, I notice that unfortunately the examples of Pull responses in 3.2 and 3.3 of Core V3 spec, show responses with refToMessageId pointing at the PullRequest signal… that is a mistake. The normative text prevails on these examples… and indeed these responses could be signed independently from which MEP these messages will participate in, One-way Push or One-way Pull.

If it is a response in a Two-Way / Push –and-Pull, then the pulled response will have a RefToMessageId pointing at the Request User message (not at the PullRequest). In that case, the MSH sender of the response is supposed to know which User message it is a response to at the time it is packaging this response, and in that case it make sense to insert the RefToMessageId before signing.)

-jacques

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Makesh Rao (marao)
Sent: Monday, December 19, 2011 10:30 AM
To: Sander Fieten; Theo Kramer
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] eb:RefToMessageId in one-way pull request responses

Hi Sander

I’m not sure I understood your last paragraph on request-response. But in a business exchange, the party that “Pulls” the business data needs to be able to correlate the message with one that they sent out (our demo scenario #2 using one way Push & Pull). Don’t we need the refToMessageId in those cases ?

~Makesh

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Sander Fieten
Sent: Monday, December 19, 2011 1:01 AM
To: Theo Kramer
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] eb:RefToMessageId in one-way pull request responses

Hi Theo,

in One-Way MEPs, both Push and Pull, the eb:RefToMessageId is not relevant as the exchanged UserMessage is unrelated to earlier messages. If the UserMessage relates to an earlier message the MEP becomes a Two-Way MEP where the response must use the eb:RefToMessageId to indicate to which request it is the response to. So in a Two-Way/Push-and-Pull MEP the pulled message will contain a eb:RefToMessageId to the earlier pushed message.

If the exchanged business documents also contain information about the request-response sequence then ebMS One-Way MEPs can be used to exchange the documents without loosing the request-response relation [on the level of the business apps].

Regards

Sander

On 19 Dec 2011, at 09:11, Theo Kramer wrote:

The core spec, ebms-core-3.0-spec, shows clear examples of pull request responses containing an eb:RefToMessageId. However, in section 2.2.6 'The One-way/Pull MEP' states the following

'To conform to this MEP the pulled User Message unit MUST NOT include an eb:RefToMessageId element.'

In AS4 the support for MEP is one-way, with support for two-way MEPs being somewhat ambiguous.
Is eb:RefToMessageId relevant in the case of one-way MEPs ie. a one-way response need not be based on any previous business message ?

In the case of signed queued messages (awaiting a pull request) eb:RefToMessageId cannot be used as it will break the previous signature.

Our take on this is that 2.2.6 is correct for one-way MEPs.

Further thoughts/comments/clarification on this appreciated.

--
Regards
Theo

---------------------------------------------------------------------
To unsubscribe, e-mail: ebxml-msg-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ebxml-msg-help@lists.oasis-open.org

ebxml-msg message