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

Tim Bray tbray at textuality.com
Mon Feb 1 11:05:56 PST 2010

On Mon, Feb 1, 2010 at 10:45 AM, Joe Touch <touch at isi.edu> wrote:
>> 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?

I repeat, this organization's specification for URIs contains no
support for the notion that extensions or suffixes have any semantic
import.  You're trying to make something up that doesn't exist.

> Yes, content-type solves this problem in terms of having one URI syntax.

Good.  We agree that the problem is solved. Why continue this discussion?

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

?!?  We are citing an RFC, which will be delivered in the format that
the IETF says it should be delivered in.  There is no ambiguity
whatsoever in what is being cited.

And another thing: there are some resources for which it's OK and
acceptable to deliver them in multiple formats, for example HTML & PDF
& text.  This is supported via the Accept header.  At this point in
time, this is not the case for RFCs, but it might be in the future.

>  For web pages, allowing the content to change is great and
> powerful. For authoritative references, it defeats the purpose.

Trying to pretend that suffixes are useful or helpful or meaningful
has no support in theory (check the specs) nor in practice (check the
working technology).  An RFC should have an authoritative identifier
that *identifies* it, without extraneous semantically-vacuous static.

More information about the rfc-interest mailing list