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

Julian Reschke julian.reschke at gmx.de
Thu Jan 28 00:22:41 PST 2010


Joe Touch wrote:
> ...
>> 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
> format).

Well, I'd like to have this changed as soon as possible. It's simply a 
bad design style to expose a format name in a URL.

In case you haven't seen that: <http://www.w3.org/Provider/Style/URI>.

> ...
>> 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,
> FWIW.
> ...

So the ASCII versions become the authoritative version, even though they 
might not faithfully reproduce the original document?

>> 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:
> 
> 	http://www.rfc-editor.org/rfc/rfc793
> 
> 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.

> Note that ".txt" is the *filename*. It doesn't need to be the format of
> the information therein, FWIW.

That's true. As such ".txt" simply is irrelevant information, and thous 
shouldn't have been in the URL in the first place.

Best regards, Julian


More information about the rfc-interest mailing list