W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

RE: AIN, NOBI and composition

From: Dale Moberg <dmoberg@us.axway.com>
Date: Thu, 10 May 2007 11:31:59 -0700
Message-ID: <97085FEE4C8BDB4AB6FA3E770EBC79BB0110F659@mail1.cyclonecommerce.com>
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, "David Orchard" <dorchard@bea.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>, "Ashok Malhotra" <ashok.malhotra@oracle.com>
Cc: "Daniel Roth" <Daniel.Roth@microsoft.com>, <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>
I agree with Sergey that the situation is too unconstrained to say
whether behaviors that conform to A & B and also happen to conform to C
cause problems.

 

Suppose wildly that A B and C are each associated with SOAP 1.2 header
blocks.

Suppose the initial SOAP sender has an implementation that when it
wishes to engage behaviors conforming with policies A & B, it also
produces an additional header block targeted at role "none" This
additional header block has some data that one vender's implementation
uses to enhance functionality when operating with another copy of itself
in role "ultimateReceiver". Assuming that the SOAP processing model is
followed, even when engaging the behavior of adding on this enhancement
for feature C (associated with policy C), no interoperability problems
will occur. 

 

Now if people want to slap on  "mustUnderstand='true'" information on
the header block, and change the targeted role,  I suspect this might
interfere with smooth operation even if technically interoperating in
some sense.

 

So it depends, and I agree with Sergey that "don't know/can't tell" is
about the best you can say about whether the additional implementational
conventions would lead to problems.

 

But it would be possible to conform with A & B even while having support
for feature C that is appropriately implemented. I remain unconvinced
that we want to banish the possibility of these functional enhancements
in general as a matter of baked-in ws-policy framework principle.

 

 

________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
Sent: Thursday, May 10, 2007 10:53 AM
To: David Orchard; Christopher B Ferris; Ashok Malhotra
Cc: Daniel Roth; public-ws-policy@w3.org;
public-ws-policy-request@w3.org
Subject: Re: AIN, NOBI and composition

 

Hi

 

That's why I actually I'd liek to interpret  "no" as "dont know, can't
tell". I feel that "No" is actually ok and simplifies things, because
the spec can't probably say in the text  that the client may still try
to apply some additional behaviours...

 

> Under your rules, I think that means all those behaviours are not to
be applied.

 

But I'd just prefer a text clarifying a bit that if the client ignores
the "No" advice then the behaviour is undefined (for example, with
security policies, the result will be no communication/interop). IMHO
with this clarification applying all those not explicitly listed
optional behaviours will be up to the client, perhaps the client has
learnt about those optional behaviours outofband, through the
documentation, tracing, etc...

 

Either way I don't read "No" as a requirement, it's a useful advice
which will probably be better followed in most cases, but I agree,
there're scenarious where the client might successfully interoperate by
not following this advice, so combining No with the undefined behaviour
clarification seems the good compromise to me. 

 

I think only the (design) UI tool can make it possible in reality not to
follow a No advice. For ex, it might ask a user : here's the selected
alternative (A & B), you also wanted C be applied, here's additional
info  which might help you to decide if C might be applied to, etc...

 

At runtime, dynamically applying additional behaviours not present in
the selected alternative seems risky unlesss it's known that this
applying this behaviour is guaranteed not to break the provider (say,
the additional behaviour results in sending a may ignore soap header ot
something similar).

 

Cheers, Sergey

 

 

	----- Original Message ----- 

	From: David Orchard <mailto:dorchard@bea.com>  

	To: Christopher B Ferris <mailto:chrisfer@us.ibm.com>  ; Ashok
Malhotra <mailto:ashok.malhotra@oracle.com>  

	Cc: Daniel Roth <mailto:Daniel.Roth@microsoft.com>  ;
public-ws-policy@w3.org ; public-ws-policy-request@w3.org 

	Sent: Thursday, May 10, 2007 6:23 PM

	Subject: RE: AIN, NOBI and composition

	 

	Ignorable/hidden: What if the service has an assertion C that
implies logging behaviour, but it isn't put in the policy?  I think the
service can do a whole bunch of things that might be disclosed to the
client for intersection.

	 

	Optional: What if the service has an optional Assertion, like
RMAssertion, and it isn't in the policy.  

	 

	Under your rules, I think that means all those behaviours are
not to be applied.  

	 

	Cheers,

	Dave

		 

		
________________________________


		From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
		Sent: Thursday, May 10, 2007 6:12 AM
		To: Ashok Malhotra
		Cc: Daniel Roth; David Orchard; public-ws-policy@w3.org;
