Update based on previous comments, and use
case where P-Mode could be hardcoded in some
light implementation:
L566-568:
replace:
"Although a standard representation of P-Mode data is out of scope of
this specification, an abstract definition of it helps to capture some aspect of
the messaging that are not directly tied to the protocol, such as the notion of
default behavior and some errors of contractual nature."
with:
"A data model for P-Modes is described in Appendix D.
Although this specification does not require support for any
particular representation of P-Mode, a
conformance profile for this specification may require support for a particular
representation. An MSH
MUST conform the processing of its
messages to the values in the P-Mode associated with this message. The details of
which P-Mode parameters must be supported by an implementation, is governed by
the features associated with the conformance profile claimed by this
implementation, i.e. by its profile feature set (see Appendix F on Conformance).
An MSH MUST NOT process to normal completion a message that has no matching
P-Mode in its P-Mode operation set - i.e. not deliver it when in Receiving
role, or not sending it when in Sending role. When it cannot match
a message to a P-Mode, an MSH MUST generate a ProcessingModeMismatch
(EBMS:0010) error."
-Jacques
Here are some needed
updates in the core spec, that are related to latest updates
in:
(1) P-Mode appendix
updates, (Editorial clarifications, and also clarification as
what exactly is required for an MSH to support
P-Modes...)
(2)
WS-ReliableMessaging appendix (need to remove any mention that DAs are out of
scope of WS-RM)
NOTE: it seems that
the line numbers in PDF WD16 are inconsistent, and are often repeated in the
same paragraph...
-Jacques
-------------
updates related to (1):
L567 (section 4):
remove:
"The set of all P-Modes that an MSH has been configured to support, is
called the P-Mode set of the MSH."
L570: Add after
"...the Security header.":
"The set of all P-Modes that
are supported by an MSH during operation, is called the P-Mode operation
set of the MSH."
L566-568:
replace:
"Although a standard representation of P-Mode data is out of scope of this
specification, an abstract definition of it helps to capture some aspect of the
messaging that are not directly tied to the protocol, such as the notion of
default behavior and some errors of contractual
nature."
with:
"A data model for
P-Modes is described in Appendix D. Although this specification does not require
support for any particular representation of P-Mode, it requires an
MSH implementation to understand at least one representation that conforms
to this data model and is human-readable. An MSH MUST be able to control the
processing of its messages based on this P-Mode representation. The details of
which P-Mode parameters must be supported by an implementation, is governed by
the features associated with the conformance profile claimed by this
implementation, i.e. by its profile feature set (see Appendix F on Conformance).
An MSH MUST NOT process to normal completion a message that has no matching
P-Mode in its P-Mode operation set - i.e. not deliver it when in Receiving
role, or not sending it when in Sending role. When it cannot match
a message to a P-Mode, an MSH MUST generate a ProcessingModeMismatch
(EBMS:0010) error."
L599:
replace:
"Agreeing on a P-Mode set..."
with
"Agreeing on a P-Mode operation
set..."
-------------
updates related to (2):
L2261: (in E.2.3.1
Rule CM3-a "Acknowledgments", p.92)
insert at the end of
E.2.3.2:
"The delivery
failure notification in V2 (always required for non-acknowledged
messages) is supported by WS-Reliability and therefore by V3 using
WS-Reliability. Such failure notification is not explicitly mandated by
WS-ReliableMessaging, or could take place on either side. In order to achieve
the same notification policy as in V2, when used in V3 an implementation of
WS-ReliableMessaging must be extended with the same notification
capability."
L2269: (in E.2.3.3,
rule CM3-c , p.93)
remove:
"There is no specification of duplicate elimination in
WS-ReliableMessaging (delivery assurance out-of-scope), but the ebMS binding to
WS-ReliableMessaging requires an extension supporting this feature (see Section
B.2 for required extensions)."
replace
with:
"It maps to the
AtMostOnce delivery assurance definition in WS-ReliableMessaging, assuming an
implementation of WS-ReliableMessaging that supports this delivery
assurance."
L2271: Just after
E.2.3.3: the Rule CM3-d should be a title numbered E.2.3.4, instead it is
just formatted as text and appears to be under
E.2.3.3.
L2274: in E.2.3.4
(rule CM3-e)
remove:
"There is no specification of ordered delivery in WS-ReliableMessaging
(delivery assurance out-of-scope), but the ebMS binding to WS-ReliableMessaging
requires an extension supporting this feature (see Section B.2 for required
extensions)."
replace
with:
"The
feature maps to the InOrder delivery assurance definition in
WS-ReliableMessaging, assuming an implementation
of WS-ReliableMessaging that supports this delivery
assurance."