W3C home > Mailing lists > Public > uri@w3.org > October 2001

Re: draft-masinter-dated-uri-00.txt

From: Mark Baker <distobj@acm.org>
Date: Sun, 21 Oct 2001 23:03:45 -0400 (EDT)
Message-Id: <200110220303.XAA28952@markbaker.ca>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:29 GMT