[rfc-i] Comments on draft-iab-rfcformatreq

Dave Thaler dthaler at microsoft.com
Mon Dec 17 10:19:25 PST 2012


I have reviewed this draft and have some comments which I've filed
http://trac.tools.ietf.org/group/iab/trac/ticket/245 to cover.
Editorial comments are in marked up copy in the PDF pointed to there.

Substantive comments are also there inline, but are summarized below
to facilitate discussion.

Section 2.1.3 (Pagination):
Arguments for continuing the requirement say that "referring to 
section numbers is too coarse a method".    I'd argue that
usually when it's too coarse then the document isn't well
organized and it should have subsections or line numbers
(e.g., within long pseudocode) to refer to rather than just page
numbers.   Just like section 2.1.1 argues that forcing ascii art
result in clearer writing and simpler diagrams, I wonder
if removing pagination will eventually result in clearer/simpler 
section organization.   So I guess I'm suggesting a counter argument
to the quoted point that would be in the arguments for removing.

Section 2.1.4 (Reflowable text):
>   Arguments against allowing for reflowable text:
>
>      *  Reflowable text may impact the usability of graphics and tables
>         within a document.

No, this isn't an argument against "allowing for" reflowable text. 
This is an argument against *requiring all* text to be reflowable.
There's no arguments given here against allowing paragraph text 
to be reflowable.   By comparison, section 3.2 says 
"Fixed-width fonts  are required for ASCII-art sections, source
code examples, and other places where strict alignment is
"required.
This implies (and I agree with this) that the requirements can vary
by type of text (ASCII art vs normal prose), and the same can be said
for reflowable text.   For example, section 3.2 might say
"Fixed-width fonts and non-reflowable text are required for..."
(Not sure whether that sentence has exactly the right constraint
but you get the point.)

Section 3.3 (Requirements to be retired)
>      *  Limitation to 100% ASCII text  ("The character codes are
>         ASCII.")

Consider placing some restrictions to avoid some of the problems 
referred to earlier in the doc.   For example, maybe UTF-8 characters
should only appear in *non-normative* text (examples, author names,
 etc.).   That would reduce character confusability issues since the
normative text would be ASCII.

-Dave Thaler



More information about the rfc-interest mailing list