Differences

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

--- 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 [[http://www.rfc-editor.org/info/rfc6949|RFC 6949]].
+See [[https://tools.ietf.org/html/draft-hoffman-xml2rfc|draft-hoffman-xml2rfc]] for more information
+about the v3 vocabulary.
+RFCs
+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
+[[https://tools.ietf.org/html/draft-flanagan-rfc-framework|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 [[http://www.rfc-editor.org/info/rfc6949|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=====
+[[https://tools.ietf.org/html/draft-hildebrand-html-rfc|draft-hildebrand-html-rfc]]
+describes the HTML representation of RFCs.
+=====RFCs in PDF=====
+[[https://tools.ietf.org/html/draft-hansen-rfc-use-of-pdf|draft-hansen-rfc-use-of-pdf]]
+describes the PDF representation of RFCs.
+=====RFCs in Text=====
+[[https://tools.ietf.org/html/draft-flanagan-plaintext|draft-flanagan-plaintext]]
+describes the plain text representation of RFCs.

RSE Wiki Archive

User Tools

Site Tools

Differences

Page Tools