# Re: FTP URL mapping

Keith Moore (moore@cs.utk.edu)
Fri, 04 Mar 1994 18:00:06 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mark P. McCahill: "Re: FTP URL mapping"
- Previous message: Erik Huizer: "Re: URL document progress"
- In reply to: Mitra: "Re: FTP URL mapping"

    Message-Id: <199403042300.SAA28514@wilma.cs.utk.edu>

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

    To: Mitra <mitra@pandora.sf.ca.us>

    Subject: Re: FTP URL mapping

    In-Reply-To: Your message of "Fri, 04 Mar 1994 10:59:48."

                 <Pine.3.89.9403041005.A19683-0100000@pandora.sf.ca.us>

    Date: Fri, 04 Mar 1994 18:00:06 -0500

Mitra writes:

> The problem with a complicated URL is
> that many times its going to be specified incorrectly. If we keep it
> simple, its more likely to be correct, and we can put the smarts in the
> clients, rather than in the users.

I believe you. We need to specify FTP URLs so that what the user thinks is
the right URL, is likely to be correct. That is, if the user prepends
ftp://hostname/ to a filename relative to the top-level ftp directory, it
will be a correct URL for most systems. (This should probably correspond to
a RETR of the entire file name with no CWD first).

But I think in the long term, that URLs will more often be derived by
programs that scan file servers, than by humans. If a scanning program
doesn't do the job right when it is first written, the deficiency will be
noticed and the program will be fixed.

Even if some clients are smart, we need a specification that defines how a
URL is *supposed* to be interpreted. That way, if a particular client fails
to look up a particular URL, there's an way to determine whether the client
or the URL is out of spec. (and even with smart clients, the URL
specification dictates which interpretation the client should try first.)

Keith

- Next message: Mark P. McCahill: "Re: FTP URL mapping"
- Previous message: Erik Huizer: "Re: URL document progress"
- In reply to: Mitra: "Re: FTP URL mapping"