W3C home > Mailing lists > Public > public-ws-policy@w3.org > October 2006

RE: Simplifying the meaning of assertions and wsp:optional

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 3 Oct 2006 15:38:01 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D64165024DDD14@uspale20.pal.sap.corp>
To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, "Sverdlov, Yakov" <Yakov.Sverdlov@ca.com>, <public-ws-policy@w3.org>
Sergey, 
 
The problem is two things are being mixed. There are two issues.
Optional vocabulary, and optional behaviors. 
 
(1) What is the vocabulary that the providers like to express to
consumers when they use the assertions. Note that this means the
vocabulary must be understood by the consumer. I believe this is the
scope of the Issue [3721]. The issue there is to be selective about the
vocabulary and thus not constrain the consumers to understand the
vocabulary. (OPTIONAL VOCABULARY) 
 
(2) Once the vocabulary is agreed on, what are the optional behaviors
that the consumers can choose from ? (OPTIONAL BEHAVIORS)
 
IMO, optional assertions is not a caveat for consumers NOT to understand
a vocabulary, but it is tempting to do so because we have a problem in
(1). We do not have a way to express it adequately today.  Note that
there are many ways to solve (1). Just to name a few: 
 
(a) invent a new marker and designate assertions that do not contribute
to the vocabulary explicitly. local/advisory, whatever we call it in the
end as proposed in the issue itself. 
 
(b) Explicitly state the vocabulary of the policy expressions in the
parent by a list. 
 
(c) Design an attachment mechanism to refer to a policy where the
"advisory/local/noncontributing" assertion applies separately or inline.

 
We at SAP acknowledge this problem and are much in favor of working
towards a solution of (1) for Issue [3721]. We have found in our
products many use cases that we need to mark assertions that we do not
want to require the consumers to understand the assertion. It is a
problem of interoperability. 
 
Once the vocabulary is agreed, meaning the consumers understand the
vocabulary but can engage the behaviors to their choosing, there are
still problems with using optional="true" assertions with this semantic.
The original scope of the problem for optional assertions, Issue [3564]
intended to address the second category, namely (2). I have a proposal
to solve the second category which I will send separately which
addresses the pitfalls of using optional assertions shortly. 
 
I am very concerned that the optional="true" assertion is regarded as a
workaround to bypass the requirement of a mutually agreed vocabulary and
thus cheating to accomplish the former,  not the latter. We should not
mix these. The wg may or may not have time to address Issue 3721
appropriately, but that should not prevent us to acknowledge that these
concerns are separate as altering a consumers view of a vocabulary is a
precursor to whether an assertion in the agreed vocabulary is deemed to
target optional behaviors. 
 
Cheers, 
 
--umit
 
 
[3721] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3721
[3564] http://www.w3.org/Bugs/Public/show_bug.cgi?id=3564
 


________________________________

	From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
	Sent: Monday, Oct 02, 2006 7:19 AM
	To: Sverdlov, Yakov; Yalcinalp, Umit; public-ws-policy@w3.org
	Subject: Re: Simplifying the meaning of assertions and
wsp:optional 
	
	
	Hi
	 
	Looks like I'm already -3 due to big -1 from Umit :-)
	 
	Seriously though, I feel we're getting sidetracked again. Yakov,
This is a very interesting and useful message, thanks, finally I
actually started understanding better what you were talking about in the
other email...
	 
	The thing is I've never ever proposed to drop optionality. I
proposed to *drop wsp:optional*. We treat wsp:optional as being equal to
Optionality, as if without it optionality doesn't exist or indeed we
can't do policies without it. It's completely not true.
	 
	How would you interpret the following normal expression :
	<Policy>
	 <ExactlyOnce>
	    <All><foo/><bar/></All>
	    <All><bar/></All>
	</Policy>
	 
	Isn't it obvious we have <foo/> as an optional assertion ?
