[rfc-i] rfc format cliff notes

Correction on wiki page url:

http://www.rfc-editor.org/rse/wiki/doku.php?id=formatsummary

On 7/19/12 9:01 AM, Heather Flanagan (RFC Series Editor) wrote:
> 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
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 