From: eostrom@gac.edu (Erik Ostrom)
Message-Id: <9310201503.AA13801@gac.edu>
Subject: Re: Final edits - summary of outstanding points.
To: mitra@path.net (Mitra)
Date: Wed, 20 Oct 1993 10:03:23 (CDT)
In-Reply-To: <CF5q2p.nF@pandora.sf.ca.us> from "Mitra" at Oct 19, 93 06:30:25 pm
> 16) Should the type field be retained in the Gopher0 URI, I think its
> redundant, I think Tim believes its needed?
It's redundant but needed unless we start tossing type information
around with URLs, an idea for which I haven't seen a lot of support,
although it seems just as necessary with FTP. (The main difference,
as far as I can tell, is that FTP paths (supposedly opaque) usually
have file extensions that clever browsers can use to guess the file
type.)
Anyway, that's all been argued before. I wanted to mention a problem
related to the inclusion of the type field which I haven't seen
mentioned.
Including a type field at the beginning of a Gopher URL path makes
relative links to documents of other types impossible.
A friend of mine wanted to set up a home page, but was not supposed to
run an HTTP server; he could, however, get documents served from the
Gopher server at his site. So he wrote up an HTML page and gave it
type `h'. He then put links in to other documents, none of which were
HTML. It would have made sense to make these relative links, but
since a relative link preserves the URL up through the part that's
modified, any documents he pointed to would have been considered type
`h', which would have been Wrong.
A possible fix for this would be to write that relative links in
Gopher can or must include a type character as the first character in
the string, but yuck.
A few months ago, I would have argued that this idea is misguided,
that Gopher selector strings are supposed to be opaque and that this
precludes the whole idea of relative links. However, since the people
who use URLs are pretty clearly uninterested in this part of the
Gopher spec, I think it's something worth considering. Let me know if
I'm wrong.
--Erik