Re: [ws-tx] Re: Groups - New Action Item #0057 Review use of RFC 2119keywords ...

[Andrew Wilkinson3 <awilkinson@uk.ibm.com>]

Hi Monica,

In my opinion both specs are right in what they state. WS-C is rightly 
being as non-prescriptive as possible as to the location of a 
CoordinationContext in a SOAP message thereby allowing extending specs 
freedom to place the CoordinationContext where they choose. Both AT and BA 
have then chosen to constrain this to the SOAP header making it easier to 
produce an interoperable implementation as we only need to look in one 
place for the CoordinationContext, i.e. the SOAP header.

I agree that there should be consistency between the AT and BA specs in 
this regard (which we currently have) and if this restriction is indeed 
the intention of the two specs then it would probably be appropriate to 
highlight the point more prominently, e.g. section 2, rather than it only 
being mentioned as part of the discussion of policy assertions.

Thanks,
Andy




"Monica J. Martin" <Monica.Martin@Sun.COM> 
Sent by: Monica.Martin@Sun.COM
26/10/2006 17:45

To
Andrew Wilkinson3/UK/IBM@IBMGB, "ws-tx@lists.oasis-open.org" 
<ws-tx@lists.oasis-open.org>
cc
Thomas Freund <tjfreund@us.ibm.com>, Ram Jeyaraman 
<Ram.Jeyaraman@microsoft.com>
Subject
Re: [ws-tx] Re: Groups - New Action Item #0057 Review use of RFC 2119 
keywords ...






Andrew,
In reviewing the proposed changes [1], we noted an inconsistency between 
WS-C and WS-AT. Note, the same inconsistency exists between WS-C and 
WS-BA. To explain, the TC previously discussed the use of SOAP headers 
[2] with respect to CoordinationContext.  Reference text in the three 
specifications:

   * WS-C, Section 2:

       "CoordinationContext elements are propagated to parties which
       may need to register Participants for the activity, using
       application-defined mechanisms -- e.g. as a header element of a
       SOAP application message sent to such parties. (Conveying a
       context in an application message is commonly referred to as
       flowing the context.)...When an application propagates an
       activity using a coordination service, applications MUST include
       a Coordination context in the message. When a context is
       exchanged as a SOAP header, the mustUnderstand attribute MUST be
       present and its value MUST be true."

   * WS-AT, Section 4.2:

       "The transaction MUST be represented as a SOAP header in
       CoordinationContext format, as defined in WS-Coordination 
[WSCOOR]."

   * WS-BA, Section 4.2:

       "The transaction MUST be represented as a SOAP header in
       CoordinationContext format, as defined in WS-Coordination 
[WSCOOR]."

WS-C allows application-defined means such as a SOAP header to be used 
to exchange this context. There, use of a SOAP header is only one 
application specific means. In WS-C, the constraint is that if a context 
is exchanged by such means, it must be understood. As evidenced in the 
references above, the statements in WS-AT (and WS-BA) are inconsistent 
with this premise.

Summary: WS-AT and WS-BA are introducing an additional constraint that a 
SOAP Header MUST be used to propagate CoordinationContext format that 
does not exist in WS-C. Suggest these three references be discussed and 
corrected to ensure our intent is clear (and consistent). Thank you.

Joe Fialli
Monica J. Martin

[1] Note, this relates to Actions #56-58, and these links.
http://lists.oasis-open.org/archives/ws-tx/200610/msg00037.html
http://lists.oasis-open.org/archives/ws-tx/200610/msg00052.html
Your response: 
http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00063.html 


[2] http://docs.oasis-open.org/ws-tx/issues/WSTransactionIssues.xml#i012

> Andrew Wilkinson3 wrote:  All,
> Please find attached the proposed RFC 2119 keyword updates for PR-01 
> of the AT spec. The changes incorporate those proposed by Ram[1] and 
> Ian[2] with the exception of line 242 where Ram had proposed MAY but I 
> believe MUST is more appropriate.
>
> Comments welcome.