W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2007

RE: New draft of Metadata document - was RE: 2007-01-15 Teleconference canceled due to low attendance <EOM>

From: David Illsley <david.illsley@uk.ibm.com>
Date: Mon, 15 Jan 2007 09:21:00 +0000
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
Cc: "Bob Freund" <bob@freunds.com>, "[WS-A]" <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org, "Rogers, Tony" <Tony.Rogers@ca.com>
Message-ID: <OF1DE6B18A.5BF5A213-ON80257264.0030F056-80257264.00335AAB@uk.ibm.com>

Hi Umit,
I'm in agreement with Tony, the intersection will fail. Inclusion of the 
empty nested policy is for use when either side wants to allow another 
mechanism to determine which Response EPRs are supported (one suggestion 
was trying one and switching if it faulted). If either party wants 
behaviour guaranteed by policy (my preferred mode of operation), they 
should not include an empty nested policy and the intersection will fail. 
My view on how this will work in practice is that servers will probably be 
permissive and include the empty policy element (with optional 
AnonymousResponses and/or NonAnonymousResponses assertions) while most 
clients will specify exactly what they want.

So, my answer to your question to the policy group [1] which appears 
related to this is (a) No.

Tony: Sorry, I've spotted a problem with the doc in Example 3-4. The 
wsam:AnonymousResponses and wsam:NonAnonymousResponses elements should not 
have wsp:Optional="true" attributes.

David

[1] http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0069

David Illsley
Web Services Development
MP211, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com



From:
"Rogers, Tony" <Tony.Rogers@ca.com>
To:
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Bob Freund" 
<bob@freunds.com>, "[WS-A]" <public-ws-addressing@w3.org>
Date:
15/01/2007 08:00
Subject:
RE: New draft of Metadata document - was RE: 2007-01-15 Teleconference 
canceled due to low attendance <EOM>


Hello Umit
 
you are quite right, the intersection will fail. 
 
If we interpret the client as MUST have anonymous response, and the server 
as NOT GUARANTEEING anonymous response, it is arguable that it SHOULD 
fail.
 
That's my interpretation, anyway.
 
If the server wants to state support for both anon and non-anon, it must 
not provide the empty policy alone; it must provide empty, anon only, 
non-anon only, and both.
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Mon 15-Jan-07 17:28
To: Rogers, Tony; Bob Freund; [WS-A]
Subject: RE: New draft of Metadata document - was RE: 2007-01-15 
Teleconference canceled due to low attendance <EOM>

There is some discussion in the WS-Policy wg about the semantics of 
intersection with empty policy alternatives and nesting. This is why the 
WS-A approach to using nesting is rather important. 
 
I read the document and the following statement is not very clear. Could 
the wg clarify what is intended: 
 
{Note also that the lack of either of these assertions (AnonymousResponses 
and NonAnonymousResponses) does not indicate lack of support. So it is 
suggested that a subject that does not have a strict compatibility 
requirement that an interacting subject understands or is concerned with 
these assertions provides an alternative without either assertion. }
 
For example, your example 3.2 (with no statement on support on supported 
response EPRs) on a service will fail to intersect with a clients policy 
which would require anonymous responses. Is the statement quoted above 
trying to recommend use of alternatives that contain nested assertions to 
indicate explicit support for type of responses (anonymous/non anonymous) 
in one of the nested alternatives ? If that is the case, Example 3.2 needs 
to be positioned appropriately. Using example 3.2 alone as a policy 
expression by a service will not allow the clients that require a specific 
type of responses to communicate with the service as the intersection 
algorithm will fail, but that is not clear from the text. Thus, example 
3.2 as "no-statement on supported responses" is misleading. 
 
Cheers, 
 
--umit
 
 
 

From: public-ws-addressing-request@w3.org [
mailto:public-ws-addressing-request@w3.org] On Behalf Of Rogers, Tony
Sent: Sunday, Jan 14, 2007 12:56 PM
To: Bob Freund; [WS-A]
Subject: New draft of Metadata document - was RE: 2007-01-15 
Teleconference canceled due to low attendance <EOM>

So everyone has a whole week to study the new Editor's Draft of the 
Metadata document :-)  You will find it at: 
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8
 
The main changes are the complete removal of UsingAddressing and the SOAP 
module as alternatives for indicating the use of WS-Addressing (yes, I 
have anticipated the WG slightly, but I can roll this back if it is not 
agreed - want you to see what it looks like without those) - the only 
mechanism supported for indicating/requiring the use of WS-Addressing is 
the policy assertion.
 
Please e-mail the list with any omissions or mistakes. 
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com

From: public-ws-addressing-request@w3.org on behalf of Bob Freund
Sent: Mon 15-Jan-07 6:51
To: [WS-A]
Subject: 2007-01-15 Teleconference canceled due to low attendance <EOM>

 
Received on Monday, 15 January 2007 09:21:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:15 GMT