- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Tue, 31 Oct 2006 16:51:19 -0800
- To: "William Henry" <william.henry@iona.com>, <public-ws-policy@w3.org>
- Cc: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, "Ashok Malhotra" <ashok.malhotra@oracle.com>, "Frederick Hirsch" <frederick.hirsch@nokia.com>, "Fabian Ritzmann" <Fabian.Ritzmann@Sun.COM>
- Message-ID: <2BA6015847F82645A9BB31C7F9D64165028D5DB0@uspale20.pal.sap.corp>
William, Please read my email before you make this proposal. It seems you are misrepresenting the existence of an agreement that does not exist or perhaps have not seen my response. We do not agree on closing this with no action. This has nothing to do with wsp:optional. --umit [1] http://lists.w3.org/Archives/Public/public-ws-policy/2006Oct/0205.html ________________________________ From: William Henry [mailto:william.henry@iona.com] Sent: Tuesday, Oct 31, 2006 4:47 PM To: public-ws-policy@w3.org Cc: Sergey Beryozkin; Ashok Malhotra; Yalcinalp, Umit; Frederick Hirsch; Fabian Ritzmann Subject: 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 >> > >> >> >> > >> >> >> > >> >
Received on Wednesday, 1 November 2006 00:52:44 UTC