Re: Back-channel: What is it and where do I find it?

Could you refer me to the definition of "back-channel" for SOAP?  I'm
aware of a narrow definition of WSA anon in the context of a single
request response operation, which is specifically /not/ what WS-RX wants
from a back-channel.

I'm not trying to be clever here.  In order to have a meaningful
definition of X functionality, we need a clear answer to "If something
says it provides X, what can I count on?".

It might seem obvious to you or to me or to someone else what a
back-channel is, but obviousness doesn't count.  Everyone's definition
has to agree.  One reality check for this is whether everyone agrees on
the answers for a list of common transports.  They don't.  This tells me
that the basic question of "What can I count on?" will not answer
itself.  That leaves it as your job to answer it.

I'm not concerned whether you can answer all the questions on the list
below.  I'm concerned that /I/ can't answer them, because I don't know
what question I'm supposed to be answering.

Francisco Curbera wrote:
>
> David,
>
> Here's a fourth: each protocol that defines a binding to WS-Addressing
> identifies whether the term back-channel applies to it, and how. We
> have done so for the protocols we support (SOA 1.1 on HTTP, a more
> generic form for SOAP 1.2), and that proves that the concept is valid.
>
> The fact that in the WS-Addressing wg we are not going to settle that
> question for all protocols you can imagine does not prove anything.
>
> Paco
>
>
>
> *David Hull <dmh@tibco.com>*
> Sent by: public-ws-addressing-request@w3.org
>
> 11/06/2006 04:03 PM
>
> 	
> To
> 	paul.downey@bt.com
> cc
> 	public-ws-addressing@w3.org
> Subject
> 	Re: Back-channel: What is it and where do I find it?
>
>
>
> 	
>
>
>
>
>
> Paul,
>
> Yours is the third eminently reasonable answer I've received on this.
>  They all differ.
>
> The points being 1) Of course we have to define it if we're going to
> use it.  2)  Agreeing on a definition is quite likely feasible, but
> certainly not trivial, so I'd like to know what we get for the effort
> if we go there.
> _
> __paul.downey@bt.com_ <mailto:paul.downey@bt.com> wrote:
> Hi David,
>
> Let me see if I can spring a few of your traps :-)
>
> I assume that a "back-channel" is some magical combination of a
> return address and message correlation implicitly supplied by
> the underlying mechaninsm by which messages are being exchanged.
>
> In other words, request-response just works.
>
> I'm guessing you are asking for us to define that in more formal
> terms in our spec, assuming we add the term?
>
>  
>    * Does email have a back-channel?
>    
>
> Reply-To, MessageId/In-Reply-To, it's certainly possible:
>
> _http://www.w3.org/TR/soap12-email_
>
>  
>    * Does a raw TCP connection have a back-channel?
>    
>
> possibly, if you place significance on the order of messages.
>
>  
>    * Does a raw UDP packet have a back-channel?
>    
>
> nope.
>
>  
>    * Does BEEP have a back-channel?
>    
>
> er, possibly, depending on the profile.
> A bit like asking if Java has polynomials, no?
>
> RFC3288's _http://iana.org/beep/soap_ supports the request/response MEP
>
>  
>    * Does XMLP <message/> have a back-channel?
>    
>
> er, SOAP abstracting away the transport is why we're here ..
>
>  
>    * Does XMLP <iq/> have a back-channel?
>    
>
> doesn't SOAP over XMPP use one?
> _http://www.xmpp.org/extensions/xep-0072.html#binding-operation-request-sendingreceiving_
>
>  
> and finally ...
>
>   * If a binding tells me "I have a back-channel", just what can I
>     count on?
>    
>
> request-response. probably.
>
> Paul
>
>
>  
>