[rfc-i] "canonical" URI for RFCs, BCPs
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Tue Feb 2 21:24:57 PST 2010
On 2010/02/02 6:01, John R Levine wrote:
> If a browser says it accepts both but prefers text, the server's going
> to send the stub. See RFC 2616.
Not necessarily. If the browser says it *slightly* prefers text, but the
server knows that Postscript is *way* better, it can/will/should serve
Postscript. It's not a setup that's used often, but it's not impossible
to do that.
> If you refuse to send the stub, we lynx
> users will curse your name unto eternity.
> There are also RFCs like 3312
> where the text is definitive but the postscript is a lot easier to read
> than the ASCII art, and users who want to see what the RFC says will
> curse you if you hide the legible version. I don't see any way to tell
> which one the user wants short of encoding the user preferences into the
I think it could be done easily. Use something like the tools.ietf.org
html version. This looks virtually exactly like the ASCII version (all
pages and lines are strictly preserved), prints more faithfully to the
original intentions on most current-day software than the ASCII version
itself, and uses a little bit of meta information at the top of the
> I still don't understand what the problem is with a canonical container
> which contains all of the info about the RFC including metadata and
> pointers to all the versions with a note to tell you which is
> definitive, but my interest in further argument is limited.
I agree with some others that these days, people are expecting instant
gratification, and a meta page that they have to parse may create
useless confusion, especially for people who have a day job besides
reading RFCs :-).
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
More information about the rfc-interest