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

[Mykyta Yevstifeyev <[e-mail]>]

20.06.2011 11:39, "Martin J. Dürst" wrote:
> Hello John,
>
> [ . . . ]
>
> With that, I don't want to necessarily say that I would disagree with 
> what you wrote e.g. specifically about the TYPE parameter. 
I may argue whether type-code part is really useful in the scheme.  I've 
checked the behavior of the browsers with regard to this part.  The results:

    * Firefox 4.0.1 (with no FTP-related addons): seems to ignore. 
      ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt;type=aft has to
      return 500 (checked; see below), but it doesn't.  The same is with
      ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt;type=f (F type-code
      isn't specified yet).
    * Google Chrome 12.0: the same.
    * Safari 3.2.1: the same.
    * IE 8: handles ";type=a" or ";type=i"; URIs with other one-letter
      type-codes are not resolved at all; if type-code has more than one
      letter - ignores.


I've also checked this with 2 FTP clients.

    *   FireZilla 3.3.2.  Type-code part is simply handled as a part of
      a path resulting in URI ftp://ftp.rfc-editor.org/in-notes/;type=a
      being interpreted as:


> Status:    Resolving address of ftp.rfc-editor.org
> Status:    Connecting to 64.170.98.47:21...
> Status:    Connection established, waiting for welcome message...
> Response:   220 "FTP Server Ready"
> Command:    USER anonymous
> Response:   331 Please specify the password.
> Command:    PASS **************
> Response:   230 Login successful.
> Command:    OPTS UTF8 ON
> Response:   200 Always in UTF8 mode.
> Status:    Connected
> Status:    Retrieving directory listing...
> Command:    CWD /in-notes/;type=a
> Response:   550 Failed to change directory.
> Command:    PWD
> Response:   257 "/"
> Status:    Directory listing successful

    * SmartFTP 4.0: the same.

FYI: bare Telnet connection to the server for checking TYPE command: 
http://i51.tinypic.com/21b10jt.jpg

So defining the scheme as currently used requires the deprecating the 
type-code part, I'm convinced.  It is mostly useless.

> 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".
Agreed here.

Mykyta
>
> 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
>>
>