[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc2483                               
URN Working Group                                             M.Mealling
INTERNET-DRAFT                                   Network Solutions, Inc.
Expires six months from March 1998                        Ron Daniel Jr.
Intended category: Experimental           Los Alamos National Laboratory
draft-ietf-urn-resolution-services-05.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.

1. 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.

Mealling, Daniel                                                [Page 1]


draft-ietf-urn-resolution-services-05.txt                     March 1998

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 [1], 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.

2. General Specification

To provide a framework both for the specifications in this document
and for future work to be written by others, the guidelines below are
suggested for documents that seek to specify new operations. Any
specification of a member of this set of operations should address
these issues with respect to its operands, its algorithm, output, and errors.

Due to the small number of listed functions, a registration mechanism
was dismissed as premature. If this list grows, a registration mechanism
will probably be needed.

Also, due to the experimental nature of this document and the systems
that use its specifications, the use of words like MUST and SHALL are
limited. Where used they reflect a case where this specification could
cause harm to existing, non-experimental systems such as HTTP and URNs.
Thus, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

Mealling, Daniel                                                [Page 2]


draft-ietf-urn-resolution-services-05.txt                     March 1998

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.

3. 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.

Mealling, Daniel                                                [Page 3]


draft-ietf-urn-resolution-services-05.txt                     March 1998

Also, a given system or protocol will have its own output specifications
that may restrict the output formats of a given operation.
Additionally, 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

The text/uri-list MIME Media Type is specified in Section 5. This Media Type
is merely a suggestion for experimental systems that need a simple
implementation. It is included here merely as an example to show
completeness (however simple it may be).

4. 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
   * 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.

Mealling, Daniel                                                [Page 4]


draft-ietf-urn-resolution-services-05.txt                     March 1998

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
   * 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 should 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.
   * 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)

Mealling, Daniel                                                [Page 5]


draft-ietf-urn-resolution-services-05.txt                     March 1998
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.
   * 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
   * 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)

Mealling, Daniel                                                [Page 6]


draft-ietf-urn-resolution-services-05.txt                     March 1998

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
   * 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 and only one URN
   * 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)

Mealling, Daniel                                                [Page 7]


draft-ietf-urn-resolution-services-05.txt                     March 1998

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.

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
   * 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
Mealling, Daniel                                                [Page 8]


draft-ietf-urn-resolution-services-05.txt                     March 1998

   * 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.

5. The text/uri-list Internet Media Type

     [This section will be augmented or replaced by the registration of
     the text/uri-list IMT once that registration has been performed].

Several of the resolution service requests, such as I2Ls, I2Ns,
result in a list of URIs being returned to the client. The
text/uri-list Internet Media Type is defined to provide a simple format
for the automatic processing of such lists of URIs.

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.

Mealling, Daniel                                                [Page 9]


draft-ietf-urn-resolution-services-05.txt                     March 1998

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

     # 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
                 ------------------------------------------

6. 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.

7. References

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

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

[3] 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.

[4] 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.

[5] 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 this reference to point to the
correct RFC number for the draft]

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

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

Mealling, Daniel                                               [Page 10]


draft-ietf-urn-resolution-services-05.txt                     March 1998

8. 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













































             This document expires 6 months from November, 1997

Mealling, Daniel                                               [Page 11]