ACTION: Charlton to review WS-Policy LC

In fulfillment of my action item [1] I reviewed the WS-Policy LC [2] , [3] and have the following notes and comments:

Framework
* No relationship to XML Base [4] is defined as of yet in Framework. As issue has been raised on this with the WG [5].
* 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."
* 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. 
* Policy Expression (4)
- As WS-Policy is expressed through XML infosets, certain elements might be defined to mean "use this policy", but there are no explicit rules for doing as such. An explicit design around this would allow for policy designers to more easily share policies unambiguously.
- 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."
* 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.
* Compact Policy Expression
- Document Information Item should reference its definition in XML Infoset [6], as does Element Information Item [7].
* 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 [8]. 
* 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. This scenario breaks policy intersection altogether. 
* 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 [9]? The use of "signing" itself in this language should reference any such standard(s). 
* WS-Policy does not explicitly provide for abstract policies - analogous to abstract interfaces in programming languages, which provide the ability to define functionality and a data-based interface.
* WS-Policy's reliance on QNames for identifying assertions and their types may complicate their representation in RDF. 

Attachments
* XML Namespaces (2.2)
- The wsdl20 namespace references that defined in the CR [10].
* 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."
* 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). 
- Element Information Item should reference its definition in XML Infoset [7].
* Attaching Policies Using WSDL 1.1 (4)
- David Orchard has proposed an element identifier syntax for WSDL 1.1 elements [11]
- This proposal has addressed a number of issues such as identifier placement, a WSDL2 style canonical form definition [12], [13], and conformance to WSDL2 style extension syntax.
- There is ongoing concern [14] regarding the alignment of this work to WSDL 2 fragment identifiers, in particular to the labelling of fragment identifiers. Arthur has already commented on this [15].
* 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 [14]. 
* 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 [9]? The use of "signing" itself in this language should reference any such standard(s). 

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2006Nov/att-0136/20061130-ws-desc-minutes.html
[2] http://www.w3.org/TR/2006/WD-ws-policy-20061117/
[3] http://www.w3.org/TR/2006/WD-ws-policy-attach-20061117/ 
[4] http://www.w3.org/TR/2001/REC-xmlbase-20010627/
[5] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0022.html
[6] http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.document
[7] http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.element
[8] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0034.html
[9] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[10] http://www.w3.org/TR/2006/CR-wsdl20-20060327/
[11] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11elementidentifiers.html
[12] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0028.html
[13] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#component-designator-canonical-form
[14] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0059.html
[15] http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0060.html

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

Received on Thursday, 14 December 2006 14:58:35 UTC