[ftpext] A review of draft-ietf-ftpext2-typeu-03

[Alfred Hönes <[e-mail]>]

I took the time to re-consider and re-review the most recent (-03)
version of draft-ietf-ftpext2-typeu and would like to submit a few
comments, most of which are editorial in nature.

The technical content of the draft seems reasonable and specified
in sufficient detail to further interoperable implementation.

The items below are listed in textual order of (first) appearance.


(1)  Terminology

In the Abstract and in the 2nd paragraph of Section 1.1,
the draft talks about "... textual data, encoded in Unicode, ...".

IMO, this is stressing the IETF terminology on character sets and
encodings, since "Unicode" -- despite its name -- is not regarded
as a character set *encoding* per se.
Instead, and actually, the draft specifies the use of a specific
encoding format for Unicode, (a profile of) UTF-8, the Unicode
Transformation Format preferred in the IETF and the contemporary
Internet.

Therefore, I suggest to substitute for the above quote (in both places)
"... textual data, represented in Unicode and encoded in UTF-8, ...".


(2)  Section 1.3

YES, I appreciate the information in this section, and it seems
to be very useful background information for all readers, and thus,
I strongly recommend to keep this part of the memo, but drop the
leading "Note in Draft" -- including the dangling reference to
another discussion list, contrary to Section 1.5 (see below).


(3)  Section 1.4, 2nd paragraph

I suggest to emphasize the key terms from RFC 959 by enclosing
them in double quotes in the second sentence of this paragraph
-- in the same style the RFC 2119 terms are presented in the
first paragraph of this section.


(4)  Section 1.5 -- pointer to discussion list

Since the draft apparently is prepared using xml2rfc, I suggest to
make use of a specific property of the RFC 2629 format that produces
an unnumbered mini-section on the draft front page to convey this
information, instead of a numbered section deeply embedded in the
document body -- thus putting this hint into a prominent place for
the attention of readers.  Thus, you might want to use the <note>
element within the <front> part of the XML source of the draft
to carry the pointer to the discussion list.


(5)  Addition to Section 2 -- likely Section 2.1

It might be wise to recall somewhere in the document, perhaps
at the end of Section 2.1, that the effective choices for TYPE
(and STRU) not only affect actual file transfers but also the
processing by other commands, in particular the SIZE command
[RFC3659].


(6)  Section 2.4 and Section 5

Since Section 2.4 specifies an extension to FEAT usage for the
"TYPE" command, it would make sense to have the "TYPE" entry in the
"FTP Commands and Extensions" IANA registry amended by an additional
reference to this document.

To this end, I suggest to insert new text paragraph into Section 5
and use the precise name of the registry in the present text.
For example:

OLD:

|5.  IANA Considerations
|
|  When this specification is approved, IANA is requested to add an
|  additional table to the FTP Extensions Registry established by RFC
|  5797 [RFC5797].  That table should be titled "TYPE command arguments"
|  and should include "A (m) RFC 959", "E (o) RFC 959", "I (o) RFC 959",
|  "L (o) RFC 959", and "U (o) RFCNNNN".

NEW:

|5.  IANA Considerations
|
|  Upon approval of this specification, IANA is requested to perform /
|  has performed the following additions to the "FTP Commands and
|  Extensions" Registry established by RFC 5797 [RFC5797].
|
|  An additional reference to this RFC is added to the "TYPE" entry.
|
|  Footnote [4] (pointed to by the "TYPE" entry) is amended to say:
|
|   [4] FEAT String: TYPE {semicolon-separated list of supported types}
|       where the supported types are drawn from the TYPE arguments
|       listed in the sub-registry below
|
|  An additional sub-registry and table titled "TYPE command arguments"
|  is added as follows, with a primary reference to this RFC, and
|  registration policy same as for the primary registry (per RFC 5797):
|
|    TYPE      conf    Reference
|  argument
|  --------  --------  ---------
|     A         m      [RFC0959]
|     E         o      [RFC0959]
|     I         o      [RFC0959]
|     L         o      [RFC0959]
|     U         o      [RFCthis]


(7)  Section 7.1, Reference for ASCII

Recently, RFC 20 has been used as the preferred reference for ASCII
in contemporary RFCs.  Maybe this choice could be adopted here.

BTW (for my interest as an I-D author):
  How do you happen to include the additional note for a reference
  as shown in the [ASCII] entry in the draft, using xml2rfc ?


(8)  Section 7.2 -- reference update

The rfc3536bis draft has been published as RFC 6365.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+