[rfc-i] RFC "source" format

Dave CROCKER dhc2 at dcrocker.net
Thu Oct 9 08:25:22 PDT 2008

Joe Touch wrote:
> source format: the format the author uses to write the doc. this has
> been .nr, .xml, .doc in the past; I'm sure there have been other
> sources, but I'm not aware of authors writing the .txt output directly
> (though that would clearly be possible).
> - -- I'm claiming that *I* don't care what the source format is.
> authoritative archive format: this is .txt (ASCII, with limitations),
> i.e., this is the authoritative version the RFC Editor maintains
> - -- the proposal appears to change only this to include UTF-8 with
> limitations.

Officially, the RFC Editor continues to use only .nr as its format for
generating published documents.  Its toolset permits it to accept submissions in
xml2rfc or txt, but it then converts to .nr.  (.ps is a peculiar exception to
the entire model and probably best ignored for most of these discussions, except
for noting that it exists...)

The fact that the .nr version is not part of the public archive is theoretically
problematic for revision efforts.  However since .nr has such a tiny user base,
at this point, it would not help to change its publication.

Conversion of .xml (xml2rfc) to .nr is claimed to be necessary because of a few
formatting issues that are not (or cannot be) performed by xml2rfc.  I think it
would be quite helpful to resolve this, so that all publication formatting can
be automated and no conversion to .nr is needed, but that is an entirely
separate issue from the current discussion.)

Hence, unfortunately, we have to distinguish between "submission" formats" and
"publication input" format, as well as input vs. output. And the process of
going from submission to publication input is not fully automated and often is
quite labor-intensive.

My interest in having the RFC Editor more formally and thoroughly embrace
xml2rfc is that it permits generation of multiple presentation formats from a
single source.  (Some of us already use it that way and the different formats
really are more useful, each for their intended venue.)  But the key is a single
source format, able to be generated from universally supported and primitive
tools (as well as more specialized ones) where that format can also be usefully
viewed with universally supported and primitive tools.  .xml might not be the
prettiest text format to read, but with reasonable formatting rules, it *is*

It turns out that .xml submissions as Internet-Drafts do make the .xml
automatically available. Although announcements of drafts don't say whether
there is an xml version, simply substituting .xml for .txt will deliver it, if
it is available.

Wouldn't it be helpful for revision efforts of RFCs (or derivative efforts
seeking to incorporate portions and build on them) if this same capability were
available for RFCs?


   Dave Crocker
   Brandenburg InternetWorking

More information about the rfc-interest mailing list