draft-ietf-urn-resolution-services-03.txt   draft-ietf-urn-resolution-services-04.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 Sept 1997 Ron Daniel Jr. Expires six months from November 1997 Ron Daniel Jr.
Intended category: Experimental Los Alamos National Laboratory Intended category: Experimental Los Alamos National Laboratory
draft-ietf-urn-resolution-services-03.txt draft-ietf-urn-resolution-services-04.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 documents This document is an Internet-Draft. Internet-Drafts are working
of the Internet Engineering Task Force (IETF), its areas, and its working documents of the Internet Engineering Task Force (IETF), its areas,
groups. Note that other groups may also distribute working documents as and its working groups. Note that other groups may also distribute
Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six months
may be updated, replaced, or obsoleted by other documents at any time. It and may be updated, replaced, or obsoleted by other documents at
is inappropriate to use Internet-Drafts as reference material or to cite them any time. It is inappropriate to use Internet-Drafts as reference
other than as work in progress. material or to cite them other than as work in progress.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
(US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract Abstract
Retrieving the resource identified by a Uniform Resource Identifier (URI) Retrieving the resource identified by a Uniform Resource Identifier
[3] is only one of the operations that can be performed on a URI. One might (URI) [3] is only one of the operations that can be performed on a URI.
also ask for and get a list of other identifiers that are aliases for the One might also ask for and get a list of other identifiers that are
original URI or a bibliographic description of the resource the URI denotes, aliases for the original URI or a bibliographic description of the
for example. This applies to both Uniform Resource Names (URNs) and Uniform resource the URI denotes, for example. This applies to both Uniform
Resource Locators (URLs). Uniform Resource Characteristics (URCs) are Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform
discussed in this document but only as descriptions of resources rather than Resource Characteristics (URCs) are discussed in this document but only
identifiers. as descriptions of resources rather than identifiers.
A service in the network providing access to a resource may provide one or A service in the network providing access to a resource may provide
some of these options, but it need not provide all of them. This memo one or some of these options, but it need not provide all of them. This
specifies an initial set of these functions, to be used to describe the memo specifies an initial set of these functions, to be used to
functions provided by any given access service and the requirements that describe the functions provided by any given access service and the
must be met when those operations are encoded in a protocol. 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 URNs [2], it In the course of formulating current proposals [1] regarding URNs
became apparent that requiring servers to deal with all desired functions or [2], it became apparent that requiring servers to deal with all desired
requiring clients to deal with complicated information returned by a server functions or requiring clients to deal with complicated information
was unrealistic and a barrier to adoption. There needed to be some way for a returned by a server was unrealistic and a barrier to adoption. There
client to be able to pick between a server that specialized in the complex needed to be some way for a client to be able to pick between a server
and another that specialized in the simple (but fast). Also, in subsequent that specialized in the complex and another that specialized in the
conversations it became obvious that, in most cases, some of the operations simple (but fast). Also, in subsequent conversations it became obvious
were inappropriate or difficult for certain identifiers. that, in most cases, some of the operations were inappropriate or
difficult for certain identifiers.
The Problem The Problem
In the process of learning about a resource in the Internet, there are a In the process of learning about a resource in the Internet, there
variety of possible functions that may be important or useful, such as are a variety of possible functions that may be important or useful,
discovery of locators, names, descriptions, and accessing the resource such as discovery of locators, names, descriptions, and accessing the
itself. A given service may support only a subset of these; hence, it is resource itself. A given service may support only a subset of these;
important to describe such an access service by the types of functions it hence, it is important to describe such an access service by the types
supports, those resources about which it knows anything. For example, in the of functions it supports, those resources about which it knows
framework for an RDS described in [5] the RDS itself may provide URLs [6][7], anything. For example, in the framework for an RDS described in [5] the
while the resolvers may provide descriptions, URLs, or even the resources RDS itself may provide URLs [6][7], while the resolvers may provide
themselves. The design of an RDS, as proposed in RFC 2168 [8], may be more descriptions, URLs, or even the resources themselves. The design of an
generous and provide all of the above. 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 This problem requires some well understood set of identifiers that
those operations. But an exhaustive set would both be impossible and not identify those operations. But an exhaustive set would both be
very necessary. Thus, this document will list several operations as well as impossible and not very necessary. Thus, this document will list
lay out requirements for specifying new operations. 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 The purpose of this document is to define a list of such functions
names for them and use them in defining the interface to an access service. and short names for them and use them in defining the interface to an
Previous versions of this document referred to services where the arguments access service. Previous versions of this document referred to services
were specific types of URIs such as URNs or URLs. These services were called where the arguments were specific types of URIs such as URNs or URLs.
"N2L" and "L2L",for example. Their use has been changed in favor of the more These services were called "N2L" and "L2L",for example. Their use has
general URI form. 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
need to identify the operation with some token and know its operands, simple. The need to identify the operation with some token and know its
algorithm, and errors was sufficient to meet the requirements. operands, algorithm, and errors was sufficient to meet the
requirements.
2. General Specification 2. General Specification
To provide a framework both for the specifications in this document and for To provide a framework both for the specifications in this document
new ones to be written by others, the requirements below are placed on any and for new ones to be written by others, the requirements below are
documents that seek to specify new operations. Any specification of a member placed on any documents that seek to specify new operations. Any
of this set of operations MUST contain at least the following pieces of 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.
At this stage it is unclear whether or not the registration of these At this stage it is unclear whether or not the registration of these
operations is required. In the future if it becomes apparent that these operations is required. In the future if it becomes apparent that these
functions are widely used and extended then some registration scheme will functions are widely used and extended then some registration scheme
need to be developed. will need to be developed.
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.
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 be specified, or it must be The exact algorithm for the operation must be specified, or it must
specified that the algorithm is opaque and defined by the server. be specified that the algorithm is opaque and defined by the server.
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 type and format * the fact that the output is an object and the object's
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 and All errors that are considered applicable across all implementations
application environments must be included. Errors that depend on the system and application environments must be included. Errors that depend on
conveying the service are not included. Thus, many of the expected errors the system conveying the service are not included. Thus, many of the
such as service availability or operation syntax are not included in this expected errors such as service availability or operation syntax are
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 protocol specified. This does NOT include considerations dealing with the
used to convey the service or to those that normally accompany the results protocol used to convey the service or to those that normally accompany
of the service. For example, an I2L service would need to discuss the the results of the service. For example, an I2L service would need to
situation where someone maliciously inserts an incorrect URL into the discuss the situation where someone maliciously inserts an incorrect
resolver but NOT the case where someone sends personal information across URL into the resolver but NOT the case where someone sends personal
the Internet to the resource identified by the correct URL. information across 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
on which operations make sense and how those that do are syntactically restrictions on which operations make sense and how those that do are
represented. It is sufficient for those protocols to define new operations syntactically represented. It is sufficient for those protocols to
within their own protocol specification documents but care should be taken define new operations within their own protocol specification
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 formats that will Also, a given system or protocol will have its own output formats
restrict the output formats of a given operation. Conversely, a given that will restrict the output formats of a given operation.
protocol may have better solution for output than the ones given here. For Additionally, a given protocol may have better solution for output
example, the I2L result may be encoded in a protocol-specific manner that than the ones given here. For example, the I2L result may be
conveys information about the closeness of each resource on the network. 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 Thus, the requirements on encoding these operations within a given
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
For those systems that can use it, MIME [4] is the suggested output format. For those systems that can use it, MIME [4] is the suggested output
The operations listed here use the text/uri-list Internet Media Type (IMT) format. The operations listed here use the text/uri-list Internet Media
[4] that is specified in Section 6. Other systems are strongly encouraged to Type (IMT) [4] that is specified in Section 6. Other systems are
use this IMT. In the case where a system does not use an IMT, a strongly encouraged to use this IMT. In the case where a system does
justification should be given. not use an IMT, a 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: 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 encoded in a text/uri-list * Output: One and only one URL encoded in a text/uri-list
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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 this One of the fundamental dangers related to any service such as
is that a malicious entry in a resolver's database will cause this is that a malicious entry in a resolver's database will
clients to resolve the URI into the wrong URL. The possible intent cause clients to resolve the URI into the wrong URL. The
may be to cause the client to retrieve a resource containing possible intent may be to cause the client to retrieve a
fraudulent or damaging material. 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 intruder By removing the URL to which the URI maps, a malicious
may remove the client's ability to retrieve the resource. intruder may remove the client's ability to retrieve the
resource.
This operation is used to map a single URI to a single URL. It is used by This operation is used to map a single URI to a single URL. It is
lightweight clients that do not have the ability to select from a list of used by lightweight clients that do not have the ability to select from
URLs or understand a URC. The algorithm for this mapping is dependent on the a list of URLs or understand a URC. The algorithm for this mapping is
URI scheme. 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 encoded in a text/uri-list * Output: A list of zero or more URLs encoded in a text/uri-list
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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 used by This operation is used to map a single URI to 0 or more URLs. It is
a client that can pick from a list of URLs based on some criteria that are used by a client that can pick from a list of URLs based on some
important to the client. The client should not make any assumptions about criteria that are important to the client. The client should not make
the order of the URLs returned. No matter what the particular media type, any assumptions about the order of the URLs returned. No matter what
the result MUST be a list of the URLs that may be used to obtain an instance the particular media type, the result MUST be a list of the URLs that
of the resource identified by the URI. All URIs shall be encoded according may be used to obtain an instance of the resource identified by the
to the URI specification [3]. URI. All URIs shall be encoded according to the URI specification [3].
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. Encoding is not * Output: An instance of the resource named by the URI. Encoding is
specified. not specified.
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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 that is This operation is used to return a single instance of the resource
named by the URI. The format of the output is dependent on the resource that is named by the URI. The format of the output is dependent on the
itself. 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.
Encoding is not specified but MIME multipart/alternative is encouraged. Encoding is not specified but MIME multipart/alternative is
encouraged.
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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, for This operation is used to return multiple instances of a resource,
example, GIF and JPEG versions of an image. The judgment about the resources for example, GIF and JPEG versions of an image. The judgment about the
being "the same" resides with the naming authority that issued the URI. 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 The output shall be a MIME multipart/alternative [4] message with
alternative versions of the resource in separate body parts. If there is the alternative versions of the resource in separate body parts. If
only one version of the resource identified by the URN, it MAY be returned there is only one version of the resource identified by the URN, it MAY
without the multipart/alternative wrapper. be 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 * Mnemonic: I2C
* 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 URC. Encoding is not specified. * Output: A URC. Encoding is not specified.
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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)
Uniform Resource Characteristics are descriptions of resources. This request Uniform Resource Characteristics are descriptions of resources. This
allows the client to obtain a description of the resource identified by a request allows the client to obtain a description of the resource
URI, as opposed to the resource itself or simply the resource's URLs. The identified by a URI, as opposed to the resource itself or simply the
description might be a bibliographic citation, a digital signature, or a resource's URLs. The description might be a bibliographic citation, a
revision history. This draft does not specify the content of any response to digital signature, or a revision history. This draft does not specify
a URC request. That content is expected to vary from one server to another. 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) 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. Encoding is not specified. * Output: Zero or more URCs. Encoding is not specified.
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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 zero or URCs can come in different formats and types. This operation returns
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 URN encoded in a text/uri-list IMT. * Output: One URN encoded in a text/uri-list IMT.
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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)
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
mean that a resource may have one and only one URN. For example, consider a does not mean that a resource may have one and only one URN. For
resource that one organization wishes to name 'foo'; another organization, example, consider a resource that one organization wishes to name
in agreement with the first, wants to call the resource 'bar'. Both 'foo'; another organization, in agreement with the first, wants to call
organizations can agree that both names 'name' the same resource and that the resource 'bar'. Both organizations can agree that both names 'name'
the URNs 'foo' and 'bar' are equivalent. 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 The result is a URN, known to the server, that identifies the same
as the input URN. The result shall be encoded in a text/uri-list IMT. resource as the input URN. The result shall be encoded in a
text/uri-list IMT.
Extreme care should be taken with this service as it toys with the idea of Extreme care should be taken with this service as it toys with the
equality with respect to URNs. As mentioned in several URN documents, the idea of equality with respect to URNs. As mentioned in several URN
idea of equality is very domain specific. For example, a URN pointing to a documents, the idea of equality is very domain specific. For example,
weather map for a particular day and a URN pointing to the map as it changes a URN pointing to a weather map for a particular day and a URN pointing
from day to day would NOT be returned in this example because they point to to the map as it changes from day to day would NOT be returned in this
do different resources. Some other concept of temporary equivalence is at example because they point to do different resources. Some other concept
work. This service instead deals with resources that have two different of temporary equivalence is at work. This service instead deals with
names where there is a binding between the names that is agreed by both name resources that have two different names where there is a binding
assigners. I.e., both namespaces must have agreed that the each name can be between the names that is agreed by both name assigners. I.e., both
used in place of the other and the meaning does not change. 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 encoded in a text/uri-list IMT * Output: A list of URNs encoded in a text/uri-list IMT
* 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 operation. o URI exists but there is no available output from this
o URI existed in the past but nothing is currently known about it. operation.
o URI existed in the past but nothing is currently known
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 criteria This operation simply returns zero or more URNs following the same
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 operation. o URIs exist but there is no available output from this
o URIs existed in the past but nothing is currently known about operation.
them. o URIs existed in the past but nothing is currently known
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 considered to This operation is used to determine whether two given URIs are
be equal by the server being asked the question. The algorithm used to considered to be equal by the server being asked the question. The
determine equality is opaque. No assertions are made about whether or not algorithm used to determine equality is opaque. No assertions are made
the URIs exhibits characteristics of URNs or URLs. 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
The text/uri-list Internet Media Type has been registered with the IANA [This section will be augmented or replaced by the registration of
as a general purpose way to transport lists of URIs. Several of the the text/uri-list IMT once that registration has been performed].
resolution service requests, such as I2Ls, I2Ns, result in just such a
list being returned to the client. 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. 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
ignored during processing. (Note that '#' is a character that may are ignored during processing. (Note that '#' is a character that
appear in URIs, so it only denotes a comment when it is the first may appear in URIs, so it only denotes a comment when it is the
character on a line.) first 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),
according to the URI specification RFC[3]. Each URI shall appear on one encoded according to the URI specification RFC[3]. Each URI shall
and only one line. appear on one 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
those characters. one of 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.
client should not make any inferences about what the order of the The client should not make any inferences about what the order of
returned list means. the 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,
response to the I2Ls request, the first line of the text/uri-list response such as in response to the I2Ls request, the first line of the
SHOULD be a comment giving the original URI. An example of such a result for text/uri-list response SHOULD be a comment giving the original URI. An
the I2L request is shown below in Figure 1. 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 6. Security Considerations
Communications with a server may be of a sensitive nature. Some servers will Communications with a server may be of a sensitive nature. Some
hold information that should only be released to authorized users. The servers will hold information that should only be released to
results from servers may be the target of spoofing, especially once authorized users. The results from servers may be the target of
electronic commerce transactions are common and there is money to be made by spoofing, especially once electronic commerce transactions are common
directing users to pirate repositories rather than repositories that pay and there is money to be made by directing users to pirate repositories
royalties to rights-holders. Server requests may be of interest to traffic rather than repositories that pay royalties to rights-holders. Server
analysts. The requests may also be subject to spoofing. 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 The "Access denied" error message assumes a system within which the
operation is being performed that can convey an authenticated concept of operation is being performed that can convey an authenticated concept
access control. Thus, the "Access denied" message should only be returned by of access control. Thus, the "Access denied" message should only be
systems that have an appropriate method of determining access control. returned by systems that have an appropriate method of determining
access control.
7. References 7. References
[1] Daniel, R., and Mealling, M., "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", RFC2168, February, 1997.
February, 1997.
[2] R. Moats, "URN Syntax", RFC2141, January, 1997. [2] R. Moats, "URN Syntax", RFC2141, January, 1997.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying
Syntax for the Expression of Names and Addresses of Objects on the Network Syntax for the Expression of Names and Addresses of Objects on the
as Used in the World-Wide Web", RFC 1630, June, 1994. Network as Used in the World-Wide Web", RFC 1630, June, 1994.
[4] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail [4] Borenstein, N. and Freed, N., "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the Format Extensions) Part One: Mechanisms for Specifying and Describing the
of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993. 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 reference 5 to point to the correct RFC
number for the draft]
[6] Kunze, J., "Functional Recommendations for Internet Resource Locators", [5] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a
RFC1736, IS&T, UC Berkeley, February, 1995. 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]
[7] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform Resource [6] Kunze, J., "Functional Recommendations for Internet Resource
Locators (URL)", RFC1738, December, 1994. Locators", RFC1736, IS&T, UC Berkeley, February, 1995.
[8] Daniel, R., and Mealling, M., "Resolution of Uniform Resource [7] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform
Identifiers Using the Domain Name System", RFC2168, June, 1997. Resource Locators (URL)", RFC1738, December, 1994.
8. Author Contact Information 8. Author Contact Information
Michael Mealling Ron Daniel Michael Mealling Ron Daniel
Network Solutions Advanced Computing Lab, MS B287 Network Solutions Advanced Computing Lab, MS B287
505 Huntmar Park Drive Los Alamos National Laboratory 505 Huntmar Park Drive Los Alamos National Laboratory
Herndon, VA 22070 Los Alamos, NM, USA, 87545 Herndon, VA 22070 Los Alamos, NM, USA, 87545
voice: (703) 742-0400 voice: (505) 665-0597 voice: (703) 742-0400 voice: (505) 665-0597
fax: (703) 742-9552 fax: (505) 665-4939 fax: (703) 742-9552 fax: (505) 665-4939
email: michaelm@rwhois.net email: rdaniel@lanl.gov email: michaelm@rwhois.net email: rdaniel@lanl.gov
This document expires 6 months from November, 1997
 End of changes. 63 change blocks. 
226 lines changed or deleted 264 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/