RE: I-D ACTION:draft-hoffman-ftp-uri-03.txt

I think it'd be more appropriate to simply note the potential for
address harvesting _if_ the recommendation to use an email address as
the password is followed, and allow implementors to determine whether
that's a privacy risk for their application, and how best to handle it.
You do have to wonder who would be downloading from an FTP site whose
owners were not trustworthy enough to leave an email address alone!

On the topic of encoding, it would seem obvious that the URI should
contain encoded characters for those characters that a) are best encoded
(non-printables, for instance), or b) require encoding (any of
"%/;<CR><LF><NUL>").  The URI should be parsable into elements by
splitting at slashes and the semi-colon, after which time the individual
components can be percent-decoded.  The FTP client implementation is
knowledgeable about the fact that FTP uses the Telnet protocol
underneath, and so should be responsible for the encoding ( FF doubling,
for instance, or adding <NUL> after <CR>).  The URI itself shouldn't
contain a doubled FF - that's putting too much of a requirement on the
users who craft URIs to objects.

Another item I noted is section 2.1, "If no user name or password is
supplied, and one is requested by the FTP server,..."  FTP never
requests a user name or password.  It greets you with a 220, and it
refuses you access with a 530 error if you try to do an action that is
prohibited because you are not logged on.  The FTP client should always
send the anonymous user name and password if no user name (and you
should be disallowed from sending a password with no username) has been
supplied.

Note also that 2396bis says that userinfo containing a password is
deprecated.  Since FTP mostly requires a password, that deprecation
should be specifically overridden in this draft, or language inserted to
the effect that the user name should be sent to the FTP server in a USER
command, and if the response to that USER command is a request for a
password, the user-agent should prompt for such a password (or use a
cached password if one exists for this host and this user name).
Ideally language should be changed in 2396bis, such that it notes that
the deprecation of userinfo values is not applied universally to all
schemes (if FTP is unique, it should be called out as such in 2396bis,
to prevent implementors of generic URI parsing schemes from being
overzealous in stripping out userinfo).

Alun.
~~~~
-- 
I am the 'F' of "WPET" under "IIS".
  

> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org] On 
> Behalf Of Frank Ellermann
> Sent: Thursday, December 02, 2004 4:43 PM
> To: uri@w3.org
> Subject: Re: I-D ACTION:draft-hoffman-ftp-uri-03.txt
> 
> 
> P. Hoffman wrote draft-hoffman-ftp-uri-03.txt :
> 
> | ALUN'S CONCERN
> |
> | email addresses can be harvested
> 
> That's true, but I'd prefer a complete sentence, how about:
> 
>   The e-mail address conventionally sent as password for
>   anonymous access (2.1) could be harvested, user agents
>   should not sielently use addresses configured for other
>   purposes.
> 
> | <cwd1> through <cwdN> and <name> are (possibly encoded)
> | strings
> 
> Is that really all you want to say about percent-encoding ?
> It took me some hours to find the problem with %FF for an
> ordinary command line client, it's hidden in RfC 1123 3.2.6:
> 
> | a Telnet escape character (known as IAC, with the value
> | 255) to be sent as data MUST be doubled.
> 
> Who's supposed to know this, the publisher of the ftp-URI,
> or the user agent ?  Certainly not the user.  Bye, Frank
> 
> 
> 
>

Received on Tuesday, 7 December 2004 10:32:00 UTC