RE: Revised positions for closed/open world assumptions

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