Message-Id: <9311212306.AA01886@mocha.bunyip.com>
From: bajan@bunyip.com (Alan Emtage)
Date: Sun, 21 Nov 1993 18:06:30 -0500
In-Reply-To: Erik Ostrom's message as of Nov 20, 15:29
To: Erik Ostrom <eostrom@pepperoncini.gac.edu>, uri@bunyip.com
Subject: Re: Minutes for URI
[Erik Ostrom writes:]
> 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?
Correct. The base URL definition contains the string "URL:" as its
initial sequence.
> > - 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"?
My understanding is that it is the sense of the group that if you happen
to be a library routine handling the fetching of objects via FTP then you
of course have to look at the rest of the URL. However, general rules
do not apply to the opaque string: you have to know how to parse that
particular URL "protocol designator" in order to know what it says.
> > - 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?
I think Mitra is the best person to handle this one....
> > - 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.
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.
-- -Alan------------------------------------------------------------------------------ Alan Emtage, "The Left in Canada is more gauche Bunyip Information Systems, than sinister" Montreal, CANADA -The Economist
bajan@bunyip.com Voice: +1 (514) 875-8611 Fax: +1 (514) 875-8134