# URN draft - whether it meets requirements

Mitra (mitra@path.net)
Sun, 30 Oct 94 17:52:16 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Owen Rees: "URNs are unambiguous rather than unique (was Re: Current URN syntax)"
- Previous message: Larry Masinter: "Re: Relative URL draft 01"

    Date: Sun, 30 Oct 94 17:52:16 -0500

    Message-Id: <aad961cc040210043f39@[192.190.111.98]>

    To: uri@bunyip.com

    From: mitra@path.net (Mitra)

    Subject: URN draft - whether it meets requirements

Larry requested that the authors of the current URN draft, review it
against the URN requirements document. Below are my comments on this
review - I should note that

* These reflect my views, and not neccessarily those of the co-authors
of the URN draft (Chris Weider, and Mike Mealing)

* The URN draft happens to meet the requirments in this document, but it
was based on requirements expressed by implementors rather than on this
document.
In particular:

+ The need to come up with a syntax and protocol for resolution NOW so that
implementors committed to doing this can use the same spec and interwork -
a standard that takes another year or so will be usefull, because like the
URL standard, it would be too late to replace current practice.

+ Resolution must be fast enough to facilitate use of URNs instead of URLs
in information retrieval applications such as WWW and Gopher.

+ The chosen syntax must be scalable, but must also allow resolution to scale.

+ The scheme chosen should be easy to integrate into existing information
systems - especially WWW, Gopher and Prospero.

+ The resolution protocol chosen should not be unneccessarily difficult to
implement.

In most cases, I have just marked a Requirement as "Met" rather than
explaining why or how it is met, something I think is easily seen from
reading the URN draft. If their are doubts let me know and I will
expand on the reasoning.

- Mitra

1. Introduction
<ommitted for brevity>
o The purpose or function of a URN is to provide a globally unique,
persistent identifier used for recognition, for access to
characteristics of the resource or for access to the resource
itself.

This is the primary goal addressed in the URN draft.

2. Requirements for functional capabilities
These are the requirements for URNs' functional capabilities:

o Global scope: A URN is a name with global scope which does not
imply a location. It has the same meaning everywhere.

Met

o Global uniqueness: The same URN will never be assigned to two
different resources.

Met - note the rules on reuse of DNS names, which are required to meet
this requirement.

o Persistence: It is intended that the lifetime of a URN be
permanent. That is, the URN will be globally unique forever, and
may well be used as a reference to a resource well beyond the
lifetime of the resource it identifies or of any naming authority
involved in the assignment of its name.

Met

o Scalability: URNs can be assigned to any resource that might
conceivably be available on the network, for hundreds of years.

Met

o Legacy support: The scheme must permit the support of existing
legacy naming systems, insofar as they satisfy the other
requirements described here. For example, ISBN numbers, ISO
public identifiers, and UPC product codes seem to satisfy the
functional requirements, and allow an embedding that satisfies
the syntactic requirements described here.

I dont know about UPCs, but ISBNs are explicitly given as an example. No
attempt has been met to support ISO's but I dont see why they wouldnt
fit in quite happily.

o Extensibility: Any scheme for URNs must permit future extensions to
the scheme.

This is met by the first part of the "Naming Authority Id" field.

o Independence: It is solely the responsibility of a name issuing
authority to determine the conditions under which it will issue a
name.

Met

o Resolution: A URN will not impede resolution (translation into a
URL, q.v.). To be more specific, for URNs that have corresponding
URLs, there must be some feasible mechanism to translate a URN to a
URL.

Met - although those of us working on this spec had much stiffer
requirements than this (see above)

3. Requirements for URN encoding
In addition to requirements on the functional elements of the URNs,
there are requirements for how they are encoded in a string:

o Single encoding: The encoding for presentation for people in clear
text, electronic mail and the like is the same as the encoding in
other transmissions.

Met

o Simple comparison: A comparison algorithm for URNs is simple,
local, and deterministic. That is, there is a single algorithm for
comparing two URNs that does not require contacting any external
server, is well specified and simple.

Met

o Human transcribability: For URNs to be easily transcribable by
humans without error, they should be short, use a minimum of
special characters, and be case insensitive. (There is no strong
requirement that it be easy for a human to generate or interpret a
URN; explicit human-accessible semantics of the names is not a
requirement.) For this reason, URN comparison is insensitive to
case, and probably white space and some punctuation marks.

Met - depending of course on reasonable choices being made by those
Naming Authorities allocating the opaque IDs.

Unfortunately the goals of "Supporting Legacy systems", "Case insensitive"
and "Minimum of special characters" are mutually exclusive for some legacy
schemes - especially "MessageIds" which are case insensitive, and would
therefore have to be percent-encoded.

o Transport friendliness: A URN can be transported unmodified in the
common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc., as
well as printed paper.

Met

o Machine consumption: A URN can be parsed by a computer.

Met

o Text recognition: The encoding of a URN should enhance the
ability to find and parse URNs in free text.

Met - note recommendation of <> to CONTAIN the URN in free text

4. Implications

For a URN specification to be acceptible, it must meet the previous
requirements. We draw a set of conclusions, listed below, from
those requirements; a specification that satisfies the requirments
without meetings these conclusions is deemed acceptable, although
unlikely to occur.

o To satisfy the requirements of uniqueness and scalability, name
assignment is delegated to naming authorities, who may then assign
names directly or delegate that authority to sub-authorities.
Uniqueness is guaranteed by requiring each naming authority to
guarantee uniqueness. The names of the naming authorities
themselves are persistent and globally unique and top level
authorities will be centrally registered.

Met

o Naming authorities that support scalable naming are encouraged, but
not required. Scalability implies that a scheme for devising names
may be scalable both at its terminators as well as within the
structure; e.g., in a hierarchical naming scheme, a naming
authority might have an extensible mechanism for adding new
sub-registries.

Met

o It is strongly recommended that there be a mapping between the
names generated by each naming authority and URLs. At any specific
time there will be zero or more URLs into which a particular URN
can be mapped. The naming authority itself need not provide the
mapping from URN to URL.

Met

o For URNs to be transcribable and transported in mail, it is
necessary to limit the character set usable in URNs, although there
is not yet consensus on what the limit might be.

Met

In assigning names, a name assignment authority must abide by the
preceding constraints, as well as defining its own criteria for
determining the necessity or indication of a new name assignment.

I disagree with this observation, the opaqueID is just that, opaque, a
naming authority IS RECOMMENDED TO abide by the constraints, it must abide
only by whatever is defined in the protocol.

5. Other considerations

<ommitted for brevity>

Last, this document intentionally does not address the problem of name
resolution, other than to recommend that for each naming authority a
name translation mechanism exist. Naming authorities assign names,
while resolvers or location services of some sort assist or provide
URN to URL mapping. There may be one or many such services for the
resources named by a particular naming authority. It may also be the

The URN draft *does* address this issue, and reserves a particular
resolution scheme for a certain range of Naming Authority Ids, i.e.
any starting "dns:". It is my belief that any scheme which does
not address resolution is of limited usefullness.

It was a requirement in our process, that we be able to grandfather in
existing information systems, and also that implementation of resolution
should not be unneccessarily complicated, in order to encourage the use
of URNs rather than URLs. For this reason, we stuck to a single
resolution process for this namespace, while not requiring that this
be the only possible process.

- Mitra

=======================================================================
Mitra mitra@path.net
Internet Consulting (415)488-0944
<http://www.path.net/mitra> fax (415)488-0988

- Next message: Owen Rees: "URNs are unambiguous rather than unique (was Re: Current URN syntax)"
- Previous message: Larry Masinter: "Re: Relative URL draft 01"