[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
> "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.

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 mailing list