User Tools

Site Tools


formatsummary

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
formatsummary [2012/07/19 08:48]
rsewikiadmin
formatsummary [2019/09/18 13:02] (current)
rsewikiadmin [Physical format] updated link
Line 5: Line 5:
  
 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.   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.  
 +
 +====== Definitions ======
 +Source format, aka Submission format, Input format = the format used by authors, etc., when writing an I-D. Currently: XML (can be uploaded to the I-D submission tool currently), NROFF, .doc, .txt
 +  * may or may not be the same as any other format (though it would make the workflow somewhat simpler for the RFC Editor if it were); 
 +  * will be converted to another format for further processing and publication if necessary
 +
 +Canonical format = the authorized, recognized, accepted, official version of the document
 +  * other document types may be derived from this format; may or may not be one of the possible output formats
 +
 +Archival format = currently the printed, paper copy AND the digital .txt of the RFC
 +  * currently the same as the canonical format
 +
 +Output format, Display format = format as it may be read or printed after publication process has completed; currently ASCII, PDF, and HTML are common output or display formats
 +  * For I-D: TXT*, PDF*, PS*, HTML.
 +  * For RFC: TXT, .TXT.PDF, Enhanced PDF (rare)
 +  * Outside RFC Editor: HTML (via rfcmarkup), HTML (via datatracker), PDF, perhaps others.
 +
 ====== Physical format ====== ====== Physical format ======
 Pagination Pagination
-  * Yes pagination: Ease of reference and clear printing; referring to section numbers is too coarse a method +  * For: Ease of reference and clear printing; referring to section numbers is too coarse a method 
-  * No pagination: Want a smooth reading experience regardless of page or screen size  +  * Against: Want a smooth reading experience regardless of page or screen size  
-  * Further information: the RFC Editor does not recommend using page numbers as points of reference+  * Additional thoughts: the RFC Editor does not recommend using page numbers as points of reference
  
  
 Character encoding - ASCII Character encoding - ASCII
-  * Yes to ASCII: Most easily searched and displayed across a variety of platforms +  * 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 
-  * No to ASCII: 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+  * Against: Too limiting with regards to internationalization issues
  
  
 Character encoding - UTF-8 Character encoding - UTF-8
-  * Move to UTF-8: 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 +  * For: 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". 
-  * Don't move to UTF-8: 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.) +  * 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.) 
-  * For further consideration: 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+  * 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 though adding a byte-order mark (BOM) to the beginning of each non-HTML UTF-8 text file will go a long way towards recognition; browsers will recognize UTF-8 and can declare the encoding definitively
  
  
 Mobile Devices Mobile Devices
-  * Yes to Mobile Devices: We should take their needs for format flexibility (reflow) in to account +  * For: We should take their needs for format flexibility (reflow) in to account 
-  * No to Mobile Devices: Not enough people use mobile devices, and those that can can generally scroll, so this should be treated as an edge case +  * 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 
- +  * Additional thoughtsinteresting numbers regarding mobile device web browsing[[https://vivipins.com/mobile-marketing-statistics/]]
- +
-ASCII art +
-  * No to ASCIIIt does not allow for reflow  +
-  * Yes to ASCIIDependence on advanced diagrams (or any diagrams) causes accessibility issues +
-  * Further thoughtsIf we go beyond ASCII art, need to pick just one format: GIF? PNG? SVG? +
- +
  
  
Line 41: Line 51:
 Use of RFC-specific tools Use of RFC-specific tools
   * Against: We can't be that unique in our needs that we can't use commercial 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+  * 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 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 +  * For: Dependence on advanced diagrams (or any diagrams) causes accessibility issues; forces people to rely more on words and clear written descriptions than the diagrams; each diagram is [relativelysimple and discrete 
-  * Against: The often poor, limited diagrams are a hindrance to visual thinkers +  * Against: It does not allow for reflow; the limitations to the diagrams are a hindrance to visual thinkers 
-  * Further thoughts: If we go beyond ASCII art and have the normative diagrams be entirely separate documents, we do not need to limit ourselves to one graphic format+  * 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).  Also, if we go beyond ASCII art, wneed to pick just one format: GIF? PNG? SVG? 
 + 
 + 
 +Graphic art / Advanced diagrams 
 +  * For: makes it easy to include complex equations; some people consider graphic art easier to understand/read 
 +  * Against: may take pressure away from authors to focus on clear language 
 +  * Additional thoughts: if an ASCII format continues to be used, graphic art may be used and referenced as a separate document; it can be internal to a document in either the XML or HTML proposed formats
  
  
Line 58: Line 74:
   * For: Ability to semantically tag some document info, at least authors' names and references is useful   * For: Ability to semantically tag some document info, at least authors' names and references is useful
   * Against: Metadata is unnecessary overhead   * Against: Metadata is unnecessary overhead
-  * Further information: 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+  * Additional thoughts: there is no complete 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 (note that a list has been started in the XML format I-D)
  
  
formatsummary.1342712906.txt.gz · Last modified: 2012/07/19 08:48 by rsewikiadmin