To: mitra@path.net
In-Reply-To: mitra@path.net's message of Thu, 3 Jun 1993 21:04:08 -0700 <93Jun3.210425pdt.2749@golden.parc.xerox.com>
Subject: Re: URLs and types: concentrate on FTP
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <93Jun4.020257pdt.2741@golden.parc.xerox.com>
Date: Fri, 4 Jun 1993 02:02:46 PDT
> Larry
> I think what you mean is that there must be a way to convey type information inside, OR with a URL.
> - Mitra
Well, I'm using 'URL' to mean 'the thing we stick inside HTML
documents and other places to link to data when you don't have a URN
or don't want to make one up.' and, in particular, the thing that
currently has a draft proposal saying:
The data format of a file can only, in the general FTP case,
be deduced from the name, normally the suffix of the name.
This is not standardised. The transfer mode (binary or text)
must in turn be deduced from the data format. It is
recommended that conventions for suffixes of public archives
be established, but it outside the scope of this paper.
So, I'm trying to say: I don't like this. Give a way to include the
data format in the FTP links. Don't require it. Strongly recommend
that, except perhaps for a few well-known suffixes, data formats
should be included. It will make browsers more reliable. It will make
more kinds of things accessible, that don't have standard suffixes but
might have well-defined MIME types.
Now, I'm saying 'put it in the URL' because we've already defined HTML
to include a 'url' in a HREF, and various other utilities are thinking
about using URLs for the same purpose.
Some URLs don't need types. HTTP2 URLs don't, because you can discover
the type once you follow the link. Gopher URLs don't need any
additional types, because the type is coded in the URL already. news
URLs don't need a type, because there's already an implicit type for
news articles. (I'd like to see some way to categorize 'telnet' URLs
by how the telnet session is supposed to be handled, what terminal
emulator is required, whether a 'mud client' might be more
appropriate, etc., but that's a different message.)