RE: NEW ISSUE 4130: Ignorable assertions must be ignored

Frederick:
The purpose of my note was to try and spell out the different usecases people had in mind for 'ignorable' and see if the current design covers all the usecases and ask for reactions.

So far, I have heard some people argue that we need another attribute, perhaps called 'informational' that indicates that the assertion is always ignored.

Sergey also seems to have a understanding of 'lax' semantics that is, at least, different from mine.


All the best, Ashok

> -----Original Message-----
> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]
> Sent: Tuesday, January 09, 2007 7:47 AM
> To: ext Ashok Malhotra
> Cc: Frederick Hirsch; public-ws-policy@w3.org
> Subject: Re: NEW ISSUE 4130: Ignorable assertions must be ignored
> 
> This summary does not argue for any change to the framework, however
> this information could be helpful for the guidelines. Is that the
> intent?
> 
> Assertion authors should depend on business intentions and the
> details of the assertion semantics for decisions whether to include
> assertions and whether to mark ignorable, so we are not proposing
> rules, but rather considerations.
> 
> comments inline.
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> On Jan 7, 2007, at 5:07 PM, ext Ashok Malhotra wrote:
> 
> >
> > 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.
> 
> They could not be ignored if the requestor wishes to use generic
> intersection for match, e.g. wants to be assured that provider does
> logging..
> 
> >
> > - 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.
> 
> Again they could be included in policy, marked as ignorable or not.
> 
> >
> > - 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.
> >>
> >>
> >>
> >>
> >
> >
>

Received on Tuesday, 9 January 2007 16:10:08 UTC