Action 218 Update

Change from (proposed in http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0057.html ):

5.3 Subject Attachment Extensibility:

Overtime, a policy expression may evolve to be applicable to policy subjects different than the policy subjects that it was originally designed for. When this type of evolution occurs, the author of the assertion should carefully consider the applicability of this usage with respect to the compatibility of the assertion's semantics. When an assertion needs to evolve to indicate a behavior that is no longer compatible with its originally intended semantics or policy subjects, a new namespace should be designed to designate the new behavior that is signified with the new namespace. Section 5.2 further clarifies the usage of multiple behaviors. In general, it is NOT recommended to deprecate policy subjects by reducing the policy subjects that an assertion was originally designed for.

When the assertion's semantics does not change to invalidate any of the original policy subjects but new policy subjects need to be added, it may be possible to use the same assertion to designate the additional policy subjects without a namespace change. The authors must retain the compatible behavior of the policy assertion. For example, a policy assertion for a protocol that is originally designed for endpoint policy subject may add message policy subject to indicate finer granular attachment provided that endpoint policy subject is also retained in its design. This approach has been used by WS-RM Policy.

Change to:

Overtime, a policy expression may evolve to be applicable to policy subjects different than the policy subjects of which ~~that~~ it was originally designed ~~for~~. When this type of evolution occurs, the author of the assertion should carefully consider the applicability of this usage with respect to the compatibility of the assertion's semantics. When an assertion needs to evolve to indicate a behavior that is no longer compatible with its originally intended semantics or policy subjects, a new namespace is preferred~~should be designe~~d to designate the new behavior that is signified with thate new namespace. Section 5.2 further clarifies the usage of multiple behaviors. In general, the preferred option is not~~it is NOT recommended~~ to deprecate policy subjects by reducing the policy subjects of which ~~that~~ an assertion was originally designed ~~for.~~

When these conditions apply - the assertion's semantics does not change, ~~to invalidate any of~~ the original policy subjects still apply, and ~~but~~ new policy subjects need to be added, it may be possible to use the same assertion to designate the additional policy subjects without a namespace change. ~~The a~~Authors ~~must~~ are encouraged to retain the compatible behavior of the policy assertion. [M1] For example, a policy assertion for a protocol that is originally designed for endpoint policy subject may add message policy subject to indicate finer granular attachment provided that endpoint policy subject is also retained in its design. This approach has been used by WS-RM Policy.