User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
design:format-and-content-rfcs [2014/09/29 07:56]
design:format-and-content-rfcs [2014/10/25 14:58]
paul Cleaned this up a bit
Line 1: Line 1:
-For Paul to drop xml2rfc v3 info.+The v3 vocabulary will be used as part of the new RFC series format described in [[|RFC 6949]]. 
 +See [[|draft-hoffman-xml2rfc]] for more information 
 +about the v3 vocabulary.
-Proof I can do it.+ 
 +will have multiple representations: the canonical document will be in XML using the v3 format, and 
 +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 
 +[[|the RFC framework]]. 
 +======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 "convert with warnings" mode that will convert a v2 XML 
 +document to a v3 XML document and converts deprecated features wherever possible, issuing warnings 
 +for where it cannot convert.  The processor will also have a "strict" mode that will issue errors if 
 +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 "final" mode, the processor will give 
 +a hard error when an input XML file has: 
 +  * any element or attribute listed as "deprecated" in the v3 vocabulary 
 +  * XML comments 
 +  * XML Processor Instructions 
 +  * an external DTD 
 +  * ENTITYs that have a SYSTEM component 
 +  * <artwork> elements with a "src" attribute that points to a URI with a scheme other than "data:" 
 +  * <cref> elements 
 +  * any TAB characters 
 +The RFC Processor will have a mode that gives hard errors on all of the above other than <cref> 
 +elements.  This exception is to allow the RPC to insert <cref> elements in the working XML for notes 
 +to authors in AUTH 48, notes to IANA, and so on. 
 +The RFC Processor will also generate values for the "boilerplateText" attribute in <rfc>, and 
 +"sectionNumber" in <section>, "figureNumber" in <figure>, and "partNumber" attributes in the many 
 +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 [[|RFC 6949]], the RFC Editor will publish non-canonical representations of RFCs.  Those 
 +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, with significant changes still being made. 
 +=====RFCs in HTML===== 
 +describes the HTML representation of RFCs. 
 +=====RFCs in PDF===== 
 +describes the PDF representation of RFCs. 
 +=====RFCs in Text===== 
 +describes the plain text representation of RFCs.
design/format-and-content-rfcs.txt · Last modified: 2014/10/25 14:58 by paul