datatracker.ietf.org
Sign in
Version 5.6.2.p2, 2014-07-24
Report a bug

Architectural Principles of Uniform Resource Name Resolution
RFC 2276

Document type: RFC - Informational (January 1998; No errata)
Updated by RFC 3401
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2276 (Informational)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                         K. Sollins
Request for Comments: 2276                                       MIT/LCS
Category: Informational                                     January 1998

      Architectural Principles of Uniform Resource Name Resolution

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   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.

Table of Contents

   1.    Introduction..................................................2
   2.    Assumptions...................................................5
   3.    Guidelines....................................................7
   3.1   Evolution.....................................................7
   3.2   Usability....................................................10
   3.2.1 The Publisher................................................11
   3.2.2 The Client...................................................12
   3.2.3 The Management...............................................13
   3.3   Security and Privacy.........................................14
   4.    The Framework................................................18
   5.    Acknowledgements.............................................23
   6.    References...................................................23
   7.    Author's Address.............................................23
   8.    Full Copyright Statement.....................................24

Sollins                      Informational                      [Page 1]
RFC 2276            Uniform Resource Name Resolution        January 1998

1. Introduction

   The purpose of this document is to lay out the engineering criteria
   for what we will call here a Resolver Discovery Service (RDS), a
   service to help in the learning about URN (Uniform Resource Name)
   resolvers.  The term "resolver" is used in this document to indicate
   a service that translates URNs to URLs (Uniform Resource Locators) or
   URCs (Uniform Resource Characteristics).  Some resolvers may provide
   direct access to resources as well.  An RDS helps in finding a
   resolver to contact for further resolution.  It is worth noting that
   some RDS designs may also incorporate resolver functionality.  This
   function of URN resolution is a component of the realization of an
   information infrastructure.  In the case of this work, that
   infrastructure is to be available, "in the Internet" or globally, and
   hence the solutions to the problems we are addressing must be
   globally scalable.  In this document, we are focussing specifically
   on the design of RDS schemes.

   The Uniform Resource Identifier Working Group defined a naming
   architecture, as demonstrated in a series of three RFCs 1736 [1],
   1737 [2], and 1738 [3].  Although several further documents are
   needed to complete the description of that architecture, it
   incorporates three core functions often associated with "naming":
   identification, location, and mnemonics or semantics.  By location,
   we mean fully-qualified Domain Names or IP addresses, possibly
   extended with TCP ports and/or local identifiers, such as pathnames.
   Names may provide the ability to distinguish one resource from
   another, by distinguishing their "names".  Names may help to provide
   access to a resource by including "location" information.  In
   addition, names may have other semantic or mnemonic information that
   either helps human users remember or figure out the names, or
   includes other semantic information about the resource being named.
   The URI working group concluded that there was need for persistent,
   globally unique identifiers, distinct from location or other semantic
   information; these were called URNs.  These "names" provide identity,
   in that if two of them are "the same" (under some simple rule of
   canonicalization), they identify the same resource.  Furthermore, the

[include full document text]