FW: [Bug 4663] Example for Section 8

Scrapping Microsoft comments that are relevant to issue 4663 from the Action 316 mail thread (See http://lists.w3.org/Archives/Public/public-ws-policy/2007Jun/0052.html):

D) Section 8

12)
>The Guidance included in this document addresses both the design and
>the use of policy assertions.

'Guidelines for Policy Assertion Authors' - assertion authors would find it useful if the Guidelines doc illustrates how to design an assertion by answering the set of questions and applying best practices outlined in the document. Also, to avoid any duplicate work, illustrating how to use policy assertions should be delegated to the Primer.

E) Section 8.1

13)
>Parent Assertion
>The wsam:Addressing policy assertion is a nested policy container
>assertion ...

This appears to be a copy of Section 3 in the WS-Addressing Metadata specification (See http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070516/#indicatinguse). It is unclear why the WS-Policy WG should include and maintain a copy of another specification (Section 3 in the WS-Addressing Metadata specification) in the Guidelines document? We suggest using such materials by reference rather than copy by value.

Regards,

Asir S Vedamuthu
Microsoft Corporation


-----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: Monday, June 18, 2007 6:32 AM
To: public-ws-policy-qa@w3.org
Subject: [Bug 4663] Example for Section 8


http://www.w3.org/Bugs/Public/show_bug.cgi?id=4663

           Summary: Example for Section 8
           Product: WS-Policy
           Version: PR
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Guidelines
        AssignedTo: fsasaki@w3.org
        ReportedBy: mhondo@us.ibm.com
         QAContact: public-ws-policy-qa@w3.org


Title: Example based on WSA experience for Section 8
Target: Guidelines Section 8

Description: The current section 8 is supposed to include guidance for policy
assertion authors but it currently contains an example for policy expression
authors.

Based on the experiences between the WSA group and the WS-Policy group, I
propose that we add this as the "example" in section 8 and offer this as a
strawman.

------------------------------------------------------------------------------
<add>

During the course of the specification editing, review and testing, the working
group collected the previous set of Best Practices.

The Guidance included in this document addresses both the design and the use of
policy assertions.

As such this section contains two parts: the first a scenario representing a
new audience of assertion designers and the process of creating a set of
assertions ( drawn from the experiences of the addressing, security and
reliable messaging WG members who also participated in the policy WG) and the
second a scenario for a hypothetical company that is attempting to utilize the
assertions defined by the WS-Security, WS-Addressing and WS-Reliable Messaging
working groups.

8.1 Designing Assertions
The WS-Addressing group had several behaviors that they wanted to express using
the WS-Policy Framework.  They wanted to indicate at a general level that an
entity implemented the WS-Addressing specification. Within the specification it
was possible for implementers to chose whether they supported anonymous
responses or non-anonymous responses in the context of a message exchange
patterns.

The authors chose to represent the behaviors through defining 3 assertions for
WS-Addressing; one parent assertion and two nested assertions.  The "parent"
assertion indicates that both forms of responses are supported.  If the parent
assertion is qualified with a nested assertion, "non-anonymous" then it
indicates that only that behavior is supported.
Parent Assertion
The wsam:Addressing policy assertion is a nested policy container assertion.
The meaning of this assertion, when present in a policy alternative, is that
WS-Addressing is required to communicate with the subject. The wsam:Addressing
assertion indicates that there are no restrictions on the use of WS-Addressing
unless otherwise qualified by assertions in its nested policy expression. In
order to indicate that the subject supports WS-Addressing but does not require
its use, an additional policy alternative should be provided which does not
contain this assertion. This may be done in WS-Policy compact form by adding
the attribute wsp:Optional="true" to the wsam:Addressing assertion.

Nested AnonymousResponses Assertion
The wsam:AnonymousResponses element MAY be used as a policy assertion nested
within the wsam:Addressing assertion in accordance with the rules laid down by
policy assertion nesting ([WS Policy 1.5], section 4.3.2).
The appearance of this element within the wsam:Addressing policy assertion
indicates that the endpoint requires request messages to use response endpoint
EPRs that contain the anonymous URI
("http://www.w3.org/2005/08/addressing/anonymous") as the value of [address].
In other words, the endpoint requires the use of anonymous responses.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the
value of [address] in place of the anonymous URI; this value MUST be accepted.
Nested NonAnonymousResponses Assertion
The wsam:NonAnonymousResponses element MAY be used as a policy assertion nested
within the Addressing assertion in accordance with the rules laid down by
policy assertion nesting ([WS Policy 1.5], section 4.3.2). The
wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy
alternative as the wsam:AnonymousResponses policy assertion.
The appearance of this element within the wsam:Addressing assertion indicates
that the endpoint expresses requires request messages to use response endpoint
EPRs that contain something other than the anonymous URI as the value of
[address]. In other words, the endpoint requires the use of non-anonymous
responses. This assertion is deliberately vague; its presence indicates that
some non-anonymous addresses will be accepted but doesn't constrain what such
an address might look like. A receiver can still reject a request that contains
an address that it doesn't understand or that requires a binding it doesn't
support.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the
value of [address] in place of a non-anonymous address; this value MUST be
accepted.

Example 3-1. Subject supports WS-Addressing
<wsp:Policy>
    <wsam:Addressing wsp:Optional="true">
        <wsp:Policy/>
    </wsam:Addressing>
</wsp:Policy>
Example 3-2. Subject requires WS-Addressing
<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy/>
    </wsam:Addressing>
</wsp:Policy>
Example 3-3. Subject requires WS-Addressing and requires the use of
non-anonymous response EPRs
<wsp:Policy>
    <wsam:Addressing>
        <wsp:Policy>
            <wsam:NonAnonymousResponses/>
        </wsp:Policy>
    </wsam:Addressing>
</wsp:Policy>

Received on Saturday, 23 June 2007 01:27:30 UTC