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

[Julian Reschke]

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 
source code?

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