New Issue: Update SP per Policy 1.5 guidelines

[Marc Goodner <mgoodner@microsoft.com>]

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.  

The issues coordinators will notify the list when that has occurred.

Title: Update SP per Policy 1.5 guidelines

Protocol:  ws-sp

Artifact:  spec 

Type: editorial

Description: 

I’ve reviewed the Policy 1.5 guidelines doc and in general didn’t find much, see attached. The one thing we didn’t do was handle in prose what to do for wsp:Ignorable according to guidelines 9 (describe in prose) and 10 (describe in XML). In many instances we’ve handled the XML job already. The instances where it isn’t handled is where there is attribute extensibility, say for wsp:Optional, which would incorrectly permit the use of wsp:Ignorable. So we can pull SP into shape from the guidelines perspective by adding prose that it isn’t allowed. For RM that would be a specific statement for the only assertion that allows attribute extensibility, for SP it would be a global statement up front. My suggested text follows.

 

Proposal:

Add the following statement to the end of section 2.1

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html  

 

Assertions defined by this specification MUST NOT include the wsp:Ignorable attribute in its attributes with a value of true.

Title: SP Policy Guidelines analysis

SP Policy Guidelines analysis

Best Practices	Apply to SP?	SP follow practice?	Comments
1. Semantics Independent of Attachment Mechanisms	Y	Y
2. Define assertions relevant to compatibility tests	Y	Y
3. Mark Ignorable Assertions not related to compatibility	N
4. Semantics Independent of the Form	Y	Y	SP used in example
5. Start with a Simple Assertion	Y	Y	SP cited example
6. Use Unique QNames	Y	Y	SP used in example
7. Provide an XML definition	Y	Y
8. Specify Semantics Clearly	Y	Y
9. Document Ignorable Behavior	Y	N	Use of wsp:Ignorable not specified in SP
10. Document Use of the Ignorable Attribute in XML	Y	N	Needs to be documented in prose where not allowed but schema might permit it via extensibility.
11. Assertion Authors should allow use of wsp:Optional	Y	Y
12. Define message format only	Y	Y
13. Avoid Duplication of Assertions	Y	Y
14. Use Parameters for Useful Information	Y	Y	SP used in example
15. Use Nested Assertions for Dependent Behaviors	Y	Y
16. Enumerate Nested Assertions	Y	Y
17. Discourage Domain Specific Intersection	Y	Y	SP cited example, used to explain.
18. Limit use of Optional Assertions	Y	Y
19. Consider entire message exchange pattern when specifying Assertions that may be optional	Y	Y
20. Indicate use of an Optional Assertion	Y	Y
21. Reusable Assertions	Y	Y	Uncited reference to SP
22. Describe Semantics of Multiple Assertions of Same Type	Y	Y	See SP section 4 as example, treat as union
23. Leverage Defined Attachment Mechanisms	Y	Y
24. Use Defined Policy Subjects	Y	Y
25. Identify Policy Subjects	Y	Y
26. Specify WSDL Policy Subject(s)	Y	Y	See SP section 3.2
27. Consider Scope of Attachment Points	Y	Y
28. Choose the Most Granular WSDL Policy Subject	Y	Y
29. Define Rules for Attachment of an Assertion type to Multiple WSDL policy subjects	Y	Y	See SP Appendix A
30. Specify Preferred WSDL Attachment Point	Y	Y	SP cited example.
31. Use defined tModels when appropriate	N
32. Specify Composition with Related Assertions	N		RM defines relation to SP, not visa versa
33. Independent Assertions for Different Versions of a Behavior	Y	Y	SP cited example
34. Document changes to policy subject	N