OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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:JDurand@us.fujitsu.com]
Sent: Tuesday, January 23, 2007 5:19 PM
To: ebxml-msg@lists.oasis-open.org
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."
 
 
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]