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

[Mykyta Yevstifeyev <[e-mail]>]

22.06.2011 7:10, Mykyta Yevstifeyev wrote:
> Hello all,
Hello,

I've made several changes to the draft-yevstifeyev-ftp-uri-scheme based 
on comments from John and I'd like to request community feedback on 
them.  Please find my changes descriptions in-line.
>
> 20.06.2011 15:13, John C Klensin wrote:
>>
>> --On Monday, June 20, 2011 17:39 +0900 "\"Martin J. Dürst\""
>> <[e-mail]>  wrote:
>> [ . . . ]
> I agree here, so let's have a discussion.
>> Three examples of the "known technical omission" problem:
>>
>> (i) At least historically, the most-used command in the FTP
>> protocol, other than the basic authentication ones (USER, PASS),
>> CWD and PWD and the basic ones actually involved in transferring
>> files (RETR, STOR, and probably PASV) has been TYPE.  It is not
>> like, e.g., STRU or the file structuring commands, which many
>> people and servers can go for many years without ever seeing.
>> TYPE was really important in the early days of the net when we
>> not only had EBCDIC floating around, but had at least three
>> different ways to encode ASCII.  A decade and a half ago, only
>> the CRLF issue remained and, if examined from a narrow web
>> perspective (see below), it doesn't make much difference (the
>> number of problems it causes every year, with lusers not
>> understanding the symptoms and a distinct shortage of standard,
>> user-accessible, conversion utilities on most systems, remains
>> non-trivial).   It gets more important again as we see more and
>> more files in non-ASCII character sets, both Unicode and
>> non-Unicode.  Even with the former alone, an IMAGE transfer may
>> yield any of more than a half-dozen forms (see
>> draft-ietf-appsawg-3536bis for a list that still does not
>> include the obscure ones).  So, to me, saying "TYPE" is not
>> needed or should be treated like any other extension indicates a
>> lack of understanding of the underlying protocol.
> Probably.  However, if we agree on leaving this part, we will need to 
> have a discussion on the handling of this part in the URI, since RFC 
> 1738 isn't clear with this regard.
Currently the syntax for <ftp-path> is:

>      ftp-path       = cwd-part [ "/" name ] [ typecode-part ]
>      cwd-part       = *( "/" cwd )
>      cwd            = segment-nsc
>      name           = segment-nsc
>      segment-nsc    = *pchar-nsc
>      pchar-nsc      = unreserved / pct-encoded / sub-delims-nsc / ":"
>                     / "@"
>      sub-delims-nsc = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" /
>                     / "," / "="
>                     ; RFC 3986 <sub-delims> excluding semicolon (";")
>                     ; character (ASCII [ASCII, RFC0020] character 0x3B)
>      typecode-part  = ";type=" typecode
>      typecode       = "a" / "e" / "i" / "u" / typecode-ext
>      typecode-ext   = ALPHA
The appropriate step was added in the algorithm in Section 2.2.3:

>    (2)  if the <typecode-part> is present, perform the TYPE command with
>         the <typecode> as an argument;
>
>      Note:  There are currently four options of the <typecode> part.
>      They include "a", "e", "i", which are specified in RFC 959
>      [RFC0959] and stand for ASCII, EBCDIC text and binary transmission,
>      respectively, and "u", which is specified in RFC mmmm [I-D ietf-
>      ftpext2-typeu] and stands for Unicode data.  Additional data types
>      may be accommodated in the URI via the <typecode-ext> production.
This incorporates the ongoing work of FTPEXT2 WG regarding U data type 
for Unicode data and provides a possibility to add new data types in the 
URI.
>> (2) There is currently a proposal in the FTPEXT2 WG to add a
>> HOST command to FTP (draft-ietf-ftpext2-hosts) for exactly the
>> same reason we needed to add one to HTTP.  I'm personally not a
>> fan of that particular way of doing the job, but one of the
>> strong arguments for it is that it could potentially be
>> automated in a shim or API that connects an FTP URI processor to
>> the FTP protocol as "always send HOST, if it is rejected as not
>> recognized, ignore and pretend it wasn't sent".  But, if we
>> think HOST is important, that needs to be considered and
>> explicitly discussed in any FTP URI document.  If it isn't
>> important enough to be considered and discussed, then the
>> extension probably isn't important enough to adopt and use.
>> Since the WG hasn't acted on the proposal, the issue is somewhat
>> forward-looking, but that puts the current FTP URI proposal in
>> the same boat as MAILTO -- it is hard to define a URI for a
>> protocol to which it is not integral and has to be retrofitted
>> when the protocol itself is being changed/extended in ways that
>> should rationally affect the URI.
> I've carefully read the FTPEXT2's draft on the proposed HOST command.  
> HOST is surely a good proposal to use at all and I currently think 
> including it in the URI specification for FTP is probably a good 
> idea.  So, with this respect I can agree with you and, therefore, 
> agree to include this proposal in the 'ftp' URI specification.
Now 2 new paragraphs were added in Section 2.2.1:

>    Upon establishing a successful TCP connection, the client SHALL first
>    try to identify the host it is trying to access using the HOST
>    command [I-D ietf-ftpext2-hosts].  It is performed by sending this
>    command with the <host> part of the URI as an argument.
>
>    If either 500 or 502 reply is received in response (which identify
>    that the HOST command is unrecognized or unimplemented,
>    respectively), the client SHALL act as if a HOST command had not been
>    sent and continue processing the URI.  If either 501 or 504 reply is
>    received (which identify that the supplied hostname is syntactically
>    invalid or it is unavailable, respectively), the client's behavior
>    depends on how does the server react.  If, in accordance with Section
>    3.3 of RFC nnnn [I-D ietf-ftpext2-hosts], the server chooses to
>    terminate the connection, the client SHALL notify the user and take
>    no further actions.  Otherwise, if the server does not terminate the
>    connection, the client SHALL act as if a HOST command had not been
>    sent and continue processing the URI.
Best,
Mykyta Yevstifeyev
> [ . . . ]
>
> All the best,
> Mykyta Yevstifeyev
>> regards,
>>      john
>>
>>
>