Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-01.txt

[Mykyta Yevstifeyev <[e-mail]>]

Hello John, all,

I'd like to comment the new revision of draft-ietf-ftpext2-typeu, which 
was uploaded on 20 June.  Probably, my comments are mostly minor and 
editorial, but I believe they will help in improving the document.
>                  FTP Extension for Internationalized Text
>                        draft-ietf-ftpext2-typeu-01
The title reads "FTP Extension for Internationalized Text".  I'd better 
changed this to "FTP Data Type for Internationalized Text" not to create 
confusion with RFC 2640, which has contiguous title.

Next,
> Abstract
>
>     The original FTP protocol supported TYPE values
I'd like to recommend you to change "TYPE values" to "data types"; TYPE 
values van be referred to only in Section 2, which is technical 
specification of new data type, since the preceding sections explain 
what does the TYPE command mean and what is it used for.  You could also 
use "data types (and, respectively, TYPE command values)" or something 
like this.
>     for ASCII and EBCDIC
>     text, plus binary ("IMAGE") transmission.  As the Internet becomes
>     more international, there is a growing requirement to be able to
>     transmit textual data, encoded in Unicode, in a way that is
>     independent of the coding and line representation forms of particular
>     operating systems.  This memo specifies a new FTP TYPE value
The same concerns this and Section 1.1.
>     for
>     Unicode data.

Section 1.4:
>     It also uses the ABNF
>     of [RFC2389] and [RFC5234] in preference to the BNF of RFC 959.
I haven't noticed any use of ABNF in the draft.  So the reference to RFC 
5234 is redundant, as well as the above sentence.

Ibid:
>     Those terms, especially reply, server-FTP
>     process, user-FTP process, server-PI, user-PI, logical byte size, and
>     user,
I don't see any occurrences of "user" in the document.

Also Section 1.4:
>     For
>     the convenience of contemporary readers, the terms "client" and
>     "server" are used interchangeably with the historic terms "user-FTP
>     process" and "server-FTP process".
Why not completely replace server-FTP process and user-FTP process with 
server and client, respectively, within the whole document at all?  In 
this case this phrase will read:
>       In this document the terms "client" and "server" are used in the
>       meaning of "user-FTP process" and "server-FTP process", respectively,
>       which are defined ibidem.
Respectively, any occurrences of "user-FTP process" and "server-FTP 
process" are to be replaced by "client" and "server".

Section 2.1:
>     E  The data are expected to be in, and are transformed by the server
>        if needed to, an EBCDIC data stream as specified in RFC 959.
For the reader's convenience, the reference to some material concerning 
EBCDIC could be provided.

Section 2.2:
>     If it does, the server MAY
Probably SHOULD or SHALL is more appropriate here; what is an other way 
to indicate that U data type isn't supported, in this case?
>     return reply-code 504, indicating that the TYPE U feature
I'd better replace this with "Unicode data type" (as well as the section 
title).
>     is not supported (unchanged from RFC 959) or MUST
I suppose your document should mention here that 200 reply must be 
returned before the data in Net-Unicode will be sent.
>     respond to any data retrieval request (e.g., GET)
You probably meant RETR here, since GET is related to HTTP only.
>     by sending the data in a stream
>     conformant to the Net-Unicode format specified in Section 3.

Section 3:
>     Unicode characters must be transmitted in UTF-8
I think the reference to RFC 3629 is missing here.

Section 5:
>     When this specification is approved, an entry for "TYPE U" that
>     refers to it should be incorporated into the FTP Extensions Registry
>     established by RFC 5797 [RFC5797].
I've checked IANA registry 
(http://www.iana.org/assignments/ftp-commands-extensions/ftp-commands-extensions.xml) 
and I see IANA doesn't officially track arguments to TYPE command.  It says:
>     TYPE  base      Representation Type               p    m     [4][RFC959]
and the [4] footnote is:
>     [4] FEAT String: TYPE {semicolon-separated list of supported types}
so I think there are no IANA considerations here.

Section 8.1:
>     [Unicode52]
>                The Unicode Consortium.  The Unicode Standard, Version
>                5.2.0, defined by:, "The Unicode Standard, Version 5.2.0",
>                (Mountain View, CA: The Unicode Consortium, 2009. ISBN
>                978-1-936213-00-9).,
>                <http://www.unicode.org/versions/Unicode5.2.0/>.
This may be considered to be obsoleted normative reference, since 
Unicode 5.2 has been obsoleted by Unicode 6.0.0.  The reference should be:
> The Unicode Consortium, "The Unicode Standard, Version 6.0.0",
> (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6),
> <http://www.unicode.org/versions/Unicode6.0.0/>.
Or, if you want to be independent from version:
> The Unicode Consortium, "The Unicode Standard",
> <http://www.unicode.org/versions/latest/>.

Thanks,
Mykyta Yevstifeyev

20.06.2011 19:06, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF.
>
> 	Title           : FTP Extension for Internationalized Text
> 	Author(s)       : John C Klensin
> 	Filename        : draft-ietf-ftpext2-typeu-01.txt
> 	Pages           : 9
> 	Date            : 2011-06-20
>
> [ . . . ]
>
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>