[ftpext] Review of draft-ietf-ftpext2-hosts-05

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

My apologies for not being able to dedicate substantial time
for over a year, but following the encouragement, I'm happy
to provide another review of the FTP HOST command document.

Prologue:
I have encouraged and helped the predecessor individual draft for
a long time, and I'm a bit surprised that the draft -- after more
than 4 years of being technically rather stable and already having
more than a handful of independent implementations -- still hasn't
made it to the RFC Editor Queue.  IETF leadership should not be
surprised if reviewers get tired after such long time periods.


I fully support this draft and, upon a detailed textual review
from scratch, it seems almost ready now for publication.

The minor issues explained below seem to be a tribute to the long
history of the draft and the evolution of meta-rules in the IETF
(/ IESG) to be followed.  I also mention a few editorials, but I
refrain from indicating minor details like placement of commas that
the RFC Editor folks will be happy to put their hands on anyway.
However, I omit topics that already seem to be covered enough by
other reviews.


A) Minor issues:
+++++++++++++++

A.1)  Section 1 / established precise terminology

Please use the correct term, "header field", in the final paragraph
of Section 1.

OLD:
   It should be noted that this same problem existed for HTTP/1.0 as
   defined in [RFC1945], and was resolved in HTTP/1.1 as defined in
|  [RFC2616] through the addition of the Host request header.  [...]
                                                      ^^^^^^
NEW:
   It should be noted that this same problem existed for HTTP/1.0 as
   defined in [RFC1945], and was resolved in HTTP/1.1 as defined in
|  [RFC2616] through the addition of the Host request header field.
   [...]                                              ^^^^^^^^^^^^


A.2)  Section 3.1 / unique normative source in IETF Std-Track

For the sake of avoiding possible conflicts and ambiguity, the IETF
prefers having a single normative source for a specific bit of
specification that is reused in different protocols.

The syntax of the <hostname> argument of the HOST command is largely
borrowed from the Generic URI Syntax (STD 66, RFC 3986) <host> rule,
with added restrictions to reflect current need and practice, and to
avoid opening the path to implementation bugs by including
unspecified extension rules, e.g. for some future address family.

I would highly appreciate if the draft could shortly spell out
this intent and indicate which parts of the syntax are copied
from RFC 3986 for informational purposes only.
To this end, I suggest a few text additions, as shown below.

a)  I suggest to insert, immediately below the ABNF at the beginning
of Section 3.1, the following paragraph:

|  The <hostname> rule is a restricted form of the <host> rule
|  specified in the "Generic URI Syntax", STD 66 [RFC3986].
|  Details of the additional restrictions imposed by this document
|  are given further down in this section in the discussion of the
|  syntax; they aim at simplifying implementations by only allowing
|  what currently is specified precisely and in use on the Internet.
|  The <IPv4address> and <IPv6address> ABNF rules and all subordinate
|  ABNF rules given above are taken literally from [RFC3986] and
|  reproduced here for the convenience of readers; however, RFC 3986
|  remains the normative specification for the syntactic form of
|  IPv4 and IPv6 address literals, in order to ensure identical
|  presentation in 'ftp' URI hostname parts and in the protocol element
|  specified here.

b)  Additionally, I suggest to fulfill part of the promise given
by the above text by adding more text at the very end of Section 3.1
as follows.

OLD:
   Neither [RFC1034] nor [RFC1035] impose any other restrictions upon
   what kinds of names can be stored in the DNS.  This specification,
   however, only allows the use of names that can be inferred from the
   ABNF grammar given for the "hostname".

NEW:
   Neither [RFC1034] nor [RFC1035] impose any other restrictions upon
   what kinds of names can be stored in the DNS.  This specification,
   however, only allows the use of names that can be inferred from the
|  ABNF grammar given for the "hostname".  Similarly, this specification
|  restricts address literals to the IPv4 and IPv6 address families well
|  established in the Internet.


