[rfc-i] DOIs and RFCs

Nico Williams nico at cryptonector.com
Tue Feb 11 15:01:59 PST 2014


Can the assignment of DOI be an algorithmic transformation of the
RFC's normal "name" (RFCXXXX) and any aliases (STD...)?

John's I-D doesn't say it, but going by the example given, it looks that way.

Assuming "yes" then I wonder why DOIs would have to be embedded in XML
inputs to xml2rfc.  I'd expect instead that xml2rfc would be able to
extract the metadata required for formatting a document's would-be
DOI.  But if the final XML source is expected to be a published
document itself, then yes, it should have the DOI embedded -- perhaps
as a result of a run of xml2rfc to produce final XML outputs, rather
than as a manual process.

(Also assuming "yes" I'm not sure what tools would be needed to
produce DOIs for existing RFCs other than... a Unix command-line shell
and human being with the appropriate skills.  It really can't be much
work -- it'd have to be done, but it seems unlikely that much effort
would need to be expended on building tools to get it done.)

Also, I assume that I-Ds should not get DOIs assigned if for no other
reason than that it costs money to assign them but submission is open
to non-paying members of the public.

That musing about I-Ds brings me to: who is to be the publisher in the
DOI sense?

RFC6635 says that the RFC-Publisher is a contractor... Clearly it
wouldn't be right then to say that a contractor is the publisher in
the DOI sense: the contractor can change over time.

Surely the IETF can't be the publisher either unless the IRTF and IAB
are also publishers in the same sense -- but they share a document
stream namespace, which might be a problem.  The IAB could be the
publisher, and so could the RSE or its employer, the IAOC.

Who pays?  Are there cost estimates?  $1 per-RFC for all past RFCs can
get expensive for a volunteer organization.

How stable are the DOI registration agencies?  I assume this won't be
an issue, but it seems worth asking.

Nico
--


More information about the rfc-interest mailing list