Re: Addressing within envelope or binding-specific?

Is enabling intermediaries which do this one of the things we want to
do 'out-of-the-box', or just allow?



On Mon, Mar 19, 2001 at 07:19:39AM -0500, marwan sabbouh wrote:
> I am concerned that the address of the client be lost as a request
> traverses multiple intermediaries that uses different protocol
> binding.  That is why I advocate a mechanism to carry a client URI
> or address in a request.  The client or an intermediary may fill
> this entry.
> 
> marwan
> 
> Scott Isaacson wrote:
> > 
> > >>> <Noah_Mendelsohn@lotus.com> 03/16/01 03:20PM >>>
> > >Jean-Jacque Moreau suggests:
> > >
> > >>> not just allocate a service URI to the
> > >>> endpoint/receiver, but also allocate one
> > >>> to the sender
> > >
> > >Maybe, but I think there may be situations in which a sender
> > >doesn't in any useful sense know its own name, but in which the
> > >binding knows the return path implicitly.  As we have seen on
> > >the web with NAT and other protocols, not all clients have
> > >useful IP addresses or DNS names, for example.  I think it
> > >should be possible to send an XMLP request/response from these. 
> > >Of course, you could fake out a return address, but the point is
> > >that in certain cases it really is the binding and underlying
> > >transport that do the correlation and routing.
> > 
> > Agreed, as long as their is a common place where the sender name
> > could go. It should be optional, but should be consistently
> > there, and by "faked out" I assume you mean some "null" or
> > "empty" or "unknown" or "anonymous" type special names that could
> > be used in place of a real name.
> > 
> > Scott
> > 
> > > <snip/>

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Monday, 19 March 2001 08:53:35 UTC