[rfc-i] "canonical" URI for RFCs, BCPs
julian.reschke at gmx.de
Thu Jan 28 10:14:48 PST 2010
Joe Touch wrote:
> 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.
I meant the historical case where there was no ASCII version in the
>>>> 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
> for that?
> 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
www.rfc-editor.org already serves BCPs in concatenated form; so this
issue is orthogonal.
Best regards, Julian
More information about the rfc-interest