Re: FW: Last Call Working Draft Transition: Web ServicesAddressing 1.0 - Metadata

Unfortunately I will not be able to make the call today, my regrets. Here 
are my thoughts about the policy WG's comments.

A. It is not clear what is 'incompatible' about the two alternatives that 
appear in the normal form provided; at most, they are potentially 
overlapping in the behavior they describe. Intersection will work fine and 
catch both clients with and w/o the wsa:AnonymousResponses qualifier. 
Again, it is not clear what is broken here. 

B. It is true that restricting behavior is not properly supported, but 
that is what we decided after months of struggling with the RM anon issue. 
Standards are made of compromises. Not sure why the policy wg thinks it 
'likely' that people will assume semantics incompatible with ones we spec 
out. 

C (first occurrence). WSA Metadata does not provide a way to say that ONLY 
a certain type of responses are allowed. This is by design. The reasoning 
that follows is thus based on an incorrect reading of the assertion 
semantics. I think we have discussed at length option 1 and leaving the 
required behavior model is what got us our of the rat hole; as for 2, I 
believe we have discussed and rejected it in the past (what options 
haven't we considered already?) but the reasons may have been people's 
desire to leverage intersection for the anonymous assertions as well. 

With respect to A, B and C(1), I believe the net is this: we have decided 
to go for an assertion structure and semantics that only supports positive 
statements about the types of responses supported. We don't need to go 
back and review the 5 months we've spent to reach this point. In the 
considerations provided by the policy wg there seems to be a level of 
uneasiness with and/or misunderstanding of those semantics, not a specific 
proof that anything is broken. So I think we have three options: 1. 
maintain the current design (since it works), 2. go back to a restrictive 
wsa:anonymous design (forget about RM), or 3. just stay away from the 
business of indicating response types (forget about anonymous). Based on 
all the work we've done I would say we go for #1, *maybe* considering once 
more the possibility of using nested elements instead of nested policy.
 
C (second occurrence). The comment seems to miss the point that other 
specifications might define assertions to be nested within the 
wsa:Addressing assertion, so multiple namespaces are possible. OTOH, 
nothing in the WS-Policy specification states that the use of the 
ignorable flag is tied to lack of understanding of the assertion semantics 
by clients. Operationally its value is quite clear: it supports lax 
intersection. This comment makes me wonder if we should in fact use the 
ignorable flag :-)

D. I agree we should clarify this.

E. I think the document is quite clear about what are the allowable 
attachment points. Do we need to exhaustively list all not supported 
attachment points?

Paco




"Bob Freund" <bob@freunds.com> 
Sent by: public-ws-addressing-request@w3.org
02/23/2007 03:53 PM

To
"[WS-A]" <public-ws-addressing@w3.org>
cc

Subject
FW: Last Call Working Draft Transition: Web ServicesAddressing 1.0 - 
Metadata






 

From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Fri 2/23/2007 11:26 AM
To: Bob Freund; www-ws-desc@w3.org
Cc: public-ws-policy@w3.org
Subject: Last Call Working Draft Transition: Web ServicesAddressing 1.0 - 
Metadata


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 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