This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
title: Guidelines for Policy Attachment Target: Guidelines Description: The current section on guidelines for Policy Attachment is only for WSDL. Proposal: this proposal has 4 parts: part 1 -- ---------- <change> title of section 5.7 from 5.7 Considerations for Policy Attachment for WSDL to 5.7 Considerations for Policy Attachment ------------------ part 2 -- ---------- <add> new text & best practice The Policy attachment mechanism used to communicate the policy assertions should not affect or imply additional semantics in the interpretation of Policy alternatives. If it did, each policy assertion would need to be written with different (and possibly unknown) attachment mechanisms in mind. Assertion authors are encouraged to use the policy subjects defined by the policy attachments specification when possible. Policy assertion authors should unambiguously identify the appropriate policy subjects for their assertions. If the best practices are followed, and the assertions are scoped according to their subject, then multiple policy domains may be combined without conflict. Each domain should define any limitations at the policy subject level that might impact interoperability. Best Practice: Preserve Context-Free Policies ------------------ part 3 -- ---------- <add> example for Best practice 24: Specify Preferred Attachment Point for an Assertion ------- An example of this is the Reliable Messaging Policy Assertion document. In section 2.5.1 Sequence STR Assertion, the authors "The STR assertion defines the requirement that an RM Sequence MUST be bound to an explicit token that is referenced from a wsse:SecurityTokenReference in the CreateSequence message. This assertion MUST apply to [Endpoint Policy Subject]. This assertion MUST NOT be used for an endpoint that does not also use the RM assertion". ------------------ part 4 -- ---------- <add> new subsection-title (leave existing text as is) 5.7.1 Considerations for Policy Attachment for WSDL
See http://www.w3.org/2007/07/18-ws-policy-irc#T09-34-40 RESOLUTION: issue 4654 closed by adopting maryann's section 5.7.1 in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0030.html (pdf) http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0024.html (doc) [05:31] pbc: Possible additional work: [05:32] pbc: 1. How to make existing WSDL section more specific to just WSDL [05:32] cferris: RESOLUTION: issue 4654 closed by adopting maryann's section 5.7.1 in http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0030.html [05:32] pbc: 2. Determine which existing BP in existing WSDL section should be made generic [05:32] pbc: 3. Determine if the WSDL section should handle WSDL 1.1 and WSDL 2.0 separately [05:32] cferris: rrsagent, where am i? [05:32] RRSAgent: See http://www.w3.org/2007/07/18-ws-policy-irc#T09-34-40 [05:33] pbc: 4. Determine if attachment terminology is used consistently in new General Guidelines section and the existing WSDL section [05:33] *** maryann has joined #ws-policy. [05:33] charlton: http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0030.html (pdf) [05:34] charlton: http://lists.w3.org/Archives/Public/public-ws-policy/2007Jul/0024.html (doc) [05:34] pbc: 5. Determine if any other specific sections are required for other attachment possibilities like UDDI [05:35] pbc: 6. Can the BP in the WSDL section (or new section) be linked back to the generic versions in the General Guidelines section?