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

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
> >> > >> >>
> >> > >> >>
> >> > >> >
>
>
>