Message-Id: <199403182119.QAA04174@wilma.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: Unresolved URL issues
In-Reply-To: Your message of "Thu, 17 Mar 1994 19:21:58 PST."
<94Mar17.192201pst.2732@golden.parc.xerox.com>
Date: Fri, 18 Mar 1994 16:19:14 -0500
> Issue:
> does a/b/c/d
>
> mean 1) CWD a ; CWD b ; CWD c ; RETR d
> or 2) CWD a/b/c RETR d
>
>
> > Unless someone can demonstrate a (real) case where zero or
> > one CWD commands will NOT work, I strongly prefer that the
> > FTP URL *not* specify repeated CWD commands.
>
> The problem is that the delimiters differ from file system to
> file system; if you want to FTP hd:folder:foo:baz from a macintosh,
> you'd have to write ftp://mac12.silly.com/hd:folder:foo/baz.
If the mac server doesn't require that you CWD first you could
use ftp://mac12.silly.com/hd:folder:foo:baz instead.
Another example: a VMS ftp file name could be written as:
ftp://vms.foo.com/device:[directory]/foo.ps;3
meaning
CWD device:[directory]
RETR foo.ps;3
(basically, I'd make the LAST unencoded '/' character (after the one
following the server's domain name) a separator between the directory
and the file name. If there isn't one, the whole thing is a file name.)
Biggest problem I can see is with relative URLs, which already have
built-in assumptions about how file names are written.
> Do is your argument against the `multiple CWD' interpretation one of
> aesthetics or efficiency?
Neither. I want it to be maximally interoperable.
> I think 'smart clients' could probably recognize a FTP greeting
> from their favorite style of FTP server, if need be.
That's fine as an efficiency hack, but if that attempt failed,
the client should be able to "fall back" to the behavior defined
in the RFC and have the retrival work.
Keith