User Tools

Site Tools


formatsummary

This is an old revision of the document!


Current proposals:

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; in discussions of internationalization, actually being able to

illustrate the issue is rather helpful, and you can't illustrate a Unicode code point with “U+nnnn”.

  • 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

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
formatsummary.1342721599.txt.gz · Last modified: 2012/07/19 11:13 by rsewikiadmin