draft-ietf-urn-resolution-services-01.txt   draft-ietf-urn-resolution-services-02.txt 
URN Working Group M.Mealling URN Working Group M.Mealling
INTERNET-DRAFT Network Solutions, Inc. INTERNET-DRAFT Network Solutions, Inc.
Expires six months from June 1997 Ron Daniel Jr. Expires six months from July 1997 Ron Daniel Jr.
Intended category: Standards Track Los Alamos National Laboratory Intended category: Experimental Los Alamos National Laboratory
draft-ietf-urn-resolution-services-01.txt draft-ietf-urn-resolution-services-02.txt
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 document is an Internet-Draft. Internet-Drafts are working documents
documents of the Internet Engineering Task Force (IETF), its areas, of the Internet Engineering Task Force (IETF), its areas, and its working
and its working groups. Note that other groups may also distribute groups. Note that other groups may also distribute working documents as
working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months and
months and may be updated, replaced, or obsoleted by other documents may be updated, replaced, or obsoleted by other documents at any time. It
at any time. It is inappropriate to use Internet-Drafts as reference is inappropriate to use Internet-Drafts as reference material or to cite them
material or to cite them other than as work in progress. other than as work in progress.
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check the
the 1id-abstracts.txt listing contained in the Internet-Drafts 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract Abstract
Fetching the resource identified by a Uniform Resource Identifier (URI) [3] Retrieving the resource identified by a Uniform Resource Identifier (URI)
is only one of the operations that can be performed on a URI. We might ask [3] is only one of the operations that can be performed on a URI. One might
for a list of other identifiers that are aliases for the original URI, a also ask for and get a list of other identifiers that are aliases for the
bibliographic description of the resource the URI denotes, etc. Because of original URI or a bibliographic description of the resource the URI denotes,
the diverse nature of resources on the network, it may be difficult (or for example. This applies to both Uniform Resource Names (URNs) and Uniform
impossible) to offer all those operations, therefore a means of indicating Resource Locators (URLs). Uniform Resource Characteristics (URCs) are
what services are and are not supported by a given resolver must be discussed in this document but only as descriptions of resources rather than
specified. This memo gives an initial set of those operations, and the identifiers.
requirements that must be met when those operations are encoded in a
protocol. 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 1. Introduction
In the course of formulating current proposals [1] regarding Uniform In the course of formulating current proposals [1] regarding URNs [2], it
Resource Names [2] it became apparent that requiring servers to deal with became apparent that requiring servers to deal with all desired functions or
all desired functions or requiring clients to deal with complicated requiring clients to deal with complicated information returned by a server
information returned by a server was unrealistic and a barrier to adoption. was unrealistic and a barrier to adoption. There needed to be some way for a
There needed to be some way for a client to be able to pick between a server client to be able to pick between a server that specialized in the complex
that specialized in the complex and another that specialized in the simple and another that specialized in the simple (but fast). Also, in subsequent
(but fast). Also, in subsequent conversations it became obvious that, in conversations it became obvious that, in most cases, some of the operations
most cases, some of the operations were inappropriate or difficult for were inappropriate or difficult for certain identifiers. For example, ISSNs
certain identifiers. For example, ISSNs identify books or magazines that are identify books or magazines that are serial in nature. An operation to
serial in nature. An operation to return the resource for an ISSN pointing return the resource for an ISSN pointing to "Time" magazine would result in
to "Time" magazine would result in dumping hundreds of thousands of pages of dumping hundreds of thousands of pages of "Time" onto a user's machine. This
"Time" onto a user's machine. This does not seem like a reasonable thing to does not seem like a reasonable thing to do in the normal case.
do in the normal case.
The Problem The Problem
The problem, stated simply, is one of a client needing to convey to a In the process of learning about a resource in the Internet, there are a
service the desired operation that the client wishes to have done on a given variety of possible functions that may be important or useful, such as
URI. The converse of this problem was that the server needed some way to discovery of locators, names, descriptions, and accessing the resource
convey to a client which services a network entity supported. 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 This problem requires some well understood set of identifiers that identify
those operations. But it was also realized that an exhaustive set would both those operations. But an exhaustive set would both be impossible and not
be impossible and not very necessary. Thus, this document will list several very necessary. Thus, this document will list several operations as well as
operations as well as lay out requirments for specifying new operations. lay out requirements for specifying new operations.
Historical Note: Since these services originated with the discussions
surrounding URN resolution, there needs to be a clarification about at which
point in the resoulution process these services reside. The URN resolution
framework [] uses a two step process. The first step is called a Resolution
Discovery Services or RDS. The second part is called a local resolver. The
RDS uses hints to point a client toward a local resolver which actually
answers the questions about the URI. The services described here reside at
the level of the local resolver. The identifiers are used in the RDS to
specify which local resolvers handle which services.
Also, previous versions of this document referred to services where the The purpose of this document is to define a list of such functions and short
arguments were specific types of URIs such as URNs or URLs. These services names for them and use them in defining the interface to an access service.
were called "N2L", "L2L", etc. Their use has been deprecated here in favor Previous versions of this document referred to services where the arguments
of the more general URI form. 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 Design Criteria
The design criteria used to meet these requirements were fairly simple. The The design criteria used to meet these requirements were fairly simple. The
need to simply identify the operation with some token and know its operands, need to identify the operation with some token and know its operands,
algorithm and errors was seen as sufficient to meet the requirements. algorithm, and errors was sufficient to meet the requirements.
2. General Specification 2. General Specification
In order to provide a framework both for the specifications in this document To provide a framework both for the specifications in this document and for
and for new ones to be written by others, the following requirments are new ones to be written by others, the requirements below are placed on any
placed on any documents that seek to specify new operations. 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
Any specification of a member of this set of operations MUST contain at information with respect to its operands, its algorithm, output, and errors.
least the following pieces of information with respect to its operands, its
algorithm, output and errors.
2.1 Operands 2.1 Operands
Must contain the following pieces of information: Operands must contain the following pieces of information:
* name of the operation * name of the operation
* mnemonic for the operation * 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
Must either specify the exact algorithm for the operation or that the The exact algorithm for the operation must be specified, or it must be
algorithm is opaque and defined by the server. specified that the algorithm is opaque and defined by the server.
2.3 Output 2.3 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 type and format. * the fact that the output is an object and the object's type and format
2.4 Error Conditions 2.4 Error Conditions
Must include all errors that are considered applicable across all All errors that are considered applicable across all implementations and
implementations and application environments. Errors that depend on the application environments must be included. Errors that depend on the system
system conveying the service are not included. Thus, many of the expected conveying the service are not included. Thus, many of the expected errors
errors such as syntax errors or service availability are not included in such as syntax errors or service availability are not included in this
this document since they are implementation dependent. document since they are implementation dependent.
2.5 Security Considerations 2.5 Security Considerations
Must specify any security considerations relating to the serivce provided. Any security considerations relating to the service provided must be
This does NOT include considerations dealing with the protocol used to specified. This does NOT include considerations dealing with the protocol
convey the service or to those that normally accompany the results of the used to convey the service or to those that normally accompany the results
service. For example, an I2L service would need to discuss the situation of the service. For example, an I2L service would need to discuss the
where someone maliciously inserts an incorrect URL into the resolver but NOT situation where someone maliciously inserts an incorrect URL into the
the case where someone sends personal information across the Internet to the resolver but NOT the case where someone sends personal information across
resource identified by the correct URL. the 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 restrictions protocol. In many cases, these systems and protocols will place restrictions
on which operations make sense and how those that do are syntactically on which operations make sense and how those that do are syntactically
represented. represented.
Also, a given system or protocol will have its own output formats that will Also, a given system or protocol will have its own output formats that will
restrict the output formats of a given operation. Additionally, a given restrict the output formats of a given operation. Additionally, a given
protocol may have better solution for output than the ones given here. For 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 example, the I2L result may be encoded in a protocol-specific manner that
causes the client to treat it as special. causes the client to treat it as special.
Thus, the requirements on encoding these operations within a given system Thus, the requirements on encoding these operations within a given system
are the following: 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
For those system that can use it, MIME [4] is the suggested output format. 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 or IMT The operations listed here use the text/uri-list Internet Media Type (IMT)
[4] that is specified in Appendix A. Other system are strongly encouraged to [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 use this IMT. In the case where a system does not use an IMT, a
should be given. justification should be given.
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: 1st operand is a URI * Type of Each Operand: First operand is a URI.
* format of each operand: 1st operand is encoded as a URI * Format of Each Operand: First operand is encoded as a URI.
* algorithm: opaque * Algorithm: Opaque
* output: 1 and only one URL encoded in a text/uri-list * Output: One and only one URL encoded in a text/uri-list
* Errors Conditions: * Errors Conditions:
o No such URI o Malformed URI
o No URL to return 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: * Security Considerations:
o Malicious Redirection o Malicious Redirection
One of the fundamental dangers related to any service such as this One of the fundamental dangers related to any service such as this
is that a malicious entry in a resolver's database will cause is that a malicious entry in a resolver's database will cause
clients to resolve the URI into the wrong URL. The intent may be clients to resolve the URI into the wrong URL. The possible intent
to cause the client to retrieve a resource possibly containing may be to cause the client to retrieve a resource containing
fradulent or damaging material. fraudulent or damaging material.
o Denial of Service o Denial of Service
By removing the URL that the URI maps to, a malicious intruder may By removing the URL to which the URI maps, a malicious intruder
remove the clients ability to retrieve the resource. 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 This operation is used to map a single URI to a single URL. It is used by
light weight clients that do not have the ability to select from a list of light weight clients that do not have the ability to select from a list of
URLs or understand a Uniform Resource Characteristic (URC). The algorithm URLs or understand a URC. The algorithm for this mapping is dependent on the
for this mapping is dependent on the URI scheme. 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: 1st operand is a URI * Type of Each Operand: First operand is a URI.
* format of each operand: 1st 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 0 or more URLs encoded in a text/uri-list * Output: A list of zero or more URLs encoded in a text/uri-list
* Errors: * Errors:
o No such URI o Malformed URI
o No URLs to return 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: * 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 used by 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 is 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 important to the client. The client should not make any assumptions about
the order of the URLs returned. 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
No matter what the particular media type, the result MUST be a list of the of the resource identified by the URI. All URIs shall be encoded according
URLs that may be used to obtain an instance of the resource identified by to the URI specification [3].
the URI. All URIs shall be encoded according to the URI specification [6].
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: 1st operand is a URI * Type of Each Operand: First operand is a URI.
* format of each operand: 1st 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. Encoding is not * Output: An instance of the resource named by the URI. Encoding is not
specified. specified.
* Errors: * Errors:
o No such URI. o Malformed URI
o No resource available. 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: * 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 that is 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 named by the URI. The format of the output is dependent on the resource
itself. 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: 1st operand is a URI * Type of Each Operand: First operand is a URI.
* format of each operand: 1st operand is encoded as a URI * Format of Each Operand: First operand is encoded as a URI.
* algorithm: opaque * Algorithm: Opaque
* output: 0 or more instances of the resource named by the URI. Encoding * Output: Zero or more instances of the resource named by the URI.
is not specified. Encoding is not specified.
* Errors: * Errors:
o No such URI. o Malformed URI
o No resource available. 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: * 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, for 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 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. being "the same" resides with the naming authority that issued the URI.
The output shall be a MIME multipart/alternative [4] message with the The output shall be a MIME multipart/alternative [4] message with the
alternative versions of the resource in separate body parts. If there is 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 only one version of the resource identified by the URN, it MAY be returned
skipping to change at line 277 skipping to change at line 283
example, GIF and JPEG versions of an image. The judgment about the resources 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. being "the same" resides with the naming authority that issued the URI.
The output shall be a MIME multipart/alternative [4] message with the The output shall be a MIME multipart/alternative [4] message with the
alternative versions of the resource in separate body parts. If there is 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 only one version of the resource identified by the URN, it MAY be returned
without the multipart/alternative wrapper. 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 * Mnemonic: I2C
* number of operands: 1 * Number of Operands: 1
* type of each operand: 1st operand is a URI * Type of Each Operand: First operand is a URI.
* format of each operand: 1st operand is encoded as a URI * Format of Each Operand: First operand is encoded as a URI.
* algorithm: opaque * Algorithm: Opaque
* output: A Uniform Resource Characteristic. Encoding is not specified. * Output: A URC. Encoding is not specified.
* Errors: * Errors:
o No such URI. o Malformed URI
o URC not available. 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: * 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 (Uniform Resource Characteristics) are descriptions of other resources. Uniform Resource Characteristics are descriptions of resources. This request
This request allows the client to obtain a description of the resource allows the client to obtain a description of the resource identified by a
identified by a URI, as opposed to the resource itself or simply the URI, as opposed to the resource itself or simply the resource's URLs. The
resources URLs. The description might be a bibliographic citation, a digital description might be a bibliographic citation, a digital signature, or a
signature, a revision history, etc. This draft does not specify the content revision history. This draft does not specify the content of any response to
of any response to a URC request. That content is expected to vary from one a URC request. That content is expected to vary from one server to another.
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: 1st operand is a URI * Type of Each Operand: First operand is a URI.
* format of each operand: 1st operand is encoded as a URI * Format of Each Operand: First operand is encoded as a URI.
* algorithm: opaque * Algorithm: Opaque
* output: 0 or more Uniform Resource Characteristic. Encoding is not * Output: Zero or more URCs. Encoding is not specified.
specified.
* Errors: * Errors:
o No such URI. o Malformed URI
o URCs not available. 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: * 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 0 or URCs can come in different formats and types. This operation returns zero or
more URCs that are appropriate for the given URI. 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: 1st operand is a URN * Type of Each Operand: First operand is a URN.
* format of each operand: 1st operand is encoded as a URI * Format of Each Operand: First operand is encoded as a URI.
* algorithm: opaque * Algorithm: Opaque
* output: One URN encoded in a text/uri-list IMT. * Output: One URN encoded in a text/uri-list IMT.
* Errors: * Errors:
o No such URI. o Malformed URI
o No URN considered equivalent at this time. 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: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
While URNs are supposed to identify one and only one resource, that does not 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 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, resource that one organization wishes to name 'foo'; another organization,
in agreement with the first, wants to call the resource 'bar'. Both in agreement with the first, wants to call the resource 'bar'. Both
organizations can agree that both names 'name' the same resource and that organizations can agree that both names 'name' the same resource and that
the URNs 'foo' and 'bar' are equivalent. the URNs 'foo' and 'bar' are equivalent.
The result a URN, known to the server, which identifies the same resource as The result is a URN, known to the server, that identifies the same resource
the input URN. The result shall be encoded in a text/uri-list IMT. 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 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 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 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 the map as it weather map for a particular day and a URN pointing to the map as it changes
changes from day to day would NOT by returned in this example because they from day to day would NOT be returned in this example because they point to
point to do different resources. Some other concept of equality is at work. do different resources. Some other concept of equality is at work. This
This service instead deals with resources that have two different names service instead deals with resources that have two different names where the
where the binding between the names and resources is permanent. binding between the names and resources is permanent.
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: 1st operand is a URI * Type of Each Operand: First operand is a URI.
* format of each operand: 1st 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 encoded in a text/uri-list IMT. * Output: A list of URNs encoded in a text/uri-list IMT
* Errors: * Errors:
o No such URI. o Malformed URI
o No URNs considered equivalent at this time. 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: * 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 0 or more URNs following the same criteria and This operation simply returns zero or more URNs following the same criteria
cautions as the I2N operation. and cautions as the I2N operation.
4.9 I2I (URI to URI): 4.9 I2I (URI to URI):
* name: URI to URI * Name: URI to URI
* mnemonic: I2I * Mnemonic: I2I
* number of operands: 1 * Number of Operands: 1
* type of each operand: 1st operand is a URL * Type of Each Operand: First operand is a URI.
* format of each operand: 1st operand is encoded as a URI * Format of Each Operand: First operand is encoded as a URI.
* algorithm: opaque * Algorithm: Opaque
* output: A URI. * Output: A URI
* Errors: * Errors:
o No such URI. o Malformed URI
o No URIs considered equivalent at this time. 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: * 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 any arbitrary URI to any other arbitrary URI. This operation is used to map any arbitrary URI to any other arbitrary URI.
No other assertions are made about whether or not the URI exhibits No other assertions are made about whether or not the URI exhibits
characteristics of URNs or URLs. characteristics of URNs or URLs.
4.10 I=I (Is URI equal to URI): 4.10 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 No such URI. o Malformed URIs
o No URIs considered equivalent at this time. 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: * 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 considered to 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 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 determine equality is opaque. No assertions are made about whether or not
the URIs exhibits characteristics of URNs or URLs. the URIs exhibits characteristics of URNs or URLs.
6. The text/uri-list Internet Media Type 5. The text/uri-list Internet Media Type
[This section will be augmented or replaced by the registration of [This section will be augmented or replaced by the registration of
the text/uri-list IMT once that registration has been performed]. the text/uri-list IMT once that registration has been performed].
Several of the resolution service requests, such as I2Ls, I2Ns, result in a 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 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 Type is defined to provide a simple format for the automatic processing of
such lists of URIs. such lists of URIs.
The format of text/uri-list resources is: The format of text/uri-list resources is as follows.
1. Any lines beginning with the '#' character are comment lines and are 1. Any lines beginning with the '#' character are comment lines and are
ignored during processing. (Note that '#' is a character that may ignored during processing. (Note that '#' is a character that may
appear in URIs, so it only denotes a comment when it is the first appear in URIs, so it only denotes a comment when it is the first
character on a line). character on a line.)
2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded 2. The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
according to the URI specification RFC[6]. Each URI shall appear on one according to the URI specification RFC[3]. Each URI shall appear on one
and only one line. and only one line.
3. As for all text/* formats, lines are terminated with a CR LF pair, 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 although clients should be liberal in accepting lines with only one of
those characters. those characters.
4. The order of the URIs given MUST be preserved upon retransmission. The 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 client should not make any inferences about what the order of the
returned list means. returned list means.
In applications where one URI has been mapped to a list of URIs, such as in 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 response to the I2Ls request, the first line of the text/uri-list response
SHOULD be a comment giving the original URI. SHOULD be a comment giving the original URI. An example of such a result for
the I2L request is shown below in Figure 1.
An example of such a result for the I2L request is shown below in figure 1. ------------------------------------------
--------------------------------------------------
# urn:cid:foo@huh.org # urn:cid:foo@huh.org
http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.html
http://www.huh.org/cid/foo.pdf http://www.huh.org/cid/foo.pdf
ftp://ftp.foo.org/cid/foo.txt ftp://ftp.foo.org/cid/foo.txt
Figure 1: Example of the text/uri-list format 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 7. References
[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource [1] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt, Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
February, 1997. February, 1997.
[2] R. Moats, "URN Syntax", RFC2141, Jan. 1997. [2] R. Moats, "URN Syntax", RFC2141, January, 1997.
[3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying
the Expression of Names and Addresses of Objects on the Network as Syntax for the Expression of Names and Addresses of Objects on the Network
used in the World-Wide Web", T. Berners-Lee, June 1994. as Used in the World-Wide Web", RFC 1630, June, 1994.
[4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One: [4] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail
Mechanisms for Specifying and Describing the Format of Internet Message Extensions) Part One: Mechanisms for Specifying and Describing the Format
Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft, of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993.
September 1993.
8. Security Considerations [5] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a Framework
for URN Resolution Systems", MIT/LCS, June, 1997.
Communications with a server may be of a sensitive nature. Some servers will [Note to RFC Editor: Please change reference 5 to point to the correct RFC
hold information that should only be released to authorized users. The number for the draft]
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 which pay
royalties to rights-holders. Server requests may be of interest to traffic
analysts. The requests may also be subject to spoofing.
9. Author Contact Information [6] Kunze, J., "Functional Recommendations for Internet Resource Locators",
RFC1736, IS&T, UC Berkeley, February, 1995.
Michael Mealling [7] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform Resource
Network Solutions Locators (URL)", RFC1738, December, 1994.
505 Huntmar Park Drive
Herndon, VA 22070
voice: (703)742-0400
fax: (703)742-9552
email: michaelm@rwhois.net
Ron Daniel [8] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
Advanced Computing Lab, MS B287 Identifiers Using the Domain Name System", RFC2168, June, 1997.
Los Alamos National Laboratory
Los Alamos, NM, USA, 87545 8. Author Contact Information
voice: +1 505 665 0597
fax: +1 505 665 4939 Michael Mealling Ron Daniel
email: rdaniel@lanl.gov 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
 End of changes. 79 change blocks. 
261 lines changed or deleted 285 lines changed or added

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