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

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

I agree: we're mixing semantics again (which only goes to show that 
wsa:ReplyTo is being overloaded as we discussed at the f2f).

Mark.


Doug Davis wrote:
>
> I don't think you want to do that because in the absence of a 
> wsa:FaultTo, setting
> wsa:ReplyTo to "none" prevents you from getting back any fault 
> messages - not
> Tx,non-related, faults, but other ones.  These are just normal 
> one-ways which
> people normally leave replyTo/faultTo blank - I see no reason to make 
> them
> anything special but including a 'none' replyTo.
> -Doug
>
>
>
> *Alastair Green <alastair.green@choreology.com>*
>
> 03/21/2006 06:46 AM
>
> 	
> To
> 	Mark Little <mark.little@jboss.com>
> cc
> 	ws-tx@lists.oasis-open.org
> Subject
> 	Re: [ws-tx] Issue 30 - One-way message replies
>
>
>
> 	
>
>
>
>
>
> 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"_ 
> <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_ <mailto: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_ 
> <mailto: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.
>
>
>