This is an old revision of the document!
The v3 vocabulary will be used as part of the new RFC series format described in 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 draft-hoffman-xml2rfc for more information
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:
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.
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.
Stuff will go on the web page about each non-canonical representation.