Message-Id: <m0p3BqV-0003WDC@ibeam.intel.com>
Date: Fri, 26 Nov 1993 14:42:28 -0800
To: timbl@nxoc01.cern.ch, Jon Knight <J.P.Knight@lut.ac.uk>
From: altis@ibeam.jf.intel.com (Kevin Altis)
Subject: Re: a better ftp URL (local file comments)
>f t p : / / [ user [ : passwd ] @ ] host [ : port ] [ @ type ] /
I like the look of this. Putting the type specification after the / makes
it look to much like it is part of the path.
>2. I propose that the type letters be the ones in the FTP RFC, ie
>I for "image" not "b" for "binary", etc.
Actually, I think we should use the full names "ascii" and "binary" rather
than abbreviating. Most users will have no idea what the "type" means, but
by being explicit I think there will be less confusion in the long run than
if abbreviations were used.
>3. John asks if "file": should be put into the spec.
>It is as he says used by all real WWW browsers in order
>to integrate the local file system with the web.
>I had removed it from the URL spec becasue there were
>comments at the IETF about it not being proper because
>it didn't reference a network entity, wasn't globally valid,
>and all that stuff. However, now that this group has decided
>to allow nntp://host/news.group/articlenumber which is
>quite local I would suggest that file: should be put into the spec
>as everyone will in fact want to use it.
>
>I also suggest that when file: is used that the fqdn of the
>host (if there is one, otherwsie "localhost") be put on
>just so that if the URL is used on a different host,
>at least the software can say "sorry, that is a local URL
>and not valid here". The fallback to anonmous FTP in this
>case should I suggest be deprecated. Comments?
file: has always been confusing. It isn't a protocol and I retrieve files
via gopher, http, ftp, etc. so it creates confusion as to where the
information is coming from and how. If we need something like "file:",
which I think we do, then I would much rather see a word used that isn't as
confusing.
Maybe "local:" would be more appropriate?
Regardless, the distinction between the local file system, the LAN, and the
rest of the network is blurring, so that clients will need to access local
elements transparently regardless of actual location; this will happen even
before URNs are ready.
With that in mind, I don't want to see any more information go into the
"file:" or "local:" URL type than necessary. Use of "localhost" would
probably be okay, because it would still allow files on a CD-ROM or local
drive to be accessed with the same URL for different machines as long as
the directory structure is the same on each localhost.
A WORD OF CAUTION
If you don't think this is important, keep in mind that sometime next year,
the number of Windows and Mac machines using the Net and the Web will
easily dwarf (probably 10 or 20 to 1 before the end of 1994) the current
installed base of Unix (and VMS...) users - where everything is connected
to the net all of the time - and many of those new Windows and Mac users
will be using interactive systems that combine local media resources with
net resources. If the standards being developed today meet the private and
commercial needs of the coming user base and are ready to be used, then
they will be adopted. That means keeping in mind that the Mac and Windows
(mostly Windows) machines WILL BE the major installed base, we're talking
tens of millions of machines.
ka