Subject: [apps-discuss] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.txt

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 31 Jul 2011 07:39:31 +0300

Hello,

Sorry for cross-posting to 6 addresses :-); please send all your 
comments to [email-masked].  Note to public-iri subscribers: 
please have a look at Section 6.  Note to [email-masked] subscribers: 
please comment Appendix A of the document.  (The link to HTML version: 
http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.)

Thanks,
Mykyta Yevstifeyev

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : The&#39;ftp&#39; URI Scheme
> 	Author(s)       : Mykyta Yevstifeyev
> 	Filename        : draft-yevstifeyev-ftp-uri-scheme-05.txt
> 	Pages           : 29
> 	Date            : 2011-07-24
>
>     This document specifies the&#39;ftp&#39; Uniform Resource Identifier (URI)
>     scheme, which is used to refer to resources accessible via File
>     Transfer Protocol (FTP).  It updates RFC 959 and RFC 1738.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-05.txt

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 31 Jul 2011 12:59:23 +0300

31.07.2011 11:38, John Cowan wrote:
> Mykyta Yevstifeyev scripsit:
>
>> Sorry for cross-posting to 6 addresses :-); please send
>> all your comments to [email-masked].  Note to
>> public-iri subscribers: please have a look at Section
>> 6.  Note to [email-masked] subscribers: please comment
>> Appendix A of the document.  (The link to HTML version:
> 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.

I think such occurrences of SHALL will be replaced with SHOULD or 
non-normative "should".  (I don't think 'ftp' URIs will be used with 
applications that have no UI; so I don't see reasons to assume they will 
be used in such way.  But, anyway, your comment regarding SHALL is 
reasonable).

>
> Editorial notes:  Lots of people don't know what "ibidem" means, or even
> its standard abbreviation "ibid".  I suggest changing the first instance
> to "in RFC 959", the second instance to "below", and the third instance
> to "in the<cwd>".

I'll make the following corrections: 1st instance - "in RFC 959" (as 
currently), 2nd one - "in the same document", 3rd one (I guess this is 
regarding ASCII) - "in RFC 959".

>
> Note error "internalization" for "internationalization", "internalized"
> for "internationalized", etc.

Fixed now.

>
> Note persistent typo "exmaple.com" for "example.com".

ACK.  Thanks for reading the document.  Mykyta

---

From: John Cowan <[email-masked]>
Date: Sun, 31 Jul 2011 04:38:53 -0400

to "in the <cwd>".

-- 
Do what you will,                       John Cowan
   this Life's a Fiction                [email-masked]
And is made up of                       http://www.ccil.org/~cowan
   Contradiction.  --William Blake

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 Jul 2011 15:42:20 -0400

> 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