Notes from RFC Format BoF, IETF 85

Questioning assumptions slide
* Most in the room read the draft
* room definitely split between people who feel a change is necessary at some level (argument about the word "necessary") and people think it is not necessary, but people think it is very highly desirable for a new format to be available.


Existing Requirements slide
"The Boilerplate and overall structure of the RFC must be in accordance with current RFC and Style Guide requirements (see [RFC5741])."
* Paul Hoffman: 3rd bullet not a format requirement: have a clean split between placement (format) and content (style)

"While several publication formats must be allowed, the publication formats must include support for plain-text printing."
* "plain text" is not appropriate in existing requirements
* definition of plain-text: 'printable' is no longer enough, Scott Bradner suggested 'monospace'
* Stefan Sanderson: we need to capture everything, including format metadata, i.e. information not intended for editing or display; neither nroff or xml captures this
  o Stefan was thanked for his work on NroffEdit.
  o If the revisable format changes from nroff, RFC authors will need WYSIWYG editing tools at least as easy to use as NroffEdit.

"RFCs must not change, regardless of format, once published."
* RFC files must not change...
* Larry Masinter: we need to make sure archival needs are met (just as we say for accessibility needs)

Other comments:
* Be more explicit in backwards compatibility


New Requirements slide
Other comments
* make archivability an explicit requirement
* RFC format should include needs implementers/users as a key driver for change
* Use fully qualified descriptive name (e.g. "canonical format") everywhere 
* All requirements should have a terse justification
* How does a new format impact MIBS and embedded code? Must allow for a machine readable format
* Christian Hoene said he has an equation ? pdf tool, if that's useful/needed one day

"Fonts are restricted to fixed-width fonts."
* request to allow both fixed and variable as appropriate in a document
* mathematical expressions do not work well in fixed-width fonts

"Graphics may include ASCII art and SVG line art.  Color will not be accepted; RFCs must correctly display in monochrome."
* some demand for color
* some agreement about allowing more complex graphics, but which graphics format and how they would be included in the document file under question
* line art: svg said to be "hard to generate" 
* two more requirements:
  o Scott: be able to submit in nroff, plain text, as well as xml
  o be able to parsed by programs (not obvious which format this applies to - could simply use existing tools to generate plain-text version, then parse that).  Maybe we need - somewhere in the draft - a system outline, i.e. {input format copy} ? cannonical format copy (used for editing and archive) ? {output format copies}



RFC Editor Requirements slide
"The final conversion of all submitted documents to nroff should be replaced by using an accepted revisable format throughout the process."
* Generic markup versus layout markup - need to consider how using something like HTML or XML might be challenging for page layout purposes
* Language on this bullet is not clear
* Stefan said nroff good for editing, not good as an archival format (?)
* Comments made about "Tools the RFC Editing team will need"    
  o A short list of examples would probably be helpful


Requirements to Retire slide
* no major objections


Next Steps slide
* remove all references to "consensus" as it does not apply to this process