W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2006

Preferences for CR 18

From: David Hull <dmh@tibco.com>
Date: Fri, 10 Feb 2006 09:55:30 -0500
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <43ECA962.2090807@tibco.com>
I would prefer option 2 (Allow anonymous in the [destination] for
messages and define it as the binding-specified destination of the
message.)  I believe this is most consistent with existing practice
(pre-WSA HTTP servers have the URL of the request available for
disp^H^H^H^H whatever purpose they may need it for), with the overall
web architecture (per Mark Baker's note, if I understand it correctly),
and with our handling of anonymous in response endpoints.  It's somewhat
inconsistent with the non-normative description we give to anonymous,
but we can fix that.

I can live with option 0 (Keep the status quo, allowing anonymous for
[destination] but not defining the behavior, and note that there are
interoperability problems with using anonymous for [destination] except
for anonymous responses (*).)  I think Paul has a better idea here for
what to note: Note that anonymous [destination] has no particular
meaning, not that "there are interoperability problems" as I suggested
in [1].  I would support Paul's proposed text for this option.

I can only live with option 1 (Disallow anonymous in the [destination])
if it is tightly scoped.  Indeed, the text in [1] should have taken into
account that anonymous [destination] is /required/ for responses when
the response endpoint used is anonymous.  In any case, I can live with
"Disallow anonymous in the [destination] of requests in a
request-response MEP", where request-response MEP means HTTP
request-response for SOAP 1.1 and any instance of SOAP 1.2 request-response.

I cannot live with disallowing anonymous [destination] everywhere except
where required in responses.  There is no way we can say that there are
no other cases where the message destination "cannot be located with a
meaningful IRI."  I'll also repeat that I really cannot live with, and
will likely formally object to, referring to HTTP specifically when
describing the SOAP 1.2 behavior.  However, there is no need to do this
(indeed, that would be one basis for objecting).  The whole point of
SOAP 1.2 (or one of them, anyway) is that it provides
binding-independent ways of talking about these things.

In this case we can say, e.g., that anonymous [destination] is
disallowed in the request message of the request-response MEP (as
opposed to talking about the HTTP request message).  If we go that
route, I would prefer to say ".../InboundMessage" as it says "request
message" more precisely, but that's a separate issue [2].

Received on Friday, 10 February 2006 14:55:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:12 UTC