User Tools

Site Tools



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

Link to this comparison view

Next revision
Previous revision
design:format-and-content-rfcs [2014/09/29 07:46]
rsewikiadmin created
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 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. 
 +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.1412001972.txt.gz · Last modified: 2014/09/29 07:46 by rsewikiadmin