W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

Re: Revised positions for closed/open world assumptions

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 16 May 2007 12:03:06 -0400
Message-Id: <011A8C80-F146-41C8-874D-51299642FC12@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, public-ws-policy@w3.org
To: ext Christopher B Ferris <chrisfer@us.ibm.com>

I think we could do both, but the longer text from Tony in the  
guidelines, and shorter text into the normative framework.

regards, Frederick

Frederick Hirsch

On May 16, 2007, at 6:38 AM, ext Christopher B Ferris wrote:

> The key thing from IBM's position is that we preserve the intent  
> behind the vocabulary-based
> AIN, so that it is clear as to the answer to the following question:
>         Can the behavior implied by C be applied __as a result of  
> policy framework processing__
>         if I intersect Policy 1 ((B, C), (A, B)) and Policy 2 (A, B)?
> In the situation that the implementation knows about the _behavior  
> implied by C_ but not
> about C the assertion, then the spec should indicate that at least  
> from the policy framework
> processing perspective, this is out of scope. As Felix suggests  
> [1], it MAY be applied, but
> interoperability might suffer as a result since the endpoint might  
> only be capable of
> processing (or willing to process) EITHER (B, C) OR (A, B), NOT (A,  
> B, C). However, I think
> that we are uncomfortable with the use of the RFC2119 keyword MAY  
> in this context
> since in this case we are talking about behavior applied outside  
> the scope
> of policy framework and attachments processing and hence it is  
> unenforcable by
> policy.
> In the case that the implementation knows both the behavior and the  
> assertion type C, then
> IBM would like it made clear that the answer is NO. Previously, in  
> this thread, Ashok seemed
> to agree that the answer should indeed be NO. I don't think that  
> anyone has suggested otherwise.
> With regards to behavior implied by Z, whether or not the  
> implementation knows about Z the
> assertion, IBM would like it made clear that this too is out of  
> scope of the policy framework
> processing since it is absent from any of the policies input to  
> intersection.
> Where the pushback on our previous proposals has focused seems to  
> be around the
> separation of behavior and the assertion type. Quite possibly, the  
> language we have offered
> goes too far in being interpreted as implying that one MUST NOT  
> (despite the absence of
> any RFC2119 keywords) apply behaviors implied by assertion types of  
> which one is unaware.
> That has never been our intent. Our intent has been to effectively  
> preserve the semantic
> that is present in the spec today with regards to the current "will  
> not be applied" language
> relative to policy vocabulary, however, without the policy  
> vocabulary definition getting in the
> way.
> I think that Tony's note [2] also captures this, possibly better  
> than I have above.
> Frederick seems to think that we should put this in the guidelines.  
> From IBM's perspective,
> that would leave the Policy spec itself to vague. The Guidelines  
> are non-normative. It comprises
> guidance for policy assertion authors, not policy framework/ 
> attachment implementers. I think
> that we would much prefer that this be made clear in the normative  
> specification.
> Proposed text added to section 4.5:
>         If an initiating entity inclides a policy assertion type A  
> in its policy, and this policy assertion type A
>         does not occur in an intersected policy, then the  
> initiating entity does not apply the behavior implied by
>         assertion type A.
> Additionally, an example such as that which we have been using for  
> this discussion should be added to help people understand
> the correct answer to the question I outlined above.
> The above proposal amends the previous proposed changes to remove  
> policy vocabulary... The text we proposed
> adding to section 3.2 no longer applies. Only the removed text in  
> section 3.2 applies.
> Cheers,
> [1] http://lists.w3.org/Archives/Public/public-ws-policy/2007May/ 
> 0151.html
> [2] http://lists.w3.org/Archives/Public/public-ws-policy/2007May/ 
> 0161.html
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 377 9295
> "Dale Moberg" <dmoberg@us.axway.com> wrote on 05/14/2007 01:40:12 PM:
> > Chris Ferris writes:
> > Maryann and I have been noodling on language that tries to capture
> > our intent better. So, rather than
> > add the "No other behaviors are to be applied" language, we think
> > that maybe if we added the following
> > prose to section 4.5 Intersection, just before the algorithm is
> > described, that that might clear up the confusion
> > while at the same time preserving the semantic that we believe to  
> beimportant.
> >
> > New text for section 4.5:
> >
> > If the intersection algorithm produces a policy alternative, common
> > to both parties, it indicates that the behaviors
> > implied by the assertions in that policy alternative are an implicit
> > contract and will be applied for any interaction
> > based on that alternative. Any behaviors not represented by policy
> > assertions in that alternative are out of scope
> > and not applied as a result of policy framework processing.
> >
> > DaleMoberg>> OK, by switching to an explanation of a “policy
> > processing model,” I think a lot of the “logical quibbles” can drop
> > out, and that I think is an improvement. The language is not
> > encroaching on the semantic options that domain policy assertion
> > designers have available.
> >
> > It seems that the advice actually gets close to common sense now,
> > for you appear to be saying that once you select a policy
> > alternative, engage in the behavior that you intend to engage in!
> >
> > The other alternatives are “out of scope” once your policy
> > alternative (for which you found a match) is selected. And if you
> > included behavior that triggered other provider-supported policy
> > assertions (present in other alternatives), then the other side can
> > be expected to make a response, and you might not be prepared for
> > it! Or something like that might occur that messes up the  
> interaction.
> >
> > The phrase “implicit contract” though seems a stretch. Suppose the
> > policy provider offers several policy alternatives. The policy
> > provider presumably does not care what policy alternative is
> > selected by the policy consumer, and unless the provider was being
> > deceptive, permits the consumer to jump from one alternative to
> > another. Is there any presumption that in the case where several
> > policy alternatives are in common between consumer and provider,
> > that the consumer cannot engage one set of behaviors one time and
> > another set of behaviors the next time? I personally can’t
> > understand how to get that commitment over time out of ws-policy at
> > present. If the commitment is just for one time, then the advice
> > boils down to the truism, that a consumer should be consistent
> > between his selected policy alternative intentions and his WS  
> behaviors.
> >
> > I am guessing that if there is push-back now, it will be because the
> > proposed policy processing model impinges on somebody’s planned
> > implementation.
> >
> >
Received on Wednesday, 16 May 2007 16:06:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC