This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
formatsummary [2012/07/25 15:03] rsewikiadmin |
formatsummary [2019/09/18 13:02] (current) rsewikiadmin [Physical format] updated link |
||
---|---|---|---|
Line 7: | Line 7: | ||
====== Definitions ====== | ====== Definitions ====== | ||
- | Submission format, Input format = Internet-Draft as submitted | + | Source format, aka Submission format, Input format = the format used by authors, etc., when writing an I-D. Currently: XML (can be uploaded |
+ | * 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 | ||
- | 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 | + | 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 | + | 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 format, and if not, what is the appropriate format to reference | + | * For RFC: TXT, .TXT.PDF, Enhanced PDF (rare) |
+ | * Outside RFC Editor: HTML (via rfcmarkup), HTML (via datatracker), | ||
====== 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, | + | * 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, |
- | illustrate the issue is rather helpful, and you can't illustrate a Unicode code point with " | + | |
* 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; | * 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; | ||
Line 40: | Line 43: | ||
* For: 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 | ||
* 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 | * 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 thoughts: interesting numbers regarding mobile device web browsing: | + | * Additional thoughts: interesting numbers regarding mobile device web browsing: |