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