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