RE: NEW ISSUE 4130: Ignorable assertions must be ignored

Ashok,

<hat mode="off">
I think that you are still missing the point that ignorableness is at the 
discretion of the policy consumer.
You have not, IMO, expressed a use case in which the policy provider needs 
to assert that the
assertion be ignored (must ignore) save for the use case in which 
configuration information is
expressed, but I thought that we had agreed that you could use a 
proprietary attribute for that
and filter these out prior to making the policy available to te outside 
world. I believe you even 
indicated that that was indeed what Oracle was already doing. You had also 
expressed,
if I recall correctly, that that was perfectly adequate for your needs. 
What am I missing?
</hat>

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 01/09/2007 11:08:22 AM:

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