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