Re: [ftpext] draft-yevstifeyev-ftp-uri-scheme-02 posted

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

--On Sunday, June 19, 2011 08:05 +0300 Mykyta Yevstifeyev
<[e-mail]> wrote:

> Hello,
> 
> After working on the document a bit, I've submitted a new
> version of draft-yevstifeyev-ftp-uri-scheme-02:
> 
> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-02
> 
> The differences from -01 are at
> http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-s
> cheme-02.txt
> 
> I personally believe the document is almost ready, yet, I'd
> like to seek more community comments (if any) on it.

First of all, I appreciate the many improvements in this
document.  Most of my difficulties with the earlier version
remain and, as a result, I don't think we are at "almost ready".
For example:

(1) Regardless of what was done in RFC 1738, if something is
going to be called an "FTP" URI, it should reflect the FTP
protocol is a serious and comprehensive way.   Failure to do so
is, IMO, a "known technical omission" and, using logic you have
used in other contexts, would require deprecating the existing
definition and moving it to Historic if it were in a stand-alone
document.   Perhaps, if you want to go down this path, you
should think about a new "ftpanon" URI that would incorporate
these capabilities (and maybe one or two more, see below), drop
<user-pass> from the syntax entirely (always send "anonymous"
and then respond to any password prompt based on what it says),
and so on.   If you did that, it would make sense to have the
document also update 1738 to deprecate its definition of an FTP
URI (or to have a discussion with the IESG about whether the
"obsoleted by" status of 1738 already accomplished that), which
I assume is part of your objective.

(2) In a world in which a lot of servers (maybe a majority) run
Linux or flavors of Unix and many client machines run something
else and get confused when trying to interpret files with
LF-only line terminations as text), I still believe that support
for TYPE is critical, even in a the stripped-down "ftpanon" URI
concept but certainly with a full FTP URI.

(3) To the extent to which the FTPEXT2 WG is actually doing
anything, a full FTP URI needs to consider the changes that are
being made there, or at least to have a mechanism for being
extended to recognize additional commands and keywords.   Again,
reducing your expectations to what I describe above as an
"ftpanon" URI would eliminate at least most of that problem.  If
you want a general FTP URI, I think that WG should carefully
review the spec once it has drained its queue of
charter-specified pending work.

(4) If your goal is not really to define a URI but to describe
the way in which the "ftp" URI is being used today, that would
be ok as an Informational document.  But, to the extent to which
what the description did or did not include constituted a known
technical omission or defect, that document would be
inappropriate for standards track.

(5) It in just a nit compared to the above, but I can find
absolutely nothing in this specification that updates RFC 959 in
any way.

All just my opinion, of course.

    john