Which “SHOULD NOT” are you referring
to?
From: Doug Davis
[mailto:]
Sent: Tuesday, July 12, 2005 5:44
AM
To: Lei Jin
Cc:
Subject: Re: [ws-rx] NEW ISSUE:
anonymous AcksTo
Lei,
w.r.t using the anonymous IRI on non-reply messages - I'd like to point out
that
even the WSA spec[1] itself doesn't adhere to their own "SHOULD NOT".
If
you look at the text for wsa:To it says:
/wsa:To
This OPTIONAL element (of type xs:anyURI) provides the value for the
[destination] property. If this element is NOT present then the value of the
[destination] property is
"http://www.w3.org/2005/03/addressing/role/anonymous". Otherwise the
[children] of this element convey the value of this property.
This
applies to all messages.
Some
of this is reading between the lines, but to me the WSA spec was simply
trying
to encourage people to use a real IRI for the wsa:To and trying to find a way
to
have a copy of the transprt URL within the envelope in order to make the
envelope
a
self-contained/self-describing entity. There are however cases where a
transport
URL is not available (like on the HTTP response
flow),
and these are the cases where anonymous IRI makes sense.
Since
we need a way to deliver ACKs for one-way messages even when a
firewall
is in place I believe using the anonymous IRI is a valid choice.
w.r.t.
your intermediary examining the wsa:ReplyTo - be a bit careful here.
The
presence of a wsa:ReplyTo does not imply anything about the MEP (sadly :-(.
There
are cases where a wsa:ReplyTo could be present even for a one-way
message.
And the presence of an anonymous wsa:ReplyTo does not guarantee
that
anything will flow back on the http response flow.
thanks,
-Doug
[1]
http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/
"Lei Jin"
<>
07/11/2005 03:18 PM
To
<>
cc
Subject
[ws-rx] NEW ISSUE: anonymous AcksTo
I
have the impression after talking to a few people that there is the
implicit assumption (though not specifically
called out) in the spec
that if the AcksTo EPR is set to use the anonymous
IRI, then all
subsequent acknowledgements for that reliable
sequence will be sent back
synchronously on the http response path of either
the application
message or an ack request message.
I think that is not a good idea. First of
all, we are saying that even
if my application message is one way (or
asynchronous), I might still
receive something back on the http response(the
WS-RX ack). Nothing
really precludes this usage, but we are
introducing unnecessary
dependency between WS-RX (acknowledgement
messages) and WS-Addressing
(normal MEP). For example, if I have an
intermediary on the server side
that takes an incoming message, looks at the
reply-to address (or
message MEP), and decides to close http connection
if it's a oneway or
asynchronous message, everything works fine.
Now, with WS-RX, it has to
know that "hmm, maybe I shouldn't close that
connection if WS-RX is
involved and synchronous ack is used".
Secondly, the paragraph below quoted from
WS-Addressing spec says the
anonymous IRI shouldn't be used as the destination
in any other
circumstances other than the destination for reply
messages. I don't
see acknowledgements as reply messages.
WS-Addressing defines the following well-known IRI
for use by endpoints
that cannot have a stable, resolvable IRI:
"http://www.w3.org/2005/03/addressing/role/anonymous"
Requests whose
[reply endpoint], [source endpoint] and/or [fault
endpoint] use this
address MUST provide some out-of-band mechanism
for delivering replies
or faults (e.g. returning the reply on the same
transport connection).
This mechanism may be a simple request/reply
transport protocol (e.g.,
HTTP GET or POST). This IRI MAY be used as the
[destination] for reply
messages and SHOULD NOT be used as the
[destination] in other
circumstances.
Proposal 1:
Specifically call out that the AcksTo EPR should
not use the anonymous
IRI.
-- One reason to use an anonymous IRI is so that
the acknowledgement may
reach sending endpoints that may be sitting behind
a NAT or firewall.
But we have to deal with the same problem with
asynchronous response
messages anyway.
Proposal 2:
Specifically call out that an anonymous IRI in the
AcksTo EPR would
indicate acknowledgement message will only be sent
back in response to
ack request messages where the ack request message
should be a
standalone synchronous invoke.
Flames?
Lei
