URN Working Group                                                   M.Mealling
INTERNET-DRAFT                                         Network Solutions, Inc.
Expires six months from Sept 1997                               Ron Daniel Jr.
Intended category: Experimental                 Los Alamos National Laboratory
draft-ietf-urn-resolution-services-03.txt

                           URI Resolution Services
                        Necessary for URN Resolution

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to cite them
other than as work in progress.

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories
on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu
(US West Coast), or munnari.oz.au (Pacific Rim).

Abstract

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.

. Introduction

In the course of formulating current proposals [1] regarding URNs [2], it
became apparent that requiring servers to deal with all desired functions or
requiring clients to deal with complicated information returned by a server
was unrealistic and a barrier to adoption. There needed to be some way for a
client to be able to pick between a server that specialized in the complex
and another that specialized in the simple (but fast). Also, in subsequent
conversations it became obvious that, in most cases, some of the operations
were inappropriate or difficult for certain identifiers.

The Problem

In the process of learning about a resource in the Internet, there are a
variety of possible functions that may be important or useful, such as
discovery of locators, names, descriptions, and accessing the resource
itself. A given service may support only a subset of these; hence, it is
important to describe such an access service by the types of functions it
supports, those resources about which it knows anything. For example, in the
framework for an RDS described in [5] the RDS itself may provide URLs [6][7],
while the resolvers may provide descriptions, URLs, or even the resources
themselves. The design of an RDS, as proposed in RFC 2168 [8], may be more
generous and provide all of the above.

This problem requires some well understood set of identifiers that identify
those operations. But an exhaustive set would both be impossible and not
very necessary. Thus, this document will list several operations as well as
lay out requirements for specifying new operations.

The purpose of this document is to define a list of such functions and short
names for them and use them in defining the interface to an access service.
Previous versions of this document referred to services where the arguments
were specific types of URIs such as URNs or URLs. These services were called
"N2L" and "L2L",for example. Their use has been changed in favor of the more
general URI form.

Design Criteria

The design criteria used to meet these requirements were fairly simple. The
need to identify the operation with some token and know its operands,
algorithm, and errors was sufficient to meet the requirements.

. General Specification

To provide a framework both for the specifications in this document and for
new ones to be written by others, the requirements below are placed on any
documents that seek to specify new operations. Any specification of a member
of this set of operations MUST contain at least the following pieces of
information with respect to its operands, its algorithm, output, and errors.

At this stage it is unclear whether or not the registration of these
operations is required. In the future if it becomes apparent that these
functions are widely used and extended then some registration scheme will
need to be developed.

2.1 Operands

Operands must contain the following pieces of information:

   * name of the operation
   * case insensitive mnemonic for the operation
   * number of operands
   * type of each operand
   * format of each operand

2.2 Algorithm

The exact algorithm for the operation must be specified, or it must be
specified that the algorithm is opaque and defined by the server.

2.3 Output

Output must specify one of the following:

   * there is no output
   * the output is undefined
   * the output itself and its content
   * the fact that the output is an object and the object's type and format
   * any non-protocol specific errors

2.4 Error Conditions

All errors that are considered applicable across all implementations and
application environments must be included. Errors that depend on the system
conveying the service are not included. Thus, many of the expected errors
such as service availability or operation syntax are not included in this
document since they are implementation dependent.

2.5 Security Considerations

Any security considerations relating to the service provided must be
specified. This does NOT include considerations dealing with the protocol
used to convey the service or to those that normally accompany the results
of the service. For example, an I2L service would need to discuss the
situation where someone maliciously inserts an incorrect URL into the
resolver but NOT the case where someone sends personal information across
the Internet to the resource identified by the correct URL.

. Encoding The Operations

To be useful, these operations have to be used within some system or
protocol. In many cases, these systems and protocols will place restrictions
on which operations make sense and how those that do are syntactically
represented. It is sufficient for those protocols to define new operations
within their own protocol specification documents but care should be taken
to make this fact well known.

Also, a given system or protocol will have its own output formats that will
restrict the output formats of a given operation. Conversely, a given
protocol may have better solution for output than the ones given here. For
example, the I2L result may be encoded in a protocol-specific manner that
conveys information about the closeness of each resource on the network.

Thus, the requirements on encoding these operations within a given system
are as follows:

   * which subset of the operations are allowed
   * how the operator is encoded
   * how the operands are encoded
   * how the error codes are returned

