[rfc-i] "canonical" URI for RFCs, BCPs
touch at ISI.EDU
Wed Jan 27 14:30:28 PST 2010
Julian Reschke wrote:
> Brian E Carpenter wrote:
>> Exactly. Formal citations of RFCs issued in ASCII will always remain
>> as citations of the ASCII version, for ever. If we ever do change to
>> .fubar as the new canonical format, that will not change anything for
>> the .txt RFCs back to RFC 1.
> That's true, but that's not really relevant.
> Let's assume for a moment that we'll move to HTML as standard format by
> April 1, 2010.
Let's continue that discussion when that happens (or at least when
that's on the visible horizon, as part of the process to accept a new
> What is your advice for people generating URIs then?
My advice would be "ask us then". We might decide to unify the URIs to a
single format. We might not.
> For each URI being
> generated, check with the RFC Index about when the RFC was published,
> and generate a different URI format?
> What if we decide to serve HTML versions even for earlier RFCs? Maybe
> based on the TXT version (monospaced font etc...), or even based on the
> XML2RFC source? Do we still serve that with a .TXT extension then? What
> about historic RFCs where the canonical version is *not* the TXT
> version, maybe because they were scanned in?
The scans are provided only until a .txt is available for existing RFCs,
> The media type simply does not *belong* into the URI. Period. And if
> it's not part of the URI it does not matter when we switch, and to what
> format. The URI format will always be the same.
If you would like that to be the case, then the following MUST
*currently* return the ASCII text:
I don't mind if that's the case, if that's what we want to have happen.
But that is NOT what happens right now.
Note that ".txt" is the *filename*. It doesn't need to be the format of
the information therein, FWIW.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: OpenPGP digital signature
More information about the rfc-interest