Re: [ws-tx] Issue 30 - One-way message replies

[Mark Little <mark.little@jboss.com>]

As per the discussion at the f2f, we agreed that we aren't sending 
replies to messages, which that section is concerned with: we are 
sending more one-way messages that happen to need to be routed to some 
endpoint that may have been identified by some previous one-way message. 
Hence wsa:ReplyTo is wrong.

In some respects, wsc:ReplyTo (again, just a placeholder, so don't get 
hung up on the name) is a convenience for encoding the recipient in the 
body of the message.

Mark.


Alastair Green wrote:
> Mark,
>
> My point is that the WS-Addressing spec mandates that an absent 
> reply-to causes the receiver to infer an anonymous response:
>
> Section 3.4 of the latest draft:
>
>     *Note:*
>
>     The [reply endpoint] message addressing property will always be
>     present when using the XML Infoset representation since, in the
>     absence of a wsa:ReplyTo element, the value of the [reply
>     endpoint] message addressing property defaults to an EPR with an
>     [address] property of
>     "http://www.w3.org/2005/08/addressing/anonymous"; - see section
>     *3.2 XML Infoset Representation of Message Addressing Properties*
>     <http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-core.html?rev=1.51&content-type=text/html;%20charset=iso-8859-1#msgaddrpropsinfoset>.
>
> My understanding of this note, and of section 3.2, is that this 
> inference MUST be drawn by a receiver, irrespective of any extension 
> property like wsc:Response. Hence my proposal that we explicitly set 
> wsa:ReplyTo to "none".
>
> Alastair
>
>
>
> Mark Little wrote:
>> The discussion during the f2f concluded that we are indeed using 
>> wsa:ReplyTo in a way that, although probably legal, is not the way it 
>> was meant to be used and can lead to confusion (as we've seen here). 
>> So the first step in the process of removing that confusion, is to 
>> remove wsa:ReplyTo, which was my proposal. What we replace it with, 
>> and what the rules are around it, are the central points of the issue.
>>
>> Alastair Green wrote:
>>> Mark,
>>>
>>> Taking off from a comment in the last paragraph of my written 
>>> contribution on this area during the F2F
>>>
>>>    
>>> http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200603/msg00088.html 
>>>
>>>
>>> I think we need to address, in resolving this issue, the question of 
>>> the [reply endpoint] value being defaulted to anonymous.
>>
>> The issue is about replacing wsa:ReplyTo in the case of "one ways 
>> that may ultimately have a response but aren't really 
>> request-response based messages" (to paraphrase). So in that case, we 
>> would be defining the rules around wsc:ReplyTo (just a name I've 
>> picked for this email so I can easily refer to it as being different 
>> to wsa:ReplyTo). As such, anonymous may not even play in that space. 
>> Why would we want an anonymous default? The current uses of 
>> wsa:ReplyTo really all assume that it was present on the message. I'd 
>> prefer a binary approach for wsc:ReplyTo.
>>
>>>
>>> An absent [reply endpoint] property in the XML infoset 
>>> representation becomes a receiver-inferred value of "anonymous" 
>>> (actually, the URI that means anon).
>>>
>>> It seems preferable that we explicitly specify the value of "none" 
>>> (again, a URI in truth).
>>
>> I would have expected us to be more specific: if there's a 
>> wsc:ReplyTo present, then this is the destination that 
>> MAY/SHOULD/MUST be used for sending a response. The absence means 
>> that no response is needed - no default.
>>
>>>
>>> This is explicit, intuitively what one would expect for a one-way in 
>>> terms of HTTP handling, and avoids any ambiguity/under-specification 
>>> if a different representation is used at some future point.
>>>
>>> The current wording banning use of anonymous reply-to addresses 
>>> would then be replaced.
>>>
>>> I think we also need to ban use of message ids, and ban use of 
>>> fault-to, i.e. make it clear (by omission or by explicit statement) 
>>> that none of these aspects of the reply-processing rules and 
>>> apparatus are being put to use. ("Ban" in this context could mean 
>>> "make it clear that these properties, if present, will be ignored".)
>>
>> We had discussed at the f2f that wsa:FaultTo is really meant just for 
>> comms faults and "application faults" would be treated as messages. 
>> I'm not sure if that made it into the minutes.
>>
>>>
>>> I think use of wsa:From tends to detract from the clarity obtained 
>>> by defining an extension property for our special use.
>>
>> Mark.
>>
>>>
>>> Yours,
>>>
>>> Alastair
>>>
>>>
>>> Mark Little wrote:
>>>> Line 472 and 480.
>>>>
>>>> Mark.
>>>>
>>>>
>>>> Ram Jeyaraman wrote:
>>>>>
>>>>> Mark,
>>>>>
>>>>>  
>>>>>
>>>>> Could you please provide the PDF line numbers in the referred 
>>>>> document that are relevant to this issue. Thanks.
>>>>>
>>>>>  
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> *From:* Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
>>>>> *Sent:* Friday, March 17, 2006 2:48 PM
>>>>> *To:* ws-tx@lists.oasis-open.org
>>>>> *Subject:* [ws-tx] Issue 30 - One-way message replies
>>>>>
>>>>>  
>>>>>
>>>>> This is identified as WS-TX issue 30.
>>>>>
>>>>>  
>>>>>
>>>>> Please ensure follow-ups have a subject line starting "Issue 30 -" 
>>>>> (after any Re:, [ws-tx] etc.)
>>>>>
>>>>>  
>>>>>
>>>>> ===================================
>>>>>
>>>>>  
>>>>>
>>>>> Issue name: One-way message replies
>>>>>
>>>>>  
>>>>>
>>>>> Issue type: spec
>>>>>
>>>>>  
>>>>>
>>>>> Owner: Mark Little (mark.little@jboss.com)
>>>>>
>>>>> Reference documents:
>>>>>
>>>>> WS-AT specification:
>>>>> http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17129/wstx-wsat-1.1-spec-wd-04.pdf 
>>>>> <http://www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17044/http:/www.oasis-open.org/apps/org/workgroup/ws-tx/download.php/17129/wstx-wsat-1.1-spec-wd-04.pdf> 
>>>>>
>>>>>
>>>>> Description:
>>>>>
>>>>> Currently we use wsa:ReplyTo for one-way messages in a way which 
>>>>> although legal in terms of the latest CR draft of WS-Addressing, 
>>>>> has led to confusion on a number of occasions. As an example, one 
>>>>> use of wsa:ReplyTo is on Prepare->Prepared, where Prepare has a 
>>>>> wsa:ReplyTo but the Prepared message is a separate (not response) 
>>>>> message, because it could be sent autonomously and not actually in 
>>>>> response to Prepare. The issue is that as far as WS-Addressing is 
>>>>> concerned, wsa:ReplyTo should really only be used in the case of 
>>>>> the request-response MEP, which is clearly not the case here.
>>>>>
>>>>> Proposed Resolution:
>>>>>
>>>>> The rules for where and when wsa:ReplyTo should be included and 
>>>>> used within WS-AT are well defined, and particularly in respect to 
>>>>> the interoperability scenarios. I propose that we replace 
>>>>> wsa:ReplyTo with something specific to WS-TX (perhaps wsc:ReplyTo, 
>>>>> wsc:OnewayTo, or somesuch).
>>>>>
>>>>> Addendum:
>>>>>
>>>>> Max suggested at the Raleigh f2f another potential resolution: 
>>>>> that we use wsa:From.
>>>>>
>>>>
>>