- From: Mark Little <mark.little@jboss.com>
- Date: Fri, 22 Sep 2006 11:13:25 +0100
- To: Sergey Beryozkin <sergey.beryozkin@iona.com>
- Cc: "William Henry" <william.henry@iona.com>, "Maryann Hondo" <mhondo@us.ibm.com>, "Anthony Nadalin" <drsecure@us.ibm.com>, <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>
- Message-Id: <96525392-ADAE-4133-8466-FF80A92DD932@jboss.com>
I can see some advantages and disadvantages to this. I like and agree with the intention. However, as William pointed out, this can be accomplished already, albeit in a slightly skewed way using wsp:optional. But obviously that should prevent us trying to fix a perceived deficiency in the specification. Unfortunately I think this could be a major can-of-worms, worthy of its own specification! Mark. On 22 Sep 2006, at 11:03, Sergey Beryozkin wrote: > Minor omission : > > "Making such policy assertion as <oasis:QOSGuarantee> would > unnecessarily limit the audience of this service." > > I missed a phrase there, should be > > "Making such policy assertion as <oasis:QOSGuarantee> *non- > optional* would unnecessarily limit the audience of this service." > > Cheers, Sergey Beryozkin > Iona Technologies > ----- Original Message ----- > From: Sergey Beryozkin > To: William Henry > Cc: Maryann Hondo ; Anthony Nadalin ; public-ws-policy@w3.org ; > public-ws-policy-request@w3.org > Sent: Friday, September 22, 2006 10:51 AM > Subject: Re: Policy expressions with no wire manifestation > > Hi all, > > After thinking a bit more about policies which express capabilities > with no wire manifestations and no associated behaviours expected > from a consumer of such policies, I came to some conclusion. > > Here's an example : > > wsp:Policy> > <wsp:ExactlyOnce> > <wsp:All> > <!--- security assertion --> > <sp:HttpsToken/> > </wsp:All> > <wsp:All> > <!-- capability assertion --> > <oasis:QOSGuarantee> > <NeverEverFails/> > </oasis:QOSGuarantee> > <!--- security assertion --> > <sp:HttpsToken/> > </wsp:All> > <wsp/ExactlyOnce> > <wsp:Policy> > > A policy designer wishes to tell to ws-policy aware entities out > there that they must be able to use HTTPS should they attempt to > start communicating with the service. > Futhermore, a policy designer wishes to tell that the service has a > well-known capability to never fail, but is careful to ensure that > the entities not aware of what this means but still meeting a key > requirement of being able to use HTTPS can still enjoy > communicating with this service. A policy author achives this by > creating two policy alternatives. > The reason is simple : <oasis:QOSGuarantee> assertion is not a > requirement but a capability which has no wire manifestations and > behavioural requirements for the entities which can understand what > it means. > > In fact, the above expression, being in a normal form, is > equivalent to this compact expression : > > wsp:Policy> > <wsp:ExactlyOnce> > <sp:HttpsToken/> > <oasis:QOSGuarantee wsp:optional="true"> > <NeverEverFails/> > </oasis:QOSGuarantee> > <wsp/ExactlyOnce> > <wsp:Policy> > > Making such policy assertion as <oasis:QOSGuarantee> would > unnecessarily limit the audience of this service. A requester > entity should never fail if it does not understand what > <oasis:QOSGuarantee> given the fact the only thing it can ever do > with it is to note that this service posesses the advertised > quality and see whether it meets its selection criteria or not. > > For example, if a requester searches for services which are known > to publish its message logging traces to a well known external site > it shoud be sufficient for it to be able to recognize a well known > <common:publishTraces href="..."/> rather than fail due to the fact > <oasis:QOSGuarantee/> is not recognized. Likewise those searching > for never failing services should be able to consume those who > assert it and not fail should they not recognize > <common:publishTraces href="..."/>. > > This brings me to a simple conclusion : Policy authors SHOULD be > encouraged to use wsp:optional when using policy asssertions which > advertise capabilities with no associated behavioral requirements > and wire representations in order to widen the service's audience > and improve interoperability. wsp:optional means here that it's a > capability which *may* be used for a service selection. I believe > guidelined for policy authors should be updated. > > At the moment the WS-Policy Framework (primer) uses wsp:optional to > mark assertions which identify behaviours which *may* be engaged. > It refers to such assertions as 'capabilities'. IMHO it's not the > best/too broad the definition and it will cause confusions. For > ex : <mtom:OptimizedMimeSerialization wsp:optional="true"/>. I feel > it's better be additionally categorised as an optional requirement. > > Any thoughts or objections ? > > Likewise an assertion like <sp:MustSupportRefKeyIdentifier /> does > not fall into this category because a policy author *requires* a > consuming entity to understand it, ortherwise the secure processing > on either side will fail. > > Thanks, Sergey Beryozkin > Iona Technologies > > > It is my understanding that people are using the wsp:optional to > handle this. So if the requester (consumer) doesn't know about it > they can ignore it. > > This works BUT it is really using wsp:optional in an unintended > way. The truth is that such an assertion is not really optional > it's only optional in the sense that the requester can ignore it > however the provider must be providing this level of service and > the requester must do nothing - so in that sense it really isn't > optional it's just a handy use of the wsp:optional. > > This is one of the reasons I think there could be another attribute > missing (like the wsp:local). > > Another reason for having such an attribute would be for the > generic engine to be able to handle such a thing consistently in > all implementations. e.g. if I had a wh:local then I'd be forcing > the requester to either know about my namespace or assume that they > can't use this service. I think it can just make things messier > than they need to be. > > Having said all that I understand the effort that introducing a new > attribute would mean and seeing as you can get a similar affect > using things like wsp:optional (albeit in an unintended way) I > expect push back on the idea. > > Regards, > William > > On Sep 20, 2006, at 11:46 AM, Beryozkin, Sergey wrote: > >> Hi Maryann, others >> >> this is most helpful... >> >> "I would note that if you're "using the assertion for selection", >> it could >> imply that you know what it is." >> >> Ok, I think I start understanding it (fingers crossed :-)). A >> requester runtime may be required to select services which are >> highly available. It expects providers to advertize well-known >> <oasis:HighlyAvailable/> assertions. If a provider advertizes a >> policy which have no <oasis:HighlyAvailable/> assertions then the >> intersection will fail. I think it's reasonable. >> >> Now consider a different case. >> A requester runtime has no priori policy requirements. However it >> understands all well-known security assertions but no others ones. >> It has found a service which requires that a requester supports >> some security policies. >> >> Futhermore, a provider wishes to advertize some of its >> capabilities, namely that it's the best service around. A >> requester does not know yet about such assertions and is not even >> planning to use assertions like this for services selection. >> >> How would we do it ? >> >> Like this ? : >> >> <wsp:Policy> >> <wsp:ExactlyOnce> >> <wsp:All> >> <!--- security assertion --> >> <sp:HttpsToken/> >> </wsp:All> >> <wsp:All> >> <!-- capability assertion --> >> <oasis:QOSGuarantee> >> <TheBestServiceInThisCategory verifiedBy="..."/> >> </oasis:QOSGuarantee> >> <!--- security assertion --> >> <sp:HttpsToken/> >> </wsp:All> >> <wsp/ExactlyOnce> >> <wsp:Policy> >> >> Thanks, >> Sergey Beryozkin >> Iona Technologies >> >> ----- Original Message ----- >> From: Maryann Hondo >> To: Sergey Beryozkin >> Cc: Anthony Nadalin ; public-ws-policy@w3.org ; public-ws-policy- >> request@w3.org ; Sergey Beryozkin >> Sent: Wednesday, September 20, 2006 2:17 PM >> Subject: Re: Policy expressions with no wire manifestation >> >> >> Sergey, >> I responded to your other mail ...so this is a bit of a repetition. >> >> In the guidelines document, Umit and I have attempted to capture >> "observations" about the use of optional, and this might >> be a case where it would be useful. I would note that if you're >> "using the assertion for selection", it could >> imply that you know what it is. Whether or not it is required on >> the wire is a facet of the behavior associated with the assertion. >> Each set of authors is given a set of tools by the specifications, >> but the authors need to craft the assertions. >> >> Maryann >> >> >> >> "Sergey Beryozkin" <sergey.beryozkin@iona.com> >> Sent by: public-ws-policy-request@w3.org >> 09/20/2006 05:35 AM >> >> To >> "Sergey Beryozkin" <sergey.beryozkin@iona.com>, Anthony Nadalin/ >> Austin/IBM@IBMUS >> cc >> <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org> >> Subject >> Re: Policy expressions with no wire manifestation >> >> >> >> >> >> Hi there >> >> That was a response in a hurry so I take it back. Before flooding >> the group concalls with trivial issues I'd rather attempt to make >> my question as clear as possible. Note that I may indeed be >> confused, but if so then I'd appreciate an answer which would help. >> >> Consider this example : >> >> <wsp:Policy> >> <wsp:ExactlyOnce> >> <oasis:QOSGuarantee> >> <NeverFails/> >> <TheBestServiceInThisCategory verifiedBy="..."/> >> <oasis:QOSGuarantee> >> <wsp/ExactlyOnce> >> <wsp:Policy> >> >> This is an example of a policy with a single alternative. This >> alternative contains non-optional assertions >> defined by a policy profile spec published a month ago. These >> assertions have no wire manifestations. >> A ws-policy aware (requester) entity whose runtime has not been >> updated yet to recognize <oasis:QOSGuarantee> is about to start >> communicating with the service which advertizes this policy. >> >> Given the fact that it's likely ws-policy aware requesters will >> refuse to start talking to a service should they fail to support >> the above policy and that the fact whether this requester supports >> this policy or not will have no effect on the actual communication >> with the service this policy attached to, my understanding is that >> such assertions with no wire manifestations SHOULD be marked as >> wsp:optional : >> >> <wsp:Policy> >> <wsp:ExactlyOnce> >> <oasis:QOSGuarantee wsp:optional="true"> >> <!-- --> >> <oasis:QOSGuarantee> >> <wsp/ExactlyOnce> >> <wsp:Policy> >> >> This means a requester may use this policy for a service selection >> but doesn't need to refuse talking to this service should it fail >> to recognize the policy. >> >> Does it make sense ? >> What is the group's position on this issue ? >> >> Thanks >> >> Sergey Beryozkin >> Iona Technologies >> >> > >
Received on Friday, 22 September 2006 10:12:34 UTC