[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion
Paul Fremantle wrote: > Tom > > Two questions: > > 1) Does this imply that to support MakeConnection REQUIRES the > endpoint to support and publish WS-Policy? NO, however if you do support and publish ws-policy on an endpoint, then you have to assert MakeConnection in that policy statement to use MakeConnection to send messaged from that endpoint. > > 2) Do you consider this a substantive change to the spec requiring > another PR? NO > > Paul > > Tom Rutt wrote: >> I just posted a PR comment on MakeConnection Policy Assertion not >> stating a requirement. >> >> I copy it here to this list as well: the following is the text I >> posted to ws-rx-comment@lists.oasis-open.org >> ------ >> Public Review Issue: >> Title: MakeConnection Policy assertion is not a Requirement. >> >> Target: Web Services Make Connection v1.0 >> http://www.oasis-open.org/apps/org/workgroup/ws- >> rx/download.php/22238/wsmc-1.0-spec-cd-05.pdf >> >> Rationale: >> >> The W3C WS-Policy working group has reviewed the WS-Addressing Metadata >> CR Specification ( http://www.w3.org/TR/2007/WD-ws-addr-metadata- >> 20070202/ ., and has sent a comment suggesting changes to the >> definitions of the AnonymousReplies, and NonAnonymousReplies nested >> policy assertions. The recommendations and rationale for this comment >> are in the email: http://lists.w3.org/Archives/Public/public-ws- >> policy/2007Feb/0140.html . >> >> It is pointed by the WS-Policy WG that these assertions are not >> expressed as requirements, which causes problems in their application >> within the policy intersection algorithm. >> >> It is recommended that these assertion definitions be changed as >> requirements within the scope of a single response message originating >> from the endpoint to which the policy is attached. Policy statements >> can be formed which state that one of a set of response types must be >> used to deliver reply messages. >> >> For example, assuming the two nested assertion types are changed to be >> requirements applying to instances of replies from an endpoint, the >> following policy expression states that either wsa:AnonymousReplies or >> wsa:NonAnonymousReplies are required to be used for sending replies from >> the endpoint to which this expression is attached:. >> >> <wsam:Addressing> >> <wsp:Policy> >> <wsp:ExactlyOne> >> <wsp:All> <!-- either anon and non-anon responses required--> >> <wsam:AnonymousResponses/> >> </wsp:All> >> <wsp:All> >> <wsam:NonanonymousResponses/> >> <wsp:All> >> </wsp:ExactlyOne> >> </wsp:Policy> >> </wsam:Addressing> >> >> It is necessary to clarify that the scope of the assertion applies to a >> single instance of an MEP, not to all instances of MEPs associated with >> the endpoint,. to allow the client to choose for each message exchange >> the appropriate type of response. >> >> For the same reasons, the MakeConnection policy assertion definition >> needs to be changed to be a requirement pertaining to instances of >> response messaged send from an endpoint. >> >> This does not cause problems of composition with ws addressing, as the >> following example demonstrates. >> >> Assuming the nested ws addressing assertions and the makeConnection >> assertion are changed to be defined as requirements on instances of >> response messages sent from an endpoint, the following policy expression >> states that either the wsa:AnonymousReplies or the >> wsa:NonAnonymousReplies or the wsmc:MakeConnection mechanism is required >> to be used for sending replies from the endpoint to which this >> expression is attached: >> >> <wsp:Policy> >> <wsp:ExactlyOne> >> <wsp:All> >> <wsam:Addressing> >> <wsp:Policy> >> <wsp:ExactlyOne> >> <wsp:All> <!-- anon or non-anon responses required--> >> <wsam:AnonymousResponses/> >> </wsp:All> >> <wsp:All> >> <wsam:NonanonymousResponses/> >> <wsp:All> >> </wsp:ExactlyOne> >> </wsp:Policy> >> </wsam:Addressing> >> <wsp:All> >> <wsp:All> <! Addressing required, usemakeConnection for reply --> >> <wsam:Addressing> >> <wsmc:MakeConnection> >> <wsp:All> >> </wsp:ExactlyOne> >> <wsp:Policy> >> >> Stated in words, this endpoint requires that responses must be sent >> either as NonAnonymousReplies, or as wsa:Anonymous replies, or as a >> wsmc:MakeConnection reply. >> >> Proposed Resolution: >> >> In Clause 3.4 MakeConnection: >> >> Change lines 327 – 329 from: >> “ >> The MakeConnection policy assertion indicates that the MakeConnection >> protocol (operation and the use of the MakeConnection URI template in >> EndpointReferences) is supported. This assertion has Endpoint Policy >> Subject [WS-PolicyAttachment]. >> “ >> To >> “ >> The MakeConnection policy assertion indicates that the MakeConnection >> protocol (operation and the use of the MakeConnection URI template in >> EndpointReferences) is required for instances of replies. This >> assertion has Endpoint Policy Subject [WS-PolicyAttachment]. >> “ >> >> Change line 334 from: >> “ >> A policy assertion that specifies that the MakeConnection protocol is >> supported. >> “ >> To >> “ >> A policy assertion that specifies that the MakeConnection protocol is >> required for instances of replies from an endpoint. >> “ >> >> Delete the following lines 341 – 343: >> “ >> Because this policy assertion expresses a capability of a receiver >> (rather than a requirement sender), care should be taken to ensure that >> it is decorated with the appropriate WS-Policy indicate that use, >> support and understanding, of this assertion is optional to the sender. >> “ >> > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]