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

["Martin J. Dürst" <[e-mail]>]

Hello John,

I'm not at all an expert in FTP, nor in the details of the current ftp: 
URI implementations. But the overall direction of your mail seems to be
"if it's in the FTP protocol, then it has to be in the ftp URI scheme".

In my eyes, that's just a non sequitur. If you look at HTTP, there are a 
lot of bits and pieces that are in the protocol but are not in the URI 
scheme, for good reasons. If you look at the mailto: URI scheme, then 
there are also a lot of features in SMTP and in the message format that 
are not available in the scheme. In fact for the mailto: scheme, in my 
understanding, the header part of the message format is now covered, but 
it was the spec that caught up with implementations, not the other way 
round.

Also, to claim that a spec that describes what's currently implemented 
(let's assume it does) can only go to informational, and that for 
standards track, it's necessary to cover all the features in the base 
protocol is totally new to me. As far as I understand it, the IETF is 
first and foremost about "rough consensus and running code" and only 
later about "known technical omissions".

With that, I don't want to necessarily say that I would disagree with 
what you wrote e.g. specifically about the TYPE parameter. But I very 
strongly think that this and other details have to be argued on their 
merits, rather than on a on the base of a non-existing principle of "if 
it's in the protocol, it has to be in the URI scheme".

Regards,   Martin.



On 2011/06/19 23: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.
>
> (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
>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>