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

[touch at ISI.EDU (Joe Touch)]

Paul Hoffman wrote:
> 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.

That information is not authoritative at all. The RFC Editor provides
it, but that doesn't make the RFC Editor an "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.

OK, *by your own rules*, the RFC Editor is already indicating the
"Canonical URL". It's clearly and explicitly indicated as such on their
/info page.

We're done now, right?

> 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.

There are no authoritative errata. Period. The RFC Editor provides them
as a courtesy, and has recently tried to verify them and indicate so,
but the concept of such errata has never been established as a required
part of the RFC series.

> 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.

First, the only errata process there is applies to errata added after
2008 (http://www.ietf.org/iesg/statement/errata-processing.html).
Second, this statement also indicates that these apply only to the IESG
stream, which means there is no such process for other RFCs at all, and
there is no distinction made when indicating the errata.

>> 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.

I've already repeatedly indicated that I'm not being optimistic. By your
argument we can't even use "HTTP:", since *that* won't be "true forever".

We can - and should - revisit the definition of "canonical URL" *when* a
new format is permitted. Until that time, alternate formats are a moot
point.

>>>> 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.

When we cite an RFC, we should cite *the RFC*.

When I cite information *about* the RFC, we can use the truncated form.

Only one of these is about the RFC. Metadata may be interesting and
useful, but it is NOT *the RFC*.

...
> 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.

Anyone who wants to find an RFC these days - and in the forseeable
long-term future - will use a search engine. The rest of this discussion
is irrelevant if that's your point.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20100127/b3212011/attachment.sig>