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

[Mykyta Yevstifeyev <[e-mail]>]

John,

19.06.2011 17:38, John C Klensin wrote:
> --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.
I really consider a number if technical omissions in the document.  
However, spontaneous deprecation of the 'ftp' scheme which is currently 
used and introducing the new 'ftp' URI scheme which no one has heard 
about isn't a good option (see Section 2.1 of RFC 4395).  My proposal 
for experimentation is probably a solution.  Let's proceed with this 
document first, and then undertake an effort to produce a completely new 
specification, first experimental, and then if success, deprecate this 
scheme entirely and move that experimental to Standard Track (see 
http://www.ietf.org/mail-archive/web/ftpext/current/msg00302.html).

I really don't think 'ftpanon' scheme may be useful.  It is 
inappropriate to create several schemes for one protocol (unless it is a 
secured variant, which is the "current practice").  Having the 
"userinfo" in the URI scheme for FTP is better that deprecating it since 
might decrease the possibilities (and, thus, usefulness) of such scheme.
> (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.
Leaving the type-code part will probably create a precedent - why do we 
provide the possibility to denote use of the only one option in the 
URI.  If type-code is retained, we should provide the extension 
mechanism and make type-code a part of it.  But see below.
> (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.
Extension mechanism is really necessary.  Yet, if we try to describe the 
scheme as it is currently used there is no place for it here.  Of 
course, if we agree to undertake the effort to produce a completely new 
scheme specification, extension mechanism will be a must there.  But not 
now.
> (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.
I agree with Martin here.  It's better to have what is currently used on 
Standards Track rather something invented for the first time.  RFC 2026, 
Section 4.1.1:

>     A Proposed Standard specification is generally stable, has resolved
>     known design choices, is believed to be well-understood,
>
>     [ . . . ]
>
>
>     Usually, neither implementation nor operational experience is
>     required for the designation of a specification as a Proposed
>     Standard.  However, such experience is highly desirable, and will
>     usually represent a strong argument in favor of a Proposed Standard
>     designation.

> (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.
I think updating RFC 959 is to reflect that we introduce (in fact, 
document) one of the protocol elements for FTP.

Mykyta
> All just my opinion, of course.
>
>      john
>
>