RE: Last Call: Instructions to Request for Comments (RFC) Authors to BCP

[Francois Yergeau <FYergeau@alis.com>]

Re: http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-04.txt

Page 5, near bottom: typo, "TYI sub-series" should be "FYI..."

Section 2.4, first sentence "RFCs are published as ASCII text (.txt) files."
This and the following paragraphs exhibit a common and long-standing
confusion between the required format (plain text here) and the required
character encoding (ASCII here).  This is made even more evident in the
second paragraph, where we have "...the great advantages of plain ASCII text
... have made the ASCII choice a clear winner.", where all the advantages
listed are those of plain text, not of ASCII.  Clearly distinguishing the
two aspects would not only be more correct, it would also facilitate future
changes in one or the other, for instance migrating from ASCII to UTF-8,
which would be in accordance with RFC 2277 and would allow authors to spell
their names and addresses correctly, or migrating to some XML format.  Same
comment comment applies to parts of section 3, notably the title of 3.1
should be "General Plain Text Format Rules".

Section 2.4, 4th paragraph, contains "and/or", which is a linguistic
abomination that is both useless ("or" is inclusive by default in English)
and commonly misunderstood.  "and/or" should not be used in any RFC,
including this document.  Simply use "A or B" or, to be excrutiatingly
clear, "A or B or both".

Section 3.1 (1) mentions "ISO 464.IRV", this should be "ISO 646.IRV" (digits
reversed).

Section 3.1 (2) says "Note: An ASCII RFC is expected to be stored on a file
disk...".  Shouldn't that be "a disk file"?  It should certainly be "A plain
text RFC..." (see above).

Section 4.1, in the description of Author in the header, there is "(first
initial and last name only)".  This is ambiguous in an international context
(such as is certainly the case for the RFC series), as different cultures
have different notions of the ordering of the parts of a person's name.
Reword to "(initial of first given name followed by family name)".

Section 4.2 contains "Periods ("dots") are not allowed in the title."  This
would forbid anything like "X.500", "version 1.0" and "802.2 packets" and
invalidate a lot of existing RFC titles.  Is that really the intent?

Section 4.7, 3rd para contains "...the references of an RFC may be normative
and should therefore be clearly accessible at the very end of the document."
This contradicts the section ordering in 4, where References is a floating
section and can therefore appear way before the end.  Fix one or the other.

Section 4.10, the first sentence doesn't appear to be grammatical; "that
are" should probably be "that is".

Section 4.12, the use of URLs should not be discouraged so bluntly.  A URL
*in addition* to a stable reference is not harmful and can certainly be
useful as long as the URL is stable.  The quasi-prohibition should be
against having *only* a URL, especially for normative references.  This is
much better stated in 
ID-nits (http://www.ietf.org/ID-nits.html):
 o All references must be stable and resolvable. 
 o A bare HTTP URL is not generally considered a stable reference.
 o For Web-only documents, adding a reference number, title and/or
   an author will help make the reference more stable.
 o Judgment can be used here; the stability of normative references
   is more important than the stability of informative references.
except that it shouldn't single out HTTP URLs.

Section 4.12, "The References sections are floating.", but shouldn't they be
kept together and in the order Normative, Informative?

Section 4.14, the requirements for inclusion of boilerplate from RFC 2026
sec 10.4 (A) and 10.4(B) and possibly 10.4(D) (IPR statement) should be
mentionned for standard track RFCs.

General: there are 3 or 4 places that say that acronyms must be expanded,
except for a short list which differs in the 3 or 4 places.  It would be
better to say that once and then refer to it (e.g. define a term "well-known
acronyms" with a short, non-exhaustive list, and then use the term).


Regards,

-- 
François Yergeau