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

RE: Action-90 Review

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Thu, 30 Nov 2006 13:21:01 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D6416502CBEC6A@uspale20.pal.sap.corp>
To: "Maryann Hondo" <mhondo@us.ibm.com>, "Frederick Hirsch" <frederick.hirsch@nokia.com>
Cc: "ext Asir Vedamuthu" <asirveda@microsoft.com>, "Frederick Hirsch" <frederick.hirsch@nokia.com>, <public-ws-policy-eds@w3.org>, <public-ws-policy-eds-request@w3.org>
That was my confusion, that is why I asked the question. 
 
I could not follow what was new or what was not, because sections which
are not new appeared to be new. 
 
--umit
 


________________________________

	From: public-ws-policy-eds-request@w3.org
[mailto:public-ws-policy-eds-request@w3.org] On Behalf Of Maryann Hondo
	Sent: Thursday, Nov 30, 2006 10:30 AM
	To: Frederick Hirsch
	Cc: ext Asir Vedamuthu; Frederick Hirsch;
public-ws-policy-eds@w3.org; public-ws-policy-eds-request@w3.org
	Subject: Re: Action-90 Review
	
	

	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 21:21:35 GMT

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