[rfc-i] "canonical" URI for RFCs, BCPs
julian.reschke at gmx.de
Tue Feb 2 00:33:13 PST 2010
Alfred � wrote:
> OTOH, as John Levine has pointed out, giving the file extension
> in an URL is deemed useful for many purposes. If not, why would
> the file extension(s) have been a part of media type registrations
> since these have ever begun?
So that it can be derived when the file is stored in a system that
doesn't keep full media type.
> The most important benefit (if managed properly) of a file extension
> in the URL is the unambiguous indication of what to expect.
Well, when you see "cgi" or "asp", do you expect shell scripts or ASP
> Thus, summing up:
> I concluse that Julian looks for a "generic URI", that could be
> generated easily algorithmically and/or can be guessed easily.
> To avoid confusion, I recommend not to use the adjective "canonical"
> (i.e. "in unique, authoritative form") in this context. I agree
> that these generic URIs for RFCs (etc.) should not carry a file
> extension, in order to emphasize the generic nature of the resource
> (document metadata) to which such URI is expected to resolve.
No, no, no. That's not what *I* wasa asking for (mainly because we
already have that with "/info").
I'm asking for a predictable format that will return *the* RFC, and this
both for existing and future RFCs, independently of potential future
format changes. That URI format should not include a file extension,
because it's both misleading, and a waste of bytes.
I have no problem with the URIs ending in ".txt" working *as well*.
Best regards, Julian
More information about the rfc-interest