RE: NEW ISSUE 4130: Ignorable assertions must be ignored

Great idea Sergey. 
 
--umit
 


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
	Sent: Friday, Jan 19, 2007 5:23 AM
	To: Ashok Malhotra; Christopher B Ferris
	Cc: Frederick Hirsch; public-ws-policy@w3.org;
public-ws-policy-request@w3.org
	Subject: 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 <mailto:chrisfer@us.ibm.com>

		To: Ashok Malhotra <mailto:ashok.malhotra@oracle.com>  
		Cc: Frederick Hirsch <mailto:frederick.hirsch@nokia.com>
; 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.
		> > >>
		> > >>
		> > >>
		> > >>
		> > >
		> > >
		> > 
		> 
		>