RE: [ebxml-msg] Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features (v46) (ebMS3-part2-V48.odt) uploaded

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

Inline <JD>

 

-jacques

-----Original Message-----
From: sander@fieten-it.com [mailto:sander@fieten-it.com]
Sent: Tuesday, January 05, 2010 2:20 PM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features (v46) (ebMS3-part2-V48.odt) uploaded

I've updated section 2.8, mostly on formatting. While editing I came accross the following issues which I also have added notes for in the document.

The new PMode parameter does not define parameters for all child elements of RoutingInput. How are these values set? Outside scope of PMode configuration? Might be okay, but should be described (imo).

<JD> Maybe we should not require the child element of ebint:RoutingInput to be named ebint:UserMessage. This is a bit confusing as non-user messages can be routed too. Also, we explain that in fact this child element does not have same namespace as the regular eb:UserMessage, due to more optional content... So instead we could stick to exactly what the Pmode parameter EPR.RoutingInput contains, which is a subset of UserMessage (excluding ConversationId and the like).

The second note on the definition of the EPR parameter states the requirement that RoutingInput.Initiator must be equal to PMode.Initiator.
But the EPR parameter may occur in several places in the PMode. I would expect that this requirement only applies to Pmode.{Initiator,Responder}.EPR and not for other EPR's. Because for response one might want to use different values than the original.

 

<JD> Agree.

If this is a general requirement, then why add these parameters instead of requiring to use the values from Pmode.{Initiatior, Responder}?

The intention of the third note is not clear to me.
It seems to suggest that EPR.BusinessInfo.{Service, Action, Properties, MPC} may contain multiple values.
I assume however that only one value is allowed and the intention of this paragraph is to say that multiple EPR parameter may point to the same ebMS endpoint.

<JD> We should reword this paragraph. The idea was that the iCloud routing function may know of only one Service/Action pair, even if there are many of these that are associated with an endpoint. In such a case the EPR.RoutingInput should use the routing-aware Service/Action even if it belongs to a PMode that relates to a different Service/Action. We may not need to allow several EPR.BusinessInfo children for this.

I think addresses referred to in the first note on PMode.Initiator.EPR have different semantics:
PMode[].Protocol.Address is the URI of the Receiver MSH.
Pmode.Initiator.EPR.Address is the URI that identifies the WS-A EPR that represents the MSH of the Initiator.
Therefor the EPR.Address and Protocol.Address should be different with the Protocol.Address identifying the MSH the message will be sent to.

<JD> Agree, as specified in 2.8.3: in a multi-hop envt, PMode[].Protocol.Address  should become the address of the first intermediary, while EPR.Address is the iCloud address.. The first note of 2.8.1.2 should be modified and reinforce this distinction instead of conflicting these parameters.

 

This of course could be an intermediary, in which case the EPR.Address is http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/part2/200811/icloud
The AcksTo.EPR and AcksTo parametes are also used in this way.

The wsa:To header is not used by the routing function, so option (2) described in the second note on PMode.Initiator.EPR is not supported by this spec.

Why is there no default EPR for
Pmode[1].Reliability.AtLeastOnce.Contract.AcksTo.EPR?

Section 2.8.2 on the migrating from point-to-point to multi-hop seems to suggest that minimal changes are required. But what about the EPR PMode parameters that may be needed?

Regards,
Sander

 -- Mr. Sander Fieten

The document revision named OASIS ebXML Messaging Services Version 3.0:
Part 2, Advanced Features (v46) (ebMS3-part2-V48.odt) has been submitted by Mr. Sander Fieten to the OASIS ebXML Messaging Services TC document repository.  This document is revision #18 of ebMS3-part2-V32-JD.odt.

Document Description:




View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=35776

Download Document: 
http://www.oasis-open.org/committees/download.php/35776/ebMS3-part2-V48.odt

Revision:
This document is revision #18 of ebMS3-part2-V32-JD.odt.  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