- From: Alun Jones <alunj@microsoft.com>
- Date: Mon, 1 Nov 2004 15:02:07 -0800
- 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 UTC