[rfc-i] RFC Format Design Team update and the IETF 88 BoF
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:
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
"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.
More information about the rfc-interest