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

Tim Bray tbray at textuality.com
Mon Feb 1 10:39:37 PST 2010


On Mon, Feb 1, 2010 at 8:47 AM, John R Levine <johnl at taugh.com> wrote:

> Honestly, that strikes me as being the absolute worst of all possible
> worlds.  You have a URL that might return a text file, might return a
> Postcript file, and in the future might return something else.  How is that
> useful to anyone?

Unfortunately, that's the only kind of URI there is.  This is one of
the defining characteristics of the Web, and it's why the Content-type
header is so important.  Whoever owns the server to which the URI is
sent gets to decide what kind of thing comes back.  Anyone who's ever
written a Web crawler learns in the first 15 minutes that what comes
after the dot at the end of a URI is really immaterial.

I can't think of a single reason why having an extension on the end of
a canonical URI is a good idea.  For a vast majority of RFCs, the
authoritative version, per IETF policy, is 80col/66line ASCII.  Thus,
the server should return that version, along with the appropriate
Content-Type, and essentially all known Web client software will Do
The Right Thing, whatever the URI looks like.

I've learned from this discussion are a small number which should be
served in a different Media-type, and the possibility remains open
that at some point in the future the IETF will decide to use a
different format for RFCs.  None of this is in the slightest dependent
on what the suffix of the URI is.  So why waste time and space.

And while we're on the subject of URIs, it might be a good idea to
consult RFC3986, where you'll find no support for the notion that
suffixes or "extensions" have any semantic weight whatsoever.  -Tim


More information about the rfc-interest mailing list