Message-Id: <9403190040.AA12435@ulua.hal.com>
To: Keith Moore <moore@cs.utk.edu>
Subject: Re: Unresolved URL issues
In-Reply-To: Your message of "Fri, 18 Mar 1994 16:19:14 EST."
<199403182119.QAA04174@wilma.cs.utk.edu>
Date: Fri, 18 Mar 1994 18:40:10 -0600
From: "Daniel W. Connolly" <connolly@hal.com>
In message <199403182119.QAA04174@wilma.cs.utk.edu>, Keith Moore writes:
>
>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
Just so we're all in sync here... what does anybody else think
about the suggestion that all characters outside of
*-.0123456789@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
have to be escaped?
In other words, you'd write:
ftp://vms.foo.com/device%3A%5Bdirectory%5D/foo.ps%3B
so the client can only "see" the / before foo.ps
>(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.
Yes... this is the crux of the matter... sometimes I wish relative
URLs were resolved on the server side... but they're not -- the spec
says that the namespace is explicitly hierarchical. This means
that there has to be a specification for how paths get mapped from
/a%2Fb/c
to
"a/b", "c"
to
CWD a/b
RETR c
or whatever.
>Neither. I want it to be maximally interoperable.
Amen.
>> 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.
Amen again. Does the FTP RFC address this issue? (Sorry... I'm
feeling lazy or I'd look it up myself)
Dan