[rfc-i] "canonical" URI for RFCs, BCPs
johnl at taugh.com
Sat Jan 30 14:24:23 PST 2010
>The ASCII version is specified as the authoritative version,
>regardless of how it was derived (XML2RFC, nroff, Word, etc.). That
>has not changed.
Well, except when it's not. Don't forget RFCs 1119, 1124, 1128, 1129,
and 1131. I wouldn't argue that it was a great idea to do Postscript
RFCs, but what's done is done.
>>> If you would like that to be the case, then the following MUST
>>> *currently* return the ASCII text:
This is a metaphysical discussion about the meaning of "the RFC" which
I don't find particularly productive. When I go into the library
stacks to find a book, I have a catalog number which tells me the
location of the book. Often the book is in the place on the shelf
corresponding to the catalog number, sometimes there's a card saying
the book is somewhere else because it's oversized or fragile,
sometimes it turns out that the entire section has been moved to the
annex at the edge of the campus. But I don't get all steamed because
"the book" isn't on the shelf in the exact place I first look for it.
I think we all agree that the canonical URL needs to let people find
"the RFC", but it seems a bit overspecified to me to insist that it be
a direct link to a TXT file. I'd rather give the RSE discretion to
make it something generally useful so long as it provides a quick and
reliable way for people to find whatever info there is about the RFC
which might include errata, pointers to other RFCs that update or
supersede it, and versions in other formats, as well as the text file.
It might be nice to define an XHTML format that is both displayable
and parsable to hold all of the info, but that's definitely something
for the RSE to do.
More information about the rfc-interest