- From: Alun Jones <alunj@microsoft.com>
- Date: Fri, 29 Oct 2004 09:27:20 -0700
- 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 implementation. Unless anyone strongly disagrees, I'd like to propose the following text: "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] Alun. ~~~~ -- 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