- From: Gilbert Pilz <Gilbert.Pilz@bea.com>
- Date: Mon, 26 Feb 2007 10:07:46 -0800
- To: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>
- Cc: <bob@freunds.com>, <public-ws-addressing@w3.org>, <public-ws-policy@w3.org>
- Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C03438117@repbex01.amer.bea.com>
I don't agree. I think it comes down to how we define wsam:NonAnonymousResponses. If we define it to mean "anything other than wsa:Anonymous" than it seems to me that a message with a wsa:ReplyTo/wsa:Address = {some instance of the WS-MC anon URI} meets behavior required by the presence of wsam:NonAnonymousResponses. The point is that, as far as WS-Addr policies are concerned, wsmc:Anon is not a subset of or in any way related to wsa:Anon. It seems counter-intuitive because we "know" that they have certain message processing characteristics in common, but I think it makes things cleaner if we define them to be complete separate. - gp > -----Original Message----- > From: public-ws-addressing-request@w3.org > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > Anish Karmarkar > Sent: Monday, February 26, 2007 9:31 AM > To: Christopher B Ferris > Cc: bob@freunds.com; public-ws-addressing@w3.org; > public-ws-policy@w3.org > Subject: Re: Last Call Working Draft Transition: Web > ServicesAddressing 1.0 - Metadata > > > It seems to me that the first recommended approach does not > solve the problem that we were trying to solve: allow ws-addr > policy to be composable with WSRM and MC spec. The 1st > approach does not allow one one to say: ws-addr anon reply-to > is supported and no claims about other reply-to addresses. > > It seems like the 2nd approach is more in line with our requirements. > > Comments? > > -Anish > -- > > Christopher B Ferris wrote: > > > > On behalf of the WS-Policy WG, here is our feedback on the > > WS-Addressing Metadata specification. > > > > The document specifies a wsam:Addressing assertion that has > two nested > > assertions wsam:AnonymousResponses and wsam:NonAnonymousResponses > > assertions. > > > > Although the use of the wsam:Addressing assertion indicates a > > requirement, the nested assertions do not express > requirements, thus > > dependent behaviors. The nested assertions appear to > express support > > of a capability. > > > > In our opinion, this duality poses several problems related to both > > understanding the intent of the assertion and to utilization of the > > WS-Policy 1.5 Framework for purposes of intersection. These > problems > > are noted below, followed by our recommendations to address the > > problems we highlight. > > > > (A) The presence of either of the two nested assertions does not > > indicate a required behavior. > > Further, per the statements in Sections 3.1.2 and 3.1.3, > their absence > > does not indicate lack of support either: > > "The absence of the XX policy assertion within a policy > > alternative does not indicate that the > > endpoint will not accept request messages with > response endpoint > > EPRs that contain the anonymous > > URI as an address; it simply indicates the lack of any > > affirmation of support for XX URIs." > > > > Thus, we believe that neither the presence nor absence of > > wsam:AnonymousResponses or wsam:NonAnonymousResponses as > nested policy > > assetions is meaningful. > > > > Without making the semantic change to the assertions, the > expression > > exemplified below is meaningless. > > > > <wsam:Addressing> > > <wsp:Policy> > > <wsam:AnonymousResponses wsp:optional="true"/> </wsp:Policy> > > </wsam:Addressing> > > > > The equivalent normalized expression implies conflicting semantics. > > The normalized policy expression (see below) gives no > indication which > > alternative can be used. > > > > The first alternative indicates support for anonymous > responses, but > > does not indicate whether a client that does not support > that behavior > > should not use this alternative (because absence of the > > wsam:NonAnonymousResponses nested assertion explicitly does > NOT make > > any statement as to whether or not that feature is supported). > > Similarly, the second alternative makes no statement > what-so-ever as > > regards the support (or lack there-of) of anon or non-anon > responses. > > > > <wsp:ExactlyOne> > > <wsp:All> > > <wsam:Addressing> > > <wsp:Policy> > > <wsp:ExactlyOne> > > <wsp:All> > > <wsam:AnonymousResponses/> > > </wsp:All> > > </wsp:ExactlyOne> > > </wsp:Policy> > > </wsam:Addressing> > > </wsp:All> > > <wsp:All> > > <wsam:Addressing> > > <wsp:Policy/> > > </wsam:Addressing> > > </wsp:All> > > </wsp:ExactlyOne> > > > > The problematic semantics expressed above makes the > utilization of the > > intersection algorithm provided by WS-Policy framework practically > > useless. > > > > (B) Given that the nested assertions express "support"s > semantics, and > > given that their omission says nothing about lack of support, it is > > not possible for an endpoint to advertise that it > explicitly DOES NOT > > support one or the other. However, it is likely that some policy > > authors might be lead to believe that by simply including > only one of > > the nested assertions, that a policy consumer would read that and > > infer that the other is not supported, despite the fact > that the spec > > says that it makes no statement. > > > > Thus, we believe that it is not possible to intersect the > behaviors of > > a consumer and a provider meaningfully to rely on the intersection > > algorithm alone to express required behaviors. > > > > (C) The advocation in section 3.1.6 of the use of > wsp:Optional='true' > > to enable intersection of two policy expressions when one > side chose > > to omit making any statement about its capabilities is itself > > problematic. > > Using the WS-Policy 1.5 Framework intersection, the following two > > policies would be compatible, despite the fact that the possible > > intent of the respective authors was meant to relate that ONLY the > > expressed nested assertion was supported (see (B)): > > > > Client: > > <wsam:Addressing> > > <wsp:Policy> > > <wsam:AnonymousResponses wsp:optional="true"/> </wsp:Policy> > > </wsam:Addressing> > > > > Server: > > <wsam:Addressing> > > <wsp:Policy> > > <wsam:NonAnonymousResponses wsp:optional="true"/> </wsp:Policy> > > </wsam:Addressing> > > > > This is because the normalized expressions would each have an > > alternative with an empty nested policy and the policy > engine applying > > intersection would report that there was a compatible policy > > alternative(s): > > > > <wsam:Addressing> > > <wsp:Policy/> > > <wsam:Addressing> > > > > Our guidelines document [1] in Section 4.5.1 further clarifies the > > appropriate use of wsp:optional attribute to create alternatives to > > indicate required and supported behaviors. > > > > Based on our review, we recommend adoption of one of the > two options > > that follow to resolve (A) and (B) above. In our view, it > is important > > to align the semantics of the nested aqssertions with the WS-Policy > > 1.5 Framework processing semantics. > > > > 1. One recommended approach would be to change the semantic of the > > nested policy assertions to represent required behavior and > use policy > > operators to convey the precise semantics. > > > > e.g. > > > > <wsam:Addressing> <!-- anon responses required, non-anon prohibited > > --> <wsp:Policy> > > <wsp:ExactlyOne> > > <wsp:All> <!-- anon responses required --> > > <wsam:AnonymousResponses/> > > </wsp:All> > > <wsp:ExactlyOne> > > </wsp:Policy> > > </wsam:Addressing> > > > > <wsam:Addressing> > > <wsp:Policy> > > <wsp:ExactlyOne> > > <wsp:All> <!-- non-anon responses required, anon prohibited --> > > <wsam:NonanonymousResponses/> > > </wsp:All> > > </wsp:ExactlyOne> > > </wsp:Policy> > > </wsam:Addressing> > > > > <wsam:Addressing> > > <wsp:Policy> > > <wsp:ExactlyOne> > > <wsp:All> <!-- either anon and non-anon responses required--> > > <wsam:AnonymousResponses/> > > </wsp:All> > > <wsp:All> > > <wsam:NonanonymousResponses/> > > <wsp:All> > > </wsp:ExactlyOne> > > </wsp:Policy> > > </wsam:Addressing> > > > > Note with this last one, it might be necessary to clarify that the > > scope of the assertion applies to a single instance of an > MEP, not to > > all instances of MEPs associated with the endpoint.... to allow the > > client to choose for each message exchange the appropriate type of > > response. > > > > Section 3.1.2 and 3.1.3 should be updated to convey that nested > > assertions indicate dependent behaviors by removing the quoted > > sections above. > > > > 2. Alternately, we believe that if the intent of the semantic to be > > conveyed is indeed purely informational (i.e. that an endpoint > > "supports" the capability) that a more appropriate means of > expressing > > this would be to use assertion parameters rather than nested policy: > > > > e.g. > > > > <wsam:Addressing> > > <wsam:AnonymousResponses/> > > <wsam:NonAnonymousResponses/> > > </wsam:Addressing> > > > > Note that with this second approach, the use of assertion > parameters > > would not effect policy intersection, yet the assertion parameters > > could be used by the policy consumer as information that it > could use > > to determine appropriate use of addressing. If formal > processing the > > assertion parameters is deemed to be necessary, then domain > specific > > intersection processing would need to be designed. For more > > information on usage of nested vs. parametric assertions, > please see > > Section 4.4 in our Guidelines document for details. > > > > (C) We note that the use of wsp:ignorable is not > appropriate in this > > context. Whether the semantics of the nested policy imply > required or > > "supported", we note that once the assertion > > (wsam:Addressing) is understood, that any nested policy or > parameters > > would also be understood by the client (by definition). > > Thus, we believe that the WS-Addressing Metadata > specification should > > not be making any recommendations as to the use of wsp:ignorable in > > section 3.1.6. > > > > (D) The WS-Addressing Metadata draft does not specify a policy > > subject, but implies one. Instead, the draft specifies attachment > > points. We recommend making the policy subject explicit. > > Please refer to our guideline in Section 4.6 in our Guidelines > > document, "An assertion description should specify a policy > subject. > > For instance, if a policy assertion is to be used with WSDL, an > > assertion description should specify a WSDL policy subject > - such as > > service, endpoint, operation and message." > > > > (E) The WS-Addressing Metadata draft should rule out > wsdl:portType and > > wsdl20:interface as possible attachment points. > > e.g, > > "A policy expression containing the Addressing policy > assertion MUST > > NOT be attached to a wsdl:portType or wsdl20:interface. > > The Addressing policy assertion specifies a concrete > behavior whereas > > the wsdl:portType or wsdl20:interface is an abstract construct." > > > > Cheers, > > > > Christopher Ferris > > STSM, Software Group Standards Strategy > > email: chrisfer@us.ibm.com > > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris > > phone: +1 508 377 9295 > > > > __________________ > > > > > > > > The W3C WS-Addressing WG has published a Last Call Working Draft of > > Web Services Addressing 1.0 - Metadata specification. The deadline > > for comments is 23 February 2007. The document is available at > > > > > > > > http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202/ > > > > > > > > We look forward to receiving any comments your WG has on this Last > > Call Working Drafts. Comments on this document are invited > and are to > > be sent to the public _public-ws-addressing-comments@w3.org_ > > <mailto:public-ws-addressing-comments@w3.org> mailing list. We are > > interested in particular in comments from the Web Services > Policy and > > Web Services Description Working Group. We are also interested in > > comments from OASIS technical committees, in particular the Web > > Services Reliable Exchange (WS-RX) TC. > > > > > > > > Please note that the document contains substantial changes > compared to > > the previous version. In particular, the document does no longer > > define a WSDL extension element or a WSDL SOAP module. This new > > version defines WS-Policy assertions, based on the Web > Services Policy 1.5 framework. > > > > > > > > If your Working Group is interested in reviewing these > drafts, please > > let me know, especially if you think you need more than three weeks > > after publication for your review. > > > > > > > > The decision to move to Last Call was made on January 29, 2007 [1]. > > > > > > > > No formal objection has been reported. > > > > > > > > No patent disclosure has been reported. > > > > > > > > Thanks > > > > -bob > > > > > > > > W3C WS-Addressing WG chair > > > > > > > > [1] http://www.w3.org/2007/01/29-ws-addr-minutes.html > > > > > > > > > > > > Bob Freund, Hitachi, Ltd. > > > > 62 Peakham Road, Sudbury, Massachusetts 01776-2914 > > > > Tel: +1-978-440-8415, Fax: +1-978-443-2168 > > > > > > > > > > > > > > > > > > > > > >
Received on Monday, 26 February 2007 18:09:42 UTC