Re: NEW ISSUE 4130: Ignorable assertions must be ignored

Hi Ashok

http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection,

If the mode is lax, two policy alternatives A and B are compatible:

  a.. if each assertion in A that is not an ignorable policy assertion is compatible with an assertion in B, and

  b.. if each assertion in B that is not an ignorable policy assertion is compatible with an assertion in A.

My understanding is that if requester has an assertion A as a requirement then provider must have it have it available in its 
alternative, the fact that a corresponding provider's A assertion might be marked as wsp:ignorable is irrelevant from a perspective 
of a requester. This is exactly wahat wsp:ignorable is for as far as I inderstand : let those who are looking for A match it and 
those who know nothing about A should safely proceed



Cheers, Sergey




----- Original Message ----- 
From: "Ashok Malhotra" <ashok.malhotra@oracle.com>
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>; <tom@coastin.com>
Cc: <public-ws-policy@w3.org>
Sent: Tuesday, January 09, 2007 2:13 PM
Subject: RE: NEW ISSUE 4130: Ignorable assertions must be ignored



Sergey, you said...

"This is not how I see lax mode working. Lax mode will have only those "ignorable" assertions ignored which have not been specified 
in the reqiester's policy as non-ignorable assertions, as described in the other email I've just sent."

Where does it say that?  My understanding was exactly what Tom recapitulated.  In 'lax' mode all assertions marked 'ignorable' are 
ignored.  In 'strict' mode, no assertions are ignored.

All the best, Ashok

