- From: David W. Morris <dwm@shell.portal.com>
- Date: Thu, 21 Mar 1996 00:15:18 -0800 (PST)
- To: John C Klensin <klensin@mail1.reston.mci.net>
- Cc: hallam@w3.org, Koen Holtman <koen@win.tue.nl>, Ari Luotonen <luotonen@netscape.com>, jg@w3.org, Harald.T.Alvestrand@uninett.no, ari@netscape.com, paulle@microsoft.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, jeff@step.mcom.com
On Wed, 20 Mar 1996, John C Klensin wrote:
>
> And, while the schedule is tight, nothing has convinced me that we can make
> better decisions in an area like this if we spend the next six months
> thinking about it than if we, well, decide. The marketplace won't wait
> while we engage in extended self-contemplation.
There is clear concenus that #2 is unacceptable. I also would have
prefered #2 but it can't be. #4 can be defined to interoperate and
solve the problem as defined.
This discussion has been useful because it saved me from having to
argue in the coming weeks that for Host: to be meaningful it
had to be required. That's decided. Lets move on to our remaing
issues as well as making sure the description of host: is correct.
One of the earlier posts which mentioned host: indicated that the
host port should be included with the host name. I fully support
that approach:
1. It simplifies the definition of the content of host: ... just
take the whole host address portion of the URL
2. It retains potentially useful information which is otherwise
lost. For example, a firewall or other gateway might desire
to map two external listening ports to a single internal
server. In essence, the current protocol has the problem
because information is thrown away. WHy take the risk.
3. It happens to correspond to NETSCAPE's implementation.
Dave Morris
Received on Thursday, 21 March 1996 00:21:03 UTC