[rfc-i] RFC Format Design Team update and the IETF 88 BoF

Dave Crocker dhc at dcrocker.net
Thu Nov 7 10:04:48 PST 2013

On 10/30/2013 1:43 PM, Heather Flanagan (RFC Series Editor) wrote:
> https://www.rfc-editor.org/rse/wiki/doku.php?id=design:start

Heather, and design team:

Nice work!  My primary reaction is that the proposal is extensive and 

Some detailed concerns, and one major concern:

 > Anchor stability

> The sections in the non-canonical HTML document need to be able to be
> addressed by a fragment identifier. The same identifiers need to
> appear in the same places in the XML. These fragment identifiers
> should follow a predictable format so that someone referencing a
> section in an RFC can create the fragment without needing to read the
> XML or HTML if they know the identifier format chosen.

    Not sure what this text means; I found the text in the requirements 
sometimes difficult to parse.


         XML permits use of tags to segments of text.  These tags can be 
used as cross-reference anchors.  HTML has a similar feature.

         A tag used in the canonical XML version of the text 
[should/must] also be used in the non-canonical HTML version of the 
document, including tags created by document authors.

         There should be format for these tags that is specific to use 
in RFCs, so that authors can create them without having to be familiar 
with the details of XML or HTML.

 > Requirements for Text Output

The text version of an RFC is especially helpful for email discussion. 
It permits easily incorporating portions of text for annotated comment. 
  For example, I do draft reviews by quoting all of the text document, 
cutting out the parts irrelevant to the review and typing my comments 
inline. While this is for I-Ds rather than RFCs, I believe the benefit 
applies to RFCs as well.

> The following assumes that the text-only non-canonical format
> intended consumer is people who like the current format but want to
> be able to get all the semantic content out of the new canonical
> format, and that  the HTML format will be done in a way where
 > copy-and-paste of text will be easy and predictable.

Even after a cup of coffee, I really couldn't parse this.  What does it 

> represent all SVG-based artwork as a “see reference” that goes to a
 > stable URL, hosted on the RFC Editor's web site,


 > After the RFC Editor has made the cut-over
 > This will allow tool makers to have a clear demarcation

Should we target 1 April 2014?

 > Requirements for HTML Output

 > One use case is that preformatted text that has different tags in the 
 > XML

"different tags"?  What does that mean?  Different from what?

 > Requirements for EPUB Output

While the brevity of this requirements set is refreshing it lacks any of 
the RFC-specific details that the HTML had, which implies that some of 
the functional benefits that epub could supply -- eg, those similar to 
the ones cited for HTML -- won't be present.

Privately I've been told that the intent is to have the epub version 
include comparable 'functionality' as the html version.  This should be 
stated explicitly.  I view epub as the long-term 'pretty' version, given 
the popularity of digital book technology.

 > Requirements for PDF Output
 > The PDF output will include the exact text of the RFC TXT format, 
with diagrams added.

Same comment as for the EPUB requirements, except that I'm less 
concerned about PDF support.  I think it's a legacy requirement, rather 
than a long-term one.

Again, thanks to you all.


Dave Crocker
Brandenburg InternetWorking

Dave Crocker
Brandenburg InternetWorking

More information about the rfc-interest mailing list