public-ws-policy-request@w3.org
		Subject: RE: AIN, NOBI and composition

		
		I don't know what C or Z imply. Again, you keep adding
assertions to the mix. The statement we proposed 
		says NOTHING about assertions. It speaks ONLY about
BEHAVIORS. 
		
		I cannot make this any more clear than that. 
		
		There are a set of behaviors implied by the set of
assertions IN an alternative. 
		Those and ONLY THOSE implied behaviors are to be
applied, full stop. 
		
		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 05/10/2007
08:48:27 AM:
		
		> Chris: 
		> I was being deliberately provocative to get you to
spell out the 
		> exact semantics.  So, if the selected policy is 
		>  <policy>
		>      <A/>
		>      <B/>
		> </policy> 
		>   
		> What can I do, or can I not do wrt C or Z? 
		> All the best, Ashok 
		> 
		> From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-
		> request@w3.org] On Behalf Of Christopher B Ferris
		> Sent: Thursday, May 10, 2007 5:02 AM
		> To: Ashok Malhotra
		> Cc: Daniel Roth; David Orchard;
public-ws-policy@w3.org; public-ws-
		> policy-request@w3.org
		> Subject: RE: AIN, NOBI and composition 
		>   
		> 
		> Ashok, 
		> 
		> Bzzzt. 
		> 
		> Where in the text that I have offered is the RFC2119
keyword "MUST 
		> NOT"? The proposal that IBM has offered 
		> does NOT require that you know the unknowable (the
complete set of 
		> policy alternatives in the universe). 
		> The proposal we have offered is an attempt to make it
clear that a 
		> policy alternative is a complete 
		> expression of the set of behaviors to be engaged. 
		> 
		> If we have the "makes no claims" interpretation, then
a policy 
		> author is free to (for instance) exclude the 
		> security policy necessary to the interaction on the
grounds that it 
		> is too complicated. Thus, an endpoint 
		> wishing to interact with an endpoint whose policy was
authored by 
		> this lazy policy author would find 
		> out the hard way that the message needed to be signed
and encrypted 
		> in order to be processed. 
		> 
		> We believe that in order for policy to have value, it
must be a 
		> complete expression of the behaviors 
		> that are engaged for purposes of interaction. 
		> 
		> This has nothing to do with omniscience of policy
assertion 
		> vocabularies and exclusion of the 
		> set of behaviors implied by those absent from a given
policy alternative. 
		> 
		> IBM wants a policy alternative to be able to be taken
at face value 
		> as the expression of the 
		> set of behaviors that are to be used to interact
(interoperate) with
		> the attached policy subject. 
		> 
		> 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 05/09/2007
06:11:23 PM:
		> 
		> > 
		> > Yes, David, I agree.  Let me put it more starkly.
		> > Chris' proposal is that if the agreed on policy is:
		> > 
		> > <policy>
		> >     <A/>
		> >     <B/>
		> > </policy>
		> > 
		> > Then you MUST NOT do assertion X or Y or any other
assertions for 
		> that matter.
		> > 
		> > This means that you must know the universe of all
possible assertions.
		> > The <encoding> assertion is one you may not think
about but unless 
		> > you specify <encoding> you cannot do it, according
to this proposal.
		> > 
		> > 
		> > All the best, Ashok
		> > 
		> > > -----Original Message-----
		> > > From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-
		> > > request@w3.org] On Behalf Of David Orchard
		> > > Sent: Wednesday, May 09, 2007 9:24 AM
		> > > To: Daniel Roth; Ashok Malhotra;
public-ws-policy@w3.org
		> > > Subject: RE: AIN, NOBI and composition
		> > > 
		> > > 
		> > > We continue to talk past each other.  I think the
following two
		> > > sentences are equivalent:
		> > > "No behaviors are to be applied for the
alternative other than the
		> > > behaviors specified by the assertions in the
alternative"
		> > > "The absence of an assertion means that the
behaviour specified by the
		> > > absent assertion should not be applied".
		> > > 
		> > > Cheers,
		> > > Dave
		> > > 
		> > > > -----Original Message-----
		> > > > From: Daniel Roth
[mailto:Daniel.Roth@microsoft.com]
		> > > > Sent: Tuesday, May 08, 2007 4:52 PM
		> > > > To: David Orchard; Ashok Malhotra;
public-ws-policy@w3.org
		> > > > Subject: RE: AIN, NOBI and composition
		> > > >
		> > > > > AIN Closed flavour: Any assertion not in an
alternative
		> > > > should not be
		> > > > > applied (revised chris proposal)
		> > > >
		> > > > Chris' revised proposal doesn't say anything
about the
		> > > > absence of assertions.  It simply says that no
