Re: NEW ISSUE 4130: Ignorable assertions must be ignored

Hi

"ignorableness is at the discretion of the policy consumer"

It would be nice for this statement be added to the primer IMHO...

Cheers, Sergey
  ----- Original Message ----- 
  From: Christopher B Ferris 
  To: Ashok Malhotra 
  Cc: Frederick Hirsch ; public-ws-policy@w3.org ; public-ws-policy-request@w3.org 
  Sent: Tuesday, January 09, 2007 5:40 PM
  Subject: 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.
  > > >>
  > > >>
  > > >>
  > > >>
  > > >
  > > >
  > > 
  > 
  >