This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
design:format-and-content-rfcs [2014/09/29 07:56] paul |
design:format-and-content-rfcs [2014/10/25 14:58] (current) paul Cleaned this up a bit |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | For Paul to drop xml2rfc | + | The v3 vocabulary will be used as part of the new RFC series format described in [[http:// |
+ | See [[https:// | ||
+ | about the v3 vocabulary. | ||
- | Proof I can do it. | + | |
+ | RFCs | ||
+ | will have multiple representations: | ||
+ | many non- canonical representations (such as HTML and text) will be generated as well. | ||
+ | The discussion of the design and content of RFCs is part of the overall discussion of | ||
+ | [[https:// | ||
+ | |||
+ | ======Canonical RFCs====== | ||
+ | |||
+ | The canonical RFCs will not have any markup that uses a feature that is deprecated in the v3 | ||
+ | vocabulary. The RFC processor will have a " | ||
+ | document to a v3 XML document and converts deprecated features wherever possible, issuing warnings | ||
+ | for where it cannot convert. | ||
+ | any deprecated features are in the input. | ||
+ | |||
+ | The canonical format for RFCs have a number of restrictions that the RFC Processor needs to enforce | ||
+ | before a document can be published in its final form. In this " | ||
+ | a hard error when an input XML file has: | ||
+ | |||
+ | * any element or attribute listed as " | ||
+ | |||
+ | * XML comments | ||
+ | |||
+ | * XML Processor Instructions | ||
+ | |||
+ | * an external DTD | ||
+ | |||
+ | * ENTITYs that have a SYSTEM component | ||
+ | |||
+ | * < | ||
+ | |||
+ | * < | ||
+ | |||
+ | * any TAB characters | ||
+ | |||
+ | The RFC Processor will have a mode that gives hard errors on all of the above other than < | ||
+ | elements. | ||
+ | to authors in AUTH 48, notes to IANA, and so on. | ||
+ | |||
+ | The RFC Processor will also generate values for the " | ||
+ | " | ||
+ | elements that can have it. These will be filled in by the RFC processor so that the canonical XML | ||
+ | file has all of the same information as the non-canonical representations. | ||
+ | |||
+ | ======Non-canonical RFC Representations====== | ||
+ | |||
+ | As described in [[http:// | ||
+ | non-canonical representations will be derived from the canonical XML. The generation of these | ||
+ | non-canonical representations means that there will be much more emphasis put on the RFC Processor. | ||
+ | |||
+ | The following sections list the current Internet Drafts on the non-canonical formats. At this time (October 2014), these drafts are still in active development, | ||
+ | |||
+ | =====RFCs in HTML===== | ||
+ | |||
+ | [[https:// | ||
+ | describes the HTML representation of RFCs. | ||
+ | |||
+ | =====RFCs in PDF===== | ||
+ | |||
+ | [[https:// | ||
+ | describes the PDF representation of RFCs. | ||
+ | |||
+ | =====RFCs in Text===== | ||
+ | |||
+ | [[https:// | ||
+ | describes the plain text representation of RFCs. |