ACTION: Charlton to write a categorized issues list for the WS-Policy LC review

As requested during the last telcon I've prepared a categorized issues list for the WS-Policy LC review: 

WS-Policy LC review
Editorial issues
Framework
1. No relationship to XML Base [1] is defined as of yet in Framework. As issue has been raised on this with the WG [2].
2. Policy Assertion (3.1)
- The definition of policy assertion appears to be redundant. 
- The style of artefact definition appears a bit cumbersome ("[Definition: An ignorable policy assertion is ...]"). As is these definitions appear to be placeholders. In their place text could be written that flows better, e.g. the second paragraph of 3.1 could be written as: "An assertion MAY indicate that it is an ignorable policy assertion (see 4.4 Ignorable Policy Assertions). An ignorable policy assertion is one that may be ignored for policy intersection (as defined in 4.5 Policy Intersection). By default, an assertion is not ignorable for policy intersection."
3. Policy Alternative (3.2)
- The definition of policy alternative needs some elaboration (e.g. "A policy alternative is a potentially empty collection of policy assertions which are used indicate an available set of behaviors."). As is it doesn't lay out well what alternatives actually are before delving into their semantics. The same approach can be applied to 3.3 Policy.
- It is suggested that "(i) Normal form of a policy expression (ii) Compact form of a policy expression (iii) Identification of policy expressions and (iv) Policy intersection" be reordered to read "(i) Normal form of a policy expression (ii) Identification of policy expressions (iii) Compact form of a policy expression and (iv) Policy intersection."
4. Policy Identification (4.1) 
- Some additional clarification may be needed around the use of xml:id in the Framework, as in associating a policy expression with the IRI-reference.
5. Compact Policy Expression
- Document Information Item should reference its definition in XML Infoset [3], as does Element Information Item [4].
6. Policy Assertion Nesting (4.3.2)
- A nested policy in normal form has the same structure as the enclosing policy. However, the example in this section does not reflect this. An issue has been raised with the WG and a resolution proposed [5]. 
7. Security Considerations (5)
- Policy/assertion "signing" is RECOMMENDED but there is no reference to what is indicated by "signing" or to any standards work (W3C or other) around any such signing. Does this refer to WSS signatures [6]? The use of "signing" itself in this language should reference any such standard(s). 

Attachments
8. Effective Policy (3.1)
- The second paragraph is very cumbersome. The first phrase in the first sentence should be broken out into its own sentence, to read, "When multiple attachments are made, their relevant policies can be combined."
- The third paragraph has the same problem. The first phrase in the first sentence should be broken out into its own sentence, to read, "This combination can be achieved through a merge."
9. XML Element Attachment (3.3)
- Element Information Item should reference its definition in XML Infoset [3].
10. Security Considerations (7)
- Policy attachments "signing" is RECOMMENDED but there is no reference to what is indicated by "signing" or to any standards work (W3C or other) around any such signing. Does this refer to WSS signatures [6]? The use of "signing" itself in this language should reference any such standard(s). 

Substantive Issues
Framework
11. Policy Intersection (4.5)
- There is a potential portability problem with intersection mode selection. While it makes sense for the mode selection specifics to lay outside of the Framework spec, it seems doing the same for mode indication leaves WS-Policy open to implementations where a provider requires one mode and a client may or may not interpret it, and may or may not support that same mode. 
The issue here is that without the specifying mode selection, a situation arises where an entities may not be able to complete intersection, if neither uses a compatible way of expressing intersection mode. 

Attachments
12. WS-Policy Attachment for WSDL 2.0 (5) 
- The lack of explicit mapping from "input"/"output" (as applied in Attaching Policies Using WSDL 1.1 (4)) to Interface Message or Fault References with {direction}="in" or "out" seems to provide for a complication with attaching policies using WSDL 2 [7]. This issue has been raised [8] and there is an action to provide a clear set of alternatives for resolving this [9]. 

Observations 
Framework
13.  WS-Policy's reliance on QNames for identifying assertions and their types may complicate their representation in RDF. 

Attachments
14. XML Namespaces (2.2)
- The wsdl20 namespace references that defined in the CR [10].
15. XML Element Attachment (3.3)
- The "template" for defining the semantics for processing policy elements is based on that of WSDL 1.1 elements as defined in the WS-Policy Attachments spec. However, this "template" is referenced as the RECOMMENDED approach in Attaching Policies Using WSDL 1.1 (4). 

[1] http://www.w3.org/TR/2001/REC-xmlbase-20010627/ 
[2] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0022.html 
[3] http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.document 
[4] http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.element 
[5] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0034.html 
[6] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf 
[7] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0059.html
[8] http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0001.html   
[9] http://www.w3.org/2007/01/10-ws-policy-minutes.html#action07
[10] http://www.w3.org/TR/2006/CR-wsdl20-20060327/ 

-Charlton.
--
charlton_b@mac.com
+1.650.222.6507 m
+1.415.692.5396 v

Received on Thursday, 11 January 2007 04:33:04 UTC