User Tools

Site Tools


formatreq

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
formatreq [2012/05/30 12:24]
rsewikiadmin
formatreq [2013/05/31 09:25] (current)
rsewikiadmin
Line 1: Line 1:
 +====== RFC 6949 ======
 +Note that the requirements have been gathered and published as [[http://www.rfc-editor.org/rfc/rfc6949.txt|RFC 6949]].
 +
 +----
 +
 The RFC Series has been in existence for over 40 years.  During much of that time, the limitations of character set, line and page length, and graphics restrictions of RFC documents met the most immediate needs of the majority of authors and readers.  As technology changed, new formats that allowed for a richer set of features when editing, reading, searching, and displaying documents came in to use and tools were created to convert the plain ASCII documents in to other desired formats such as HTML, PDF, and Microsoft Word.  While the converted versions of the RFC are widely available, the canonical display format remains the plain text, ASCII, line-printer structured one.  The canonical source format is nroff.   The RFC Series has been in existence for over 40 years.  During much of that time, the limitations of character set, line and page length, and graphics restrictions of RFC documents met the most immediate needs of the majority of authors and readers.  As technology changed, new formats that allowed for a richer set of features when editing, reading, searching, and displaying documents came in to use and tools were created to convert the plain ASCII documents in to other desired formats such as HTML, PDF, and Microsoft Word.  While the converted versions of the RFC are widely available, the canonical display format remains the plain text, ASCII, line-printer structured one.  The canonical source format is nroff.  
  
Line 19: Line 24:
  
  
-So, the community and the RFC Editor have decided to review the canonical format of the RFC series and discuss whether it needs to change and, if change is required, what the change should look like.  This wiki page attempts to capture the requirements of the community regarding format for the RFC, including suggestions that will be fed back to the IETF regarding similar changes to the Internet-Draft format.+So, the community and the RFC Editor have decided to review the canonical format of the RFC series and discuss whether it needs to change  to address those limitations and, if change is required, what the change should look like.  This wiki page attempts to capture the requirements of the community regarding format for the RFC, including suggestions that will be fed back to the IETF regarding similar changes to the Internet-Draft format.
  
  
 ---- ----
 === Fundamental requirement === === Fundamental requirement ===
-  * Any new format MUST continue the persistence and convertibility of the existing format+  * Any new format MUST continue the level of persistence found in the existing format
   * While the canonical source format MUST be easily converted in to a variety of other formats, a single canonical display format must exist to satisfy the requirements of legal and content disputes   * While the canonical source format MUST be easily converted in to a variety of other formats, a single canonical display format must exist to satisfy the requirements of legal and content disputes
  
Line 31: Line 36:
  
 //Note that requiring change to I-D format is outside the purview of the RFC Series Editor.  Information collected that suggests changes to I-D format will be submitted to the IESG.// //Note that requiring change to I-D format is outside the purview of the RFC Series Editor.  Information collected that suggests changes to I-D format will be submitted to the IESG.//
-^ Feature      ^ Consensus       ^ Comments          ^ +^ Feature      ^ Current available      ^ Consensus       ^ Comments          ^ 
-| Need broader character encoding for author names    |  **No**    | [RSE] would note that at least one TLD registrar (AFNIC) is beginning to register domain names with diacritical marks and these will eventually show up in references and author's addresses; a potential compromise is to limit what characters are allowed, such as to the list allowed by DNS domain registrars     | +| Need broader character encoding for author names    |  No   Yes, with limitations  | [RSE] would note that at least one TLD registrar (AFNIC) is beginning to register domain names with diacritical marks and these will eventually show up in references and author's addresses; a potential compromise is to limit what characters are allowed, such as to the list allowed by DNS domain registrars; suggestion that all authors must also provide a transliteration of his/her name with ASCII-only characters      | 
-| Need to be able to update documents easily and see how they might look when published  |  Yes  |      | +| Need to be able to update documents easily and see how they might look when published   Yes   Yes  |      | 
-| Need to be able to include graphics/images    **No**  | [RSE] graphics, whether ASCII or other, have complications when considering resizeability (see small device request)   | +| Need to be able to include non-ASCII graphics/images   |  Not in canonical text version  |  **No**  | [RSE] graphics, whether ASCII or other, have complications when considering resizeability (see small device request); [RSE] may point to a separate document such as PDF with different images/graphics for clarity   | 
-| Need to be able to create new documents by hacking away at older ones |  Yes  |   | +| Need to be able to create new documents by hacking away at older ones |  Yes  |  Yes  |   | 
-| Need be able to diff versions of a draft  |  Yes  |   | +| Need be able to diff versions of a draft   Yes   Yes  |   | 
-| Need format to be easily rendered in to other, potentially undefined formats (.txt, .html, other)  |  Yes  |   +| Need format to be easily rendered in to other, potentially undefined formats (.txt, .html, other)  |  Yes  |  Yes  | While current format can be rendered in other formats such as HTML, PDF, PS, there are arguments that that conversion is not perfect as it cannot take advantage of some of the features in the newer formats  
-| Need to be able to search document and document repositories with tools such as *grep  |  Yes  |   | +| Need to be able to search document and document repositories with tools such as *grep   Yes   Yes  |   | 
-| Want broader character encoding for body of document  |  **No**    +| Want broader character encoding for body of document  |  No  |  Yes, with limitations  |  UTF-8, probably; need to determine what further limitations, if any, will be required  
-| Want the ability to denote protocol examples using the character sets those examples support  |  **No**   |   | +| Want the ability to denote protocol examples using the character sets those examples support  |  No   Yes   | [RSE] similar to the general request for broader character encoding for the body of a document  
-| Want the ability to semantically tag some document info, at least authors' names and references  |  **No**  |  | +| Want the ability to semantically tag some document info, at least authors' names and references   No   **No** [RSE] implication here is that semantically tagging doc info would result in the canonical format of the RFC being source code, to be converted to a variety of display formats  | 
-| Want to be able to include equations |  **No**     +| Want to be able to include equations |  Limited  |  **No**   Does not seem to be sufficient need for this to make it an explicit requirement 
-| Want a more flexible line length  |  Yes  | [RSE] should be rephrased to state want to make the new format display reasonably well on a variety of screen sizes  | +| Want a more flexible line length   No   Yes  | [RSE] should be rephrased to state want to make the new format display reasonably well on a variety of screen sizes  | 
-| Want to be able to tag ownership/source of comments  |  **No**  |  |+| Want to be able to tag ownership/source of comments   No   **No**  |  |
  
  
Line 51: Line 56:
 === RFC-Edit === === RFC-Edit ===
 //additional requirements to the Draft Edit/Review list as provided by the RFC editors// //additional requirements to the Draft Edit/Review list as provided by the RFC editors//
-^ Feature      ^ Consensus       ^ Comments          ^ +^ Feature      ^ Current available      ^ Consensus       ^ Comments          ^ 
-| Need source file to be editable by both authors and RFC editors    |  Yes  | Consensus within RFC Editor    | +| Need source file to be editable by both authors and RFC editors    |  Yes  |  Yes  | Consensus within RFC Editor    | 
-| Want a single, discrete source file for a draft (not multiple files and a make file) |  Yes  |   +| Want a single, discrete source file for a draft (not multiple files and a make file) |  No  |  Yes  | RFC Ed currently accepts XML and nroff and does all the necessary conversions as part of the editorial process 
-| Want a publicly available "official" conversion tool (same source file producing the same output between I-D submission and RFC editing step) |  Yes  |    |+| Want a publicly available "official" conversion tool (same source file producing the same output between I-D submission and RFC editing step) |  Yes (limited)  |  Yes  |    |
  
  
Line 60: Line 65:
 === RFC-Archive === === RFC-Archive ===
 //what the RFC Editor worries about when publishing an RFC// //what the RFC Editor worries about when publishing an RFC//
-^ Feature      ^ Consensus       ^ Comments          ^ +^ Feature      ^ Current available      ^ Consensus       ^ Comments          ^ 
-| Need source format to be easily rendered in to other, potentially undefined formats (.txt, .html, other)    |  Yes  |        | +| Need source format to be easily rendered in to other, potentially undefined formats (.txt, .html, other)    |  ?  |  Yes  |        | 
-| Need one source and display format to be the authoritative version, suitable for legal records  | Yes  |   | +| Need one source and display format to be the authoritative version, suitable for legal records  Yes  |  Yes  |   | 
-| Need to be able to create new documents by hacking away at older ones  |  Yes  |   | +| Need to be able to create new documents by hacking away at older ones   Yes   Yes  |   | 
-| Need backward compatibility to recreate documents originally created in an older version of the output tools (backward compatibility issue doesn't apply to docs published prior to the format change)  |  Yes  |   | +| Need backward compatibility to recreate documents originally created in an older version of the output tools (backward compatibility issue doesn't apply to docs published prior to the format change)   n/a   Yes  |   | 
-| Need a long-lived file format with an open specification, i.e., such that the community can continue to support it even if commercial support disappears  |  Yes  |    |+| Need a long-lived file format with an open specification, i.e., such that the community can continue to support it even if commercial support disappears   Yes   Yes  |    |
  
  
Line 71: Line 76:
 === End consumption === === End consumption ===
 ^ Feature      ^ Consensus       ^ Comments          ^ ^ Feature      ^ Consensus       ^ Comments          ^
-| Need to be able to see non-ASCII graphics/images    |  **No**       +| Need to be able to see non-ASCII graphics/images    |  No  |  **No** [RSE] may point to a separate document such as PDF with different images/graphics for clarity      
-| Need to be able to search document and document repositories with tools such as *grep  |  Yes  |     | +| Need to be able to search document and document repositories with tools such as *grep   Yes   Yes  |     | 
-| Need to be able to create new documents by hacking away at older ones  |  Yes  |   | +| Need to be able to create new documents by hacking away at older ones   Yes   Yes  |   | 
-| Want intelligent html-style linking within references  |  **No**  |   | +| Want intelligent html-style linking within references   No   **No**  |   | 
-| Want the RFC to be suitable for small screens/mobile devices  |  **No**      | +| Want the RFC to be suitable for small screens/mobile devices  |  No   Yes      | 
-| Want to have neat printing (intelligent pagination)  |  Yes  |  But there is disagreement as to what that would actually look like  | +| Want to have neat printing (intelligent pagination)  |  Yes (but limited to a narrowly defined page format)  |  Yes  |  But there is disagreement as to what that would actually look like  | 
-| Want to be able to view equations  |  **No**  |    | +| Want to be able to view equations   Yes (limited to simple equations or contorted writing)   **No**  |    | 
-| Want a more flexible line length  |  **No**    +| Want a more flexible line length   No   **No** [RSE] should be rephrased to state want to make the new format display reasonably well on a variety of screen sizes   
-| Want a single document to view (should not have to jump between two documents for complete information)  |  **No**     |+| Want a single document to view (should not have to jump between two documents for complete information)  |  Yes (usually)  |  **No**  [RSE] currently an RFC may include pointers to a separate document such as PDF with different images/graphics for clarity    |
  
  
formatreq.1338405888.txt.gz · Last modified: 2012/05/30 12:24 by rsewikiadmin