# Re: Minutes for URI

Mark P. McCahill (mpm@boombox.micro.umn.edu)
Sun, 21 Nov 93 17:41:54 CST

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mitra: "Re: Minutes for URI"
- Previous message: Alan Emtage: "Re: Minutes for URI"
- Maybe in reply to: Alan Emtage: "Minutes for URI"
- Next in thread: Mitra: "Re: Minutes for URI"

    Date: Sun, 21 Nov 93 17:41:54 CST

    Message-Id: <9311212341.AA23777@boombox.micro.umn.edu>

    From: "Mark P. McCahill" <mpm@boombox.micro.umn.edu>

    To: eostrom@pepperoncini.gac.edu, uri@bunyip.com

    Subject: Re: Minutes for URI

In message <9311202129.AA02638@gac.edu> 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?
>

Yup...

> > - 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?

Type information is also needed for ftp access since you have to be able to
distinguish directories from documents... it is also important in ftp to
know if the file needs to be retrieved in binary mode or ascii mode.

>
> 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)

But we should not have to ignore directories :-)... URLs ought to be
able to point to collections (directories) as well as single
documents.

> 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.

At the Houston IETF it was agreed that URLs can contain type information
required by the access protocol for retrieval. So ftp and gopher (which need
some type information for retrieval) get to have the minimal type
information they need.

The ftp URL spec needs to be rewritten... Is anyone working on this?

Mark P. McCahill

gopherspace engineer/University of Minnesota
mpm@boombox.micro.umn.edu
612 625 1300 (voice) 612 625 6817 (fax)

- Next message: Mitra: "Re: Minutes for URI"
- Previous message: Alan Emtage: "Re: Minutes for URI"
- Maybe in reply to: Alan Emtage: "Minutes for URI"
- Next in thread: Mitra: "Re: Minutes for URI"