W3C home > Mailing lists > Public > uri@w3.org > November 2004

RE: Are we done with draft-hoffman-ftp-uri-02.txt?

From: Alun Jones <alunj@microsoft.com>
Date: Mon, 1 Nov 2004 15:02:07 -0800
Message-ID: <0966E90CB313084DA7A9C55799FDEFD203004D43@RED-MSG-50.redmond.corp.microsoft.com>
To: "Frank Ellermann" <nobody@xyzzy.claranet.de>, <uri@w3.org>

> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org] On 
> 
> Makes sense.  But we can't have a dot in ftp URLs with 2396bis:
> <ftp://example/./stuff> is the same as <ftp://example/stuff>.

Awkward.  I never liked the "/./" idea myself, as it seemed likely to be
trimmed by a pre-processor, if one existed.

> Or do you consider <ftp://example/%2e/stuff> to avoid a CD / ?

No, that should cause the client to (effectively) pass the dot on down
to the FTP server (where it will essentially be treated as a no-op).

> But is this relevant for Paul's draft ?  He said that it's
> messy, and that's obviously correct.  And recommending URLs
> <ftp://example/%2e/relative/path> resp.
> <ftp://example/%2f/absolute/path> is dubious, or isn't it ?

What's dubious, to my mind, is to have an RFC that proposes the
specification for an FTP URL, and yet doesn't predict what FTP commands
are likely to be given out by a conformant client.  I had hoped that the
behaviour I had observed was sufficiently widespread enough that,
awkward though it might be for some, the RFC could be pushed into
compliance with consensus.  Now that it appears that there is less
consensus than I had thought, I think it's very unclear what should be
done.  I will, however, see if I can shake a few apples loose around
here to get someone else's opinion.

Alun.
~~~~
-- 
I am the 'F' in "IIS".
  
Received on Monday, 1 November 2004 23:03:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:35 GMT