wsp:optional is just a shortcut, it's just a little helper for a compact
form editor. But yet we look at it as some special attribute which
brings some additional semantics we can't live without, etc, etc...What
is this complexity for ? One can easily express optionality without
it...
	 
	I have a very simple, basic and valid case IMHO. I just want my
service be searcheable. No sophisticated scenarious, just want my
service be selectable. I'd like to say that my service is the most
responsive service and I'd like those who understand to use it as a base
for the selection. 
	I don't want people saying that it's completely wrong to say
<oasis:fastestToReply wsp:optional="true"/>, because according to the
current wording it's indeed looks strange... 
	 
	So please don't regard my proposal as a proposal to drop
Optionality. The proposal was about improving the wording for
wsp:optional or dropping wsp:optional.
	 
	But as I said in my reply to Umit, I'd happy if a wording is
changed appropriately, so that a policy author can freely advertize
assertions like <oasis:fastestToReply/> without feeling wsp:optional is
misused...
	 
	Enjoy, Sergey
	 
	 

		
		

		+1 to Umit. I think the optionally should stay.

		 

		Just summarizing the problem and also responding on the
different email threads related to the issue 3564: "Optional Assertions
may not be usable..." I think that trying to interpret the Framework
policies in the context of the requester/provider and
requirements/capabilities, and to separate policy semantics with regard
to requester and provider, seems to be counterproductive because of the
three fundamental problems:

		1. Presence of intermediaries between requester and
provider (always)

		2. Multiple entities, requester and provider consist of
(almost always)

		3. Bidirectional nature of messages/transactions
(always)

		 

		#1 and #2 were already illustrated by the HTTPS/HTTP
example, which clearly shows that a "requirement" may be imposed on the
requester without taking into account the provider's "capabilities"
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0179.html

		 

		Let's look at another typical example (authentication
domain) to show that the provider capabilities may not necessarily
impose any requirements on the requester: 

		A provider's policy may specify WS-Security token with
the SAML profile as the only acceptable authentication scheme. Let's
assume that the client application "knows" about the policy. Does this
mean that the requester must generate the token and attach it to the
request? I don't think so. Some intermediary may be involved which would
generate the token from credentials provided by the requester. One can
argue that the intermediary becomes the actual "requester" but not the
client app, and after this we can get into a discussion about whether
the intermediary is actually a "provider" for the client app. Just to
make it a little bit more complicated - in the context of the same
scenario we can specify a second policy for the intermediary to generate
the WS-Security token. So the intermediary definitely becomes the
requester and the provider at the same time. 

		 

		As for #3, I think the REST scenario proves the same
point - that trying to resolve these definition issues above just
unnecessarily complicates things.

		 

		In my previous email
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0154.html I
stated that the requester/provider and requirements/capabilities
paradigm may be applicable to some policy domains. At this point, I
don't see which policy domain requires this. The problem with
wsp:optional only exists in the
"requester/provider/requirements/capabilities" context. Using the
'behavior' and 'subject' concepts in conjunction with creating multiple
assertions, alternatives and policies, and using the specification's
merge and intersection mechanisms, should be sufficient to support the
wide variety of use cases. The issue of a policy covering one or more
entities (and possible relationship between the entities) should be (and
can be) handled at the policy domain level and/or by the enterprise
architecture.

		 

		Email threads - I apologize in advance if I missed
somebody:

	
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0198.html

	
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0205.html

	
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0202.html

	
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0172.html

	
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0197.html

		 

		Regards,

		 

		Yakov Sverdlov

		CA

		 

		 

		
________________________________


		From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
		Sent: Sunday, October 01, 2006 8:37 PM
		To: Sergey Beryozkin; public-ws-policy@w3.org
		Subject: RE: Simplifying the meaning of assertions and
wsp:optional 

		 

		A Big -1 to dropping Optionality. It is completely
backwards incompatible with the current practice and existing
assertions. Our charter indicates that we should retain backwards
compatibility as a goal. 

		 

		Explaination of what it is should not require us to drop
the functionality. 

		 

		I will write more about some wording suggestings in a