behaviors are
		> > > > to be applied for the alternative other than the
behaviors
		> > > > specified by the assertions in the alternative.
		> > > >
		> > > > Daniel Roth
		> > > >
		> > > > -----Original Message-----
		> > > > From: David Orchard [mailto:dorchard@bea.com]
		> > > > Sent: Tuesday, May 08, 2007 4:42 PM
		> > > > To: Ashok Malhotra; Daniel Roth;
public-ws-policy@w3.org
		> > > > Subject: RE: AIN, NOBI and composition
		> > > >
		> > > > Well, I think we need to have clear wording for
all the "alternatives"
		> > > > before the working group.
		> > > >
		> > > > The way I see it:
		> > > > AIN Vocabulary flavour: Any assertion not in a
vocabulary
		> > > > should not be applied (Original chris proposal)
AIN Closed
		> > > > favour: Any assertion not in an alternative
should not be
		> > > > applied (revised chris proposal) AIN Removal:
Any assertion
		> > > > not in alternative means nothing.  It may or may
not be applied.
		> > > >
		> > > > Cheers,
		> > > > Dave
		> > > >
		> > > > > -----Original Message-----
		> > > > > From: Ashok Malhotra
[mailto:ashok.malhotra@oracle.com]
		> > > > > Sent: Tuesday, May 08, 2007 4:29 PM
		> > > > > To: Daniel Roth; David Orchard;
public-ws-policy@w3.org
		> > > > > Subject: RE: AIN, NOBI and composition
		> > > > >
		> > > > > Dan:
		> > > > > I'm sorry, but that's not how I read it.
		> > > > >
		> > > > > My reading is that you CANNOT apply assertions
that are not in the
		> > > > > selected alternative.  That, to me feels like
negation.
		> > > > >
		> > > > > I think we shd get behind Monica's explicit
wording that eliminates
		> > > > > the fuzz factor.
		> > > > >
		> > > > > All the best, Ashok
		> > > > >
		> > > > > > -----Original Message-----
		> > > > > > From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-
		> > > > > > request@w3.org] On Behalf Of Daniel Roth
		> > > > > > Sent: Tuesday, May 08, 2007 4:12 PM
		> > > > > > To: David Orchard; public-ws-policy@w3.org
		> > > > > > Subject: RE: AIN, NOBI and composition
		> > > > > >
		> > > > > >
		> > > > > > This is exactly the problem with tying
negation semantics to the
		> > > > > > absence of assertion types (AIN).
		> > > > > >
		> > > > > > IBM's proposal fixes this by simply saying
you do what you
		> > > > > assert and
		> > > > > > nothing else (NOBI).
		> > > > > >
		> > > > > > Daniel Roth
		> > > > > >
		> > > > > > -----Original Message-----
		> > > > > > From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-
		> > > > > > request@w3.org] On Behalf Of David Orchard
		> > > > > > Sent: Tuesday, May 08, 2007 3:23 PM
		> > > > > > To: public-ws-policy@w3.org
		> > > > > > Subject: AIN, NOBI and composition
		> > > > > >
		> > > > > >
		> > > > > > I wonder about AIN, NOBI, etc. and
composition.
		> > > > > >
		> > > > > > Imagine that WS-I produces an assertion that
says a "RSPAssertion"
		> > > > > > means RMAssertion and Security, perhaps
exactly one of
		> > > > > > messageSecurity|transportsecurity.  What's
the meaning
		> > > > when some of
		> > > > > > messageSecurity|the
		> > > > > > assertions that are in the composition are
missing?  For
		> > > > example, I
		> > > > > > just say RSPAssertion.  I don't say
RMAssertion, though
		> > > > > RMAssertion is
		> > > > > > in the vocabulary.  If I get an intersection
that says
		> > > > RSPAssertion
		> > > > > > but not RMAssertion, AIN has the implication
that you
		> > > > > shouldn't apply
		> > > > > > RMAssertion yet RSPAssertion does.
		> > > > > >
		> > > > > > We don't say anything about whether an
assertion that means a
		> > > > > > behaviour "trumps" the lack of such an
assertion.
		> > > > > >
		> > > > > > With AIN, there's a problem.  Without AIN,
there's no
		> > > > > problem because
		> > > > > > there's no conflict.
		> > > > > >
		> > > > > > Cheers,
		> > > > > > Dav3e
		> > > > > >
		> > > > > >
		> > > > > >
		> > > > > >
		> > > > > >
		> > > > >
		> > > > >
		> > > >
		> > > 
		> > 
		> > 
Received on Thursday, 10 May 2007 18:32:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC