As per Relevance of the word registration, we have this rfc below:
Network Working Group L.
Request for Comments: 2611 Thinking Cat
BCP: 33 D. van
Category: Best Current Practice ISIS/CEO, JRC
R.
DSTC Pty
P.
Tele2/
June 1999
URN Namespace Definition
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The URN WG has defined a syntax for Uniform Resource Names (URNs
[RFC2141], as well as some proposed mechanisms for their
and use in Internet applications ([RFC2168, RFC2169]). The
rests on the concept of individual "namespaces" within the
structure. Apart from proof-of-concept namespaces, the use
existing identifiers in URNs has been discussed ([RFC2288]), and
document lays out general definitions of and mechanisms
establishing URN "namespaces".
1.0
Uniform Resource Names (URNs) are resource identifiers with
specific requirements for enabling location
identification of a resource, as well as longevity of reference
There are 2 assumptions that are key to this document
Assumption #1:
Assignment of a URN is a managed process
I.e., not all strings that conform to URN syntax are
valid URNs. A URN is assigned according to the rules of
particular namespace (in terms of syntax, semantics, and process).
Daigle, et al. Best Current Practice [Page 1]
RFC 2611 URN Namespace Definition Mechanisms June 1999
Assumption #2:
The space of URN namespaces is managed
I.e., not all syntactically correct URN namespaces (per the
syntax definition) are valid URN namespaces. A URN
must have a recognized definition in order to be valid
The purpose of this document is to outline a mechanism and provide
template for explicit namespace definition, along with the
for associating an identifier (called a "Namespace ID", or NID)
is registered with the Internet Assigned Numbers Authority, IANA
Note that this document restricts itself to the description
processes for the creation of URN namespaces. If "resolution" of
so-created URN identifiers is desired, a separate process
registration in a global NID directory, such as that provided by
NAPTR system [RFC2168], is necessary. See [NAPTR-REG]
information on obtaining registration in the NAPTR global
directory
2.0 What is a URN Namespace
For the purposes of URNs, a "namespace" is a collection of uniquely
assigned identifiers. A URN namespace itself has an identifier
order
- ensure global uniqueness of
- (where desired) provide a cue for the structure of
For example, ISBNs and ISSNs are both collections of identifiers
in the traditional publishing world; while there may be some
(or numbers) that is both a valid ISBN identifier and
identifier, using different designators for the two
ensures that no two URNs will be the same for different resources
The development of an identifier structure, and thereby a
of identifiers, is a process that is inherently dependent on
requirements of the community defining the identifier, how they
be assigned, and the uses to which they will be put. All of
issues are specific to the individual community seeking to define
namespace (e.g., publishing community, association of booksellers
protocol developers, etc); they are beyond the scope of the IETF
work
Daigle, et al. Best Current Practice [Page 2]
RFC 2611 URN Namespace Definition Mechanisms June 1999
This document outlines the processes by which a collection
identifiers satisfying certain constraints (uniqueness of assignment
etc) can become a bona fide URN namespace by obtaining a NID. In
nutshell, a template for the definition of the namespace is
for deposit with IANA, and a NID is assigned. The details of
process and possibilities for NID strings are outlined below; first
a template for the definition is provided
3.0 URN Namespace Definition
Definition of a URN namespace is accomplished by completing
following information template. Apart from providing a mechanism
disclosing structure of the URN namespace, this information
designed to be useful
- entities seeking to have a URN assigned in a namespace (
applicable
- entities seeking to provide URN resolvers for a namespace (
applicable
This is particularly important for communities evaluating
possibility of using a portion of an existing URN namespace
than creating their own
Information in the template is as follows
Namespace ID
Assigned by IANA. In some contexts, a particular one may
requested (see below).
Registration Information
This is information to identify the particular version
registration information
- registration version number: starting with 1, incrementing by 1
with each new
- registration date: date submitted to the IANA, using the
YYYY-MM-
as outlined in [ISO8601].
Declared registrant of the namespace
Required: Name and e-mail address
Recommended: Affiliation, address, etc
Daigle, et al. Best Current Practice [Page 3]
RFC 2611 URN Namespace Definition Mechanisms June 1999
Declaration of syntactic structure
This section should outline any structural features of
in this namespace. At the very least, this description may
used to introduce terminology used in other sections.
structure may also be used for determining
caching/shortcuts approaches; suitable caveats should be provided
If there are any specific character encoding rules (e.g.,
character should always be used for single-quotes), these
be listed here
Answers might include, but are not limited to
- the structure is opaque (no exposition) - a regular
for parsing the identifier into components, including
Relevant ancillary documentation
This section should list any RFCs, standards, or other
documentation that defines or explains all or part of
namespace structure
Answers might include, but are not limited to
- RFCs outlining syntax of the
- Other of the defining community's (e.g., ISO)
outlining syntax of the identifiers in the
- Explanatory material introducing the
Identifier uniqueness considerations
This section should address the requirement that URN identifiers
assigned uniquely -- they are assigned to at most one resource,
are not reassigned
(Note that the definition of "resource" is fairly broad; for example
information on "Today's Weather" might be considered a
resource, although the content is dynamic.)
Possible answers include, but are not limited to
- exposition of the structure of the identifiers, and
of the space of identifiers amongst assignment authorities
are individually responsible for respecting uniqueness
- identifiers are assigned
- information is withheld; the namespace is
Daigle, et al. Best Current Practice [Page 4]
RFC 2611 URN Namespace Definition Mechanisms June 1999
Identifier persistence considerations
Although non-reassignment of URN identifiers ensures that a
will persist in identifying a particular resource even after
"lifetime of the resource", some consideration should be given
the persistence of the usability of the URN. This is
important in the case of URN namespaces providing
resolution
Possible answers include, but are not limited to
- quality of service
Process of identifier assignment
This section should detail the mechanisms and/or authorities
assigning URNs to resources. It should make clear
assignment is completely open, or if limited, how to become
assigner of identifiers, and/or get one assigned by
assignment authorities. Answers could include, but are
limited to
- assignment is completely open, following a particular
- assignment is delegated to authorities recognized by
particular organization (e.g., the Digital Object
Foundation controls the DOI assignment space and its delegation
- assignment is completely closed (e.g., for a
organization
Process for identifier resolution
If a namespace is intended to be accessible for global resolution
it must be registerd in an RDS (Resolution Discovery System,
[RFC2276]) such as NAPTR. Resolution then proceeds according
standard URI resolution processes, and the mechanisms of the RDS
What this section should outline is the requirements for
a recognized resolver of URNs in this namespace (and being so
listed in the RDS registry).
Answers may include, but are not limited to
- the namespace is not listed with an RDS; this is not
- resolution mirroring is completely open, with a mechanism
updating an appropriate
- resolution is controlled by entities to which assignment
been
Daigle, et al. Best Current Practice [Page 5]
RFC 2611 URN Namespace Definition Mechanisms June 1999
Rules for Lexical Equivalence
If there are particular algorithms for determining
between two identifiers in the underlying namespace (hence, in
URN string itself), rules can be provided here
Some examples include
- equivalence between hyphenated and non-hyphenated groupings
the identifier
- equivalence between single-quotes and double-
- Namespace-defined equivalences between specific characters,
as "character X with or without diacritic marks".
Note that these are not normative statements for any kind of
practice for handling equivalences between characters; they
statements limited to reflecting the namespace's own rules
Conformance with URN Syntax
This section should outline any special considerations
for conforming with the URN syntax. This is
applicable in the case of legacy naming systems that are used
the context of URNs
For example, if a namespace is used in contexts other than URNs
it may make use of characters that are reserved in the URN syntax
This section should flag any such characters, and
necessary mappings to conform to URN syntax. Normally, this
be handled by hex encoding the symbol
For example, see the section on SICIs in [RFC2288].
Validation mechanism
Apart from attempting resolution of a URN, a URN namespace
provide mechanism for "validating" a URN -- i.e.,
whether a given string is currently a validly-assigned URN.
example, even if an ISBN URN namespace is created, it is not
that all ISBNs will translate directly into "assigned URNs".
A validation mechanims might be
- a syntax
- an on-line
- an off-line
Daigle, et al. Best Current Practice [Page 6]
RFC 2611 URN Namespace Definition Mechanisms June 1999
Scope
This section should outline the scope of the use of
identifiers in this namespace. Apart from considerations
private vs. public namespaces, this section is critical
evaluating the applicability of a requested NID. For example,
namespace claiming to deal in "social security numbers"
have a global scope and address all social security
structures (unlikely). On the other hand, at a national level,
is reasonable to propose a URN namespace for "this nation's
security numbers".
4.0 URN Namespace Registration, Update, and NID Assignment
Different levels of disclosure are expected/defined for namespaces
According to the level of open-forum discussion surrounding
disclosure, a URN namespace may be assigned or may request
particular identifier. The [RFC2434] document suggests the need
specify update mechanisms for registrations -- who is given
authority to do so, from time to time, and what are the processes
Since URNs are meant to be persistently useful, few (if any)
should be made to the structural interpretation of URN strings (e.g.,
adding or removing rules for lexical equivalence that might
the interpretation of URN IDs already assigned). However, it may
important to introduce clarifications, expand the list of
URN assigners, etc, over the natural course of a namespace'
lifetime. Specific processes are outlined below
There are 3 categories of URN namespaces defined here,
by expected level of service and required procedures
registration. Furthermore, registration maintenance procedures
slightly from one category to another
I. Experimental: These are not explicitly registered with IANA
They take the
X-
No provision is made for avoiding collision of
NIDs; they are intended for use within internal or
experimental contexts
As there is no registration, no registration
procedures are needed
II. Informal: These are registered with IANA and are assigned
number sequence as an identifier, in the format
Daigle, et al. Best Current Practice [Page 7]
RFC 2611 URN Namespace Definition Mechanisms June 1999
"urn-"
where is chosen by the IANA on a First Come
Served basis (see [RFC2434]).
Registrants should send a copy of the registration
(see section 3.0), duly completed, to
urn-nid@apps.ietf.
mailing and allow for a 2 week discussion period
clarifying the expression of the registration information
suggestions for improvements to the namespace proposal
After suggestions for clarification of the
information have been incorporated, the template may
submitted to
iana@iana.
for assignment of a NID
The only restrictions on are that it
strictly of digits and that it not cause the NID to
length limitations outlined in the URN syntax ([RFC2168]).
Registrations may be updated by the original registrant,
an entity designated by the registrant, by updating
registration template, submitting it to the discussion
for a further 2 week discussion period, and
resubmitting it to IANA, as described above
III. Formal: These are processed through an RFC review process
The RFC need not be standards-track. The template defined
section 3.0 may be included as part of an RFC defining
other aspect of the namespace, or it may be put forward as
RFC in its own right. The proposed template should be
to
urn-nid@apps.ietf.
mailing list to allow for a 2 week discussion period
clarifying the expression of the registration information
before the IESG progresses the document to RFC status
A particular NID string is requested, and is assigned by
consensus (as defined in [RFC2434]), with the
constraints that the NID string
Daigle, et al. Best Current Practice [Page 8]
RFC 2611 URN Namespace Definition Mechanisms June 1999
- not be an already-registered
- not start with "x-" (see Type I above
- not start with "urn-" (see Type II above
- not start with "XY-", where XY is any combination of 2
ASCII letters (see NOTE, below
- be more than 2 letters
NOTE: ALL two-letter combinations, and two-
combinations followed by "-" and any sequence of valid
characters, are reserved for potential use as countrycode
based NIDs for eventual national registrations of
namespaces. The definition and scoping of rules
allocation of responsibility for such namespaces is
the scope of this document
Registrations may be updated by updating the RFC
standard IETF RFC update mechanisms. Thus, proposals
updates may be made by the original authors, other
participants, or the IESG. In any case, the proposed
template must be circulated on the urn-nid discussion list
allowing for a 2 week review period
URN namespace registrations will be posted in the anonymous
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN
namespaces/".
5.0
The following example is provided for the purposes of illustration
the URN NID template described in section 3.0. Although it is
on a hypothetical "generic Internet namespace" that has
discussed informally within the URN WG, there are still technical
infrastructural issues that would have to be resolved before such
namespace could be properly and completely described
Namespace ID
To be
Registration Information
Version 1
Date:
Declared registrant of the namespace
Required: Name and e-mail address
Recommended: Affiliation, address, etc
Daigle, et al. Best Current Practice [Page 9]
RFC 2611 URN Namespace Definition Mechanisms June 1999
Declared registrant of the namespace
Name: T.
E-mail: leslie@thinkingcat.
Affiliation: Thinking Cat
Address: 1 ThinkingCat
Trupville,
Declaration of structure
The identifier structure is as follows
URN:<assigned number>::<assigned US-ASCII string
where FQDN is a fully-qualified domain name, and the
string is conformant to URN syntax requirements
Relevant ancillary documentation
Definition of domain names, found in
P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC1035, November 1987.
Identifier uniqueness considerations
Uniqueness is guaranteed as long as the assigned string is
reassigned for a given FQDN, and that the FQDN is
reassigned
N.B.: operationally, there is nothing that prevents a domain
from being reassigned; indeed, it is not an uncommon occurrence
This is one of the reasons that this example makes a poor
namespace in practice, and is therefore not seriously
proposed as it stands
Identifier persistence considerations
Persistence of identifiers is dependent upon suitable
of resolution at the level of "FQDN"s, and persistence of
assignment
Same note as above
Daigle, et al. Best Current Practice [Page 10]
RFC 2611 URN Namespace Definition Mechanisms June 1999
Process of identifier assignment
Assignment of these URNs delegated to individual domain
holders (for FQDNs). The holder of the FQDN registration
required to maintain an entry (or delegate it) in the NAPTR RDS
Within each of these delegated name partitions, the string may
assigned per local requirements
e.g. urn:<assigned number>:thinkingcat.com:001203
Process for identifier resolution
Domain name holders are responsible for operating or
resolution servers for the FQDN in which they have assigned URNs
Rules for Lexical Equivalence
FQDNs are case-insensitive. Thus, the portion of the
urn:<assigned number>::
is case-insenstive for matches. The remainder of the
must be considered case-sensitve
Conformance with URN Syntax
No special considerations
Validation mechanism
None specified
Scope
Global
6.0 Security
This document largely focuses on providing mechanisms for
declaration of public information. Nominally, these
should be of relatively low security profile, however there is
the danger of "spoofing" and providing mis-information.
in these declarations should be taken as advisory
Daigle, et al. Best Current Practice [Page 11]
RFC 2611 URN Namespace Definition Mechanisms June 1999
7.0
[RFC2168] Daniel, R. and M. Mealling, "Resolution of
Resource Identifiers using the Domain Name System",
2168, June 1997.
[RFC2169] Daniel, R., "A Trivial Convention for using HTTP in
Resolution", RFC 2169, June 1997.
[ISO8601] ISO 8601 : 1988 (E), "Data elements and
formats - Information interchange - Representation
dates and times
[RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using
Bibliographic Identifiers as Uniform Resource Names",
2288, February 1998.
[NAPTR-REG] Mealling, M., "Assignment Procedures for NAPTR DNS
Resolution", Work in Progress
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements
Uniform Resource Names", RFC 1737, December 1994.
[RFC2276] Sollins, K., "Architectural Principles of
Resource Name Resolution", RFC 2276, January 1998.
Daigle, et al. Best Current Practice [Page 12]
RFC 2611 URN Namespace Definition Mechanisms June 1999
8.0 Authors'
Leslie L.
Thinking Cat
EMail: leslie@thinkingcat.
Dirk-Willem van
ISIS/STA/CEO - TP 270
Joint Research Centre
21020 Ispra (Va
Italy
Phone: +39 332 78 9549 or 5044
Fax: +39 332 78 9185
EMail: Dirk.vanGulik@jrc.
Renato
DSTC Pty
Gehrmann Labs, The Uni of
AUSTRALIA, 4072
Phone: +61 7 3365 4310
Fax: +61 7 3365 4311
EMail: renato@dstc.edu.
Patrik
Tele2/
Borgarfjordsgatan 16
P.O. Box 62
S-164 94
Phone: +46-5626 4000
Fax: +46-5626 4200
EMail: paf@swip.
Daigle, et al. Best Current Practice [Page 13]
RFC 2611 URN Namespace Definition Mechanisms June 1999
9.0 Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Daigle, et al. Best Current Practice [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
