RSE Wiki Archive

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
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

Page Tools
