[rfc-i] rfc format cliff notes

[rse at rfc-editor.org (Heather Flanagan (RFC Series Editor))]

Hi all -

Quite a number of people have gotten lost in the vast expanse of mud
pits, rabbit holes, bike sheds, and bubbling caldera, and so I've tried
to pull together a neutral list of the more contentious issues and their
major "for/against/did you consider?" points.

If you'd like to read this on the wiki, it is available online at:
http://cursive.net/draft-hildebrand-html-rfc-2012-07-16.html

To keep the rfc-i wholly contained, a copy of the information is below.

** If you have something to add, a point I missed or an argument that
you feel needs to be captured, please send it to me directly. I don't
want to rehash it on the mailing list at this time.**

--------
Current proposals:
  *
[[ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-hoffman-rfcformat-canon-others-03.txt|draft-hoffman-rfcformat-canon-others-03.txt]]
  *
[[http://cursive.net/draft-hildebrand-html-rfc-2012-07-16.html|draft-hildebrand-html-rfc-2012-07-16.txt]]
  *
[[ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-rfc-image-files-03.txt|draft-rfc-image-files-03.txt]]

This is a summation of the more polarizing issues related to RFC format.
 Many participants in the discussion have dropped off in reaction to the
sheer quantity of discussion around these and the other topics.  To
bring everyone back up to speed, this list the more contentious topics.

====== Physical format ======
Pagination
  * For: Ease of reference and clear printing; referring to section
numbers is too coarse a method
  * Against: Want a smooth reading experience regardless of page or
screen size
  * Additional thoughts: the RFC Editor does not recommend using page
numbers as points of reference


Character encoding - ASCII
  * For: Most easily searched and displayed across a variety of
platforms.  In extreme cases of having to retype/scan hard copies of
documents (it has been required in the past) ASCII is significantly
easier to work with for rescanning and retaining all of the original
information
  * Against: Too limiting with regards to internationalization issues


Character encoding - UTF-8
  * For8: Allows authors to spell their names correctly; certain special
characters in equations or quoted from other texts allowed; citations of
web pages using more international characters possible
  * Against: Exactly what characters are allowed and where the line
should be drawn remains unclear (why some characters commonly used in
European languages and not other, non-Latin characters? This is just
pushing the problem around.)
  * Additional thoughts: just moving from ASCII to UTF-8 (as opposed to
UTF-8 and HTML or XML) leaves us with dependencies on the local file
systems and processors to be configured properly and do the right thing
with the document, where as browsers will recognize UTF-8 and can
declare the encoding definitively


Mobile Devices
  * For: We should take their needs for format flexibility (reflow) in
to account
  * Against: Not enough people use mobile devices, and those that can
can generally scroll, so this should be treated as an edge case at best


ASCII art
  * For: Dependence on advanced diagrams (or any diagrams) causes
accessibility issues
  * Against: It does not allow for reflow
  * Additional thoughts: If we go beyond ASCII art, need to pick just
one format: GIF? PNG? SVG?





====== Production and publication issues ======

Use of RFC-specific tools
  * Against: We can't be that unique in our needs that we can't use
commercial tools
  * For: We have more control over the tools we write, and the audience
that reads RFCs will always be capable of coding up something new if
needed; we have xml2rfc to work from as a base and should perhaps
consider how to retain nroff


ASCII art
  * For: It forces people to rely more on words and clear written
descriptions than the diagrams; each diagram is relatively simple and
discrete
  * Against: The often poor, limited diagrams are a hindrance to visual
thinkers
  * Additional thoughts: If we go beyond ASCII art and have the
normative diagrams be entirely separate documents, we may not need to
limit ourselves to one graphic format (but doing so may make things simpler)


Equations
  * For: Some authors have chosen not to publish RFC due to difficulty
in displaying proper mathematical equations
  * Against: So few RFC include mathematical equations that this should
not be given any priority in the discussion of format


Metadata and tagging
  * For: Ability to semantically tag some document info, at least
authors' names and references is useful
  * Against: Metadata is unnecessary overhead
  * Additional thoughts: there is no list of tags that will be required
for XML or HTML that would build-in required simplification and support
for the archival nature of the series (that people can work longer with
a simplified set of tags), and until we have that, we cannot talk about tags


Containment
  * For: Lack of containment for sections means that processing software
cannot be fully aware of the document structure, and that is serious
restriction
  * Against: Containment is unnecessary and not compatible (or perhaps
just not required?) with traditional HTML and word processor document
  * Against: Requiring containment may limit the number of editors
authors can use to create documents
  * Against: Requiring containment would require every authoring format
to be translatable to the submission format
  * Against: Containment should be optional


Source Code format
  * For: having a source code format such as XML or HTML allows for
greater flexibility in creating a variety of display formats, with a
greater likelihood of similarity between them
  * Against: having the canonical format be in code ties us in to
specific tools and/or tool support going forward