Re: Revised positions for closed/open world assumptions

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
Nokia


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