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

I see no resolution to this issue from the f2f.

The discussion today was limited to 3789 from everything I could  
tell. Nobody made reference to 3721 as far as I can tell.

There was reference to "Ashok's wsp:local" which I assumed to mean  
that Ashok was proposing wsp:local for the problem we were discussing  
on at the f2f which was the 3789 problem.

I remember people specifically saying that 3789 and 3721 are different.

So when can we discuss wsp:local ?

Regards,
William

William G Henry
Enterprise Architect, Technical Director, Alliances    |    IONA  
Technologies Inc.
Phone (719) 302 2302    |    Mobile: (719) 640 6868    |    e-mail:  
william.henry@iona.com
Blog: www.ipbabble.com

The SOA Revolution
On-Demand Webcast hosted by IONA, featuring Gartner, Inc
http://www.accelacast.com/webcasts/gartner_iona/


On Oct 31, 2006, at 5:46 PM, William Henry wrote:

> Having watched the discussion for a while and seeing some of the  
> input I propose that I close #3721 without action and revise in  
> v.next.
>
> It seems we alll agree that proprietary attributes suffice for the  
> moment and we can review the need for something called/like  
> wsp:local in the next version.
>
> Unless there is an objection I'll close this tomorrow with the  
> chair's direction.
>
> This is not about the wsp:optional (/wsp:advisory) issue.
>
> Regards,
> William
>
>
> On Oct 31, 2006, at 6:41 AM, Fabian Ritzmann wrote:
>
>>
>> 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
>> >> > >> >>
>> >> > >> >>
>> >> > >> >
>>
>>
>>
>