mandatory ReplyTo, handling replies in WS-Addressing

Hi,

as an LC comment for WS-Addressing, I'd like to voice my disagreement
with some of the WS-Addressing choices in handling replies, in
particular with the following excerpts: "if a reply is expected, a
message MUST contain a [reply endpoint]" and "If the reply is a normal
message, select the EPR from the incoming message's [reply endpoint]
message addressing property. If none is present, the processor MUST
fault".

Instead of this strict requirement for a reply endpoint, I'd prefer that
in absence of explicit reply endpoint it would be assumed to be an EPR
with the address "http://www.w3.org/2005/03/addressing/role/anonymous"
and no parameters nor metadata. This still allows the processor to fault
when a reply is generated but no reply endpoint is known (and none is
provided out-of-band), but it allows for shorter messages that transfer
replies over the same communication channel, like in HTTP request/reply.

This would remove the text "This element MUST be present if a reply is
expected" in description of ReplyTo (or soften the MUST to SHOULD), and
the description of MessageIdD would additionally be suggested (SHOULD)
when a reply is expected but ReplyTo is empty.

In fact, I'd soften the MUST around MessageID to SHOULD anyway as it is
not necessary in some cases, like the mentioned HTTP request/reply
single communication channel.

Further, section 3.2 "Formulating a Reply Message" doesn't seem to allow
faults (or replies, if you accept my suggestion above) to messages
without ID. In particular, point two describes how [relationship] is
populated in the reply message but since a fault can occur on a message
that doesn't have ReplyTo or FaultTo (therefore MessageID is optional),
this description would end up with only half of the relationship URI
pair. I believe the text should mention that no relationship will be
created in the reply message if the request message had no ID.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Received on Tuesday, 3 May 2005 14:13:46 UTC