Message-Id: <9311202129.AA02638@gac.edu>
To: uri@bunyip.com
Subject: Re: Minutes for URI
Date: Sat, 20 Nov 1993 15:29:47 -0600
From: Erik Ostrom <eostrom@pepperoncini.gac.edu>
I wanted a couple of things clarified about the decisions made about URLs.
> By rough consensus (though not unanimity) it was decided that the
> prefix "URL:" would be used on the URL specification. No versioning
> information will be included.
Um, does this mean the "URL:" prefix will be part of the URL, rather
than just prepended to URLs in some situations?
> - Other than the prefix and protocol designators the URL is an opaque
> string to everything other than that protocol. Unless the
> information is needed to access the resource, the information should
> not be included in the URL.
I'm confused about this opacity. In the last URL spec I read:
- Clients have to parse various pieces of information out of
different kinds of URLs. (Are these `protocol designators'?)
- Clients have to unescape paths for some URL protocols and not for
others.
- Partial URLs that contain certain elements can be munged at will
according to a set of rules. This may not be a concern if we're
talking only about absolute URLs here.
Am I confused about the meaning of "opaque"?
> - Group decided that the "news" URL should be removed from the
> document, and replaced with a valid NNTP: URL. Installed base will
> continue to use "news" URL until transition can be made
What will the nntp: URL contain? Will server names be permitted? Allowed?
> - Gopher type needs to be added back in because it is required for
> access and is thus not considered "type" information in this context.
> Suggestions will be presented on the list for this.
I don't understand this. In what way is type information more
necessary for Gopher access than for FTP access?
The way you get the information identified by a Gopher URL is by
connecting to the server and sending the selector string. The way you
get the information identified by an FTP URL (ignoring directories for
the moment) is by connecting to the server, sending a cd command, and
sending a get command.
In both cases, the result is a bitstream that you don't know what to
do with.
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.
I recognize that a document retrieved from Gopher without type
information is fairly useless for most purposes. But let's not
pretend it's a problem specific to Gopher. If we need type
information in URLs, let's add it. If we don't, let's leave it out.