- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Tue, 7 Nov 2006 21:15:17 -0800
- To: "William Henry" <william.henry@iona.com>, <public-ws-policy@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D64165029C8F6A@uspale20.pal.sap.corp>
William, I did not see our chairs respond, but i do not think that is an accurate characterization. Apologies if it was not clear in the minutes as I was also the scribe and defending the proposal. After a long discussion, there were 7 different proposals on the board. As Chris Ferris also stated during the meeting, the 7 options on the board reflected options that address generally all the use cases that we had covered up to that point and what needs to be standardized. There is a consensus point that was reached by a mini group that will present the results tomorrow that were trying to reconcile the options on the board. I personally think you should wait until that presentation/discussion is done to see whether you agree/disagree with that direction, etc. --umit ________________________________ From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of William Henry Sent: Tuesday, Nov 07, 2006 4:08 PM To: public-ws-policy@w3.org Subject: 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 >> > >> >> >> > >> >> >> > >> >
Received on Wednesday, 8 November 2006 05:16:10 UTC