not on vacation (was Re: utilizing UR?s in PKI? )

[[e-mail]]

At 04:33 PM 11/10/97 -0800, you wrote:
>> 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. 
>
>
>
>
>
>
>
>
>
>
This is a test.  Sorry to bug you.