different email.  

		 

		--umit

		 

			 

			
________________________________


			From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
			Sent: Friday, Sep 29, 2006 9:05 AM
			To: public-ws-policy@w3.org
			Subject: Simplifying the meaning of assertions
and wsp:optional 

			Hi there

			 

			After reading and reflecting on a lot of
interesting messages on what wsp:optional means, on what is the
differences between requirements and capabilities are and what
provideres and requestors should do about various types of assertions,
I'd like to offer to your attention a modest proposal on simplifying the
way assertions and wsp:optional are covered in the WS-Policy Framework
and primer/policy guidelines. This is all really based on what I've
learnt form the others while reading those emails and from the spec... 

			 

			The following is how (in a simplistic way) we
might want to talk about assertions and wsp:optional.

			 

			1. Any policy assertion, either marked as
optional or not, is first and foremost is a requirement. It's a
requirement to a requester to understand it and do something about it.
What is it that a requester should do is part of a policy assertion
documentation/spec. 

			In many cases a requirement would require a
requester to make a commitment to engage in some kind of activity
(direct or out-of-band) during the interaction.

			Alternatively, a requirement can simply be "to
understand it and use it for choosing a given provider among other
providers". In a sense, a requester should do nothing here but use it
during the selection process, and this in itself encapsulates a
requirement : an ability to use it during the selction process.

			 

			Requirement is a capability and should be used
interchangeably. It's a capability because it is something a provider
knows about and can do something about. It's a requirement because a
client needs to do something about it (engaing in a behavior, using for
selction, etc )

			 

			2. Assertion may or may not be optional. This
*only* means that a requester is given an option to ignore a given
requirement. No assertion can be ignored by a provider. Provider is
guaranteed to support all assertions. Optionality is something which is
only for a requester to worry about.

			 

			3. Assertions must be understood by both
parties. Spec says about it already, but it's worth highlighting it.

			 

			Given above 3 points, we can state that an
assertion like sp:HttpsToken and oasis:replyInTenSecs are equal
WS-Policy citizens because in both cases there's something a client can
do about them. In the former case

			a client will understand that it needs to use
HTTPs in order to be able to talk a provider. In the latter case a
client will understand that a service is very responsive and might use
this fact as a basis for choosing this provider among others.

			 

			Now about wsp:optional (based on above 3
points).

			 

			Two options are proposed :

			Option1. Retain wsp:optional but explain that
wsp:optional is just a syntactic shortcut to nominate a requirement as
being optional for a requester to understand/do anything about. As well
captured elsewhere, at the moment an optional "capability" in a compact
form suddenly becomes a requirement in a normal form. This is confusing.
wsp:optional is a way to nominate an optional requirement. 

			 

			Option2. (Preferred) Drop wsp:optional
altogether. Why ? Because IMHO it doesn't bring anything useful but the
complexity. It makes it more complex for a policy engine to convert a
policy alternative from a compact form to a normal one, and for policy
authors to understand how to work with it and when it's appropriate to
use it. 

			Lets explain clearly that for a given
assertion/requirement be optional it should be avalable in one
alternative and not in the other one and this is all... It will add a bt
more work for a policy author, but IMHO not a lot.

			 

			Finally :

			 

			Point 2 above refers to oasis:replyIn10Secs
assertion. A client can not really do  something about it as far as the
interaction is concerned, but it still can do something about it : use
it to select a provider, for ex. For such assertions not to interfere
with those policy-aware clients which are not aware of what
oasis:replyIn10Secs means and which may or may not have some priory
polic requirements, we should recommend that when possible, policy
authors should attempt to give an option to ignore such assertions by
using policy alternatives as appropriate. Note no 'optional' qualifier
is used here :-)

			 

			So that's it... Does it make it a bit simplier ?
Criticize away please :-)

			 

			 

			Cheers, 

			Sergey Beryozkin

			Iona Technologies

			 

			 
Received on Tuesday, 3 October 2006 22:33:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:42 GMT