This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
formatsummary [2012/07/14 13:28] rsewikiadmin created |
formatsummary [2019/09/18 13:02] (current) rsewikiadmin [Physical format] updated link |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | Current proposals: | ||
+ | * [[ftp:// | ||
+ | * [[http:// | ||
+ | * [[ftp:// | ||
+ | |||
+ | 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 ====== | ||
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 | + | * Against: Want a smooth reading experience regardless of page or screen size |
+ | * Additional thoughts: the RFC Editor does not recommend using page numbers as points | ||
- | Character encoding | + | Character encoding |
- | * ASCII encoding: 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 |
- | * UTF-8 encoding: 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 | + | * Against: Too limiting with regards to internationalization issues |
+ | |||
+ | |||
+ | Character encoding - UTF-8 | ||
+ | * 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, | ||
+ | * 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 | ||
- | * 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 |
- | * Not enough people use mobile devices, and those that can can generally scroll, so this should be treated as an edge case | + | * Against: |
+ | * Additional thoughts: interesting numbers regarding mobile device web browsing: [[https:// | ||
- | Use of tools | + | |
- | * We can't be that unique in our needs that we can't use commercial tools | + | ====== Production and publication issues ====== |
- | * We have more control over the tools we write, to make sure it meets all other requirements, and we have xml2rfc to work from as a base | + | |
+ | Use of RFC-specific | ||
+ | * Against: | ||
+ | * 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; | ||
ASCII art | ASCII art | ||
- | * It does not allow for reflow | + | * For: Dependence on advanced diagrams (or any diagrams) causes accessibility issues; |
- | * It forces people to rely more on words and clear written descriptions than the diagrams; each diagram is relatively simple and discrete | + | * Against: It does not allow for reflow; the limitations to the diagrams are a hindrance to visual thinkers |
- | * The often poor, limited | + | * 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). |
+ | |||
+ | |||
+ | 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 | ||
Equations | Equations | ||
- | * Some authors have chosen not to publish RFC due to difficulty in displaying proper mathematical equations | + | * For: Some authors have chosen not to publish RFC due to difficulty in displaying proper mathematical equations |
- | * So few RFC include mathematical equations that this should not be given any priority in the discussion of format | + | * Against: |
Metadata and tagging | Metadata and tagging | ||
- | * Ability to semantically tag some document info, at least authors' | + | * For: Ability to semantically tag some document info, at least authors' |
- | * Metadata is unnecessary overhead | + | * Against: |
+ | * 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) | ||
+ | |||
+ | |||
+ | Containment | ||
+ | * For: Lack of containment for sections means that processing software cannot be fully aware of the document structure, and that is serious restriction | ||
+ | * Against: Containment is unnecessary and not compatible (or perhaps just not required?) with traditional HTML and word processor document | ||
+ | * Against: Requiring containment may limit the number of editors authors can use to create documents | ||
+ | * Against: Requiring containment would require every authoring format to be translatable to the submission format | ||
+ | * Against: Containment should be optional | ||
+ | |||
+ | |||
+ | Source Code format | ||
+ | * For: having a source code format such as XML or HTML allows for greater flexibility in creating a variety of display formats, with a greater likelihood of similarity between them | ||
+ | * Against: having the canonical format be in code ties us in to specific tools and/or tool support going forward | ||
+ | |||
+ |