To: hoymand@joe.uwex.edu
In-Reply-To: hoymand@joe.uwex.edu's message of Fri, 22 Oct 1993 17:00:46 -0700 <93Oct22.170101pdt.2797@golden.parc.xerox.com>
Subject: Re: Final edits - summary of outstanding points.
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <93Oct22.222549pdt.2795@golden.parc.xerox.com>
Date: Fri, 22 Oct 1993 22:25:40 PDT
You made some untrue statements that I think will confuse this issue:
> But, the Gopher "type" is not necessary. The client will be able to look
> at the selector string for Gopher and know whether what's coming is a menu
> or not (which is necessary).
This isn't true. The selector string is (supposed to be) opaque to the
clients. Some gopher servers don't encode the 'type' as the first
character of the selector string, and it is definitely not part of the
gopher documentation.
> While we might consider the Gopher menu
> return just another type consideration, you really can't work with Gopher
> if you can't distinguish between menus and documents. Distinguishing
> document types, is a separate matter that spans all protocols.
I agree this is a separate matter, and that it spans other protocols.
However, i think the solution is to include type information for other
protocols for which type information is not otherwise available (FTP,
for example.)
> All in all, I'd have to say that the Gopher "type" is just meta-info
yes
> and as such should be in the UR[C|M].
Maybe the problem is that we're trying to make them all different.
What if there were a single thing that could either be a name or an
address and also had type information and other kinds of things?
> Is it correct to presume that changing this will break existing WWW
> clients? Are WWW clients using this information to know, for example,
> that the item is a Mac BinHexed file and then preceed to unbinhex it?
Current WWW clients have ugly kludges where they try to guess that
FTP-able files that end in .ps are postscript, etc.
Summary: taking type information OUT of gopher locations is a step in
the wrong direction.