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

[johnl at taugh.com (John R Levine)]

>> Note that type negotiation doesn't do what you want; all of the Postscript
>> RFCs have text stub versions, and if a web browser says it prefers text to
>> postscript, it'll get the text.
>
> Eek, really?  That's a bug in the configuration of the server.  It's
> perfectly reasonable to decree that
> the-one-and-only-representation-of-a-resource-shall-be-thus-and-so and
> I believe that's what the IETF policy is, so the server should bloody
> well ignore the Accept header, except to return 406 Not Acceptable if
> the client says it won't accept text.

If a browser says it accepts both but prefers text, the server's going to 
send the stub.  See RFC 2616.  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 URL:

  .../definitive/rfc9999
  .../legible/rfc9999
  .../legible-unless-it-is-megabytes-of-pdf-scans/rfc123

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.

R's,
John