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

Joe Touch touch at ISI.EDU
Mon Feb 1 10:45:25 PST 2010



Tim Bray wrote:
> 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

Except as specific examples in Section 1.1.2?

Yes, content-type solves this problem in terms of having one URI syntax.
However, there's plenty of reason why we ought to include the suffix
names - notably to ensure that when we cite the RFC, we know what we're
citing. For web pages, allowing the content to change is great and
powerful. For authoritative references, it defeats the purpose.

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/20100201/74dacdfa/attachment.sig>


More information about the rfc-interest mailing list