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
Last revision Both sides next revision
formatsummary [2012/07/25 14:52]
rsewikiadmin
formatsummary [2012/07/28 08:33]
rsewikiadmin
Line 7: Line 7:
  
 ====== Definitions ====== ====== Definitions ======
-Submission format, Input format = Internet-Draft as submitted ​to the RFC Editor; ​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); ​if necessary, ​will be converted to another format for further processing and publication+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 documentother document types may be derived from this format; may or may not be one of the possible output formats+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 of the RFC+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 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. 
-Reference format = the version of the RFC commonly used as a normative or informative reference; currently the ASCII format; need to determine if this format can/will be the equivalent to the Canonical formatand if notwhat is the appropriate format to reference +  * For RFC: TXT.TXT.PDFEnhanced PDF (rare) 
 +  * Outside RFC Editor: HTML (via rfcmarkup), HTML (via datatracker),​ PDF, perhaps others.
  
 ====== Physical format ====== ====== Physical format ======
Line 31: Line 35:
  
 Character encoding - UTF-8 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 +  * 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"​.
-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.)   * 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 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   * 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
formatsummary.txt · Last modified: 2019/09/18 13:02 by rsewikiadmin