Date: Fri, 29 Oct 93 13:59:26 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-Id: <9310291259.AA02218@www3.cern.ch>
To: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
Subject: Re: URLs -- the ftp case
>Date: Thu, 28 Oct 93 09:10:41 CDT
>From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>
>In message <9310271954.AA04238@merit.edu> "Fred Swartz" writes:
>> In the case of ftp, the URL as specified does NOT allow the
retrieval
>> of files since the text/binary mode can not be determined. [...]
>> Instead of giving the false impression that URLs work for ftp,
perhaps
>> the mode, as with Gopher, could be added.
The problem then is that you can't browse an FTP directory.
An FTP directory returns you a list of file names, from
which you can currently generate URLs. It does't return
file types. And most FTP URLS are in fact generated by
FTP server directory listings, not cut out of mail
messages.
Yes, you need the content-tranfer-encoding for each file.
But you don't have it.
This is because the FTP model is basically broken.
It is not a consistent and complete data model.
Onw is that you have to use out-of-band telepathy to
know what sort of a file it is. The other is that the
directory syntax is not modeled, the syntax is quite
system-dependent.
The URLs were designed to model the way the protocols
are *actually used*. We are not reinventing or fixing
FTP, we are just providing hooks into it for
back-compatibility. To make a server which wasn't
broke, we invented HTTP, Mark invented Gopher.
Gopher is not broken in either of these ways.
The Gopher convention is you always give the type
along with the selector string.
The HTPP convention is that the data is returned
marked with its type and its encoding. The server
owns the data and the one in a position to say what
type its in. Not the URL, not the client, but the
server.
The FTP convention -- how it actually is used --
is that you guess the transfer mode from the filename.
That's how it happens. Its broken. You can't fix
FTP though. You can suggest FTP site admins run
HTTP or gopher on top of their archive to help real users
pick stuff up without confusion and disappointment.
In the mean time there is a whole bunch of FTP stuff
for which we want a transition strategy. Most of it
is unix. For unix, we can fix it kinda. It's been useful.
It is complete in that a URL can point to a directory
which returns a list of URLs.
For VM and VMS -- even experienced programmers can't
understand to archives -- how do you hope to automate it? :-)
Perhaps we shouldn't cry too much over FTP.
>yes. a simple flag that tells you transfer mode (text or
binary)[...]
>You would also need ftpd (for URLs that point at directories), if
you were
>going to take this approach.
Directories you can tell by trial and error, in fact,
which WWW does.
Maybe we would need 4 flags:
- text file
- binary file
- directory
- dunno yet but see what you can do (cuurent state)
This is not a suggestion.
Tim