RE: [ebxml-msg] Edits in core WD16 to align with updates in Appendices.

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

 

From: Durand, Jacques R. 
[mailto:] 
Sent: Tuesday, January 23, 2007 5:19 
PM
To: 
Subject: [ebxml-msg] 
Edits in core WD16 to align with updates in Appendices.

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."