- From: marwan sabbouh <ms@mitre.org>
- Date: Mon, 19 Mar 2001 10:03:26 -0500
- To: Mark Nottingham <mnot@akamai.com>
- CC: Scott Isaacson <SISAACSON@novell.com>, moreau@crf.canon.fr, Noah_Mendelsohn@lotus.com, w3c-xml-protocol-wg@w3.org, xml-dist-app@w3.org
That is what we have to agree on. I am not sure what the answer is.What are the trade-offs between the two options?What are the trade-offs between the two options? I am tempted to say that we just allow that. This way, the specification can be written in a modular way. On the on the other hand, this may result in different vendors implementing the same functionality in many different ways, unless some working group address these issues. . Mark Nottingham wrote: > > 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 10:03:35 UTC