Re: AIN, NOBI and composition

Monica,

Let's review what the proposal I have offered says:

        [Definition: A policy alternative is a potentially empty 
collection of policy assertions.] An alternative with 
        zero assertions indicates no behaviors. An alternative with one or 
more assertions indicates behaviors implied by 
        those, and only those assertions. No other behaviors are to be 
applied for the alternative. 

Let me reiterate the key phrase here, this time, with emphasis added:

         An alternative with one or more assertions indicates behaviors 
implied by 
        those, and ONLY those assertions.

Note that this is text that is currently in the CR spec.

What I have offered is effectively a clarification that is intended to 
make it clear that this means that it is a
closed statement with regards to the set of behaviors used to interact 
with that endpoint. 

Frankly, I don't understand the distinction you are trying to make here.

The second sentence in Dave O's note is NOT the interpretation that I read 
into: "No other behaviors are to be
applied to the alternative". There is no mention in that sentence that the 
behaviors implied by assertions absent 
in the alternative not being applied. That would, as Dan has correctly 
pointed out, result in policy assertions
having the potential to cancel eachother out (as in the RSP and RM case he 
cited) which would be bad.

There is a clear distinction between Dave O's 1 and 2. The proposal 
offered by IBM doesn't even come
close to saying Dave O's #2, certainly not in my mind. Again, there is no 
mention in the last sentence of
the absent assertions. There is only a statement that closes the set of 
behaviors to be applied in the
context of an alternative that limits the set of behaviors to the set 
implied by the assertions IN that
alternative.

What we want is something that makes it clear that all you need to do is 
follow the policy in order to interact.

What I said that IBM could NOT live with was Dave O's option 3, whcih 
derives from the language that
you had offered about "makes no claims".

        AIN Removal: Any assertion not in alternative means nothing.  It 
may or
may not be applied.

If we leave things open (as in the "makes no claims" case) then there is 
the potential that a policy can be
incomplete with regards to specifying the behaviors necessary to interact 
with the policy subject, thus requiring
some unspecified OOB means of determining the set of behaviors that are 
needed, but not specified in the
policy (the proverbial secret handshake). To us, that is not acceptable 
because it significantly reduces
the value of policy to being nothing more than a hint.

I would also like to clarify that this is not about enforcement. The 
framework cannot enforce anything
(at least as we understand it). If an endpoint wants to "color outside the 
lines", it is free to do that,
but it can have no expectation of interoperability with the policy subject 
to which a policy applies
if it does so. The language that we have added does not include any 
normative RFC2119 language
(e.g. an endpoint MUST NOT apply any behaviors). It simply says that the 
set of behaviors
expressed by the assertions IN an alternative is a closed set of behaviors 
that are used for
interaction with the attached policy subject in the context of a given 
alternative.
 
Cheers,

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

public-ws-policy-request@w3.org wrote on 05/09/2007 04:50:27 PM:

