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

Inline 
<JD>

 

-jacques

-----Original Message-----
From:  
[mailto:]
Sent: 
Tuesday, January 05, 2010 2:20 PM
To: 

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