# Re: URLs and types: concentrate on FTP

Keith Moore (moore@cs.utk.edu)
Fri, 04 Jun 1993 01:21:38 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Richard W Wiggins: "Re: URLs and types: concentrate on FTP"
- Previous message: John Curran: "TYPE information in URLs"

    Message-Id: <9306040521.AA01153@wilma.cs.utk.edu>

    From: Keith Moore <moore@cs.utk.edu>

    To: Richard W Wiggins <WIGGINS@msu.edu>

    Subject: Re: URLs and types: concentrate on FTP

    In-Reply-To: Your message of "Fri, 04 Jun 1993 00:10:23 EDT."

                 <9306040501.AA25933@CS.UTK.EDU>

    Date: Fri, 04 Jun 1993 01:21:38 -0400

To: Keith Moore <moore@cs.utk.edu>, uri@bunyip.com
Subject: Re: URLs and types: concentrate on FTP
Date: Fri, 04 Jun 93 00:10:23 EDT

> >> FTP URLs should have a way to specify type.
> >
> >I don't buy it, because it's tantamount to saying that URLs are file names
> .
> >Sometimes they are, sometimes they are not.
>
> Huh? A URL is just like a Gopher selector string -- it's a server
> name plus whatever you need to feed the server to grab the thing.
> The string may resemble a file name, but it need not.

As a practical matter, an FTP URL is going to contain the file name. You
could tack a type on somewhere, I suppose, but the idea that the location of
a resource should contain its type seems completely wrong.

> Adding type
> information doesn't make it any more like a file name. Instead,
> it lets an administrator post multiple forms of a document, and
> lets users (or their clients) make intelligent decisions as to
> what to retrieve, based on what the user can deal with.

Yes, having type information is useful. So is having size information.
That doesn't mean the information needs to be in the URL.

Of course, I'm assuming the existance of servers that return URNs and
citation information describing objects that reside on ftp servers.

> >.... This won't work because you are insisting, in effect, that
> >everyone adopt a particular file naming convention for their ftp servers.
> >
> >In effect, we have 'optional' type information right now -- if the server
> >uses this file naming convention, the type information is there. If the
> >URL doesn't have a recognizable suffix, you can't tell the type of the
> >object.
>
> Putting typing in the URL liberates us from relying on extensions.
> Conventions put the control in the wrong place.

It also makes it very difficult to generate URLs by listing ftpable
directories, which in turn makes it difficult for archie-like things
to return URLs in response to searches. (I'd rather it return URNs,
but URLs are better than nothing.)

> Today I got a message from someone who was trying to set up a pointer
> to a WK1 file via a Gopher FTP gateway. Current Gopher code doesn't
> list that as a known binary extension, so this transfer always goes
> ASCII. Seems to me that the type should go in the URL; if we
> don't agree on that, it shouldn't be an array of file extensions
> in the server.

I would agree that it's useful to have the *transfer mode* in an FTP URL,
since it's part of the information required to transfer the object
successfully.

Keith

- Next message: Richard W Wiggins: "Re: URLs and types: concentrate on FTP"
- Previous message: John Curran: "TYPE information in URLs"