Action-316 (was RE: Strawman for AI 286, 303, 305, 313

>Action-316: [and other WG members] to respond with
>comments to Maryann on proposal in June msg 33

Here are our comments on the omnibus proposal attached in

Items 1) through 11) below are technical comments. Items 12) and 13) are high level comments.

A. Section 5.4.2

>In particular, when assertion authors define nested
>assertions, it is important that the semantic of an
>empty policy element be defined.

Cannot understand why assertion authors should define the semantics of an empty policy element. Not aware of any domain that defined the semantics of an empty policy element. <Policy/> is a policy with one policy alternative that has no behaviors specified (0 assertions).

We think that you meant - "In particular, when assertion authors define nested assertions, it is important to also define the semantics of the parent assertion when it is not qualified by any nested assertions." If so, then you should say that instead.

>In the example above, the first alternative vocabulary
>(V1) indicates that the full WS-Addressing spec is supported.

To resolve issue 4544, the Working Group dropped all the vocabulary related definitions. To avoid confusion, we suggest not to use the term vocabulary.

B. Section 5.5.1

Note: there is an editorial note in Section 5.5.1 - "Looks incomplete - carries Good Practices but there isn't any explanatory text." Does the omnibus proposal resolve the editorial note in Section 5.5.1?

>At a minimum, assertion authors need to document the
>semantics of the assertions [Best Practice 2] and
>included in that definition should be some indication
>about any impact of the assertion behavior at intersection

Cannot understand what does it mean to say "assertion behavior at intersection".

As you know, the behavior indicated by an assertion plays no role in the policy intersection.

The assertion description may define domain specific intersection rules. However, this is not in the minimum to define an assertion.

>When policy expression authors include assertions
>in service policies

We think you meant "policy expressions" instead of "service policies".

>Ignorable behaviors indicate behavior at the time of intersection.

A policy assertion (ignorable or not) indicates a behavior of a policy subject. It is unclear what does it mean to say "behavior at the time of intersection".

>Assertion authors should indicate the semantic of the
>runtime behavior in the description of the assertion
>that allows the ignorable attribute.

Regardless of ignorable or not, we think that an assertion author should clearly and completely specify the semantics of a policy assertion.

>In the case where one party chooses to engage in
>runtime behavior with another party based on alternatives
>from a lax mode intersection algorithm, the runtime behavior
>is out of scope of the policy framework.

Regardless of the chosen mode for policy intersection, any runtime behavior is always out of scope for the policy framework.

C) Section 5.7

>Best Practice:  Preserve Context-Free Policies

That sounds like a bumper sticker. What is the best practice? Where is the one line description of the best practice? Who should follow this best practice?

>Best Practice: Identify Assertion Subjects

That sounds like a bumper sticker. What is the best practice? Where is the one line description of the best practice? Who should follow this best practice?

>Each domain should define any limitations at the
>policy subject level that might impact interoperability
>(i.e. WS-SecurityPolicy - binding abstraction to group
>capabilities per message exchange)

It is unclear what limitations should be defined or documented by a domain. Perhaps, 'limitation' may not be right word.

>Best Practice: Identify any Interaction between subjects

That sounds like a bumper sticker. What is the best practice? Where is the one line description of the best practice? Who should follow this best practice?

D) Section 8

>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

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

We hope this helps.


Asir S Vedamuthu
Microsoft Corporation

From: [] On Behalf Of Maryann Hondo
Sent: Tuesday, June 12, 2007 3:30 PM
Subject: Strawman for AI 286, 303, 305, 313


I've had several AI's for the Guidelines document, and I have created a strawman for addressing them.
I've created a diff doc against the latest version of the Guidelines document to address the following:

AI 286 - There has been an ongoing action to deal with the Guidelines document with regard to things we
have learned from the WS-Addressing groups efforts to create new assertions.

        Monica had floated several proposals dealing with context and vocabulary.
        I tried to incorporate this input into the sections 5.4.2 "Nested Assertions" and Section 8 "Designing Assertions".
        I may not have captured all the text, but I thought I'd tee this up for discussion

AI 303 - propose "bumper sticker text"

        This one came up at the F2F where we were discussing changes to BP 7.

        This may seem like a radical change, but when I looked at the table of Best Practices, I couldn't really relate
        to this list.  It seemed very inconsistent in its "guidance".  I looked at other BP docs at the W3C and used the
        I18N one as an example.

        I took the model of having each item  be
                "Best Practice # - <statement> "
        I think its now more of a clear "should" or "action" statement ( but am always open to friendly amendments)

AI 305- Generalize Best Practice for XML outline

        I moved a bunch of things around trying to "group" all the best practices that deal with the XML outline section
        and I included an example from the Reliable exchange document.

        In doing this I also restructured the "ignorable" and "optional" sections to remove the "general guidance" on
        defining the attributes ( since this is now in the "general" section) and tried to add text to make the sections
        be more in parallel.

AI 313 - Bug 3978---- Section 7

        I still think the Best Practices text in this section should be included.  But I think it was in the wrong place.
        So I propose moving it to Section  5.7 and propose rewording this to be Best Practices for Policy Attachment.
        Then have a "general" section, and then have a section for "WSDL" specific Best practices.


Received on Friday, 15 June 2007 21:12:40 UTC