# Re: Unresolved URL issues

Keith Moore (moore@cs.utk.edu)
Fri, 18 Mar 1994 16:19:14 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Daniel W. Connolly: "Re: Unresolved URL issues"
- Previous message: Keith Moore: "Re: Unresolved URL issues"
- In reply to: Larry Masinter: "Re: Unresolved URL issues"
- Next in thread: Daniel W. Connolly: "Re: Unresolved URL issues"
- Reply: Daniel W. Connolly: "Re: Unresolved URL issues"

    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

- Next message: Daniel W. Connolly: "Re: Unresolved URL issues"
- Previous message: Keith Moore: "Re: Unresolved URL issues"
- In reply to: Larry Masinter: "Re: Unresolved URL issues"
- Next in thread: Daniel W. Connolly: "Re: Unresolved URL issues"
- Reply: Daniel W. Connolly: "Re: Unresolved URL issues"