> 
> Daniel Roth wrote:
> 
> >We think these sentences are different.  Let me try to explain 
> using Dave's RSPAssertion example.
> >
> >The RSPAssertion maps to two behaviors: (RM, Security)
> >The RMAssertion maps to one behavior: (RM)
> >
> >OK, so based on the two sentences below, what does the following 
> policy mean?  What behaviors does the policy subject require?:
> >
> ><Policy><RSPAssertion/></Policy>
> >
> >The first sentence says that the policy means the policy subject 
> requires (RM, Security).  Full stop.
> >
> >The second sentence says that the policy means the policy subject 
> requires (RM, Security, NOT(RM), NOT(Addressing), NOT(MTOM), ... etc
> for all absent assertions)
> >
> >The second sentence results in a very confusing situation: What 
> does it mean to do RM and NOT(RM)?  Does the absence of the 
> RMAssertion cancel out the RM-ness of the RSPAssertion?  Is the 
> policy self-contradicting?  This is definitely not the semantic we 
> want for policy alternatives.
> >
> >The first sentence results in a clear and simple interpretation of 
> the policy and its alternatives.
> >
> >Daniel Roth
> > 
> >
> Daniel, there is a difference between:
> 
>     1. An alternative with one or more assertions indicates behaviors
>     implied by those, and only those assertions.
> 
> and 
> 
>     2. No behaviors are to be applied for the alternative other than the
>     behaviors specified by the assertions in the alternative.
> 
> I believe we seemingly agree on 1.; where we differ is 2. Since the 
> definition of a policy assertion
> elicits a behavior, it is hard to differentiate the two statements 
> that Dave O quoted despite the caveat you've provided.
> 
> If we require RSP FULL STOP, that should be it FULL STOP.
> 
>     An alternative with one or more assertions indicates behaviors
>     implied by those, and only those assertions.
> 
> This is also consistent with that Mary Ann Hondo suggested is we 
> acknowledge this aspect in Section 4.5 in intersection.
> 
> If I heard and understood Chris Ferris correctly today, he did say what 
> he couldn't live with. Is this something he could (live with)? Thanks.
> 
> 
> >-----Original Message-----
> >From: David Orchard [mailto:dorchard@bea.com]
> >Sent: Wednesday, May 09, 2007 9:24 AM
> >To: Daniel Roth; Ashok Malhotra; public-ws-policy@w3.org
> >Subject: RE: AIN, NOBI and composition
> >
> >We continue to talk past each other.  I think the following two
> >sentences are equivalent:
> >"No behaviors are to be applied for the alternative other than the
> >behaviors specified by the assertions in the alternative"
> >"The absence of an assertion means that the behaviour specified by the
> >absent assertion should not be applied".
> >
> >Cheers,
> >Dave
> >
> > 
> >
> >>-----Original Message-----
> >>From: Daniel Roth [mailto:Daniel.Roth@microsoft.com]
> >>Sent: Tuesday, May 08, 2007 4:52 PM
> >>To: David Orchard; Ashok Malhotra; public-ws-policy@w3.org
> >>Subject: RE: AIN, NOBI and composition
> >>
> >> 
> >>
> >>>AIN Closed flavour: Any assertion not in an alternative
> >>> 
> >>>
> >>should not be
> >> 
> >>
> >>>applied (revised chris proposal)
> >>> 
> >>>
> >>Chris' revised proposal doesn't say anything about the
> >>absence of assertions.  It simply says that no behaviors are
> >>to be applied for the alternative other than the behaviors
> >>specified by the assertions in the alternative.
> >>
> >>Daniel Roth
> >>
> >>-----Original Message-----
> >>From: David Orchard [mailto:dorchard@bea.com]
> >>Sent: Tuesday, May 08, 2007 4:42 PM
> >>To: Ashok Malhotra; Daniel Roth; public-ws-policy@w3.org
> >>Subject: RE: AIN, NOBI and composition
> >>
> >>Well, I think we need to have clear wording for all the "alternatives"
> >>before the working group.
> >>
> >>The way I see it:
> >>AIN Vocabulary flavour: Any assertion not in a vocabulary
> >>should not be applied (Original chris proposal) AIN Closed
> >>favour: Any assertion not in an alternative should not be
> >>applied (revised chris proposal) AIN Removal: Any assertion
> >>not in alternative means nothing.  It may or may not be applied.
> >>
> >>Cheers,
> >>Dave
> >>
> >> 
> >>
> >>>-----Original Message-----
> >>>From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
> >>>Sent: Tuesday, May 08, 2007 4:29 PM
> >>>To: Daniel Roth; David Orchard; public-ws-policy@w3.org
> >>>Subject: RE: AIN, NOBI and composition
> >>>
> >>>Dan:
> >>>I'm sorry, but that's not how I read it.
> >>>
> >>>My reading is that you CANNOT apply assertions that are not in the
> >>>selected alternative.  That, to me feels like negation.
> >>>
> >>>I think we shd get behind Monica's explicit wording that eliminates
> >>>the fuzz factor.
> >>>
> >>>All the best, Ashok
> >>>
> >>> 
> >>>
> >>>>-----Original Message-----
> >>>>From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> >>>>request@w3.org] On Behalf Of Daniel Roth
> >>>>Sent: Tuesday, May 08, 2007 4:12 PM
> >>>>To: David Orchard; public-ws-policy@w3.org
> >>>>Subject: RE: AIN, NOBI and composition
> >>>>
> >>>>
> >>>>This is exactly the problem with tying negation semantics to the
> >>>>absence of assertion types (AIN).
> >>>>
> >>>>IBM's proposal fixes this by simply saying you do what you
> >>>> 
> >>>>
> >>>assert and
> >>> 
> >>>
> >>>>nothing else (NOBI).
> >>>>
> >>>>Daniel Roth
> >>>>
> >>>>-----Original Message-----
> >>>>From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> >>>>request@w3.org] On Behalf Of David Orchard
> >>>>Sent: Tuesday, May 08, 2007 3:23 PM
> >>>>To: public-ws-policy@w3.org
> >>>>Subject: AIN, NOBI and composition
> >>>>
> >>>>
> >>>>I wonder about AIN, NOBI, etc. and composition.
> >>>>
> >>>>Imagine that WS-I produces an assertion that says a "RSPAssertion"
> >>>>means RMAssertion and Security, perhaps exactly one of
> >>>>messageSecurity|transportsecurity.  What's the meaning
> >>>> 
> >>>>
> >>when some of
> >> 
> >>
> >>>>messageSecurity|the
> >>>>assertions that are in the composition are missing?  For
> >>>> 
> >>>>
> >>example, I
> >> 
> >>
> >>>>just say RSPAssertion.  I don't say RMAssertion, though
> >>>> 
> >>>>
> >>>RMAssertion is
> >>> 
> >>>
> >>>>in the vocabulary.  If I get an intersection that says
> >>>> 
> >>>>
> >>RSPAssertion
> >> 
> >>
> >>>>but not RMAssertion, AIN has the implication that you
> >>>> 
> >>>>
> >>>shouldn't apply
> >>> 
> >>>
> >>>>RMAssertion yet RSPAssertion does.
> >>>>
> >>>>We don't say anything about whether an assertion that means a
> >>>>behaviour "trumps" the lack of such an assertion.
> >>>>
> >>>>With AIN, there's a problem.  Without AIN, there's no
> >>>> 
> >>>>
> >>>problem because
> >>> 
> >>>
> >>>>there's no conflict.
> >>>>
> >>>>Cheers,
> >>>>Dav3e
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 
> >>>>
> >>> 
> >>>
> >
> > 
> >
> 
> 
>