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

Joe Touch touch at ISI.EDU
Mon Feb 1 10:47:00 PST 2010



John R. Levine wrote:
>>> Let's say, hypothetically, that the RSE came up with a canonical XHTML
>>> format with fields for pointers to text, PS, errata, prior and
>>> subsequent versions. Other than the fact that it's not what we did in
>>> 1973, why would that be a less satisfactory canonical form than a
>>> pointer to a file in an unknown format?
>>
>> Because one points to a file, and the other points to information about
>> a file.
>>
>> If I cite a file, I point to the file.
>>
>> Or do you cite books as "see card catalog, drawer #32, Yale
>> University,..."?
> 
> Well, if we're following that metaphor, if I'm looking for a book in the
> library, it has a call number like TK5105.875.I57 L66 and I have to use
> a variety of directories to map that in real time to something like
> engineering library, 2nd floor, third aisle, left side, fourth rank of
> shelves, fifth shelf from the top, sixth from the left.  If I come back
> next year, it might well be somewhere else.  There's a reason they leave
> some indirection in the label.

Yes. Because books are physical, and the physical location could move.
By analogy, we give a URL, but not a disk sector.

> I understand that you feel it is deeply wrong to have a level of
> indirection between the canonical URL and the text of the RFC, but I'm
> not hearing any rationale beyond we've always done it that way, yet it
> has clear problems starting with the unknown format of what you get. 
> Can you help me out?

There are multiple versions of many docs. When citing the RFC, it's not
useful for someone to come back and say "well, I saw X on page Y" -
which page Y? The one you printed in 8 point from the HTML, or the one
you printed from the ASCII text (or PS, in some cases) that includes
explicit page numbers?

I appreciate that removing the suffix allows the file format to change.
I consider that exactly the reason why including the suffix is appropriate.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20100201/eea2ed51/attachment.sig>


More information about the rfc-interest mailing list