**Comments:** This draft document will be retired on completion of a
recommendation by the U.S. Federal Interagency Committee on Government
Information (ICGI), in December 2004. Until December 5, 2004, comments
on this document may be sent to the editor, James Erwin,
Defense Technical Information Center (e-mail: <jerwin@dtic.mil>).

1.  **Background**

This recommendation addresses the requirement under law that the U.S.
Federal Government adopts an open standard of "searchable identifiers"
for government information, pursuant to the E‑Government Act of 2002,
Section 207 (\"Accessibility, Usability, And Preservation of Government
Information\"). The Act specifies that the Interagency Committee on
Government Information (ICGI) shall submit to the Director, Office
of Management and Budget, recommendations on \"the adoption of
standards, which are open to the maximum extent feasible, to enable the
organization and categorization of Government information in a way that
is searchable electronically, including by searchable identifiers; and
in ways that are interoperable across agencies\".

This particular recommendation aligns with, though is not dependent
upon, other ICGI recommendations required under the E‑Government Act,
Subsection 207(d)(1). The ICGI will recommend an overall definition of
Government information, and this recommended searchable identifier would
apply to each item encompassed within that definition. The ICGI will
recommend a standard set of categories for all government information,
and this recommended searchable identifier will be among the standard
categories. The ICGI also will recommend a standard for search
interoperability, and this recommended searchable identifier will be
searchable by that standard.

One of the early and persistent criticisms of the Internet is the
impermanence of content. Digital objects appear one day only to
disappear the next. Although it is technically possible to maintain
digital content persistence through scrupulous Uniform Resource Locator
(URL) maintenance, in practice, \"Error 404s\" are all too commonplace.

Therefore, researchers proposed the assignment of \"names\" to digital
objects that could subsequently be resolved to actual physical
locations. Under this approach the digital object\'s name would remain
constant while the associated physical location(s) could change. The
Internet community adopted the term, \"Uniform Resource Name\" to
describe this approach.

In October 1995, Keith Moore hosted a meeting at the University of
Tennessee for research groups interested in URNs. One of the key
concepts that emerged from the meeting was that for URNs \"...the
resolution system must be separate from the way names are assigned\"
\[1\]. This concept was dubbed the \"Knoxville Framework\" by the
attendees. The Knoxville Framework provides a mechanism for
incorporating existing naming and resolution schemes into a URN
framework and also encourages the development of new approaches to take
advantage of changing requirements and technologies.

In the meantime, the URN functionality requirements and syntax were
refined by the Internet Engineering Task Force (IETF) in a number of
Requests for Comments (RFCs). In addition, several RFCs proposed
approaches for resolver \"discovery\", e.g. Resolution Discovery System
(RDS).

Although the URN and Knoxville Framework approaches are conceptually
attractive and support the long-term incorporation of multiple naming
and resolution approaches, actual deployment has lagged. Currently,
browsers do not support URN resolution. Therefore, several non-URN
searchable identifier schemes have emerged including the Persistent URL
(PURL) developed by the Online Computer Library Center (OCLC), the
Handle System developed by the Corporation for National Research
Initiatives (CNRI), the Digital Object Identifier (DOI) based on the
Handle System and popularized within the commercial publishing industry
by the International DOI Foundation (IDF), and the Archival Resource Key
(ARK) scheme developed by John Kunze and implemented at the University
of California and prototyped at the U.S. National Library of Medicine.
Although proponents point out that their schemes could be made
compatible with the URN framework, all, taking a pragmatic approach, are
based on http.

The public cannot effectively use ephemeral and un-authoritative
government information. Consequently, Congress emphasized the important
role of searchable identifiers in the E‑Government Act of 2002. For the
purpose of these recommendations, the functional intent of searchable
identifiers, persistent identifiers, and URNs are conceptually very
similar.

**2. Recommendations**

The U.S. Federal Government should adopt a searchable identifier
standard to provide long-term persistent access to digital government
information through a global naming and resolution framework. The
searchable identification standard should not only be flexible enough to
remain viable as technology changes, but also be specific enough to
provide real, near term functionality and authoritative access to
government information.

**Recommendation 1:** The overall searchable identifier standard should
be based on URNs as described in RFC 1737 \[4\] and RFC 2141 \[5\]. In
addition, the standard should attempt to achieve the goals of the
Knoxville Framework, i.e. separation of naming and resolution to
encourage the introduction of multiple, competing, and innovative
approaches.

Ultimately, the searchable identifier framework must be flexible enough
to easily incorporate new naming approaches and changes in technology.
The URN syntax can support the definition of multiple, competing naming
schemes or namespaces, e.g. Organization for Advancement of Structured
Information (OASIS), International Standard Book Numbers (ISBN), and
National Bibliography Numbers (NBN). The URN can also support existing
and future naming schemes by providing a syntax that facilitates the
generation of globally unique identifiers.

**Recommendation 2:** A URN Resolution Discovery System (RDS) should be
developed and implemented.

Although URNs provide a flexible syntax for generating globally unique
identifiers, URNs are not resolvable through standard browsers.
Consequently, while URNs are attractive from a flexibility point of
view, they have limited practical utility. Several proposals have been
specified over the years to utilize the Domain Name Service (DNS) to
support URN resolver discovery. RFC 2168 \[10\] suggested use of the
Naming Authority Pointer DNS Resource Record (NAPTR). Most recently,
RFCs 3401-3404 \[6-9\] suggested a Dynamic Delegation Discovery System
(DDDS). To date, an operational, scaleable RDS has not been developed.
However, an operational RDS is technically feasible and essential for
the effective support of multiple URN resolution methods.

Initial informal industry feedback indicates that the development of an
RDS and its integration into popular browser software is very doable.
However, it is only doable, if the U.S. Federal Government sends a clear
signal to industry that such development and integration is essential to
the government\'s information management and dissemination needs.

**Recommendation 3:** Naming and resolution schemes should support
standard, intuitive access to digital object metadata.

Searchable identification coupled with metadata supports the effective
use, reuse and value-adding of digital content. The metadata should
include both descriptive and policy metadata. Minimally, policy metadata
should describe what users can expect in terms of a digital object\'s
permanence. However, the policy metadata should also provide information
about digital object differentiation, i.e. alert the user to the
existence of other versions or disseminations of the same logical
object. In addition, the policy metadata should contain information on
digital object modification through parameterization as described by
Kunze \[3\]. Since the appropriate metadata is often genre specific, URN
registration should specify metadata appropriate for a particular URN
scheme.

**Recommendation 4:** Although the URN framework and the implementation
of an RDS are recommended to facilitate long-term support of multiple
identification schemes and changing technology, the U.S. Federal
Government should immediately adopt the Handle System.

The Handle System, as described in RFC 3651 \[2\], is the most fully
functional and widely deployed Internet searchable identifier naming and
resolution system. In addition, since it was developed under a grant
from the Defense Advanced Research Agency (DARPA), it is available free
to government organizations. Finally, since it was implemented using
open source software, it is relatively inexpensive to deploy and can be
enhanced to meet future requirements.

However, adoption of the Handle System should include the integration of
the Handles into the URN framework, standard, intuitive access to
digital object metadata, and the modification of the Handle System to
support fully distributed name space allocation. Currently, Handles name
space assignment is centrally controlled. A fully centralized name space
assignment approach will not scale for a government-wide implementation.
In addition, funding and operational support of a Global Handle Registry
(GHR) will be required to achieve maximum functionality. A GHR provides
the critical capability to resolve a Handle or DOI from any Handle
resolver.

Initial, informal industry feedback indicates that the tighter
integration of Handle resolution support into popular browser software
is, like the integration of an RDS, very doable with a clear indication
of U.S. Federal Government interest. Consequently, support of both an
RDS and the integration of Handle resolution support into browser
software would provide a general naming and resolution framework for
which the Handle System would be an operational reference
implementation.

**Recommendation 5:** The U.S. Federal Government should designate
organizations to manage the allocation of Handle namespaces and to
operate a GHR.

Since the Defense Information Systems Agency (DISA) and the General
Services Administrations (GSA) currently manage the allocation of the
.mil and .gov Internet domains, they would be logical choices to perform
the allocation of high level Handle namespaces and to oversee the
operation of a GHR.

3.  **Implications**

**Policy:** Policy may be required to specify the type and granularity
of the digital objects requiring searchable identifiers and associated
metadata. Policy may also be required to specify the existence of a
minimal set of policy metadata. In addition, policy will be required for
the specification of Handle namespaces. Finally, policy may be required
to specify levels of performance and information assurance.

**Oversight:** The Office of Management and Budget (OMB) should review,
coordinate, and approve the high level Handle name space assignment
scheme at the highest level, e.g. the DISA and GSA, to ensure
consistency and uniqueness across the U.S. Federal Government.

**Cost:** There will be cost associated with URN registration, the
development of an RDS, Handle name space management, URN resolution
services, and operation of the GHR. It is estimated that Handle name
space management and the operation of a robust GHR would cost between
\$.3-1M per year. In addition, individual organizations will have to
develop searchable identifier policy, operate local namespaces, maintain
searchable identifier records, create digital object metadata, and
provide training.

**Benefits:** Reliable searchable identifiers and associated metadata
will provide the basis for increased functionality and \"value adding\"
by government and commercial organizations. The implementation of
searchable identifiers will also reduce the number of duplicate
information items on the Internet and provide a basis for informed
decision making through the use of authoritative information Web
Services raises the possibility of long-term, standard approaches to
digital content preservation.

**Priorities and schedule:** Recommendations 4-5 should be implemented
on a priority basis. Specification of the Handle System as an interim
searchable identification standard, the establishment of DISA/GSA Handle
naming authorities, and support of a robust GHR can be accomplished by
the end of FY06. Concurrently, funding should be provided for the design
and development of an RDS to support existing and future URN
implementations. The RDS will eliminate the need to reference proxy
servers or to develop multiple plug-ins, thereby greatly improving
searchable identifier usability by the public.

**4. Base Requirements**

These recommendations satisfy all of the requirements identified in the
*CGI Requirements for Enabling the Identification, Categorization and
Consistent Retrieval of Government Information* that was posted for
public comments and revised over the period August - September 2004
\[http://www.cio.gov/documents/ICGI/CGI-Requirement-040805.doc\].

**Major Requirements**

+----------------+-------------------------------------+---------------+
| *              | **Paraphrased Statement of          | *             |
| *Requirement** | Requirement**                       | *Supporting** |
|                |                                     |               |
|                |                                     | **Reco        |
|                |                                     | mmendations** |
+----------------+-------------------------------------+---------------+
| 7.6 (paragraph | Global uniqueness. The same         | 1, 4, and 5   |
| 1)             | identifier will never be assigned   |               |
|                | to two different resources.         |               |
+----------------+-------------------------------------+---------------+
| 7.6 (paragraph | Support distributed naming and      | 1, 2, 4 and 5 |
| 1)             | resolution. Since information is    |               |
|                | created in a highly distributed     |               |
|                | manner, it is essential that any    |               |
|                | identifier scheme support           |               |
|                | distributed naming or               |               |
|                | identification.                     |               |
+----------------+-------------------------------------+---------------+
| 7.6 (paragraph | Support both tangible and           | 1             |
| 2)             | intangible objects.                 |               |
+----------------+-------------------------------------+---------------+
| 7.6 (paragraph | Utilize an open, extensible         | 1, 2, 3, 4    |
| 2)             | architecture. Since persistently    | and 5         |
|                | identified objects will exist into  |               |
|                | perpetuity, the identification      |               |
|                | scheme must be open and adaptable   |               |
|                | to changing technology.             |               |
+----------------+-------------------------------------+---------------+
| 7.7 (paragraph | Provide persistent access to        | 1, 2, 4 and 5 |
| 1)             | digital information objects         |               |
|                | regardless of the current status of |               |
|                | the organization that created,      |               |
|                | named, or previously maintained     |               |
|                | them. In other words, address all   |               |
|                | aspects of the government           |               |
|                | information life cycle, i.e.,       |               |
|                | creation, long-term management and  |               |
|                | access, and permanent preservation. |               |
+----------------+-------------------------------------+---------------+
| 7.7 (paragraph | Be robust. The searchable           | 1, 2, 4 and 5 |
| 2)             | identifier scheme must provide      |               |
|                | highly reliable access to           |               |
|                | authoritative information objects.  |               |
+----------------+-------------------------------------+---------------+
| 7.7 (paragraph | Be compatible, to the greatest      | 1 and 2       |
| 2)             | extent possible, with existing and  |               |
|                | emerging persistent identification  |               |
|                | standards for intangible and        |               |
|                | tangible objects. In addition,      |               |
|                | leverage existing and globally      |               |
|                | unique identifier schemes, e.g.,    |               |
|                | ISSN, ISBN, UPC, etc.               |               |
+----------------+-------------------------------------+---------------+
| 7.8 (paragraph | Be scalable in terms of identifier  | 1, 2, 4 and 5 |
| 1)             | assignment and resolvability.       |               |
|                | Ultimately, billions of objects     |               |
|                | will be persistently identified. In |               |
|                | addition, persistent identification |               |
|                | leads to information aggregation.   |               |
|                | However, information aggregation is |               |
|                | only possible if objects can be     |               |
|                | instantaneously resolved and        |               |
|                | accessed.                           |               |
+----------------+-------------------------------------+---------------+
| 7.8 (paragraph | Be easy to use. In other words, be  | 2             |
| 1)             | resolvable by the end user with     |               |
|                | minimal, or ideally no, additional  |               |
|                | knowledge beyond the object's name  |               |
|                | or identifier.                      |               |
+----------------+-------------------------------------+---------------+
| 7.8 (paragraph | Support multiple machine and user   | 1 and 2       |
| 1)             | interfaces, e.g. browsers and bar   |               |
|                | code readers.                       |               |
+----------------+-------------------------------------+---------------+
| 7.8 (paragraph | Be human readable.                  | 1             |
| 1)             |                                     |               |
+----------------+-------------------------------------+---------------+
| 7.8 (paragraph | Support information object metadata | 3             |
| 2)             | to be used for object discovery,    |               |
|                | digital rights management,          |               |
|                | specification of inter-object       |               |
|                | relationships, and other services.  |               |
+----------------+-------------------------------------+---------------+
| 7.8 (paragraph | Reference digital object metadata   | 3             |
| 2)             | with a standard syntax, e.g.        |               |
|                | urn:ark:100.20/doc?                 |               |
+----------------+-------------------------------------+---------------+

5.  **Alternatives Considered for the URN Recommendations (1-3)**

Several alternatives were considered:

• Selection of a single searchable identifier scheme.

• Utilization of the Uniform Resource Identifier (URI).

Although specific, deployed schemes, e.g. Handles, are required to
support the searchable identifier requirements of the E-Government Act
of 2002, in the short-term, a single searchable identifier approach
cannot leverage existing searchable identifier deployments, meet the
government\'s long-term requirements, and provide an optimal response to
changing technology. Therefore, a generalized approach that integrates
multiple schemes and encourages competition and innovation is essential
for meeting the long-term searchable identifier requirement.

Under the \"classical\" view there were two URI types: URLs and URNs. It
was expected that other types would be defined. However, the only other
type ever proposed was the Uniform Resource Citation (URC).

The \"contemporary\" view is that individual schemes or namespaces can
all be URIs \[11\]. Consequently, some searchable identifier scheme
proponents question the utility of registering their schemes as URNs,
preferring the URI designation. Under this approach, \"hdl\" or \"ark\"
would be designated as a URI scheme or namespace. Currently, there are
at least 84 registered and unregistered URI schemes including http, ftp,
gopher, ldap, and urn.

On the other hand, URNs are defined as \"... resource identifiers with
the specific requirements for enabling location independent
identification of a resource, as well as longevity of reference\" \[RFC
3406\]. This is the definition of a searchable identifier. Therefore,
grouping all searchable identifier schemes under the URN designation
facilitates functional standardization and registration. In addition,
URN grouping, as opposed to the utilization of \"flat\" URI space mixing
identifier schemes of differing functionality, makes the development of
a searchable identifier RDS easier.

The syntax of the URN is as follows:

> urn:\<NID\>:\<NSS\>\
> where NID is the Namespace Identifier and NSS is the Namespace
> Specific String.

Consequently, this URN approach allows non-interoperable schemes such as
PURLs, Handles, ARKs, and ISSNs to assign unique identifiers within a
global URN framework. For example, an organization using Handles may
assign 100.2/ADA123456 as a unique identifier. An organization using
ARKs could inadvertently assign the same identifier. However, since the
identifier schemes are explicitly identified, there is no ambiguity.

> urn:hdl:100.2/ADA123456
>
> urn:ark:100.2/ADA123456

Although the NSS is identical, the different NIDs make these two URNs
globally unique. Consequently, URNs support both flexible naming and the
incorporation of legacy or new unique identification schemes. Finally,
once a RDS is developed, the NID will identify the appropriate
resolution facility.

To summarize, the URN syntax accommodates both existing and future
searchable identifier schemes, supports the distributed assignment of
globally unique identifiers, and simplifies the development and
operation of a RDS.

6.  **Alternatives Considered for the Handles Recommendations (4-5)**

Although a URN framework with an RDS is recommended for the long-term,
short-term searchable identification support requires the implementation
and support of an operational searchable identifier scheme that can
provide global resolution.

Currently, the Handles system enjoys the broadest implementation coupled
with the highest level of functionality. The latter statement is based
on the Handle System\'s ability to globally resolve both Handles and
DOIs from any Handle or DOI resolver. In other words, if a specific,
local Handle/DOI resolver cannot resolve a particular resolution
request, that request is redirected to the GHR. Since the GHR is aware
of all registered Handle/DOI resolvers, it can redirect the request to
the appropriate resolver. In addition, since the Handle System, was
developed under a grant from the Defense Advanced Research Agency
(DARPA), it is available free to government organizations. Finally, the
Handle System has been implemented using open source software.
Therefore, it should be relatively inexpensive to maintain.

PURLs also enjoy widespread use and the PURL server software is
available free from OCLC. However, PURLs do not support global
resolution. PURL resolution is limited to a particular PURL resolver.

DOIs, which are based on the Handle concept and software, provide
additional functionality developed by partners known as Registry
Agencies (RAs). However, the RA enhancements are proprietary and
therefore, do not provide a solid basis for a government directed and
managed searchable identifier infrastructure. In addition, over time the
question may arise as to who \"owns\" the searchable identifier, the RA
or the RA\'s customer.

ARKs provide a conceptually elegant searchable identifier approach.
However, ARKs lack a broadly deployed base. ARKs are currently
operationally deployed at the University of California and are being
prototyped at the U.S. National Library of Medicine.

Finally, as previously mentioned, all of these persistent identification
schemes coupled with URN naming and an RDS could provide searchable
identifier functionality.

7.  **Review Process Used**

These recommendations were informed by the draft requirements document
comments; RFCs addressing URNs, Handles, ARKS, and RDS; the CENDI
persistent identification white paper; CENDI organizational feedback;
extensive work with the Handles system; interaction and consultation
with the International DOI Foundation (IDF) and IDF Registration
Agencies; and discussions with experts in the field of searchable
identifiers.

**8. Notes and References**

1\. Arms, W., \"Uniform Resource Names, A Progress Report, \" D-Lib
Magazine, February 1996.
\[http://www.dlib.org/dlib/february96/02arms.html\]

2\. Sun, S., Reilly, S., Lannom, L. \"RFC 3651 - Handle System Namespace
and Service Definition.\" \[http://www.faqs.org/rfcs/rfc3651.html\]

3\. Kunze, J. and Rogers, R.P.C. "The ARK Persistent Identifier Scheme,"
Internet Draft, 31 July 2004.
\[http://www.ietf.org/internet-drafts/draft-kunze-ark-08.txt\]

4\. Sollins, K. and Masinter, L. "RFC 1737 -- Functional Requirements
for Uniform Resource Names," December 1994.
\[http://www.w3.org/Addressing/rfc1737.txt\]

5\. Moats, R. \"RFC 2141 - URN Syntax,\" May 1997.
\[http://www.faqs.org/rfcs/rfc2141.html\]

6\. Mealling, M. \"RFC 3401 - Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS,\" October 2002.
\[http://www.faqs/org/rfcs/rfc3401.html\]

7\. Mealling, M. \"RFC 3402 - Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm,\" October 2002.
\[http://www.faqs/org/rfcs/rfc3402.html\]

8\. Mealling, M. \"RFC 3403 - Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database,\" October 2002.
\[http://www.faqs.org/rfcs/rfc3403.html\]

9\. Mealling, M. \"RFC 3404 - Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI),\" October 2002.
\[http://www.faqs.org/rfcs/rfc3403.html\]

10\. Daniel, R. and Mealling, M. \"RFC 2168 - Resolution of Uniform
Resource Identifiers using the Domain Name System,\" June 1997.
\[http://www.faqs.org/rfcs/rfc2168.html\]

11\. Joint W3C/IETF Planning Interest Group. \"URIs, URLs, and URNs:
Clarifications and Recommendations 1.0,\" September 2001.
\[http://www.w3.org/TR/uri-clarification/\]