For those systems that can use it, MIME [4] is the suggested output format.
The operations listed here use the text/uri-list Internet Media Type (IMT)
[4] that is specified in Section 6. Other systems are strongly encouraged to
use this IMT. In the case where a system does not use an IMT, a
justification should be given.

. The Incomplete Set

4.1 I2L (URI to URL)

   * Name: URI to URL
   * Mnemonic: I2L
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URI.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: One and only one URL encoded in a text/uri-list
   * Errors Conditions:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection
          One of the fundamental dangers related to any service such as this
          is that a malicious entry in a resolver's database will cause
          clients to resolve the URI into the wrong URL. The possible intent
          may be to cause the client to retrieve a resource containing
          fraudulent or damaging material.
        o Denial of Service
          By removing the URL to which the URI maps, a malicious intruder
          may remove the client's ability to retrieve the resource.

This operation is used to map a single URI to a single URL. It is used by
lightweight clients that do not have the ability to select from a list of
URLs or understand a URC. The algorithm for this mapping is dependent on the
URI scheme.

4.2 I2Ls (URI to URLs)

   * Name: URI to URLs
   * Mnemonic: I2LS
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URI.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: A list of zero or more URLs encoded in a text/uri-list
   * Errors:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to map a single URI to 0 or more URLs. It is used by
a client that can pick from a list of URLs based on some criteria that are
important to the client. The client should not make any assumptions about
the order of the URLs returned. No matter what the particular media type,
the result MUST be a list of the URLs that may be used to obtain an instance
of the resource identified by the URI. All URIs shall be encoded according
to the URI specification [3].

4.3 I2R (URI to Resource)

   * Name: URI to Resource
   * Mnemonic: I2R
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URI.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: An instance of the resource named by the URI. Encoding is not
     specified.
   * Errors:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to return a single instance of the resource that is
named by the URI. The format of the output is dependent on the resource
itself.

4.4 I2Rs (URI to Resources)

   * Name: URI to Resources
   * Mnemonic: I2Rs
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URI.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: Zero or more instances of the resource named by the URI.
     Encoding is not specified but MIME multipart/alternative is encouraged.
   * Errors:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to return multiple instances of a resource, for
example, GIF and JPEG versions of an image. The judgment about the resources
being "the same" resides with the naming authority that issued the URI.

The output shall be a MIME multipart/alternative [4] message with the
alternative versions of the resource in separate body parts. If there is
only one version of the resource identified by the URN, it MAY be returned
without the multipart/alternative wrapper.

4.5 I2C (URI to URC)

   * Name: URI to URC
   * Mnemonic: I2C
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URI.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: A URC. Encoding is not specified.
   * Errors:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

Uniform Resource Characteristics are descriptions of resources. This request
allows the client to obtain a description of the resource identified by a
URI, as opposed to the resource itself or simply the resource's URLs. The
description might be a bibliographic citation, a digital signature, or a
revision history. This draft does not specify the content of any response to
a URC request. That content is expected to vary from one server to another.

4.6 I2CS (URI to URCs)

   * Name: URI to URCs
   * Mnemonic: I2CS
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URI.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: Zero or more URCs. Encoding is not specified.
   * Errors:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

URCs can come in different formats and types. This operation returns zero or
more URCs that are appropriate for the given URI.

4.7 I2N (URI to URN)

   * Name: URI to URN
   * Mnemonic: I2N
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URN.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: One URN encoded in a text/uri-list IMT.
   * Errors:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

While URNs are supposed to identify one and only one resource, that does not
mean that a resource may have one and only one URN. For example, consider a
resource that one organization wishes to name 'foo'; another organization,
in agreement with the first, wants to call the resource 'bar'. Both
organizations can agree that both names 'name' the same resource and that
the URNs 'foo' and 'bar' are equivalent.

The result is a URN, known to the server, that identifies the same resource
as the input URN. The result shall be encoded in a text/uri-list IMT.

Extreme care should be taken with this service as it toys with the idea of
equality with respect to URNs. As mentioned in several URN documents, the
idea of equality is very domain specific. For example, a URN pointing to a
weather map for a particular day and a URN pointing to the map as it changes
from day to day would NOT be returned in this example because they point to
do different resources. Some other concept of temporary equivalence is at
work. This service instead deals with resources that have two different
names where there is a binding between the names that is agreed by both name
assigners. I.e., both namespaces must have agreed that the each name can be
used in place of the other and the meaning does not change.

