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

Re: NEW ISSUE: New Attribute keyword to identify 'local' policies #3721

From: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
Date: Tue, 31 Oct 2006 15:41:40 +0200
To: Sergey Beryozkin <sergey.beryozkin@iona.com>
Cc: Ashok Malhotra <ashok.malhotra@oracle.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, Frederick Hirsch <frederick.hirsch@nokia.com>, William Henry <william.henry@iona.com>, public-ws-policy@w3.org
Message-id: <45475294.7020505@Sun.COM>

Hi,

We are using an attribute in our product as well [visibility="private"]. 
There clearly is a need. However, these assertions or policies should 
never escape from the product specific space, i.e. I'm not clear what 
advantage it would have to standardize. The only case that I can see 
that would bring an advantage [1] is if you have implementation 
constraints that force you to publish these assertions or policies.

Fabian


[1] This case does not apply to our product.


Sergey Beryozkin wrote:
> Hi Ashok
>
> Are 'silent' assertions stripped of the provider's policies before the 
> intersection engine starts working ?
> What advantage do you think we can get if we have a standard wsp:local 
> attribute ?
>
> It appears that every vendor can have a private attribute in order to 
> mark "server-only" assertions but I'd like to think more of what the 
> advantage we can get if we can get a standard attribute like 
> wsp:local. It would be nice if we can come up with some good practical 
> examples...
>
> Thanks, Sergey
>
>
> I was talking to some of our product folks today and, it turns out,
> they use an attribute called "silent" to indicate assertions that are not
> visible to anyone outside the system and do not take part in Policy 
> intersection.
> I think this is what you want with 'local'.
>
> I agree with Umit that 'optional' does not cover this usecase.
>
> All the best, Ashok
>
>
>> -----Original Message-----
>> From: public-ws-policy-request@w3.org
>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Yalcinalp, Umit
>> Sent: Thursday, October 19, 2006 10:56 AM
>> To: Frederick Hirsch; ext Sergey Beryozkin
>> Cc: William Henry; public-ws-policy@w3.org
>> Subject: RE: NEW ISSUE: New Attribute keyword to identify
>> 'local' policies #3721
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: public-ws-policy-request@w3.org
>> > [mailto:public-ws-policy-request@w3.org] On Behalf Of
>> Frederick Hirsch
>> > Sent: Thursday, Oct 19, 2006 7:31 AM
>> > To: ext Sergey Beryozkin
>> > Cc: Frederick Hirsch; Yalcinalp, Umit; William Henry;
>> > public-ws-policy@w3.org
>> > Subject: Re: NEW ISSUE: New Attribute keyword to identify 'local'
>> > policies #3721
>> >
>> >
>> > I believe optional and advisory are different.
>> >
>> > Optional is a shortcut to provide two policy alternatives, one with
>> > and one without an assertion.
>> >
>> > I was thinking that advisory means that an optional
>> assertion does not
>> > apply to the interaction per se but is relevant to provider action
>> > (e.g. logging etc). So it could be implemented as optional
>> but has the
>> > additional semantics that it explicitly does not affect
>> what is on the
>> > wire.
>> >
>> > Whether we want this is another question.  This information can
>> > actually be part of the assertion definition, so, optional would
>> > probably be adequate by itself since the semantics can be
>> part of the
>> > assertion.
>> >
>>
>> Here is the problem. The information, even it is part of the
>> semantics of the assertion does NOT
>>
>> -- Allow you NOT to understand the assertion
>> -- Thus allow mechanical means of stripping
>>
>> Again, the problem is with the vocabulary. From a client's
>> perspective, here are the questions to ask:
>>
>> -- Do you need to understand the assertion semantics?
>> -- Can you ignore the assertion without understanding the assertion?
>> -- Can understanding the semantic of the assertion allow you
>> to ignore it and not get it involved in your matching algorithm?
>>
>> These are distinct use cases.
>>
>> Overloading the wsp:optional marker just complicates the
>> matter, because it provides a cop-out for not understanding
>> the semantics of the assertion by creating an alternative
>> that only a class of clients will understand and will engage with.
>>
>> In terms of logging, I do not believe that it should be
>> implemented by optional. Here is why.
>>
>> My company policy may be to log all the messages. So, if one
>> uses optional to designate this behavior and advertise it as such:
>>
>> -- it is a lie. The provider will log all the messages
>> anyway. It is not an optional behavior for the provider.
>>
>> -- Even the client may not need to understand it by choosing
>> the specific alternative that does not include the assertion,
>> again the client is subjected to a behavior that is not
>> advertised incorrectly.
>>
>> -- The client is not forced to understand the logging by
>> semantics as a side effect of using optional. On the other
>> hand, if logging was marked specifically (other than
>> wsp:optional="true") it would be possible for the client to
>> determine that it will or it will not use this endpoint
>> because logging is enforced. So, the marker will provide the
>> choice on the selection of an endpoint as well. After that
>> determination is made, it will also help the client to use
>> the alternative that is suitable to communicate with the
>> endpoint as the assertion can be ignored for the client
>> interaction purposes.
>>
>>
>> IMO, overloading the two cases is simply does NOT represent
>> what is required in reality and can not really be solved by
>> the semantics of the assertion. We do not have a provision to
>> to utilize the semantics of an assertion to include or not
>> include in the intersection algorithm currently.
>>
>> That is the problem I see with using optional category for
>> both optional vocabulary and optional behavior.
>>
>>
>>
>> > Thus I suspect we do not need the advisory attribute, or am I
>> > forgetting something?
>>
>> See above,
>>
>> >
>> > regards, Frederick
>> >
>> > Frederick Hirsch
>> > Nokia
>> >
>>
>> --umit
>>
>> >
>> > On Oct 19, 2006, at 2:36 AM, ext Sergey Beryozkin wrote:
>> >
>> > > Hi Umit
>> > >
>> > > "It is my understanding that presence of wsp:local or
>> wsp:advisory
>> > > would provide the same functionality."
>> > >
>> > > No, as far as I understand it won't. wsp:local mark
>> assertions which
>> > > should be stripped off by a provider and if a provider
>> can't do it
>> > > then they must be ignored completely by a requester.
>> > >
>> > > wsp:advisory is similar, but it's more loose in that it permits a
>> > > client to actually *optionally* use the assertion, to optionally
>> > > include in the intersection algorithm, etc.
>> > >
>> > > that's the same as wsp:optional. Perhaps the semantical
>> meanings are
>> > > different between wsp:optional and wsp:advisory but in
>> the end both
>> > > would permit the client to optionally choose an assertion and do
>> > > something about it. IMHO they'd overlap and more
>> confusion and hence
>> > > more complexity.
>> > >
>> > > Actually, I think wsp:advisory is what wsp:optional is, they're
>> > > identical in my naive view. wsp:advisory *advises* the
>> requester and
>> > > this is something a provider is additionally capable of
>> (accepting
>> > > mtom messages, being replicatable, etc) and a requester
>> is free to
>> > > notice it and do something about it or ignore it.
>> > >
>> > > wsp:local is not the same as wsp:advisory.
>> > > wsp:optional is not the same as wsp:local wsp:optional is
>> similar to
>> > > wsp:advisory
>> > >
>> > > Modified wording for wsp:optional would be a simpliest and non-
>> > > ambiguous solution IMHO.
>> > > If a policy author wants an assertion be visible then this is
>> > > assertion is either optional or not optional.If it's
>> optional then
>> > > it's advisory to client in that a client free to notice it and do
>> > > something about it.
>> > > If a policy author does not want an assertion be visible to an
>> > > ultimate requester then it's wsp:local.
>> > >
>> > > I'd prefer :
>> > > wsp:optional and wsp:local
>> > > or
>> > > wsp:advisory and wsp:local
>> > >
>> > > Thanks, Sergey
>> > > ----- Original Message -----
>> > > From: Yalcinalp, Umit
>> > > To: Sergey Beryozkin ; William Henry
>> > > Cc: Frederick Hirsch ; public-ws-policy@w3.org
>> > > Sent: Wednesday, October 18, 2006 8:30 PM
>> > > Subject: RE: NEW ISSUE: New Attribute keyword to identify
>> 'local'
>> > > policies #3721
>> > >
>> > > It is my understanding that presence of wsp:local or wsp:advisory
>> > > would provide the same functionality. So, the question is
>> to come up
>> > > with an appropriate name everyone agrees.
>> > >
>> > > --umit
>> > >
>> > >
>> > > From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
>> > > Sent: Wednesday, Oct 18, 2006 10:28 AM
>> > > To: William Henry
>> > > Cc: Frederick Hirsch; Yalcinalp, Umit; public-ws-policy@w3.org
>> > > Subject: Re: NEW ISSUE: New Attribute keyword to identify
>> 'local'
>> > > policies #3721
>> > >
>> > > HI William
>> > >
>> > > "The idea of using this as a mechanism for providers to strip on
>> > > configuration information gets weaker - especially when
>> making the
>> > > above argument.  "How do it know?" ;-) to strip or not to strip?
>> > >
>> > > That ideas was that wsp:local would provide a consistent approach
>> > > for providers to have a way of stripping out such local policies
>> > > before publishing. But how do you distinguish between
>> those that get
>> > > stripped out and those that get advertised."
>> > >
>> > > Just don't put wsp:local on those assertions you want to make
>> > > visible to requesters.
>> > > I think what you're talking about is very close to waht Frederick
>> > > suggests with awsp:advisory attribute. They mark assertions of
>> > > interest to providers, clients might choose to notice it or
>> > ignore it.
>> > >
>> > > So suppose we have wsp:advisory, I thinbk it would be a
>> > better name
>> > > then.
>> > > And we also have wsp:optional which can be used to mark
>> assertions
>> > > which a requester can choose to ignore.
>> > >
>> > > I think we'll have an overlap and more confusion as a result. I
>> > > think I like wsp:advisory, just feeling that if we adopt a new
>> > > attribute overlapping with wsp:optional then we'll have more
>> > > complexity in the end
>> > >
>> > > I believe it will be simplier if a wording for wsp:optional is
>> > > updated given that wsp:optional is about assertions which
>> are not
>> > > optional for a provider but optional for a requester to
>> consume... .
>> > >
>> > > Cheers, Sergey
>> > > ----- Original Message -----
>> > > From: William Henry
>> > > To: Beryozkin, Sergey
>> > > Cc: Frederick Hirsch ; Yalcinalp, Umit ; public-ws-policy@w3.org
>> > > Sent: Wednesday, October 18, 2006 6:05 PM
>> > > Subject: Re: NEW ISSUE: New Attribute keyword to identify
>> 'local'
>> > > policies #3721
>> > >
>> > > Hi folks,
>> > >
>> > > The more I think about this the more I'm convinced that
>> it is more
>> > > appropriate for advertising features or qualities of
>> service that
>> > > do not require action by the consumer. So using an
>> earlier example
>> > > that Sergey used with a modification
>> > >
>> > >  <wsdl:port>
>> > >  <soap:address location="http://foo"/>
>> > >  <wsp:Policy>...
>> > >    <sp:HTTPSToken/>
>> > >    <custom:HighAvailability wsp:local="true"/>
>> > >  </wsp:Policy>
>> > > </wsdl:port>
>> > >
>> > > Though HighAvailability might require the server to do
>> some extra
>> > > configuration the reason for putting it in the WSDL is not for
>> > > configuration but for providing extra information that MAY be of
>> > > interest to the consumer but would NOT prohibit the
>> consumer from
>> > > using the service if they can't understand it - they can
>> ignore it.
>> > >
>> > > The idea of using this as a mechanism for providers to strip on
>> > > configuration information gets weaker - especially when
>> making the
>> > > above argument.  "How do it know?" ;-) to strip or not to strip?
>> > >
>> > > That ideas was that wsp:local would provide a consistent
>> approach
>> > > for providers to have a way of stripping out such local policies
>> > > before publishing. But how do you distinguish between those that
>> > > get stripped out and those that get advertised.
>> > >
>> > > Furthermore people in this group would say that that is
>> really up
>> > > to the implementor and they can be responsible. (Dan holds this
>> > > position)
>> > >
>> > > HOWEVER, in this case this is also the issue of portability. A
>> > > provider that is using policies defined by another vendor
>> that has
>> > > significance for the provider but not for the consumer
>> would like
>> > > to understand how to handle this consistently. So for
>> third party
>> > > policies one can imagine that a consistent way of
>> stripping these
>> > > out would be useful.
>> > >
>> > > So then does wsp:local (or whatever it's name is) have
>> > true, false,
>> > > provideronly ??????? Otherwise how do we distinguish between
>> > > advertise-as-a-feature Vs. provider-should-strip-before-publish?
>> > >
>> > > Regards,
>> > > William
>> > >
>> > >
>> > > On Oct 6, 2006, at 3:17 AM, Beryozkin, Sergey wrote:
>> > >
>> > >> Hi Frederick,
>> > >>
>> > >> Sorry for a late response.
>> > >>
>> > >> First of all I'd like to draw a line between wsp:optional and
>> > >> something like wsp:local. We do not see any relationship
>> between
>> > >> wsp:optional and wsp:local.
>> > >>
>> > >> The differentiator between wsp:local and wsp:optional is
>> simple.
>> > >> wsp:local marks assertions which are only intended for a
>> > provider.
>> > >> Provider *should do the best effort to strip such
>> assertions out*
>> > >> of the policy to be published. If such an assertion is
>> > leaked then
>> > >> the only thing the client knows about it is that it has to
>> > skip it
>> > >> and move on to the next assertion. Client may choose to
>> notice it
>> > >> but there're absolutely no obligations on the provider's
>> > behalf as
>> > >> to whether this assertion will be honoured or not.
>> > >> wsp:local assertions are not the ones WS-Policy
>> framework primer
>> > >> talks about when recommending best practices for policy
>> authors.
>> > >> Good interoperatable policy assertion is the one which is
>> > >> understood and used by both parties involved. So why do we even
>> > >> want to create a noise in the WS-Policy space with
>> wsp:local ? We
>> > >> feel there might some scenarios which I'll address in a
>> follow-up
>> > >> message...
>> > >>
>> > >> On the contrary wsp:optional and the whole optionality tar
>> > ball is
>> > >> about assertions which may be of use for requesters. wsp:local
>> > >> assertions may not be of use for requesters.
>> > >>
>> > >> Optionality is a hint to a requestor. >From the
>> provider's point
>> > >> view wsp:optional assertions are not optional at all, it
>> > >> guarantees to support them.
>> > >>
>> > >> Given what I've said I'd like to say that I agree with
>> some parts
>> > >> of your message but here're two parts which I'n not happy
>> > about :-) :
>> > >>
>> > >> > 2) The client can choose to include or not in intersection
>> > >> operation,
>> > >> > depending on interest.
>> > >> I don't think wsp:local assertions can be of any interest to a
>> > >> client. I don't think we need a new attribute like
>> wsp:local for
>> > >> assertions which a client may want to do something
>> useful about.
>> > >> Policy alternatives/wsp:optional will do just fine for
>> > this to work.
>> > >>
>> > >> > Without wsp:local/wsp:optional all assertions MUST be
>> included in
>> > >> > intersection operation.
>> > >> Please see above. Lets just draw the line between wsp:local and
>> > >> wsp:optional :-)
>> > >>
>> > >> > 3) This is additional information that a client might wish to
>> > >> consider.
>> > >> Please see above. If it is of any use to a client then
>> it's not a
>> > >> wsp:local assertion
>> > >>
>> > >> Thanks, Sergey
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> > Sergey
>> > >> >
>> > >> > It was mentioned by Fabian on the call today that different
>> > >> > assertions can have different properties, and I think
>> > this is where
>> > >> > we are heading with wsp:local/wsp:advisory (alternative names
>> > >> for the
>> > >> > same concept and attribute)
>> > >> >
>> > >> > In general an assertion present in a policy assertion
>> > means that
>> > >> the
>> > >> > client MUST understand that assertion and that the
>> provider WILL
>> > >> > support it. This is regardless of whether the assertion
>> > has a wire
>> > >> > implication.
>> > >> >
>> > >> > Using wsp:optional enables policy alternatives to be easily
>> > >> created,
>> > >> > either requiring and asserting the assertion and not.
>> > >> >
>> > >> > However there are cases where wsp:optional is not what
>> > is desired,
>> > >> > and where wsp:local/wsp:advisory is needed.
>> > >> >
>> > >> > The use case is that a provider should be able to state an
>> > >> assertion
>> > >> > that will be in effect, but it obeys the following properties:
>> > >> >
>> > >> > 1) It can safely be ignored by web service client,
>> even though
>> > >> true.
>> > >> > The provider is making no obligation to the client. It has no
>> > >> > essential impact on a contract between client and provider.
>> > >> >
>> > >> > An example is an assertion that server logging is
>> performed (e.g.
>> > >> > clients might not care about it, but it is *not*
>> optional in the
>> > >> > sense that the server *will* do it).
>> > >> >
>> > >> > 1a) Assertions that imply mutual contract between client and
>> > >> provider
>> > >> > cannot be wsp:local/wsp:advisory. These include
>> > >> >
>> > >> > + Assertions that impact wire formats
>> > >> > + Assertions that define quality of service (service level
>> > >> > agreements), quality/reliable messaging.
>> > >> >
>> > >> > 2) The client can choose to include or not in intersection
>> > >> operation,
>> > >> > depending on interest.
>> > >> > Without wsp:local/wsp:optional all assertions MUST be
>> included in
>> > >> > intersection operation.
>> > >> >
>> > >> > 3) This is additional information that a client might wish to
>> > >> consider.
>> > >> >
>> > >> > we need to distinguish optional for agreement of a
>> > contract with or
>> > >> > without an asserted requirement/capability and
>> > informational items
>> > >> > that are not necessarily optional.
>> > >> >
>> > >> > regards, Frederick
>> > >> >
>> > >> > Frederick Hirsch
>> > >> > Nokia
>> > >> >
>> > >> >
>> > >> > On Oct 4, 2006, at 4:30 AM, ext Sergey Beryozkin wrote:
>> > >> >
>> > >> >> Hi
>> > >> >>
>> > >> >> Reference to the thread[1] is misleading IMHO.
>> > >> >> I was stating from the start that a proposed wsp:local
>> > was nothing
>> > >> >> to do with what is discussed in that thread. The semantics of
>> > >> >> wsp:local are : mark assertions which *must be ignored* by a
>> > >> >> requester. That is it, no more semantics...
>> > >> >>
>> > >> >> Thanks, Sergey
>> > >> >> ----- Original Message -----
>> > >> >> From: Yalcinalp, Umit
>> > >> >> To: public-ws-policy@w3.org
>> > >> >> Sent: Tuesday, October 03, 2006 11:44 PM
>> > >> >> Subject: Re: NEW ISSUE: New Attribute keyword to
>> > identify 'local'
>> > >> >> policies #3721
>> > >> >>
>> > >> >>
>> > >> >> There has been a lot of discussion on Issues 3721 and
>> 3564. I am
>> > >> >> posting this response to this thread in order to
>> illustrate why
>> > >> >> there are two separate issues that need to be tackled
>> > >> >> independently. However, they are NOT the same issue.
>> > >> Utilization of
>> > >> >> optional assertions is a separate concern and those
>> > issues must
>> > >> not
>> > >> >> be lumped together.
>> > >> >>
>> > >> >> Please find some comments in a different thread that
>> > explains why
>> > >> >> there are two separate issues here for the details [1].
>> > >> >>
>> > >> >> Thanks,
>> > >> >>
>> > >> >> --umit
>> > >> >>
>> > >> >> [1]
>> > http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/
>> > >> >> 0016.html
>> > >> >>
>> > >> >> ----------------------
>> > >> >>
>> > >> >> Dr. Umit Yalcinalp
>> > >> >> Architect
>> > >> >> NetWeaver Industry Standards
>> > >> >> SAP Labs, LLC
>> > >> >> Email: umit.yalcinalp@sap.com Tel: (650) 320-3095
>> > >> >> SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
>> > >> >> --------
>> > >> >> "First they ignore you, then they ridicule you,
>> > >> >> then they fight you, then you win." Gandhi
>> > >> >>
>> > >> >>
>> > >> >
Received on Tuesday, 31 October 2006 13:41:24 GMT

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