[rfc-i] "canonical" URI for RFCs, BCPs

paul.hoffman at vpnc.org (Paul Hoffman) Wed, 27 January 2010 21:47 UTC

From: "paul.hoffman at vpnc.org"
Date: Wed, 27 Jan 2010 13:47:30 -0800
Subject: [rfc-i] "canonical" URI for RFCs, BCPs
In-Reply-To: <4B60AF77.2030703@isi.edu>
References: <4B5F50B7.2080104@gmx.de> <D4F73C27-8249-4149-9C6D-10F4F1FC5095@cs.columbia.edu> <4B5F5C2D.1080404@isi.edu> <D4F73C27-8249-4149-9C6D-10F4F1FC5095@cs.columbia.edu> <p0624081fc7850fdd8d43@[10.20.30.158]> <4B5F62E5.80605@isi.edu> <p06240822c785165310bc@[10.20.30.158]> <4B5FA5A7.6070105@isi.edu> <p06240825c7856294385d@[10.20.30.158]> <4B60588C.7030309@isi.edu> <4B605D27.4010609@gmx.de> <4B606B5E.5010602@isi.edu> <4B609FA1.3090306@gmail.com> <p06240835c786533f9f2e@[10.20.30.158]> <4B60AC66.8080506@isi.edu> <p06240839c7865da00ddb@[10.20.30.158]> <4B60AF77.2030703@isi.edu>
Message-ID: <p0624083ac7866130e3a5@[10.20.30.158]>

At 1:26 PM -0800 1/27/10, Joe Touch wrote:
>Please explain what "canonical" means in reference to an RFC if not to
>the canonical text.

The authoritative information about the RFC. In this case, the RFC Editor is the authority.

>Note that neither the meta information nor the
>errata are considered authoritative or required.

We disagree here. If the RFC Editor tells me that location of RFC has moved from ftp://ftp.isi.edu/in-notes/rfc987.txt to http://www.rfc-editor.org/rfcs/rfc987.txt, I consider that authoritative. If I might be so bold, you should too.

Similarly, when the RFC Editor tells me that "here is the list of errata for RFC 987", I consider that authoritative. I know that some RFCs have errata, and I know of no one else who can tell me that authoritatively.

And so on.

>As I noted, if there's
>an error that is so significant that it must be included with the doc,
>such would be justification for revising the RFC.

That's a fine opinion, and one that I share, but it is not one embodied in the current RFC process. The RFC errata *is* part of the RFC process.

>Note also that the meta data explicitly indicates that the .txt *is* the
>canonical information for the RFC, and this is also specified (I don't
>have the RFC number in front of me, but can dig it up if needed).

That is currently true, sure. Your assumption that it will be true forever is optimistic.

> >> Information *about* the RFC is a different matter.
>>
>> For you. For others, the canonical pointer to an RFC should lead to
>> things like an archival pointer to the underlying RFC, metainfo about
>> the RFC, pointers to other formats, and so on.
>
>As above, none of that information is canonical. All of it can change,
>and none of it is anything other than advisory.

I never said it was canonical: I said it was authoritative. The canonical URI would point to the authoritative data.

> >> As Brian said, both are useful, depending on the context. AFAICT, only
>>> one is *canonical*.
>>
>> If you think "both are useful", then why have the canonical one be
>> the one that returns much less information?
>
>Both are useful *depending on the context*. In the context of
>"canonical" reference, only the txt is canonical, so only that URL is
>appropriate.

If you believe that, great: ignore all the other information at the canonical URI. Others of us put more faith in the authority of the RFC Editor.

>Canonical refs aren't intended to provide as much information as
>possible; they are intended to provide only the canonical information.
>That does not include the info sheet, status, or errata.

The RFC Editor's opinion of the location of the RFC is canonical to many of us. YMMV.

It really does sound like you have equated canonical and archival. I am trying to disambiguate them without preventing anyone from finding the archival version of the RFCs.

--Paul Hoffman, Director
--VPN Consortium