Re: mandatory ReplyTo, handling replies in WS-Addressing

Jacek,

Thank you for reviewing the WS-Addressing documents. The Working  
Group has resolved this issue <http://www.w3.org/2002/ws/addr/lc- 
issues/#lc69>.

We have adopted the core of your proposal, in that replyTo now  
defaults to the 'anonymous' URI. Additionally, we have added another  
pre-defined URI to indicate that there is no reply expected, so as to  
preserve the semantics of the current default.

After discussion and consideration of other, similar LC issues, the  
WG has voted to retain MessageID as a mandatory property.

Please review the current editors' drafts, linked from <http:// 
www.w3.org/2002/ws/addr/>, which have incorporated this resolution.  
If you have further comments or a problem with this resolution,  
please contact us ASAP; we are meeting F2F next Monday and Tuesday,  
and expect to close our remaining LC issues at that time.

Cheers,


On 03/05/2005, at 7:13 AM, Jacek Kopecky wrote:

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


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Thursday, 14 July 2005 20:52:19 UTC