[rfc-i] Comments on draft-iab-rfcformatreq
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Mon Dec 17 11:35:34 PST 2012
On 12/17/12 10:19 AM, Dave Thaler wrote:
> 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
> 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
> 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.
Thanks for the comments, Dave. I agree that the UTF-8 requirement could
use some clarification. Rather than get in to too much detail, I'm
working on wording to the effect of "document has to be readable even if
UTF-8 characters do not display properly".
More information about the rfc-interest