Date: Mon, 24 May 1993 20:09:26 (CDT)
From: eostrom@nic.gac.edu (Erik Ostrom)
Subject: Re: URLs, URIs, and references
In-Reply-To: <4g0Krce3LE06QshF0u@saintjoe.edu> from "Brian Capouch" at May 24,
To: brianc@saintjoe.edu (Brian Capouch)
Message-Id: <9305250109.AA01272@mcs-server.gac.edu>
> Unfortunately, that is only partially true; to discover the complete
> type information for a gopher object, one must have access to the
> directory entry in which the object resides. For instance, a .gif image
> shows up in a directory as being of type "I," but the object selector
> (-->URL) has the prefix "9," which signifies "undifferentiated binary."
The URL contains as much information as the directory entry. The
`gtype' element of the URL in this case should be "I", and the
`selector' element should begin with "9". The selector is for server
reference, not for the browser's use.
Realistically, browsers end up looking at selector strings because
they have to be able to recognize suffixes such as ".ps" and ".jpeg"
in order to determine how to present objects. This is a separate
deficiency in the Gopher type system as a whole, and I think it's a
problem Larry wants to address by putting type information in URLs.
(I can't decide if URLs should contain type information, or if HTML
and other things should use URsomethingelses, but I agree that type
information has to be passed around somehow. This problem is even
worse in FTP, and I presume other protocols.)
Nag mode on: So, should a slash after a gtype be considered part of
the selector or not? It would be nice to know if the spec or the
defining implementation is going to be changed, for peace of mind in
my own URL hacking.