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

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

From: Alun Jones <alunj@microsoft.com>
Date: Fri, 29 Oct 2004 09:27:20 -0700
Message-ID: <0966E90CB313084DA7A9C55799FDEFD202FBF2A0@RED-MSG-50.redmond.corp.microsoft.com>
To: "Paul Hoffman / IMC" <phoffman@imc.org>, <uri@w3.org>

Sorry - haven't had as much time as I'd have liked lately.

Here's a few considerations.

Section 1, Introduction - "URIs are were previously defined..." - the
word "are" is superfluous.

Section 2.2, penultimate paragraph - the historical note.  It's not
"arguably in conflict", it _is_ in conflict.  The wording "quite
widespread" is not sufficient, IMHO, to convey that this is the
behaviour of the major browsers (which, let's face it, are close to the
only FTP clients that operate on URIs) - it's also possible that
regional variations may cause this phrase to be misinterpreted.  In some
usage, "quite widespread" means "completely widespread", and in other
usage, it would mean "slightly widespread".  I would prefer "so common
as to be almost universal."

I would also like to see some sort of guideline as to what behaviour new
implementors should be doing.  My gut feeling is that the widespread
practice of including the "/" means that new implementations should
default to doing that, and fall back to RFC-behaviour if that fails.
There's a certain robustness in that, since any server that can not
accept a "/" in the argument will fail immediately on that command.
Going the other way - starting with RFC-behaviour and failing over to
the rooted format - doesn't produce any syntax errors, only access
errors, which may or may not be perfectly valid.  Starting with the
practice of prefixing the path with a stroke also means that existing
URLs that work in browsers will work immediately in such a new

Unless anyone strongly disagrees, I'd like to propose the following

"Developers of new FTP client implementations that consume FTP URIs
should attempt access to the file using the slash-prefixed
('/<cwd1>...') path first, and only use the format specified in RFC 1738
('<cwd1>...') if that operation fails."

Section 3, "Security Considerations" - is it appropriate to list also
RFC2577, "FTP Security Considerations", RFC2228 "FTP Security
Extensions" (although the GSSAPI extension listed in its appendix is
horribly flakey), and the upcoming draft-murray-auth-ftp-ssl-15.txt
"Securing FTP with TLS"?  [The latter is hopefully going to result in an
"ftps:" URI]

I am the 'F' in "IIS".

> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org] On 
> Behalf Of Paul Hoffman / IMC
> Sent: Thursday, October 28, 2004 6:20 PM
> To: uri@w3.org
> Subject: Are we done with draft-hoffman-ftp-uri-02.txt?
> In a previous message, I said:
> >I updated the "ftp" draft to reflect the discussion on the list; it 
> >is now available as draft-hoffman-ftp-uri-02.txt. I think I got it 
> >right, but having folks review it would be great. Is it done, or did 
> >I mess up, or did I get it right but it could use more explanation?
> >  . . .
> >	Title		: The ftp URI Scheme
> >	Author(s)	: P. Hoffman
> >	Filename	: draft-hoffman-ftp-uri-02.txt
> >	Pages		: 5
> >	Date		: 2004-10-21
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-hoffman-ftp-uri-02.txt
> It would be grand to hear if anyone has any further refinements that 
> they want made to this draft in the next few weeks.
> --Paul Hoffman, Director
> --Internet Mail Consortium
Received on Friday, 29 October 2004 16:28:33 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:46 UTC