4.8 I2Ns (URI to URNs)

   * Name: URI to URNs
   * Mnemonic: I2NS
   * Number of Operands: 1
   * Type of Each Operand: First operand is a URI.
   * Format of Each Operand: First operand is encoded as a URI.
   * Algorithm: Opaque
   * Output: A list of URNs encoded in a text/uri-list IMT
   * Errors:
        o Malformed URI
        o URI is syntactically valid but does not exist in any form.
        o URI exists but there is no available output from this operation.
        o URI existed in the past but nothing is currently known about it.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation simply returns zero or more URNs following the same criteria
and cautions as the I2N operation.

4.9 I=I (Is URI equal to URI):

   * Name: URI = URI
   * Mnemonic: I=I
   * Number of Operands: 2
   * Type of Each Operand: Both operands are URIs.
   * Format of Each Operand: Both operands are encoded as a URIs.
   * Algorithm: Opaque
   * Output: TRUE or FALSE
   * Errors:
        o Malformed URIs
        o URIs are syntactically valid but do not exist in any form.
        o URIs exist but there is no available output from this operation.
        o URIs existed in the past but nothing is currently known about
          them.
        o Access denied
   * Security Considerations:
        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to determine whether two given URIs are considered to
be equal by the server being asked the question. The algorithm used to
determine equality is opaque. No assertions are made about whether or not
the URIs exhibits characteristics of URNs or URLs.

. The text/uri-list Internet Media Type

The text/uri-list Internet Media Type has been registered with the IANA
as a general purpose way to transport lists of URIs.  Several of the
resolution service requests, such as I2Ls, I2Ns, result in just such a
list being returned to the client.

The format of text/uri-list resources is as follows.

  1. Any lines beginning with the '#' character are comment lines and are
     ignored during processing. (Note that '#' is a character that may
     appear in URIs, so it only denotes a comment when it is the first
     character on a line.)
  2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
     according to the URI specification RFC[3]. Each URI shall appear on one
     and only one line.
  3. As for all text/* formats, lines are terminated with a CR LF pair,
     although clients should be liberal in accepting lines with only one of
     those characters.
  4. The order of the URIs given MUST be preserved upon retransmission. The
     client should not make any inferences about what the order of the
     returned list means.

In applications where one URI has been mapped to a list of URIs, such as in
response to the I2Ls request, the first line of the text/uri-list response
SHOULD be a comment giving the original URI. An example of such a result for
the I2L request is shown below in Figure 1.

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

     # urn:cid:foo@huh.org
     http://www.huh.org/cid/foo.html
     http://www.huh.org/cid/foo.pdf
     ftp://ftp.foo.org/cid/foo.txt

                Figure 1: Example of the text/uri-list format

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

. Security Considerations

Communications with a server may be of a sensitive nature. Some servers will
hold information that should only be released to authorized users. The
results from servers may be the target of spoofing, especially once
electronic commerce transactions are common and there is money to be made by
directing users to pirate repositories rather than repositories that pay
royalties to rights-holders. Server requests may be of interest to traffic
analysts. The requests may also be subject to spoofing.

The "Access denied" error message assumes a system within which the
operation is being performed that can convey an authenticated concept of
access control. Thus, the "Access denied" message should only be returned by
systems that have an appropriate method of determining access control.

. References

[] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
February, 1997.

[] R. Moats, "URN Syntax", RFC2141, January, 1997.

[] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying
Syntax for the Expression of Names and Addresses of Objects on the Network
as Used in the World-Wide Web", RFC 1630, June, 1994.

[] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the Format
of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993.

[] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a Framework
for URN Resolution Systems", MIT/LCS, June, 1997.

[Note to RFC Editor: Please change reference 5 to point to the correct RFC
number for the draft]

[] Kunze, J., "Functional Recommendations for Internet Resource Locators",
RFC1736, IS&T, UC Berkeley, February, 1995.

[] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform Resource
Locators (URL)", RFC1738, December, 1994.

[] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
Identifiers Using the Domain Name System", RFC2168, June, 1997.

. Author Contact Information

 Michael Mealling                      Ron Daniel
 Network Solutions                     Advanced Computing Lab, MS B287
 505 Huntmar Park Drive                Los Alamos National Laboratory
 Herndon, VA 22070                     Los Alamos, NM, USA, 87545
 voice: (703) 742-0400                 voice: (505) 665-0597
 fax: (703) 742-9552                   fax: (505) 665-4939
 email: michaelm@rwhois.net            email: rdaniel@lanl.gov