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/09/29 09:28]
paul
@@ 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]].  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.
+See [[https://tools.ietf.org/html/draft-hoffman-xml2rfc|draft-hoffman-xml2rfc]] for more information
+======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
+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.
+// Stuff will go on the web page about each non-canonical
+representation. //
+=====RFCs in HTML=====
+=====RFCs in PDF=====
+=====RFCs in Text=====

RSE Wiki Archive

User Tools

Site Tools

Differences

Page Tools