A.3)  Section 3.1 -- Internationalization / IDNA -- and Section 6.1

The draft needs to be updated to refer to the IDNA2008 document set
and use IDNA2008 terminology.

OLD:
   Internationalization of domain names is only supported through the
|  use of Punycode as described in [RFC3492].

NEW:
   Internationalization of domain names is only supported through the
|  use of IDNA "A-Labels" for <sub-domain> as described in [RFC5890].
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                     ^^^^

[ Note:
  This is one instance of description of additional restrictions
  in the syntax vs. RFC 3986 as mentioned in item A.2 a) above. ]

Consequentially, the Ref. item [RFC3492] in the Normative References
(Section 6.1) needs to be replaced by a citation of RFC 5890.


A.4)  Section 3.2.3 -- clarification for transitions omitted in diagrams

I suggest to clarify the text intended to indicate state transitions
not shown in the state diagrams in Section 3.2.3, by amending the 4th
paragraph of Section 3.2.3 as follows.

OLD:
|  In each of these diagrams, a REIN command will return the diagram to
|  the (B) "begin" state.

NEW:
|  For each of these diagrams, without those state transitions being
|  shown, a REIN command will return the diagram from any wait state to
|  the (B) "begin" state.



B) Editorials:
+++++++++++++

B.1) Abstract

  RFC Abstracts are to be exctracted and placed into metadata records
  without access to the References; therefore, formal citations are
  not possible in the Abstract.  So please drop "[RFC0959]" there:

OLD:
|  The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not
   provide a way for FTP clients and servers to differentiate between
   multiple DNS names that are registered for a single IP address.  [...]

NEW:
|  The File Transfer Protocol, as defined in RFC 959, does not provide
   a way for FTP clients and servers to differentiate between multiple
   DNS names that are registered for a single IP address.  [...]


B.2 Section 2.2, last paragraph

Please provide the needed hypen:
    "three digit code"  -->  "three-digit code"


B.3  Section 3.2.1 -- textual clarification

I suggest to add the word "afterwards" for clarification, as follows.

OLD:
   As specified in [RFC0959], the REIN command returns the state of the
   connection to what it was immediately after the transport connection
   was opened.  This specification makes no changes to that behavior.
   The effect of a HOST command MUST be reset if a REIN command is
|  performed, and a new HOST command MUST be issued in order to connect
   to a virtual host.

NEW:
   As specified in [RFC0959], the REIN command returns the state of the
   connection to what it was immediately after the transport connection
   was opened.  This specification makes no changes to that behavior.
   The effect of a HOST command MUST be reset if a REIN command is
|  performed, and a new HOST command MUST be issued afterwards in order
   to connect to a virtual host.



C) Remarks on other review comments
+++++++++++++++++++++++++++++++++++

C.1) Section 3.1, <domain> ABNF rule

Patrik suggested to require at least two domain labels in the ABNF.

However, the draft, in response to implementation and deployment
practice, explains in the sequel of Section 3.1 that in specific
environments, the use of *relative* domain names might be
appropriate, and therefore the present draft doen *not* require
a Fully Qualified Domain Name (FQDN) for the <domain> production.


C.2) Several comments on use of specific terms in Section 1

We have Terminology/Conventions sections in I-Ds / RFCs to explain
the usage and provenience of technical terms used in a document.
Other SDOs place such section *before* the Introduction, but
RFC Editor policy doesn't allow that.

It would IMHO be detrimental to the readability of a well-written
introduction (that is intended to give a high-level intro to the
topic while being precise in terminology) to reproduce there all
things explained in the Terminology/Conventions section, only
because, for the sake of precision, specific terms are used there.

If we really want to insist on full explanation (with citation)
at the very first use, even in the leading introductory text,
we should better allow the Introduction to go after the
Terminology Section(s) of IETF documents.


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]                     |
+------------------------+--------------------------------------------+