[rfc-i] DOIs and RFCs

Nico Williams nico at cryptonector.com
Thu Feb 13 09:40:28 PST 2014

On Thu, Feb 13, 2014 at 11:15 AM, Dave Crocker <dhc at dcrocker.net> wrote:
> On 2/13/2014 6:32 AM, John Levine wrote:
>>> I believe whatever the future "canonical" URI of a RFC is, it
>>> should be what people most likely want to see - an HTML version,
>>> potentially augmented with up-to-date status information.

When no other preference can be derived anyways (e.g., if there's no
Accept: header in an HTTP request for an RFC).

<manner type="facetious" modifier="semi">Maybe we need an API for RFC

>> What I want to see depends on the device I'm using. It might be
>> HTML, it might be PDF, it might be ePub. A nice page that lets me
>> pick one is just the ticket.

Maybe.  When using a tablet I just want it to display nicely.  Web
browsers still don't make the distinction between PDF and HTML and
ePub seamless -- they behave differently w.r.t. resizing screens, link
following behavior, and so on.  It's obnoxious.  I'm not sure that I
care about PDF vs. HTML vs ePub for any good and _lasting_ reason on
any one type of device.

> Why should a citation be restricted from specifying the form of the
> document?  Why should human interaction be required before retrieval is
> possible?

The IETF URN namespace for RFCs and so on does not make reference to
document format.  Nobody really uses these URNs, so maybe who cares.
But whether by accident or design, we already have a way of referring
to an RFC without referring to output format.

We've spent a lot of time arguing about canonical output formats in
the past, and really, I'm not sure why.  All supported output formats
for which output was reviewed and approved by the RFC-Editor and the
authors should be canonical.


More information about the rfc-interest mailing list