formatsummary
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
formatsummary [2012/07/15 16:59] rsewikiadmin |
formatsummary [2019/09/18 13:02] (current) rsewikiadmin [Physical format] updated link |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | draft-hoffman-rfcformat-canon-others-03 | + | 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 |
| - | * Dependence on advanced | + | |
| - | * If we go beyond ASCII art, need to pick just one format: GIF? PNG? SVG? | + | |
| - | * If we go beyond ASCII art and have the normative diagrams be entirely separate documents, we do not need to limit ourselves | + | Graphic art / Advanced diagrams |
| - | * | + | * For: makes it easy to include complex equations; some people consider graphic |
| + | * Against: may take pressure away from authors | ||
| + | * 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) | |
| - | HTML | + | |
| Containment | Containment | ||
| - | * Containment | + | * For: Lack of containment for sections means that processing software cannot be fully aware of the document structure, and that is serious restriction |
| - | * Containment is unnecessary and not compatible (or perhaps just not required?) with traditional HTML and word processor document | + | * Against: |
| - | * Lack of containment for sections means that processing software cannot be fully aware of the document structure, and that is serious restriction. | + | * 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 |
| - | Tags | + | Source Code format |
| - | * there is no list of tags that will be required for XML or HTML, thus building in required simplification and support | + | * For: having a source code format such as XML or HTML allows |
| - | * | + | * Against: having the canonical format be in code ties us in to specific tools and/or tool support going forward |
| - | XML | ||
| - | ASCII | ||
| - | Containment | ||
| - | * Containment is good | ||
| - | * Containment is unnecessary and not compatible (or perhaps just not required?) with traditional HTML and word processor document structure | ||
formatsummary.1342396745.txt.gz · Last modified: 2012/07/15 16:59 by rsewikiadmin
Page Tools
