This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
formatsummary [2012/07/17 14:20] rsewikiadmin |
formatsummary [2019/09/18 13:02] (current) rsewikiadmin [Physical format] updated link |
||
---|---|---|---|
Line 1: | Line 1: | ||
Current proposals: | Current proposals: | ||
* [[ftp:// | * [[ftp:// | ||
- | * [[http:// | + | * [[http:// |
* [[ftp:// | * [[ftp:// | ||
- | This is a summation of the more polarizing issues related to RFC format. | + | This is a summation of the more polarizing issues related to RFC format. |
+ | |||
+ | ====== 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), | ||
====== Physical format ====== | ====== Physical format ====== | ||
Pagination | Pagination | ||
- | * No pagination: Want a smooth reading experience regardless of page or screen size | + | * For: Ease of reference and clear printing; referring to section numbers is too coarse a method |
- | * Yes pagination: Ease of reference and clear printing | + | * 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: | + | * 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, |
- | * 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.) |
+ | * 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; | ||
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 thoughts: interesting numbers regarding mobile device web browsing: [[https:// | |
- | + | ||
- | ASCII art | + | |
- | * No to ASCII: It does not allow for reflow | + | |
- | * Yes to ASCII: Dependence on advanced diagrams (or any diagrams) causes accessibility issues | + | |
- | * Further thoughts: If 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; |
- | * Against: | + | * Against: |
- | * Further | + | * Additional |
+ | |||
+ | |||
+ | Graphic art / Advanced diagrams | ||
+ | * For: makes it easy to include complex equations; some people consider graphic art easier to understand/ | ||
+ | * 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' | * For: Ability to semantically tag some document info, at least authors' | ||
* 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 |
Line 67: | Line 83: | ||
* Against: Requiring containment would require every authoring format to be translatable to the submission format | * Against: Requiring containment would require every authoring format to be translatable to the submission format | ||
* Against: Containment should be optional | * Against: Containment should be optional | ||
+ | |||
Source Code format | Source Code format | ||
Line 72: | Line 89: | ||
* Against: having the canonical format be in code ties us in to specific tools and/or tool support going forward | * Against: having the canonical format be in code ties us in to specific tools and/or tool support going forward | ||
- | HTML | ||
- | |||
- | |||
- | XML | ||
- | ASCII |