- From: Mark Baker <distobj@acm.org>
- Date: Sun, 21 Oct 2001 23:03:45 -0400 (EDT)
- To: aswartz@upclink.com (Aaron Swartz)
- Cc: uri@w3.org, lmnet@attglobal.net (Larry Masinter - LMM@acm.org)
> > The IETF explicitly reassigns the numbers in the STD series as > > documents get updated, and doesn't reassign RFC numbers. The > > use of "duri" doesn't change the semantics of the resource, just > > of the reference. It fixes the reference in time. At the beginning > > of 2000, "urn:ietf:std:50" referred to RFC 1643. > > No, it identifies a Resource (STD 50), a conceptual mapping > which corresponds do a different "entity" over time. Why can't it be both? An advantage of the HTTP URI scheme here, is HTTP's notion of identity that has explicity support for this type of resource. Status code 302 (Found) could be used to establish the current meaning of "STD 50". That obviously wouldn't preserve the meaning of "STD 50" at other points in time; that would require separate resources. I envision resource identifiers such as; http://www.ietf.org/std/50 - resolves to current meaning of "STD 50", always a 302 to some RFC http://www.ietf.org/std/50-20000101 - resolves to meaning of "STD 50" at beginning of 2000, always a 301 (Moved Permanently) to RFC 1643, since it's a historical statement that will never change. Note that the latter URI is opaque. It is not intended that clients be able to enter arbitrary date suffixes to find out the meaning of "STD 50" on that date. That relationship would be best communicated by other means. MB
Received on Sunday, 21 October 2001 23:00:17 UTC