Re: NEW ISSUE 4130: Ignorable assertions must be ignored

So with Lax and Strict what is the usecase for ignorable ? as with Lax you
can make the choice to ignore the fact there is not an intersection

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122


                                                                           
             "Sergey                                                       
             Beryozkin"                                                    
             <sergey.beryozkin                                          To 
             @iona.com>                "Ashok Malhotra"                    
             Sent by:                  <ashok.malhotra@oracle.com>,        
             public-ws-policy-         <public-ws-policy@w3.org>           
             request@w3.org                                             cc 
                                                                           
                                                                   Subject 
             01/08/2007 12:35          Re: NEW ISSUE 4130: Ignorable       
             PM                        assertions must be ignored          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi

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

"- 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] On Behalf Of Ashok Malhotra
> Sent: Tuesday, January 02, 2007 6:37 AM
> To: 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.
>
>
>
>