W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > November 2006

Re: Action-90 Review

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Thu, 30 Nov 2006 14:10:53 -0500
Message-Id: <981530D8-1AEE-456E-9909-E6F01B4F8F0A@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "ext Asir Vedamuthu" <asirveda@microsoft.com>, public-ws-policy-eds@w3.org, public-ws-policy-eds-request@w3.org
To: "ext Maryann Hondo" <mhondo@us.ibm.com>

Sorry, I should have been clearer - the text has not changed at all,  
but shows in the diff since I changed it to have two bullets, rather  
than inline, to match the previous style.

regards, Frederick

Frederick Hirsch
Nokia


On Nov 30, 2006, at 1:29 PM, ext Maryann Hondo wrote:

>
> ok,
> I guess i'm getting confused with the way the diffs show the changes.
> it looks like its new text.
>
> Maryann
>
>
> Frederick Hirsch <frederick.hirsch@nokia.com>
> Sent by: public-ws-policy-eds-request@w3.org
> 11/30/2006 11:01 AM
>
> To
> Maryann Hondo/Austin/IBM@IBMUS
> cc
> Frederick Hirsch <frederick.hirsch@nokia.com>, "ext Asir Vedamuthu"  
> <asirveda@microsoft.com>, public-ws-policy-eds@w3.org, public-ws- 
> policy-eds-request@w3.org
> Subject
> Re: Action-90 Review
>
>
>
>
>
>
> I think you should raise this as a guidelines issue, unless it is a
> question about the editorial changes I made.
>
> I also have a few issues about the guidelines content to raise but
> that should not hold up getting the document out.
>
> If this is a generic issue I think it should be logged as an issue to
> the Policy work group.
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
> On Nov 30, 2006, at 8:31 AM, ext Maryann Hondo wrote:
>
> >
> > Frederick,
> >
> > In general the edits look good.
> > I have some questions about  the following section[4.4.3
> > Considerations for choosing parameters vs nesting]:
> >
> > Are these assertions designed for the same policy subject?
> > Do these assertions represent dependent behaviors?
> > If the answers are yes to both of these questions then leveraging
> > nested policy expressions is something to consider. Keep in mind
> > that a nested policy expression participates in the policy
> > intersection algorithm. If a requester uses policy intersection to
> > select a compatible policy alternative then the assertions in a
> > nested policy expression play a first class role in the outcome.
> > There is one caveat to watch out for: policy assertions with deeply
> > nested policy can greatly increase the complexity of a policy and
> > should be avoided when they are not needed.
> >
> > with regard to the first question, I don't think this is explained
> > at all in the following paragraph, so i'm not sure what the value
> > of the question is, and if it is going to be there, I think we need
> > to explain what the alternatives are if both answers are NOT yes.
> >
> > Maryann
> >
> >
> > Frederick Hirsch <frederick.hirsch@nokia.com>
> > Sent by: public-ws-policy-eds-request@w3.org
> > 11/29/2006 11:06 PM
> >
> > To
> > "ext Asir Vedamuthu" <asirveda@microsoft.com>
> > cc
> > Frederick Hirsch <frederick.hirsch@nokia.com>, <public-ws-policy-
> > eds@w3.org>
> > Subject
> > Re: Action-90 Review
> >
> >
> >
> >
> >
> >
> > Thanks for noting these editorial issues.
> >
> > I have corrected all of these as part of this editorial pass, with
> > the following exceptions:
> >
> > > 4.5.2 Optional behavior at runtime
> > >
> > > s/Leaving the semantics undescribed/Leaving the semantics not or
> > under
> > > specified/
> >
> > changed to "Leaving the semantics not specified or incompletely
> > specified"
> >
> > > s/See also 4.3.3 Self Describing Messages . /See also 4.3.3 Self
> > > Describing Messages./
> >
> > Issue here seems to be in the specref target, so I didn't touch this
> > since it could break elsewhere.
> >  "See also <specref ref="self-describing"/>."
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> > Nokia
> >
> >
> > On Nov 29, 2006, at 9:10 PM, ext Asir Vedamuthu wrote:
> >
> > > ACTION-90 [1] - Review Action 77 snapshot (document is at
> > > http://tinyurl.com/yjpbyf
> > >
> > > Please find below suggestions to fix typos, grammar and spaces. I
> > > request other editors to review Action 77 snapshot at
> > > http://tinyurl.com/yjpbyf
> > >
> > > [1] http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90
> > >
> > > Regards,
> > >
> > > Asir S Vedamuthu
> > > Microsoft Corporation
> > >
> > >
> > > ----- Notation Used -----
> > >
> > > s/Mary/Marie/ Change most recent occurrence of "Mary" to "Marie".
> > The
> > > old string is currently treated as a literal string -- not a  
> regex.
> > >
> > > s/Mary/Marie/G Change all previous and future occurrences of
> > "Mary" to
> > > "Marie" (within this document).
> > >
> > >
> > > ----- Typos, Grammar and Spaces for Action 77 -----
> > >
> > > Table of Contents:
> > >
> > > s/parameters vs nesting/parameters vs. nesting/
> > >
> > >
> > > 1. Introduction
> > >
> > > s/consistent compinations/consistent combinations/
> > > s/metadata exxpression/metadata expression/
> > > s/Web Services Policy 1.5 - Guidelines for Policy Assertion  
> Authors
> > > is a
> > > resource primarily for assertion authors that provides guidelines
> > > on the
> > > use of Web/Web Services Policy 1.5 - Guidelines for Policy  
> Assertion
> > > Authors is a resource primarily for assertion authors and provides
> > > guidelines on the use of Web/
> > >
> > >
> > > 3.1.1 WS-Policy Authors
> > >
> > > s/WS-SecurityPolicy pecification/WS-SecurityPolicy specification/
> > >
> > >
> > > 3.1.3 Providers
> > >
> > > s/policies it is uesful/policies it is useful/
> > >
> > >
> > > 4. General Guidelines for WS-Policy Assertion Authors
> > >
> > > s/validation in their desgin/validation in their design/
> > > s/relies on the Qname/relies on the QName/
> > > s/provides somes/provides some/
> > >
> > >
> > > 4.1 Assertions and Their Target Use
> > >
> > > s/Once the range of policy subjects are/Once the range of policy
> > > subjects is/
> > > s/A eferencing mechanism/A referencing mechanism/
> > >
> > >
> > > 4.2 Authoring Styles
> > >
> > > s/the @optional attribute/the wsp:optional attribute/
> > >
> > >
> > > 4.3.1 Minimal Approach
> > >
> > > s/a way that eflects/a way that effects/
> > >
> > >
> > > 4.3.3 Self Describing Messages
> > >
> > > s/when messages can not/when messages cannot/
> > > s/Best practice:Policy/Best practice: Policy/
> > >
> > >
> > > 4.3.4 Single Domains
> > >
> > > s/some might say its/some might say it is/
> > >
> > >
> > > 4.4.2 Nested Assertions
> > >
> > > s/Thesp:AlgorithmSuite assertion/The sp:AlgorithmSuite assertion/
> > > s/Setting aside the details of using transport-level security,,/
> > > Setting
> > > aside the details of using transport-level security,/
> > >
> > >
> > > 4.4.3 Considerations for choosing parameters vs. nesting
> > >
> > > s/for selecting parameters or nesting of assertions,/for selecting
> > > parameters or nesting of assertions/
> > >
> > >
> > > 4.5.1 Optional behavior in Compact authoring
> > >
> > > s/using wsp:optional attribute/using wsp:Optional attribute/
> > >
> > >
> > > 4.5.2 Optional behavior at runtime
> > >
> > > s/Note that in order for an optional behaviors to be engaged/Note
> > that
> > > in order for an optional behavior to be engaged/
> > > s/[4.3.3 Self Describing Messages ]/[4.3.3 Self Describing
> > Messages]/
> > > s/specific endpoint when optional behavior is engaged ./specific
> > > endpoint when optional behavior is engaged./
> > > s/Leaving the semantics undescribed/Leaving the semantics not or
> > under
> > > specified/
> > > s/policy assertion authors should consider to describe/policy
> > > assertion
> > > authors should consider describing/
> > > s/See also 4.3.3 Self Describing Messages . /See also 4.3.3 Self
> > > Describing Messages./
> > >
> > >
> > > 4.6 Typing Assertions
> > >
> > > s/(endpoints) or artifacts ( messages)/(endpoints) or artifacts
> > > (messages)/
> > > s/indicates which Qnames/indicates which QNames/
> > >
> > >
> > > 4.7 Levels of Abstraction in WSDL
> > >
> > > s/This resulted in the finer granularity of the assertion to
> > apply at
> > > the message policy subject, but the assertion semantics also
> > indicates
> > > that the if the senders choose to engage RM semantics (although  
> not
> > > specified via attachment in WSDL at incoming messages), the
> > providers
> > > will honor the engagement of RM./This resulted in the finer
> > > granularity
> > > of the assertion to apply at the message policy subject, but the
> > > assertion semantics also indicates that if a sender chose to
> > engage RM
> > > semantics (although not specified via attachment in WSDL at  
> incoming
> > > messages), the providers will honor the engagement of RM./
> > >
> > >
> > > 6. Inter-domain Policy and Composition Issues
> > >
> > > s/, utilization of WS-Security Policy with other protocols  
> affect/,
> > > utilization of WS-Security Policy with other protocols affects/
> > >
> > >
> > > 7.3 Appropriate Attachment: Identifying Assertion Sources
> > >
> > > s/( in WSDL, the source/(in WSDL, the source/
> > > s/( using WS-Trust)/(using WS-Trust)/
> > >
> > >
> > > 8. Scenario and a worked example
> > >
> > > s/CompanyA/Company A/G
> > > s/( Policy, All and ExactlyOne)/(Policy, All and ExactlyOne)/
> > > s/ProfileA/Profile A/G
> > > s/( not expanded)/(not expanded)/
> > > s/Since CompanyA has decided to use well known policy expressions
> > that
> > > are themselves part of a specification/Since CompanyA has decided
> > > to use
> > > well known policy expressions that are part of a specification/
> >
> >
> >
>
>
>
Received on Thursday, 30 November 2006 19:29:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:59 GMT