[rfc-i] "canonical" URI for RFCs, BCPs
touch at ISI.EDU
Thu Jan 28 09:52:17 PST 2010
Julian Reschke wrote:
> Joe Touch wrote:
>>> 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,
> So the ASCII versions become the authoritative version, even though they
> might not faithfully reproduce the original document?
The ASCII version is specified as the authoritative version, regardless
of how it was derived (XML2RFC, nroff, Word, etc.). That has not changed.
>>> 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.
> Yes. That's what should change.
I think we're in agreement that this might be useful; the RFC Editor has
to agree to this step, though, and put it in place. What's the process
FWIW, that works for single docs (all RFCs), but won't work for STDs or
BCPs, which are sometimes composed of more than one doc, unless it
returns the concatenation of both (though many are likely to not notice
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: OpenPGP digital signature
More information about the rfc-interest