- 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:39 UTC