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 13:45:49 UTC