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