Message-Id: <9311240551.AA06127@mocha.bunyip.com>
Date: Wed, 24 Nov 93 00:20:34 EST
From: Rich Wiggins <WIGGINS@msu.edu>
Subject: Re: Minutes for URI
To: Alan Emtage <bajan@bunyip.com>, uri@bunyip.com
In-Reply-To: Your message of Sun, 21 Nov 1993 18:06:30 -0500
>> Is the difference that you're more likely to be able to guess the file
>> type by poking around in the allegedly opaque FTP path for a file
>> extension than by looking at the Gopher selector? This hardly seems
>> valid, but I'm really afraid that's what it is.
>Actually it is not. Since the "type" under FTP (binary, ASCII, tenex
>whatever) is required for proper access, then this is in fact more
>"access" information that "type" information. Admittedly the distinction
>is kind of blurred, but the intention is that while something like
>"PostScript" would not be allowed in the URL for FTP, "ASCII" would be to
>tell you what transfer mode to use.
[This doesn't relate to the minutes per se, but rather the thread being
discussed.]
I think Erik is absolutely right on here. FTP has a very narrow set of
"types" in the form of a couple of transfer modes (more under some
implementations but that's another story). If this limited "type"
information deserves special treatment for FTP then it's useful in other
contexts.
In my opinion the transfer mode should be explicitly carried as an
attribute of the file, not inferred from extensions, whether we're
talking FTP, Archie, Gopher, WWW, whatever. Text versus binary can be
inferred from the Gopher0 type, but how that fits in with Gopher+
and with the URI discussions is beyond me.
I don't want to start another "where does meta-information belong?"
loop, but it seems to me explicit specification of transfer mode
is the way to go in all cases. FTP doesn't seem unique.
/Rich Wiggins, CWIS Coordinator, Michigan State U