draft-ietf-urn-resolution-services-07.txt   rfc2483.txt 
URN Working Group M.Mealling Network Working Group M. Mealling
INTERNET-DRAFT Network Solutions, Inc. Request for Comments: 2483 Network Solutions, Inc.
Expires six months from October1998 Ron Daniel Jr. Category: Experimental R. Daniel, Jr.
Intended category: Experimental Los Alamos National Laboratory Los Alamos National Laboratory
draft-ietf-urn-resolution-services-07.txt January 1999
URI Resolution Services URI Resolution Services
Necessary for URN Resolution Necessary for URN Resolution
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its areas, community. It does not specify an Internet standard of any kind.
and its working groups. Note that other groups may also distribute Discussion and suggestions for improvement are requested.
working documents as Internet-Drafts. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
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 Copyright (C) The Internet Society (1999). All Rights Reserved.
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract Abstract
Retrieving the resource identified by a Uniform Resource Identifier Retrieving the resource identified by a Uniform Resource Identifier
(URI) [1] is only one of the operations that can be performed on a URI. (URI) [1] is only one of the operations that can be performed on a
One might also ask for and get a list of other identifiers that are URI. One might also ask for and get a list of other identifiers that
aliases for the original URI or a bibliographic description of the are aliases for the original URI or a bibliographic description of
resource the URI denotes, for example. This applies to both Uniform the resource the URI denotes, for example. This applies to both
Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Uniform Resource Names (URNs) and Uniform Resource Locators (URLs).
Resource Characteristics (URCs) are discussed in this document but only Uniform Resource Characteristics (URCs) are discussed in this
as descriptions of resources rather than identifiers. document but only as descriptions of resources rather than
identifiers.
A service in the network providing access to a resource may provide 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 one or some of these options, but it need not provide all of them.
memo specifies an initial set of these operations that can be used to This memo specifies an initial set of these operations that can be
describe the interactions provided by a given access service. It also used to describe the interactions provided by a given access service.
suggests guidelines that should be adhered to when those operations It also suggests guidelines that should be adhered to when those
are encoded in a protocol. operations are encoded in a protocol.
1. Introduction 1. Introduction
In the course of formulating current proposals [2] regarding URNs In the course of formulating current proposals [2] regarding URNs
[3], it became apparent that requiring servers to manage all of the desired [3], it became apparent that requiring servers to manage all of the
functions or requiring clients to process varied information desired functions or requiring clients to process varied information
returned by a server was unrealistic and a barrier to adoption. There returned by a server was unrealistic and a barrier to adoption. There
needed to be some way for a client to be able to identify a server needed to be some way for a client to be able to identify a server
that specialized in the complex and another that specialized in the that specialized in the complex and another that specialized in the
simple (but fast). Also, in subsequent conversations it became obvious simple (but fast). Also, in subsequent conversations it became
that, in most cases, some of the operations were inappropriate or obvious that, in most cases, some of the operations were
difficult for certain identifiers. inappropriate or difficult for certain identifiers.
The Problem The Problem
In the process of learning about a resource in the Internet, there In the process of learning about a resource in the Internet, there
are a variety of possible functions that may be important and/or useful, are a variety of possible functions that may be important and/or
such as discovery of locators, names, descriptions, and accessing the useful, such as discovery of locators, names, descriptions, and
resource itself. A given service may support only a subset of these; accessing the resource itself. A given service may support only a
hence, it is important to describe such an access service by the types subset of these; hence, it is important to describe such an access
of functions supported and the resources of which it has some knowledge. service by the types of functions supported and the resources of
For example, in the framework for an RDS described in [5] the which it has some knowledge. For example, in the framework for an RDS
RDS itself may provide URLs [6][7], while the resolvers may provide described in [5] the RDS itself may provide URLs [6][7], while the
descriptions, URLs, or even the resources themselves. The design of an resolvers may provide descriptions, URLs, or even the resources
RDS, as proposed in RFC 2168 [2], may be more generous and provide all themselves. The design of an RDS, as proposed in RFC 2168 [2], may be
of the above. more generous and provide all of the above.
This problem requires some well understood set of identifiers that This problem requires some well understood set of identifiers that
specify those operations. But an exhaustive set would both be specify those operations. But an exhaustive set would both be
impossible and not very necessary. Thus, this document will list impossible and not very necessary. Thus, this document will list
several operations, as well as, lay out requirements for specifying new several operations, as well as, lay out requirements for specifying
operations. new operations.
The purpose of this document is to define a list of such functions The purpose of this document is to define a list of such functions
and short names for them and then use them in defining the interface to an and short names for them and then use them in defining the interface
access service. Previous versions of this document referred to services to an access service. Previous versions of this document referred to
where the arguments were specific types of URIs such as URNs or URLs. services where the arguments were specific types of URIs such as URNs
These services were called "N2L" and "L2L",for example. Their use has or URLs. These services were called "N2L" and "L2L",for example.
been changed in favor of the more general URI form. Their use has been changed in favor of the more general URI form.
Design Criteria Design Criteria
To meet these requirements a fairly simple design criteria To meet these requirements a fairly simple design criteria was used.
was used. The need to identify the operation with some token such that its The need to identify the operation with some token such that its
operands, algorithm, and errors were known proved sufficient to meet these operands, algorithm, and errors were known proved sufficient to meet
requirements. these requirements.
2. General Specification 2. General Specification
To provide a framework both for the specifications in this document To provide a framework both for the specifications in this document
and for future work to be written by others, the guidelines below are and for future work to be written by others, the guidelines below are
suggested for documents that seek to specify new operations. Any specification suggested for documents that seek to specify new operations. Any
of a member of this set of operations should address these issues with respect specification of a member of this set of operations should address
to its operands, algorithm, output, and errors. these issues with respect to its operands, algorithm, output, and
errors.
Due to the small number of listed functions, a registration mechanism Due to the small number of listed functions, a registration mechanism
was dismissed as premature. If this list grows, a registration mechanism was dismissed as premature. If this list grows, a registration
will probably be needed. mechanism will probably be needed.
Also, due to the experimental nature of this document and the systems 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 that use its specifications, the use of words like MUST and SHALL are
limited. Where used they reflect a case where this specification could limited. Where used they reflect a case where this specification
cause harm to existing, non-experimental systems such as HTTP and URNs. could cause harm to existing, non-experimental systems such as HTTP
Thus, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", and URNs. Thus, the key words "MUST", "MUST NOT", "REQUIRED",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
document are to be interpreted as described in RFC 2119. and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
2.1 Operands 2.1 Operands
Operands must contain the following pieces of information: Operands must contain the following pieces of information:
* name of the operation * name of the operation
* case insensitive mnemonic for the operation * case insensitive mnemonic for the operation
* number of operands * number of operands
* type of each operand * type of each operand
* format of each operand * format of each operand
2.2 Algorithm 2.2 Algorithm
The exact algorithm for the operation must either be specified completely The exact algorithm for the operation must either be specified
or it must be considered opaque and defined by the server or application. completely or it must be considered opaque and defined by the server
or application.
2.3 Output 2.3 Output
Output must specify one of the following: Output must specify one of the following:
* there is no output * there is no output
* the output is undefined * the output is undefined
* the output itself and its content * the output itself and its content
* the fact that the output is an object and the object's * the fact that the output is an object and the object's
type and format type and format
* any non-protocol specific errors * any non-protocol specific errors
2.4 Error Conditions 2.4 Error Conditions
All errors that are considered applicable across all implementations All errors that are considered applicable across all implementations
and application environments must be included. Errors that depend on and application environments must be included. Errors that depend on
the system conveying the service are not included. Thus, many of the the system conveying the service are not included. Thus, many of the
expected errors such as service availability or operation syntax are expected errors such as service availability or operation syntax are
not included in this document since they are implementation dependent. not included in this document since they are implementation
dependent.
2.5 Security Considerations 2.5 Security Considerations
Any security considerations relating to the service provided must be Any security considerations relating to the service provided must be
specified. This does NOT include considerations dealing with the specified. This does NOT include considerations dealing with the
protocol used to convey the service or to those that normally accompany protocol used to convey the service or to those that normally
the results of the service. For example, a service that returned a single accompany the results of the service. For example, a service that
URL would need to discuss the situation where someone maliciously inserts returned a single URL would need to discuss the situation where
an incorrect URL into the resolver but NOT the case where someone sends someone maliciously inserts an incorrect URL into the resolver but
personal information across the Internet to the resource identified by the NOT the case where someone sends personal information across the
correct URL. Internet to the resource identified by the correct URL.
3. Encoding The Operations 3. Encoding The Operations
To be useful, these operations have to be used within some system or To be useful, these operations have to be used within some system or
protocol. In many cases, these systems and protocols will place protocol. In many cases, these systems and protocols will place
restrictions on which operations make sense and how those that do are restrictions on which operations make sense and how those that do are
syntactically represented. It is sufficient for those protocols to syntactically represented. It is sufficient for those protocols to
define new operations within their own protocol specification define new operations within their own protocol specification
documents but care should be taken to make this fact well known. documents but care should be taken to make this fact well known.
Also, a given system or protocol will have its own output specifications Also, a given system or protocol will have its own output
that may restrict the output formats of a given operation. specifications that may restrict the output formats of a given
Additionally, a given protocol may have better solution for output operation. Additionally, a given protocol may have better solution
than the ones given here. For example, the result of an operation that for output than the ones given here. For example, the result of an
converts a URI to more than one URL may be encoded in a protocol- operation that converts a URI to more than one URL may be encoded in
specific manner that conveys information about the closeness of each a protocol-specific manner that conveys information about the
resource on the network. closeness of each resource on the network.
Thus, the requirements on encoding these operations within a given Thus, the requirements on encoding these operations within a given
system are as follows: system are as follows:
* which subset of the operations are allowed * which subset of the operations are allowed
* how the operator is encoded * how the operator is encoded
* how the operands are encoded * how the operands are encoded
* how the error codes are returned * how the error codes are returned
The text/uri-list MIME Media Type is specified in Section 5. This Media Type The text/uri-list MIME Media Type is specified in Section 5. This
is merely a suggestion for experimental systems that need a simple Media Type is merely a suggestion for experimental systems that need
implementation. It is included here merely as an example to show a simple implementation. It is included here merely as an example to
completeness (however simple it may be). show completeness (however simple it may be).
4. The Incomplete Set 4. The Incomplete Set
4.1 I2L (URI to URL) 4.1 I2L (URI to URL)
* Name: URI to URL * Name: URI to URL
* Mnemonic: I2L * Mnemonic: I2L
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URI. * Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: One and only one URL * Output: One and only one URL
* Errors Conditions: * Errors Conditions:
o Malformed URI o Malformed URI
o URI is syntactically valid but does not exist in any form. o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this o URI exists but there is no available output from this
operation. operation.
o URI existed in the past but nothing is currently known o URI existed in the past but nothing is currently known
about it. about it.
o Access denied o Access denied
* Security Considerations: * Security Considerations:
o Malicious Redirection o Malicious Redirection
One of the fundamental dangers related to any service such as One of the fundamental dangers related to any service such
this is that a malicious entry in a resolver's database will as this is that a malicious entry in a resolver's database
cause clients to resolve the URI into the wrong URL. The will cause clients to resolve the URI into the wrong URL.
possible intent may be to cause the client to retrieve a The possible intent may be to cause the client to retrieve
resource containing fraudulent or damaging material. a resource containing fraudulent or damaging material.
o Denial of Service o Denial of Service
By removing the URL to which the URI maps, a malicious By removing the URL to which the URI maps, a malicious
intruder may remove the client's ability to retrieve the intruder may remove the client's ability to retrieve the
resource. resource.
This operation is used to map a single URI to a single URL. It is 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 used by lightweight clients that do not have the ability to select
a list of URLs or understand a URC. The algorithm for this mapping is from a list of URLs or understand a URC. The algorithm for this
dependent on the URI scheme. mapping is dependent on the URI scheme.
4.2 I2Ls (URI to URLs) 4.2 I2Ls (URI to URLs)
* Name: URI to URLs * Name: URI to URLs
* Mnemonic: I2LS * Mnemonic: I2LS
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URI. * Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: A list of zero or more URLs * Output: A list of zero or more URLs
* Errors: * Errors:
o Malformed URI o Malformed URI
o URI is syntactically valid but does not exist in any form. o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this o URI exists but there is no available output from this
operation. operation.
o URI existed in the past but nothing is currently known o URI existed in the past but nothing is currently known
about it. about it.
o Access denied o Access denied
* Security Considerations: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
This operation is used to map a single URI to 0 or more URLs. It is 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 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 criteria that are important to the client. The client should not make
any assumptions about the order of the URLs returned. No matter what 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 the particular media type, the result should be a list of the URLs
may be used to obtain an instance of the resource identified by the that may be used to obtain an instance of the resource identified by
URI. All URIs shall be encoded according to the URL [7] and URN [3] the URI. All URIs shall be encoded according to the URL [7] and URN
specifications. [3] specifications.
4.3 I2R (URI to Resource) 4.3 I2R (URI to Resource)
* Name: URI to Resource * Name: URI to Resource
* Mnemonic: I2R * Mnemonic: I2R
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URI. * Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: An instance of the resource named by the URI. * Output: An instance of the resource named by the URI.
* Errors: * Errors:
o Malformed URI o Malformed URI
o URI is syntactically valid but does not exist in any form. o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this o URI exists but there is no available output from this
operation. operation.
o URI existed in the past but nothing is currently known o URI existed in the past but nothing is currently known
about it. about it.
o Access denied o Access denied
* Security Considerations: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
This operation is used to return a single instance of the resource 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 that is named by the URI. The format of the output is dependent on
resource itself. the resource itself.
4.4 I2Rs (URI to Resources) 4.4 I2Rs (URI to Resources)
* Name: URI to Resources * Name: URI to Resources
* Mnemonic: I2Rs * Mnemonic: I2Rs
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URI. * Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: Zero or more instances of the resource named by the URI. * Output: Zero or more instances of the resource named by the URI.
* Errors: * Errors:
o Malformed URI o Malformed URI
o URI is syntactically valid but does not exist in any form. o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this o URI exists but there is no available output from this
operation. operation.
o URI existed in the past but nothing is currently known o URI existed in the past but nothing is currently known
about it. about it.
o Access denied o Access denied
* Security Considerations: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
This operation is used to return multiple instances of a resource, This operation is used to return multiple instances of a resource,
for example, GIF and JPEG versions of an image. The judgment about the for example, GIF and JPEG versions of an image. The judgment about
resources being "the same" resides with the naming authority that the resources being "the same" resides with the naming authority that
issued the URI. issued the URI.
The output shall be a MIME multipart/alternative [4] message with The output shall be a MIME multipart/alternative [4] message with the
the alternative versions of the resource in separate body parts. If alternative versions of the resource in separate body parts. If there
there is only one version of the resource identified by the URN, it MAY is only one version of the resource identified by the URN, it MAY be
be returned without the multipart/alternative wrapper. returned without the multipart/alternative wrapper.
4.5 I2C (URI to URC) 4.5 I2C (URI to URC)
* Name: URI to URC * Name: URI to URC * Mnemonic: I2C * Number of Operands: 1 * Type
* Mnemonic: I2C of Each Operand: First operand is a URI. * Format of Each
* Number of Operands: 1 Operand: First operand is encoded as a URI. * Algorithm: Opaque *
* Type of Each Operand: First operand is a URI. Output: A URC * Errors:
* Format of Each Operand: First operand is encoded as a URI. o Malformed URI
* Algorithm: Opaque o URI is syntactically valid but does not exist in any form.
* Output: A URC o URI exists but there is no available output from this
* Errors: operation.
o Malformed URI o URI existed in the past but nothing is currently known
o URI is syntactically valid but does not exist in any form. about it.
o URI exists but there is no available output from this o Access denied * Security Considerations:
operation. o Malicious Redirection (see I2L)
o URI existed in the past but nothing is currently known o Denial of Service (see I2L)
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 Uniform Resource Characteristics are descriptions of resources. This
request allows the client to obtain a description of the resource request allows the client to obtain a description of the resource
identified by a URI, as opposed to the resource itself or simply the identified by a URI, as opposed to the resource itself or simply the
resource's URLs. The description might be a bibliographic citation, a resource's URLs. The description might be a bibliographic citation, a
digital signature, or a revision history. This draft does not specify digital signature, or a revision history. This memo does not specify
the content of any response to a URC request. That content is expected the content of any response to a URC request. That content is
to vary from one server to another. expected to vary from one server to another.
4.6 I2CS (URI to URCs) 4.6 I2CS (URI to URCs)
* Name: URI to URCs * Name: URI to URCs
* Mnemonic: I2CS * Mnemonic: I2CS
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URI. * Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: Zero or more URCs * Output: Zero or more URCs
* Errors: * Errors:
o Malformed URI o Malformed URI
o URI is syntactically valid but does not exist in any form. o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this o URI exists but there is no available output from this
operation. operation.
o URI existed in the past but nothing is currently known o URI existed in the past but nothing is currently known
about it. about it.
o Access denied o Access denied
* Security Considerations: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
URCs can come in different formats and types. This operation returns URCs can come in different formats and types. This operation returns
zero or more URCs that are appropriate for the given URI. zero or more URCs that are appropriate for the given URI.
4.7 I2N (URI to URN) 4.7 I2N (URI to URN)
* Name: URI to URN * Name: URI to URN
* Mnemonic: I2N * Mnemonic: I2N
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URN. * Type of Each Operand: First operand is a URN.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: One and only one URN * Output: One and only one URN
* Errors: * Errors:
o Malformed URI o Malformed URI
o URI is syntactically valid but does not exist in any form. o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this o URI exists but there is no available output from this
operation. operation.
o URI existed in the past but nothing is currently known o URI existed in the past but nothing is currently known
about it. 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 o Access denied
does not mean that a resource may have one and only one URN. For * Security Considerations:
example, consider a resource that one organization wishes to name o Malicious Redirection (see I2L)
'foo'; another organization, in agreement with the first, wants to call o Denial of Service (see I2L)
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 While URNs are supposed to identify one and only one resource, that
resource as the input URN. 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.
Extreme care should be taken with this service as it toys with the The result is a URN, known to the server, that identifies the same
idea of equality with respect to URNs. As mentioned in several URN resource as the input 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 Extreme care should be taken with this service as it toys with the
to the map as it changes from day to day would NOT be returned in this idea of equality with respect to URNs. As mentioned in several URN
example because they point to do different resources. Some other concept documents, the idea of equality is very domain specific. For example,
of temporary equivalence is at work. This service instead deals with a URN pointing to a weather map for a particular day and a URN
resources that have two different names where there is a binding pointing to the map as it changes from day to day would NOT be
between the names that is agreed by both name assigners. I.e., both returned in this example because they point to do different
namespaces MUST have agreed that the each name can be used in place of resources. Some other concept of temporary equivalence is at work.
the other and the meaning does not change. 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) 4.8 I2Ns (URI to URNs)
* Name: URI to URNs * Name: URI to URNs
* Mnemonic: I2NS * Mnemonic: I2NS
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URI. * Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: A list of URNs * Output: A list of URNs
* Errors: * Errors:
o Malformed URI o Malformed URI
o URI is syntactically valid but does not exist in any form. o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this o URI exists but there is no available output from this
operation. operation.
o URI existed in the past but nothing is currently known o URI existed in the past but nothing is currently known
about it. about it.
o Access denied o Access denied
* Security Considerations: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
This operation simply returns zero or more URNs following the same This operation simply returns zero or more URNs following the same
criteria and cautions as the I2N operation. criteria and cautions as the I2N operation.
4.9 I=I (Is URI equal to URI): 4.9 I=I (Is URI equal to URI):
* Name: URI = URI * Name: URI = URI
* Mnemonic: I=I * Mnemonic: I=I
* Number of Operands: 2 * Number of Operands: 2
* Type of Each Operand: Both operands are URIs. * Type of Each Operand: Both operands are URIs.
* Format of Each Operand: Both operands are encoded as a URIs. * Format of Each Operand: Both operands are encoded as a URIs.
* Algorithm: Opaque * Algorithm: Opaque
* Output: TRUE or FALSE * Output: TRUE or FALSE
* Errors: * Errors:
o Malformed URIs o Malformed URIs
o URIs are syntactically valid but do not exist in any form. o URIs are syntactically valid but do not exist in any form.
o URIs exist but there is no available output from this o URIs exist but there is no available output from this
operation. operation.
o URIs existed in the past but nothing is currently known o URIs existed in the past but nothing is currently known
about them. about them.
o Access denied o Access denied
* Security Considerations: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
This operation is used to determine whether two given URIs are This operation is used to determine whether two given URIs are
considered to be equal by the server being asked the question. The considered to be equal by the server being asked the question. The
algorithm used to determine equality is opaque. No assertions are made algorithm used to determine equality is opaque. No assertions are
about whether or not the URIs exhibits characteristics of URNs or URLs. made about whether or not the URIs exhibits characteristics of URNs
or URLs.
5. The text/uri-list Internet Media Type 5. The text/uri-list Internet Media Type
Several of the resolution service requests, such as I2Ls, I2Ns, 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 result in a list of URIs being returned to the client. The text/uri-
Internet Media Type is defined to provide a simple format for the list Internet Media Type is defined to provide a simple format for
automatic processing of such lists of URIs. the automatic processing of such lists of URIs.
This is a copy of the IANA registration of the text/uri-list Media Type. This is a copy of the IANA registration of the text/uri-list Media
Type.
Date: Fri, 18 Apr 97 08:36:07 PDT Date: Fri, 18 Apr 97 08:36:07 PDT
From: Ron Daniel Jr. <rdaniel@lanl.gov> From: Ron Daniel Jr. <rdaniel@lanl.gov>
To: iana@iana.org, rdaniel@lanl.gov To: iana@iana.org, rdaniel@lanl.gov
Subject: Request for MIME media type Text/IETF Tree - uri-list Subject: Request for MIME media type Text/IETF Tree - uri-list
Name : Ron Daniel Jr. Name : Ron Daniel Jr.
E-mail : rdaniel@lanl.gov E-mail : rdaniel@lanl.gov
MIME media type name : Text MIME media type name : Text
MIME subtype name : IETF Tree -uri-list MIME subtype name : IETF Tree -uri-list
Required parameters : none Required parameters : none
Optional parameters : charset Optional parameters : charset
Currently, URIs can be represented using US-ASCII. However, there are Currently, URIs can be represented using US-ASCII. However, there
many non-standard URIs which use special character sets. Discussion of are many non-standard URIs which use special character sets.
how to best achieve internationalization of URIs is underway. This Discussion of how to best achieve internationalization of URIs is
registration will be updated with a discussion of the URI charsets once underway. This registration will be updated with a discussion of the
that discussion has concluded. URI charsets once that discussion has concluded.
Encoding considerations : Encoding considerations : Some transfer protocols, such as SMTP,
Some transfer protocols, such as SMTP, place limits on the length of place limits on the length of lines. Very long URIs might exceed
lines. Very long URIs might exceed those limits. Systems must therefore those limits. Systems must therefore be prepared to use a suitable
be prepared to use a suitable content transfer encoding. This is content transfer encoding. This is anticipated to be a rare
anticipated to be a rare occurance. occurance.
Security considerations : Security considerations : Client software should be aware of the
Client software should be aware of the security considerations of security considerations of URIs. For example, accessing some URIs
URIs. For example, accessing some URIs can result in sending a death can result in sending a death threat to a head of state, frequently
threat to a head of state, frequently prompting a visit from the prompting a visit from the relevant protective service. Accessing
relevant protective service. Accessing other URIs may result in other URIs may result in financial obligations, or access to
financial obligations, or access to resources considered inappropriate resources considered inappropriate by one's employer.
by one's employer.
While the legitimate provider of a uri-list could exploit these While the legitimate provider of a uri-list could exploit these
properties for good or ill, it is more likely that uri-lists will be properties for good or ill, it is more likely that uri-lists will be
falsified in order to exploit such characteristics of URIs. falsified in order to exploit such characteristics of URIs.
Additionally, the lookup and reverse lookup potential of the uri-list Additionally, the lookup and reverse lookup potential of the uri-
may be attractive to traffic analysts. URI lists may also reveal list may be attractive to traffic analysts. URI lists may also
confidential information, such as the location of sensitive reveal confidential information, such as the location of sensitive
information. information.
Because of these considerations, external confidentiality measures Because of these considerations, external confidentiality measures
should be available to protect uri-list responses when appropriate. should be available to protect uri-list responses when appropriate.
Interoperability considerations : none known Interoperability considerations : none known
Published specification : Published specification : Uniform Resource Locators (URLs) and
Uniform Resource Locators (URLs) and Uniform Resource Names (URNs) are Uniform Resource Names (URNs) are two instances of the more general
two instances of the more general class of identifiers known as Uniform class of identifiers known as Uniform Resource Identifiers (URIs).
Resource Identifiers (URIs). URN resolution methods frequently wish to URN resolution methods frequently wish to return lists of URLs for a
return lists of URLs for a resource so that fault-tolerance and load resource so that fault-tolerance and load balancing can be achieved.
balancing can be achieved. The text/uri-list format is intended to be a The text/uri-list format is intended to be a very simple format for
very simple format for communicating such lists of URLs (and URNs) in a communicating such lists of URLs (and URNs) in a form suitable for
form suitable for automatic processing. automatic processing.
The format of text/uri-list resources is: The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
and are ignored during processing. (Note that URIs may contain the
'#' character, so it is only a comment character when it is the
first character on a line.)
2) The remaining non-comment lines shall be URIs (URNs or URLs), encoded 1) Any lines beginning with the '#' character are comment lines
according to the URL or URN specifications (RFC2141, RFC1738 and and are ignored during processing. (Note that URIs may contain
RFC2396). Each URI shall appear on one and only one line. Very long the '#' character, so it is only a comment character when it is
URIs are not broken in the text/uri-list format. the first character on a line.)
Content-transfer-encodings may be used to enforce line length
limitations.
3) As for all text/* formats, lines are terminated with a CRLF pair. 2) The remaining non-comment lines shall be URIs (URNs or URLs),
encoded according to the URL or URN specifications (RFC2141,
RFC1738 and RFC2396). Each URI shall appear on one and only one
line. Very long URIs are not broken in the text/uri-list format.
Content-transfer-encodings may be used to enforce line length
limitations.
In applications where one URI has been mapped to a list of URIs, the 3) As for all text/* formats, lines are terminated with a CRLF pair.
first line of the text/uri-list response SHOULD be a comment giving the
original URI.
An example of the format is given below: In applications where one URI has been mapped to a list of URIs, the
first line of the text/uri-list response SHOULD be a comment giving
the original URI.
An example of the format is given below:
# urn:isbn:0-201-08372-8 # urn:isbn:0-201-08372-8
http://www.huh.org/books/foo.html http://www.huh.org/books/foo.html
http://www.huh.org/books/foo.pdf http://www.huh.org/books/foo.pdf
ftp://ftp.foo.org/books/foo.txt ftp://ftp.foo.org/books/foo.txt
Applications which use this media : Applications which use this media : URN resolvers are the initial
URN resolvers are the initial applications. Web clients and proxies are applications. Web clients and proxies are applications that are
applications that are likely to support this format in the future. likely to support this format in the future.
Additional information : Additional information :
1. Magic number(s) : none at this time 1. Magic number(s) : none at this time
2. File extension(s) : .uris or .uri recommended 2. File extension(s) : .uris or .uri recommended
3. Macintosh file type code : URIs recommended 3. Macintosh file type code : URIs recommended
This media type is the product of the URN working group of the IETF. This media type is the product of the URN working group of the IETF.
Person to contact for further information : Person to contact for further information :
1. Name : Ron Daniel Jr. 1. Name : Ron Daniel Jr.
2. E-mail : rdaniel@lanl.gov 2. E-mail : rdaniel@lanl.gov
Intended usage : Limited Use Intended usage : Limited Use
The text/uri-list media type is intended for use in applications which The text/uri-list media type is intended for use in applications
utilize URIs for replicated resources. which utilize URIs for replicated resources.
Author/Change controller : Ron Daniel Jr. Author/Change controller : Ron Daniel Jr.
Los Alamos National Laboratory Los Alamos National Laboratory
rdaniel@lanl.gov rdaniel@lanl.gov
In applications where one URI has been mapped to a list of URIs, In applications where one URI has been mapped to a list of URIs, such
such as in response to the I2Ls request, the first line of the as in response to the I2Ls request, the first line of the text/uri-
text/uri-list response SHOULD be a comment giving the original URI. An list response SHOULD be a comment giving the original URI. An example
example of such a result for the I2L request is shown below in Figure 1. of such a result for the I2L request is shown below in Figure 1.
6. Security Considerations 6. Security Considerations
Communications with a server may be of a sensitive nature. Some Communications with a server may be of a sensitive nature. Some
servers will hold information that should only be released to servers will hold information that should only be released to
authorized users. The results from servers may be the target of authorized users. The results from servers may be the target of
spoofing, especially once electronic commerce transactions are common spoofing, especially once electronic commerce transactions are common
and there is money to be made by directing users to pirate repositories and there is money to be made by directing users to pirate
rather than repositories that pay royalties to rights-holders. Server repositories rather than repositories that pay royalties to rights-
requests may be of interest to traffic analysts. The requests may also holders. Server requests may be of interest to traffic analysts. The
be subject to spoofing. requests may also be subject to spoofing.
The "Access denied" error message assumes a system within which the The "Access denied" error message assumes a system within which the
operation is being performed that can convey an authenticated concept operation is being performed that can convey an authenticated concept
of access control. Thus, the "Access denied" message should only be of access control. Thus, the "Access denied" message should only be
returned by systems that have an appropriate method of determining returned by systems that have an appropriate method of determining
access control. access control.
7. References 7. References
[1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying [1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Syntax for the Expression of Names and Addresses of Objects on the Unifying Syntax for the Expression of Names and Addresses of
Network as Used in the World-Wide Web", RFC 1630, June, 1994. Objects on the Network as Used in the World-Wide Web", RFC 1630,
June 1994.
[2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource [2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC2168, February, 1997. Identifiers using the Domain Name System", RFC 2168, February
1997.
[3] R. Moats, "URN Syntax", RFC2141, January, 1997. [3] Moats, R., "URN Syntax", RFC 2141, January 1997.
[4] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the Extensions (MIME) Part One: Format of Internet Message Bodies",
Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, RFC 2045, November 1996.
September, 1993.
[5] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a [5] Sollins, K., "Architectural Principles of Uniform Resource Name
Framework for URN Resolution Systems", MIT/LCS, June, 1997. Resolution", RFC 2276, January 1998.
[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 [6] Kunze, J., "Functional Recommendations for Internet Resource
Locators", RFC1736, IS&T, UC Berkeley, February, 1995. Locators", RFC 1736, February 1995.
[7] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform [7] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Resource Locators (URL)", RFC1738, December, 1994. Locators (URL)", RFC 1738, December 1994.
8. Author Contact Information 8. Authors' Addresses
Michael Mealling Ron Daniel Michael Mealling
Network Solutions Advanced Computing Lab, MS B287 Network Solutions
505 Huntmar Park Drive Los Alamos National Laboratory 505 Huntmar Park Drive
Herndon, VA 22070 Los Alamos, NM, USA, 87545 Herndon, VA 22070
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 October, 1998 Phone: (703) 742-0400
Fax: (703) 742-9552
EMail: michaelm@rwhois.net
Ron Daniel
Advanced Computing Lab, MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA, 87545
Phone: (505) 665-0597
Fax: (505) 665-4939
EMail: rdaniel@lanl.gov
9. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 94 change blocks. 
489 lines changed or deleted 484 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/