> -----Original Message-----
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of Sergey Beryozkin
> Sent: Tuesday, January 09, 2007 5:45 AM
> To: tom@coastin.com
> Cc: Ashok Malhotra; public-ws-policy@w3.org
> Subject: Re: NEW ISSUE 4130: Ignorable assertions must be ignored
>
>
> Hi
>
> > Lax will have the "ignorable" ignored, and "Strict" will include the
> ignorable in the intersection.
>
> This is not how I see lax mode working. Lax mode will have only those
> "ignorable" assertions ignored which have not been specified
> in the reqiester's policy as non-ignorable assertions, as described in the
> other email I've just sent.
> For ex, <Policy><A/></Policy> and <Policy><A wsp:ignorable="true"/><B
> wsp:ignorable="true"/></Policy>
>
> Only <B> will be ignored, <A wsp:ignorable="true"/> will also be included
> in the intersection because A is what a requester is
> expecting - doesn't matter that wsp:ignorable is set on the provider's A
> assertion.
>
> Cheers, Sergey
>
>
> > Sergey Beryozkin wrote:
> >> Hi
> > clarification in line below
> >
> > Tom Rutt
> >>  "- ASSERTIONS THAT THE OTHER PARTY SHOULD NEVER SEE
> >> Such as logging.  These are private to my implementation.
> >> Glen: Such assertions should be removed prior to intersection and never
> exposed to the other party.
> >> Ashok:  They can be included in the policy and always 'ignore' d."
> >>  S.B. Ashok what you're suggesting is exactly what we were trying to
> pursue with our wsp:local proposal, without success :-). We
> >> wanted a standard attribute which can be used to mark private
> assertions (would be useful for writing generic tools, etc),
> >> furthermore we were agreeing that such assertions must be stripped of,
> but ignored by requesteres if leaked (inadvertently or due
> >> to some constraints).
> >> Now that we have wsp:ignorable I don't see a way of getting back...So I
> agree with Glen.
> >>  As was noted before, you can now use a lax mode if you want your
> provider assertions be ignored. Otherwise, why to expose
> >> assertions which need to be always ignored ? Assertions are for
> requesters.
> >>  "
> >> - ASSERTIONS THAT CANNOT BE MATCHED BY MACHINE
> >> A: I think these are useful to include in policies for advertising.
> >> For example, legal or privacy policies.  Users cannot match on these
> but will look at them and decide whether to use a particular
> >> service or not based on their contents.
> >> These too must be always 'ignore' d during intersection.
> >> G: Such assertions should not be included in policies but, rather,
> included in some other metadata bucket.
> >> A: But we have not defined any other metadata buckets. "
> >>  S.B. I agree that these are useful to include in policies for
> advertising. Two options :
> >> * Make these assertions as "ignorable" and use the lax mode to handle
> such policies. This will require a smart requester UI tool
> >> which will offer users a chance to vote on "ignorable" provider
> assertions which have not been understood during the
> >> intersection.
> >> * As Tom noted, you can use a strict mode too. This will require
> requesteres though to be aware of these assertions in advance.
> > What I really wanted to say is that the receiver of the policy decides
> when to use lax or strict in their policy incersection
> > tests.
> >
> > Lax will have the "ignorable" ignored, and "Strict" will include the
> ignorable in the intersection.
> >
> > I think this degree of control is enough, and we do not really need a
> new attribute for this use case.  If we do, it should be
> > named
> > something like ("informational").
> >
> >
> >> "- ASSERTIONS THAT THE OTHER PARTY MAY BE ABLE TO MATCH
> >> G: If he can match the assertions, great!  If not, he should be able to
> proceed even if he cannot match.  This is the rationale
> >> for lax and strict matching.
> >> A: I accept this usecase but that's not what I was thinking of."
> >>  So if you agree with Glen here then I'm not qute sure what exactly is
> your scenario...
> >>  Thanks, Sergey
> >>
> >>
> >>
> >>
> >> Glen Daniels and I had a chat about 'ignorable'.
> >>
> >> It turns out, not surprisingly, that we had different usecases in mind
> >> and different ideas as to how they should be handled.
> >>
> >> Here is a summary of our positions.  Please respond if you have views
> on
> >> them.
> >>
> >> Glen, please correct me if I have misrepresented your positions.
> >>
> >> - ASSERTIONS THAT THE OTHER PARTY SHOULD NEVER SEE
> >> Such as logging.  These are private to my implementation.
> >> Glen: Such assertions should be removed prior to intersection and never
> exposed to the other party.
> >> Ashok:  They can be included in the policy and always 'ignore' d.
> >>
> >> - ASSERTIONS THAT CANNOT BE MATCHED BY MACHINE
> >> A: I think these are useful to include in policies for advertising.
> >> For example, legal or privacy policies.  Users cannot match on these
> but will look at them and decide whether to use a particular
> >> service or not based on their contents.
> >> These too must be always 'ignore' d during intersection.
> >> G: Such assertions should not be included in policies but, rather,
> included in some other metadata bucket.
> >> A: But we have not defined any other metadata buckets.
> >>
> >> - ASSERTIONS THAT THE OTHER PARTY MAY BE ABLE TO MATCH
> >> G: If he can match the assertions, great!  If not, he should be able to
> proceed even if he cannot match.  This is the rationale
> >> for lax and strict matching.
> >> A: I accept this usecase but that's not what I was thinking of.
> >>
> >> All the best, Ashok
> >>
> >> > -----Original Message-----
> >> > From: public-ws-policy-request@w3.org
> >> <mailto:public-ws-policy-request@w3.org> [mailto:public-ws-policy-
> >> > request@w3.org <mailto:request@w3.org>] On Behalf Of Ashok Malhotra
> >> > Sent: Tuesday, January 02, 2007 6:37 AM
> >> > To: public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>
> >> > Subject: NEW ISSUE 4130: Ignorable assertions must be ignored
> >> >
> >> >
> >> >
> >> >
> >> > Title
> >> >
> >> > Ignorable assertion must be ignored
> >> >
> >> > Description
> >> >
> >> > At the last f2f meeting the WS-Policy WG agreed to add an attribute
> >> called
> >> > 'ignorable' to the WS-Policy assertion syntax.  We think this is a
> >> step in
> >> > the right direction.  The WG, however, blunted the effect of this
> change
> >> > by
> >> > allowing the ignorable attribute to be ignored during policy
> >> intersection
> >> > by
> >> > allowing two intersection modes one of which honors the ignorable
> >> > attribute and the other which ignores it.
> >> >
> >> > We argue this creates a problem as the parties attempting to agree on
> a
> >> > policy alternative may use different forms of the intersection
> algorithm
> >> > and come up with different solutions.  A standard that allows such
> >> > variation is not very useful.
> >> >
> >> > We suggest that the policy intersection algorithm be changed so that
> >> > assertions marked ignorable are always ignored.
> >> >
> >> > Justification
> >> >
> >> > See above.
> >> >
> >> > Target
> >> >
> >> > WS-Policy Framework
> >> >
> >> > Proposal
> >> >
> >> > 1. In section 4.5 Policy Intersection, add a third bullet after the
> >> first
> >> > two bullets that says:
> >> > o Assertions with ignorable = 'true' are ignored in during policy
> >> > intersection.
> >> >
> >> > 2. Remove the first bullet, including its sub-bullets from the
> >> second set
> >> > of 2 bullets.
> >> >
> >> > 3. Add an ignorable assertion to the following example.
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >
> > --
> > ----------------------------------------------------
> > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
> > Tel: +1 732 801 5744          Fax: +1 732 774 5133
> >
> >
>
>

Received on Tuesday, 9 January 2007 14:27:51 UTC