Re: utilizing UR?s in PKI?

[[e-mail]]

> I never thought about it.  What advantages does URNs offer?

I'm not way up-to-speed on URNs either. Tho, here's what RFC1737 says about 
URNs/URLs/URCs...

   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.

..which seems innaresting from the PKI perspective. Quotes from a couple of 
their docs and abstracts of the current drafts are below.

Jeff
---------------
>From the intro to RFC1737...

   This document specifies a minimum set of requirements for a kind of
   Internet resource identifier known as Uniform Resource Names (URNs).
   URNs fit within a larger Internet information architecture, which in
   turn is composed of, additionally, Uniform Resource Characteristics
   (URCs), and Uniform Resource Locators (URLs).  URNs are used for
   identification, URCs for including meta-information, and URLs for
   locating or finding resources.
			.
			.
			.
   The requirements for Uniform Resource Names fit within the overall
   architecture of Uniform Resource Identification.  In order to build
   applications in the most general case, the user must be able to
   discover and identify the information, objects, or what we will call
   in this architecture resources, on which the application is to
   operate.  Beyond this statement, the URI architecture does not define
   "resource."  As the network and interconnectivity grow, the ability
   to make use of remote, perhaps independently managed, resources will
   become more and more important.  This activity of discovering and
   utilizing resources can be broken down into those activities where
   one of the primary constraints is human utility and facility and
   those in which human involvement is small or nonexistent.  Human
   naming must have such characteristics as being both mnemonic and
   short.  Humans, in contrast with computers, are good at heuristic
   disambiguation and wide variability in structure.  In order for
   computer and network based systems to support global naming and
   access to resources that have perhaps an indeterminate lifetime, the
   flexibility and attendant unreliability of human-friendly names
   should be translated into a naming infrastructure more appropriate
   for the underlying support system.  It is this underlying support
   system that the Internet Information Infrastructure Architecture
   (IIIA) is addressing.

   Within the IIIA, several sorts of information about resources are
   specified and divided among different sorts of structures, along
   functional lines.  In order to access information, one must be able
   to discover or identify the particular information desired,
   determined both how and where it might be used or accessed.  The
   partitioning of the functionality in this architecture is into
   uniform resource names (URN), uniform resource characteristics (URC),
   and uniform resource locators (URL).  A URN identifies a resource or
   unit of information.  It may identify, for example, intellectual
   content, a particular presentation of intellectual content, or
   whatever a name assignment authority determines is a distinctly
   namable entity.  A URL identifies the location or a container for an
   instance of a resource identified by a URN.  The resource identified
   by a URN may reside in one or more locations at any given time, may
   move, or may not be available at all.  Of course, not all resources
   will move during their lifetimes, and not all resources, although
   identifiable and identified by a URN will be instantiated at any
   given time.  As such a URL is identifying a place where a resource
   may reside, or a container, as distinct from the resource itself
   identified by the URN.  A URC is a set of meta-level information
   about a resource.  Some examples of such meta-information are: owner,
   encoding, access restrictions (perhaps for particular instances),
   cost.

   With this in mind, we can make the following statement:

   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.

   More specifically, there are two kinds of requirements on URNs:
   requirements on the functional capabilities of URNs, and requirements
   on the way URNs are encoded in data streams and written
   communications.


>From draft-ietf-urn-syntax-05.txt....

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers. This document sets
   forward the canonical syntax for URNs.  A discussion of both existing
   legacy and new namespaces and requirements for URN presentation and
   transmission are presented.  Finally, there is a discussion of URN
   equivalence and how to determine it.


		-------------------------------------------------

URN draft abstracts...


http://info.internet.isi.edu:80/R820419-825216-1m/in-drafts/id-abstracts.html


Uniform Resource Names (urn) 

"Architectural Principles of Uniform Resource Name Resolution", K. Sollins,
09/26/1997, <draft-ietf-urn-req-frame-04.txt> 
       This document addresses the issues of the discovery of URN (Uniform
       Resource Name) resolver services that in turn will directly translate URNs into
       URLs (Uniform Resource Locators) and URCs (Uniform Resource
       Characteristics). The document falls into three major parts, the assumptions
       underlying the work, the guidelines in order to be a viable Resolver Discovery
       Service or RDS, and a framework for designing RDSs. The guidelines fall into
       three principle areas: evolvability, usability, and security and privacy. An RDS
       that is compliant with the framework will not necessarily be compliant with the
       guidelines. Compliance with the guidelines will need to be validated separately.

"Namespace Identifier Requirements for URN Services", Patrik Faltstrom, R.
Iannella, 03/27/1997, <draft-ietf-urn-nid-req-01.txt> 
       Services that offer to resolve Uniform Resource Names implicitly require that
       they support a persistent and reliable service for an indeterminate length of
       time. This draft outlines the requirements for any such service that wishes to
       participate as a Namespace Identifier. 

"URI Resolution Services Necessary for URN Resolution", M. Mealling, R. Daniel,
08/09/1997, <draft-ietf-urn-resolution-services-03.txt> 
       Retrieving the resource identified by a Uniform Resource Identifier (URI) [3] is
       only one of the operations that can be performed on a URI. One might also ask
       for and get a list of other identifiers that are aliases for the original URI or a
       bibliographic description of the resource the URI denotes, for example. This
       applies to both Uniform Resource Names (URNs) and Uniform Resource
       Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in
       this document but only as descriptions of resources rather than identifiers. 
       A service in the network providing access to a resource may provide one or
       some of these options, but it need not provide all of them. This memo specifies
       an initial set of these functions, to be used to describe the functions provided by
       any given access service and the requirements that must be met when those
       operations are encoded in a protocol. 
       "Using Existing Bibliographic Identifiers as Uniform Resource Names", C.
       Lynch, C. Preston, R. Daniel, 09/26/1997, <draft-ietf-urn-biblio-02.txt> 
       A system for Uniform Resource Names (URNs) must be capable of supporting
       identifiers from existing widely-used naming systems. This document
       discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI)
       can be supported within the URN framework and the currently proposed
       syntax for URNs. 

"URN Syntax", R. Moats, 05/05/1997, <draft-ietf-urn-syntax-05.txt> 
       Uniform Resource Names (URNs) are intended to serve as persistent,
       location-independent, resource identifiers. This document sets forward the
       canonical syntax for URNs. A discussion of both existing legacy and new
       namespaces and requirements for URN presentation and transmission are
       presented. Finally, there is a discussion of URN equivalence and how to
       determine it. 

"A URN Namespace for IETF Documents", R. Moats, 07/14/1997,
<draft-ietf-urn-ietf-02.txt> 
       A system for Uniform Resource Names (URNs) must be capable of supporting
       new naming systems. As an example of how a new namespace may be
       proposed, this document presents a naming system based on the RFC family of
       documents (RFCs, STDs, and FYIs) developed by the IETF and published by
       the RFC editor and the minutes of working groups (WG) and birds of a feather
       (BOF) meetings that occur during IETF conferences. This namespace can be
       supported within the URN framework and the currently proposed syntax for
       URNs.