RE: [ws-rx] NEW ISSUE: What does 'anon' URI mean when used in AcksTo

From
Yalcinalp, Umit <>
Date
2005-09-09T23:24:15+00:00
ID
Thread
RE: [ws-rx] NEW ISSUE: What does 'anon' URI mean when used in AcksTo
I fail to understand the similarity or more simply why one 
would use anonymous IRI for "To".  Where would you send the 
initial message?  /dev/null ;-) 

 

AcksTo EPR using anon IRI is different, it is piggybacking 
on the existing channel provided by the binding, similar to ReplyTo and Fault 
which corresponds to a kind of "response". Acknowledgement is a kind of 
response. 

 

--umit

 

  

  
  From: Doug Davis [mailto:] 
  
Sent: Friday, Sep 09, 2005 3:47 PM
To: 
  
Subject: RE: [ws-rx] NEW ISSUE: What does 
  'anon' URI mean when used in AcksTo

  

Right - it talks about ReplyTo and 
  FaultTo but not "To".  So, we can either assume that it is implicitly 
  talking about "To" which means wecan  make the same assumption for 
  AcksTo.  Or we can assume that silence on "To" implies something else - 
  like "its obvious". dunno.  Whatever that assumption is, we can probably 
  carry it over to the AcksTo EPR :-) 
thanks, 
-Doug 
  

  
    
    

      "Yalcinalp, Umit" 
        <> 
        
09/09/2005 06:24 PM 

      
        
          
          

            
              
To

            Doug 
              Davis/Raleigh/IBM@IBMUS, <> 

          

            
              
cc

            
          

            
              
Subject

            RE: [ws-rx] NEW ISSUE: 
              What does 'anon' URI mean when used in 
        AcksTo

        
          
          

            
            

Hmm. I am wondering whether we are looking at different 
  versions of the soap binding spec. The current editor's copy [1] has the 
  following statement in Section 3.5 (Anish was suggesting adding basically a 
  similar language to our spec in this thread). 
  
{ 
When 
  "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified as the address 
  of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a 
  channel to the specified endpoint. Any underlying protocol binding supporting 
  the SOAP request-response message exchange pattern provides such a channel. 
  For instance, the SOAP 1.2 HTTP binding[SOAP 1.2 Part 2: 
  Adjuncts] puts the reply 
  message in the HTTP response. 
} 
  
  
  
--umit 
  
  
[1] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#soaphttp 
  

  
  From: Doug Davis [mailto:] 
  
Sent: Friday, Sep 09, 2005 1:57 PM
To: 
  
Subject: RE: [ws-rx] NEW ISSUE: What does 
  'anon' URI mean when used in AcksTo

I saw no mention of what an anonymous wsa:To means 
  in the soap binding spec - but perhaps I missed it.  If not, then they're 
  silent on it. 
thanks, 
-Doug 

  
    
    

      "Yalcinalp, Umit" 
        <> 
        
09/09/2005 04:43 PM 
        

      

        
          
          

            
              
To

            Doug 
              Davis/Raleigh/IBM@IBMUS, 
              <> 
          

            
              
cc

            
          

            
              
Subject

            RE: [ws-rx] NEW ISSUE: 
              What does 'anon' URI mean when used in 
        AcksTo

        
          
          

            
            

Doug, 
  
 
I 
  think it is incorrect to characterize that WS-Addressing is silent. It just 
  defers the definition to the binding where it belongs to the extent of how the 
  definition is used for WS-Addressing purposes only. 
 
I would be very 
  much in favor of (a) or (b) for our own spec. If (b) can not be coordinated 
  with WS-Addressing wg (we need to do that rather fast due to the timelines of 
  WS-Addressing) , we should definitely explore (a). 
 
Cheers, 
 
--umit 
 

  
  From: Doug Davis [mailto:] 
  
Sent: Friday, Sep 09, 2005 11:42 AM
To: 
  
Subject: Re: [ws-rx] NEW ISSUE: What does 
  'anon' URI mean when used in AcksTo

Is WS-Addressing's silence on what it means to 
  use the anonymous IRI in the wsa:To header mean that it should be obvious to 
  the reader?  If so, then perhaps we can take the same approach to its use 
  in other places that WS-Addressing is silent as well - for example, AcksTo - 
  and say nothing and assume its obvious to the reader. 
  
thanks 
  
-Doug 
  

Anish Karmarkar 
  <> wrote on 09/09/2005 02:20:12 
  AM:

> As discussed on the call today, I'm raising an issue about the 
  meaning 
> of 'anon' URI when used in AcksTo URI.
> 
> 
  Title:
> 
> What does 'anon' URI mean when used in AcksTo 
  EPR?
> 
> Description:
> 
> WS-Addressing Core [1], 
  section 2.1 says the following about 'anon':
> 
> "Some endpoints 
  cannot be located with a meaningful IRI; this URI is 
> used to allow 
  such endpoints to send and receive messages. The precise 
> meaning of 
  this URI is defined by the binding of Addressing to a 
> specific 
  protocol."
> 
> WS-Addressing SOAP binding [2] defines what the 
  'anon' address means 
> when used with ReplyTo and FaultTo in SOAP and 
  SOAP/HTTP binding. It 
> does not say anything about what it means when 
  used in other headers 
> such as AcksTo.
> 
> 
  Justification:
> 
> WSRM defines AcksTo element of type 
  EndpointReferenceType and allows 
> 'anon' URI for the address. But the 
  meaning of such an anon address is 
> not defined anywhere.
> 
  
> Target:
> 
> core, soap
> 
> Type:
> 
  
> design
> 
> Proposal:
> 
> This can be 
  resolved by:
> 
> a) Adding a stmt similar to WS-Addressing SOAP 
  binding. Something like:
> 
> "When 
  "http://www.w3.org/2005/08/addressing/anonymous" is specified as 
> the 
  address of the wsrm:AcksTo EPR, the underlying SOAP protocol binding 
> 
  provides a channel to the specified endpoint. Any underlying protocol 
> 
  binding supporting the SOAP request-response message exchange pattern 
> 
  provides such a channel. For instance, the SOAP 1.2 HTTP binding[SOAP 
> 
  1.2 Part 2: Adjuncts] puts the reply message in the HTTP response."
> 
  
> OR
> 
> b) we could ask the WS-Addressing WG to fix their 
  SOAP binding to 
> include not just ReplyTo and FaultTo EPRs but any EPR 
  when used in the 
> context of SOAP/HTTP binding.
> 
> I 
  prefer that we do (b). If they refuse, we can do (a)
> 
> Related 
  issues:
> i012
> 
>