draft-ietf-urn-resolution-services-02.txt   draft-ietf-urn-resolution-services-03.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 July 1997 Ron Daniel Jr. Expires six months from Sept 1997 Ron Daniel Jr.
Intended category: Experimental Los Alamos National Laboratory Intended category: Experimental Los Alamos National Laboratory
draft-ietf-urn-resolution-services-02.txt draft-ietf-urn-resolution-services-03.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 documents
of the Internet Engineering Task Force (IETF), its areas, and its working of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 54 skipping to change at line 53
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 [2], it
became apparent that requiring servers to deal with all desired functions or became apparent that requiring servers to deal with all desired functions or
requiring clients to deal with complicated information returned by a server requiring clients to deal with complicated information returned by a server
was unrealistic and a barrier to adoption. There needed to be some way for a was unrealistic and a barrier to adoption. There needed to be some way for a
client to be able to pick between a server that specialized in the complex client to be able to pick between a server that specialized in the complex
and another that specialized in the simple (but fast). Also, in subsequent and another that specialized in the simple (but fast). Also, in subsequent
conversations it became obvious that, in most cases, some of the operations conversations it became obvious that, in most cases, some of the operations
were inappropriate or difficult for certain identifiers. For example, ISSNs were inappropriate or difficult for certain identifiers.
identify books or magazines that are serial in nature. An operation to
return the resource for an ISSN pointing to "Time" magazine would result in
dumping hundreds of thousands of pages of "Time" onto a user's machine. This
does not seem like a reasonable thing to do in the normal case.
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 are a
variety of possible functions that may be important or useful, such as variety of possible functions that may be important or useful, such as
discovery of locators, names, descriptions, and accessing the resource discovery of locators, names, descriptions, and accessing the resource
itself. A given service may support only a subset of these; hence, it is 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 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 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 framework for an RDS described in [5] the RDS itself may provide URLs [6][7],
[6][7], while the resolvers may provide descriptions, URLs, or even the while the resolvers may provide descriptions, URLs, or even the resources
resources themselves. The design of an RDS, as proposed in RFC 2168 [8], may themselves. The design of an RDS, as proposed in RFC 2168 [8], may be more
be more generous and provide all of the above. 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 an exhaustive set would both be impossible and not those operations. But an exhaustive set would both be impossible and not
very necessary. Thus, this document will list several operations as well as very necessary. Thus, this document will list several operations as well as
lay out requirements for specifying new operations. 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 and short
names for them and use them in defining the interface to an access service. names for them and use them in defining the interface to an access service.
Previous versions of this document referred to services where the arguments Previous versions of this document referred to services where the arguments
were specific types of URIs such as URNs or URLs. These services were called were specific types of URIs such as URNs or URLs. These services were called
skipping to change at line 99 skipping to change at line 94
algorithm, and errors was sufficient to meet the requirements. 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 and for
new ones to be written by others, the requirements below are placed on any new ones to be written by others, the requirements below are placed on any
documents that seek to specify new operations. Any specification of a member 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 of this set of operations MUST contain at least the following pieces of
information with respect to its operands, its algorithm, output, and errors. information with respect to its operands, its algorithm, output, and errors.
At this stage it is unclear whether or not the registration of these
operations is required. In the future if it becomes apparent that these
functions are widely used and extended then some registration scheme will
need to be developed.
2.1 Operands 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
* 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 be
specified that the 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
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
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 and
application environments must be included. Errors that depend on the system application environments must be included. Errors that depend on the system
conveying the service are not included. Thus, many of the expected errors conveying the service are not included. Thus, many of the expected errors
such as syntax errors or service availability are not included in this such as service availability or operation syntax are not included in this
document since they are implementation dependent. 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 protocol
used to convey the service or to those that normally accompany the results used to convey the service or to those that normally accompany the results
of the service. For example, an I2L service would need to discuss the of the service. For example, an I2L service would need to discuss the
situation where someone maliciously inserts an incorrect URL into the situation where someone maliciously inserts an incorrect URL into the
resolver but NOT the case where someone sends personal information across resolver but NOT the case where someone sends personal information across
the Internet to the 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. It is sufficient for those protocols to define new operations
within their own protocol specification documents but care should be taken
to make this fact well known.
Also, a given system or protocol will have its own output formats that will 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. Conversely, 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. 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 system
are as follows: 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 format.
skipping to change at line 261 skipping to change at line 264
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. 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 operation.
o URI existed in the past but nothing is currently known about it. 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)
skipping to change at line 363 skipping to change at line 366
the URNs 'foo' and 'bar' are equivalent. 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 resource
as 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 map as it changes weather map for a particular day and a URN pointing to the map as it changes
from day to day would NOT be returned in this example because they point to from day to day would NOT be returned in this example because they point to
do different resources. Some other concept of equality is at work. This do different resources. Some other concept of temporary equivalence is at
service instead deals with resources that have two different names where the work. This service instead deals with resources that have two different
binding between the names and resources is permanent. 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 encoded in a text/uri-list IMT * Output: A list of URNs encoded in a text/uri-list IMT
skipping to change at line 389 skipping to change at line 394
o URI exists but there is no available output from this operation. 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 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 criteria
and cautions as the I2N operation. and cautions as the I2N operation.
4.9 I2I (URI to URI): 4.9 I=I (Is URI equal to URI):
* Name: URI to URI
* Mnemonic: I2I
* Number of Operands: 1
* Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque
* Output: A URI
* Errors:
o Malformed URI
o URI is syntactically valid but does not exist in any form.
o URI exists but there is no available output from this operation.
o URI existed in the past but nothing is currently known about it.
o Access denied
* Security Considerations:
o Malicious Redirection (see I2L)
o Denial of Service (see I2L)
This operation is used to map any arbitrary URI to any other arbitrary URI.
No other assertions are made about whether or not the URI exhibits
characteristics of URNs or URLs.
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 Malformed URIs o Malformed URIs
skipping to change at line 439 skipping to change at line 421
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.
5. 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 The text/uri-list Internet Media Type has been registered with the IANA
the text/uri-list IMT once that registration has been performed]. as a general purpose way to transport lists of URIs. Several of the
resolution service requests, such as I2Ls, I2Ns, result in just such a
Several of the resolution service requests, such as I2Ls, I2Ns, result in a list being returned to the client.
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 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[3]. 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.
 End of changes. 16 change blocks. 
52 lines changed or deleted 31 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/