- From: marwan sabbouh <ms@mitre.org>
- Date: Mon, 19 Mar 2001 07:19:39 -0500
- To: Scott Isaacson <SISAACSON@novell.com>
- CC: moreau@crf.canon.fr, Noah_Mendelsohn@lotus.com, w3c-xml-protocol-wg@w3.org, xml-dist-app@w3.org
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/>
Received on Monday, 19 March 2001 07:19:40 UTC