- From: Aaron Swartz <me@aaronsw.com>
- Date: Thu, 2 Aug 2001 22:04:47 -0500
- To: urn-nid@apps.ietf.org
- Cc: uri@w3.org, Sandro Hawke <sandro@w3.org>, Tim Kindberg <timothy@hpl.hp.com>, "Sean B. Palmer" <sean@mysterylights.com>
Request for Comments: xxxx S. B. Palmer
Category: Informational A. Swartz
August 2001
A "pts" URN Namespace
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The need for URNs that identify arbitrary resources, are persistent
and unique across time and network space, and yet remain easy to
create has been evident for quite some time now. This is an attempt
at a concrete registration for such a scheme.
1. Introduction
This document proposes the "pts" namespace, which enables people
that have acquired the right to create these URNs quickly and easily
following certain conditions.
The namespace specification is for a formal namespace.
2. Specification Template
Namespace ID:
"pts" requested
Palmer and Swartz Informational [Page 1]
RFC xxxx A "pts" URN Namespace August 2001
Registration Information:
Registration version number: 1
Registration date: 2001-08-02
Declared registrant of the namespace:
Name: Aaron Swartz
Email address: <mailto:me@aaronsw.com>
Declaration of syntactic structure:
The syntactic definition of these URNs is:-
urn = "urn:" nid ":" authority ":" name
Where:-
nid = "pts"
authority = domain "," date
domain = hostname ; [RFC 2396]
date = year "-" month
year = digitx0 *digit
month = digitx0 | "10" | "11" | "12"
digit = "0" | digitx0
digitx0 = "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
name = *( char [ ":" ] )
char = 1*( unreserved | escaped ) ; [RFC 2396]
Examples of syntactically valid URNs under this scheme include:-
urn:pts:infomesh.net,2001-05:myterm
urn:pts:example.org,2001-05:mything
urn:pts:example.org,2001-05:my%20thing
urn:pts:purl.org,1998-10:101010001010:86%25%80
urn:pts:sub.mydomain.net,2001-05:myns-Myterm
[N.B. all authority components are purely illustrative.]
Relevant ancillary documentation:
All URNs defined herein conform to [RFC 2141].
The <hostname>, <unreserved> and <escaped> tokens are imported
from [RFC 2396].
[RFC 2396] <urn:ietf:rfc:2396>.
[RFC 2141] Moats, R. "URN Syntax", RFC 2141, <urn:ietf:rfc:2141>,
May 1997.
[RFC 2611] <urn:ietf:rfc:2611>.
[RFC 2434] <urn:ietf:rfc:2434>.
Identifier uniqueness considerations:
The delegated authorities must ensure that conforming URNs
following these rules are unique; assigned to at most one
resource, and not reassigned under any circumstances.
Identifier persistence considerations:
URNs have the requirement that they be persistently bound to one
resource.
Process of identifier assignment:
Assignment of URNs using this scheme is completely open,
provided the following algorithm is adhered to.
Assignment is based upon ownership of a domain name for a
particular month. Upon ownership of a certain approved domain
name for a calendar month, the owner of the domain name acquires
the right to create names under the corresponding authority part.
For example, if Fred Bloggs owns the domain example.org for the
entire month of May, in the year 2002, then he acquires the right
to create names under the authority component (<authority>):-
example.org,2002-05
This is a non-transferable right. Persons or entities MUST NOT
create URNs using authority components (<authority>) that they do
not own based upon the rules above.
Practically speaking, one will be using the date of the last
month that one held the domain, and not the current month (which
one is not guaranteed to hold, even if this is a likely
eventuality).
Process for identifier resolution:
It is possible (but not required) that the identifiers may be
resolved by converting the authority and name components
into a request using the HTTP protocol. In such a method, all
commas (,), hyphens (-), and colons (:) are replaced with slashes
(/). The colon (:) separating the authority and the name is also
replaced with a slash.
For example:-
urn:pts:example.org,2002-05:foo:bar
would become:-
http://example.org/2002/05/foo/bar
Obviously such a mechanism of resolution would not be persistent.
Rules for Lexical Equivalence:
Two PTS URNs are equivalent if the strings are
character-for-character equivalent.
Conformance with URN Syntax:
No special considerations. Processors of these URNs must follow
the conventions in [RFC 2141], notably Section 5, "Lexical
Equivalence in URNs".
Validation mechanism:
None specified.
Scope:
Global. These URNs may be referred to by anyone worldwide, for
use in their own applications. We encourage the use of these
URNs.
Palmer and Swartz Informational [Page 2]
Received on Thursday, 2 August 2001 23:05:02 UTC