Re: [ftpext] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.txt

[John C Klensin <[e-mail]>]

--On Sunday, July 31, 2011 04:38 -0400 John Cowan
<[e-mail]> wrote:

> Mykyta Yevstifeyev scripsit:
> 
>> Sorry for cross-posting to 6 addresses :-); please send
>> all your comments to [e-mail].  Note to
>> public-iri subscribers: please have a look at Section
>> 6.  Note to [e-mail] subscribers: please comment
>> Appendix A of the document.  (The link to HTML version:
>> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.)
 
> It's inappropriate to say that the client SHALL request a
> password from the user if none is supplied and the server
> demands one (and likewise for accounts).  The client must be
> free to fail under such circumstances, as it may be a robot or
> otherwise not have a user available.  Likewise with SHALL
> notify the user, etc.  These should be changed to MAYs or
> SHOULDs.

In principle, this sort of thing could be addressed in the spec
by adopting the model described in RFC 5321 for SMTP.  That spec
basically says that, independent of any other rules, the the
client may abort the session at any time for any reason
whatsoever.  Then it defines what "abort" means.  If one wanted
to state the above that way, it would be, e.g., "if no password
is supplied and the server demands one, then the client MUST
either find a password and send it and send a QUIT to abort the
session".

However, this identifies two other issues:

(1) FTP really is designed as an interactive protocol.  If it
had been designed for single-command-line or URI
implementations, several things might be different.   The IETF
has rarely taken on UI designs directly and has a history of
doing poorly when it does try.  If the client hasn't
spontaneously supplied a password but the server demands one,
there are lots of ways (depending on the client and its
operational environment) to obtain something password-like and
respond to the request.  Constraining those choices to "ask the
user" when the client does not decide to just abort doesn't
reflect either reality or reasonable design.  Hence "must
respond and send it" above, with the implication that the client
MAY do anything it considers reasonable to satisfy that request.

(2) More broadly, this is one of many special cases of why I
continue to object to doing this as a URI without a lot of
careful consideration.

It seems to me that there are two logical possibilities for an
FTP URI:

(a) Do something absolutely minimal that satisfies a large
number of cases.  This is probably anonymous login only, stream
and image transfer only, probably PASV only these days, maybe
even a restriction to an ASCII command stream.  If an email
address is needed for login, a provision for picking that up
from an environment variable rather than having it incorporated
into the URI, would be important.

(b) Fully-reflect the protocol and all of its standardized
options.  This would get fairly complex for a URI because one
would not only want to supply a lot of information but might
want to supply it conditionally.

Between those two points, there isn't a lot other than slippery
slope.

   john