# Re: Unresolved URL issues

Daniel W. Connolly (connolly@hal.com)
Fri, 18 Mar 1994 18:40:10 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Scott W Brim: "Re: Unresolved URL issues"
- Previous message: Keith Moore: "Re: Unresolved URL issues"
- In reply to: Keith Moore: "Re: Unresolved URL issues"

    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

- Next message: Scott W Brim: "Re: Unresolved URL issues"
- Previous message: Keith Moore: "Re: Unresolved URL issues"
- In reply to: Keith Moore: "Re: Unresolved URL issues"