Re: [Bug 4210] WSDL WG Editorial comments on Framework

Thanks for your comments. The WS-Policy Working Group tracked this as a Last Call Issue 4210 [1], [2].

The Working Group agreed to fix the problems as detailed in-line below [3].

Please let us know if you have any difficulty with these resolutions. .

[1] http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0098.html
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4210
[3] IRC Anchor:  http://www.w3.org/2007/01/16-ws-policy-irc#T18-46-44

On Saturday, January 13, 2007, at 12:10AM, "Paul Cotton" <Paul.Cotton@microsoft.com> wrote:
>
>
>-----Original Message-----
>From: public-ws-policy-qa-request@w3.org [mailto:public-ws-policy-qa-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
>Sent: January 12, 2007 6:56 PM
>To: public-ws-policy-qa@w3.org
>Subject: [Bug 4210] WSDL WG Editorial comments on Framework
>
>
>http://www.w3.org/Bugs/Public/show_bug.cgi?id=4210
>
>           Summary: WSDL WG Editorial comments on Framework
>           Product: WS-Policy
>           Version: LC
>          Platform: All
>        OS/Version: All
>            Status: NEW
>          Severity: minor
>          Priority: P2
>         Component: Framework
>        AssignedTo: fsasaki@w3.org
>        ReportedBy: jonathan@wso2.com
>         QAContact: public-ws-policy-qa@w3.org
>
>
>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].

[cbb] This has been addressed in the resolution to ISSUE 4039 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4039

>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."

[cbb] The WS-Policy WG notes that the text in WS-Policy Framework Sections 4.5 and 4.6 depends on this definition. The WG agreed to take no action on this.

>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.

[cbb] WS-Policy Framework says, "A policy alternative is a potentially empty collection
of policy assertions" and "A policy assertion represents an individual requirement, capability ..." The WG feels that this phrasing is equivalent, thus agreeing to take no action on this. 

>- 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."

[cbb] The WG noted that this sentence is a duplicate of the TOC and inconsistent with the
latest content in Section 4. The WG agreed to drop this sentence altogether.
http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0109.html (See Item 5) 

>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.

[cbb] The WG proposed http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0012 (related editors AI is http://www.w3.org/2005/06/tracker/wspolicyeds/actions/115) to resolve this issue. 

>5. Compact Policy Expression
>- Document Information Item should reference its definition in XML Infoset [3],
>as does Element Information Item [4].

[cbb] The WG proposed to make the following editorial changes to resolve this:
a) s/Start with the [document element] property D of the Document
Information Item/Start with the [document element] property D of the
Document Information Item (as defined in [XML Information Set])/
b) s/Expand Element Information Items in the [children] property of
D/Expand Element Information Items (as defined in [XML Information Set])
in the [children] property of D/
The WG agreed to adopt this resolution. 

>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].

[cbb] The WG adopted the resolution to this issue (4038) which is now in the latest version of the editors
draft (See http://tinyurl.com/yn8z4u) 

>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).

[cbb] The WG proposed to make the following editorial change to resolve this:
Replace: "It is RECOMMENDED that policies and assertions be signed to prevent tampering", 
the first sentence of Section 5 Security Considerations with: 
"It is RECOMMENDED that policies and assertions be integrity protected to permit the detection of tampering. This can be done by using a technology such as [XML D-Sig], [SSL/TLS], or [WS-Security 2004]. 
The WG agreed to adopt this resolution.

Received on Tuesday, 16 January 2007 20:24:30 UTC