draft-ietf-urn-resolution-services-05.txt   draft-ietf-urn-resolution-services-06.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 March 1998 Ron Daniel Jr. Expires six months from March 1998 Ron Daniel Jr.
Intended category: Experimental Los Alamos National Laboratory Intended category: Experimental Los Alamos National Laboratory
draft-ietf-urn-resolution-services-05.txt draft-ietf-urn-resolution-services-06.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 of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
material or to cite them 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 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (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 Retrieving the resource identified by a Uniform Resource Identifier
(URI) [3] is only one of the operations that can be performed on a URI. (URI) [1] is only one of the operations that can be performed on a URI.
One might also ask for and get a list of other identifiers that are One might also ask for and get a list of other identifiers that are
aliases for the original URI or a bibliographic description of the aliases for the original URI or a bibliographic description of the
resource the URI denotes, for example. This applies to both Uniform resource the URI denotes, for example. This applies to both Uniform
Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform
Resource Characteristics (URCs) are discussed in this document but only Resource Characteristics (URCs) are discussed in this document but only
as descriptions of resources rather than identifiers. as descriptions of resources rather than identifiers.
A service in the network providing access to a resource may provide A service in the network providing access to a resource may provide
one or some of these options, but it need not provide all of them. This one or some of these options, but it need not provide all of them. This
memo specifies an initial set of these functions, to be used to memo specifies an initial set of these operations that can be used to
describe the functions provided by any given access service and the describe the interactions provided by a given access service. It also
requirements that must be met when those operations are encoded in a suggests guidelines that should be adhered to when those operations
protocol. are encoded in a protocol.
1. Introduction 1. Introduction
In the course of formulating current proposals [1] regarding URNs In the course of formulating current proposals [2] regarding URNs
[2], it became apparent that requiring servers to deal with all desired [3], it became apparent that requiring servers to manage all of the desired
functions or requiring clients to deal with complicated information functions or requiring clients to process varied information
returned by a server was unrealistic and a barrier to adoption. There returned by a server was unrealistic and a barrier to adoption. There
needed to be some way for a client to be able to pick between a server needed to be some way for a client to be able to identify a server
that specialized in the complex and another that specialized in the that specialized in the complex and another that specialized in the
simple (but fast). Also, in subsequent conversations it became obvious simple (but fast). Also, in subsequent conversations it became obvious
that, in most cases, some of the operations were inappropriate or that, in most cases, some of the operations were inappropriate or
difficult for certain identifiers. difficult for certain identifiers.
The Problem The Problem
In the process of learning about a resource in the Internet, there In the process of learning about a resource in the Internet, there
are a variety of possible functions that may be important or useful, are a variety of possible functions that may be important and/or useful,
such as discovery of locators, names, descriptions, and accessing the such as discovery of locators, names, descriptions, and accessing the
resource itself. A given service may support only a subset of these; resource itself. A given service may support only a subset of these;
hence, it is important to describe such an access service by the types hence, it is important to describe such an access service by the types
of functions it supports, those resources about which it knows of functions supported and the resources of which it has some knowledge.
anything. For example, in the framework for an RDS described in [5] the For example, in the framework for an RDS described in [5] the
RDS itself may provide URLs [6][7], while the resolvers may provide RDS itself may provide URLs [6][7], while the resolvers may provide
descriptions, URLs, or even the resources themselves. The design of an descriptions, URLs, or even the resources themselves. The design of an
RDS, as proposed in RFC 2168 [1], may be more generous and provide all RDS, as proposed in RFC 2168 [2], may be more generous and provide all
of the above. of the above.
This problem requires some well understood set of identifiers that This problem requires some well understood set of identifiers that
identify those operations. But an exhaustive set would both be specify those operations. But an exhaustive set would both be
impossible and not very necessary. Thus, this document will list impossible and not very necessary. Thus, this document will list
several operations as well as lay out requirements for specifying new several operations, as well as, lay out requirements for specifying new
operations. operations.
The purpose of this document is to define a list of such functions The purpose of this document is to define a list of such functions
and short names for them and use them in defining the interface to an and short names for them and then use them in defining the interface to an
access service. Previous versions of this document referred to services access service. Previous versions of this document referred to services
where the arguments were specific types of URIs such as URNs or URLs. where the arguments were specific types of URIs such as URNs or URLs.
These services were called "N2L" and "L2L",for example. Their use has These services were called "N2L" and "L2L",for example. Their use has
been changed in favor of the more 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 To meet these requirements a fairly simple design criteria
simple. The need to identify the operation with some token and know its was used. The need to identify the operation with some token such that its
operands, algorithm, and errors was sufficient to meet the operands, algorithm, and errors were known proved sufficient to meet these
requirements. requirements.
2. General Specification 2. General Specification
To provide a framework both for the specifications in this document To provide a framework both for the specifications in this document
and for future work to be written by others, the guidelines below are and for future work to be written by others, the guidelines below are
suggested for documents that seek to specify new operations. Any suggested for documents that seek to specify new operations. Any specification
specification of a member of this set of operations should address of a member of this set of operations should address these issues with respect
these issues with respect to its operands, its algorithm, output, and errors. to its operands, algorithm, output, and errors.
Due to the small number of listed functions, a registration mechanism Due to the small number of listed functions, a registration mechanism
was dismissed as premature. If this list grows, a registration mechanism was dismissed as premature. If this list grows, a registration mechanism
will probably be needed. will probably be needed.
Also, due to the experimental nature of this document and the systems Also, due to the experimental nature of this document and the systems
that use its specifications, the use of words like MUST and SHALL are that use its specifications, the use of words like MUST and SHALL are
limited. Where used they reflect a case where this specification could limited. Where used they reflect a case where this specification could
cause harm to existing, non-experimental systems such as HTTP and URNs. cause harm to existing, non-experimental systems such as HTTP and URNs.
Thus, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Thus, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 The exact algorithm for the operation must either be specified completely
be specified that the algorithm is opaque and defined by the server. or it must be considered opaque and defined by the server or application.
2.3 Output 2.3 Output
Output must specify one of the following: Output must specify one of the following:
* there is no output * there is no output
* the output is undefined * the output is undefined
* the output itself and its content * the output itself and its content
* the fact that the output is an object and the object's * the fact that the output is an object and the object's
type and format type and format
skipping to change at page 3, line 44 skipping to change at page 3, line 44
and application environments must be included. Errors that depend on and application environments must be included. Errors that depend on
the system conveying the service are not included. Thus, many of the the system conveying the service are not included. Thus, many of the
expected errors such as service availability or operation syntax are expected errors such as service availability or operation syntax are
not included in this document since they are implementation dependent. not included in this document since they are implementation dependent.
2.5 Security Considerations 2.5 Security Considerations
Any security considerations relating to the service provided must be Any security considerations relating to the service provided must be
specified. This does NOT include considerations dealing with the specified. This does NOT include considerations dealing with the
protocol used to convey the service or to those that normally accompany protocol used to convey the service or to those that normally accompany
the results of the service. For example, an I2L service would need to the results of the service. For example, a service that returned a single
discuss the situation where someone maliciously inserts an incorrect URL would need to discuss the situation where someone maliciously inserts
URL into the resolver but NOT the case where someone sends personal an incorrect URL into the resolver but NOT the case where someone sends
information across the Internet to the resource identified by the personal information across the Internet to the resource identified by the
correct URL. correct URL.
3. Encoding The Operations 3. Encoding The Operations
To be useful, these operations have to be used within some system or To be useful, these operations have to be used within some system or
protocol. In many cases, these systems and protocols will place protocol. In many cases, these systems and protocols will place
restrictions on which operations make sense and how those that do are restrictions on which operations make sense and how those that do are
syntactically represented. It is sufficient for those protocols to syntactically represented. It is sufficient for those protocols to
define new operations within their own protocol specification define new operations within their own protocol specification
documents but care should be taken to make this fact well known. documents but care should be taken to make this fact well known.
Also, a given system or protocol will have its own output specifications Also, a given system or protocol will have its own output specifications
that may restrict the output formats of a given operation. that may restrict the output formats of a given operation.
Additionally, a given protocol may have better solution for output Additionally, a given protocol may have better solution for output
than the ones given here. For example, the I2L result may be than the ones given here. For example, the result of an operation that
encoded in a protocol-specific manner that conveys information about converts a URI to more than one URL may be encoded in a protocol-
the closeness of each resource on the network. specific manner that conveys information about the closeness of each
resource on the network.
Thus, the requirements on encoding these operations within a given Thus, the requirements on encoding these operations within a given
system are as follows: system are as follows:
* which subset of the operations are allowed * which subset of the operations are allowed
* how the operator is encoded * how the operator is encoded
* how the operands are encoded * how the operands are encoded
* how the error codes are returned * how the error codes are returned
The text/uri-list MIME Media Type is specified in Section 5. This Media Type The text/uri-list MIME Media Type is specified in Section 5. This Media Type
skipping to change at page 5, line 37 skipping to change at page 5, line 37
* Security Considerations: * Security Considerations:
o Malicious Redirection (see I2L) o Malicious Redirection (see I2L)
o Denial of Service (see I2L) o Denial of Service (see I2L)
This operation is used to map a single URI to 0 or more URLs. It is This operation is used to map a single URI to 0 or more URLs. It is
used by a client that can pick from a list of URLs based on some used by a client that can pick from a list of URLs based on some
criteria that are important to the client. The client should not make criteria that are important to the client. The client should not make
any assumptions about the order of the URLs returned. No matter what any assumptions about the order of the URLs returned. No matter what
the particular media type, the result should be a list of the URLs that the particular media type, the result should be a list of the URLs that
may be used to obtain an instance of the resource identified by the may be used to obtain an instance of the resource identified by the
URI. All URIs shall be encoded according to the URI specification [3]. URI. All URIs shall be encoded according to the URL [7] and URN [3]
specifications.
4.3 I2R (URI to Resource) 4.3 I2R (URI to Resource)
* Name: URI to Resource * Name: URI to Resource
* Mnemonic: I2R * Mnemonic: I2R
* Number of Operands: 1 * Number of Operands: 1
* Type of Each Operand: First operand is a URI. * Type of Each Operand: First operand is a URI.
* Format of Each Operand: First operand is encoded as a URI. * Format of Each Operand: First operand is encoded as a URI.
* Algorithm: Opaque * Algorithm: Opaque
* Output: An instance of the resource named by the URI. * Output: An instance of the resource named by the URI.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
text/uri-list Internet Media Type is defined to provide a simple format text/uri-list Internet Media Type is defined to provide a simple format
for the automatic processing of such lists of URIs. 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 1. Any lines beginning with the '#' character are comment lines and
are ignored during processing. (Note that '#' is a character that are ignored during processing. (Note that '#' is a character that
may appear in URIs, so it only denotes a comment when it is the may appear in URIs, so it only denotes a comment when it is the
first character on a line.) first character on a line.)
2. The remaining non-comment lines MUST be URIs (URNs or URLs), 2. The remaining non-comment lines MUST be URIs (URNs or URLs),
encoded according to the URI specification RFC[3]. Each URI shall encoded according to the URN [3] or URL [7] specification RFCs.
appear on one and only one line. Each URI shall 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 although clients should be liberal in accepting lines with only
one of those characters. one of those characters.
4. The order of the URIs given MUST be preserved upon retransmission. 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. the returned list means.
In applications where one URI has been mapped to a list of URIs, In applications where one URI has been mapped to a list of URIs,
such as in response to the I2Ls request, the first line of the such as in response to the I2Ls request, the first line of the
text/uri-list response SHOULD be a comment giving the original URI. An text/uri-list response SHOULD be a comment giving the original URI. An
skipping to change at page 10, line 34 skipping to change at page 10, line 34
be subject to spoofing. be subject to spoofing.
The "Access denied" error message assumes a system within which the The "Access denied" error message assumes a system within which the
operation is being performed that can convey an authenticated concept operation is being performed that can convey an authenticated concept
of access control. Thus, the "Access denied" message should only be of access control. Thus, the "Access denied" message should only be
returned by systems that have an appropriate method of determining returned by systems that have an appropriate method of determining
access control. access control.
7. References 7. References
[1] Daniel, R., and Mealling, M., "Resolution of Uniform Resource [1] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying
Identifiers using the Domain Name System", RFC2168, February, 1997.
[2] R. Moats, "URN Syntax", RFC2141, January, 1997.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying
Syntax for the Expression of Names and Addresses of Objects on the Syntax for the Expression of Names and Addresses of Objects on the
Network as Used in the World-Wide Web", RFC 1630, June, 1994. Network as Used in the World-Wide Web", RFC 1630, June, 1994.
[2] Daniel, R., and Mealling, M., "Resolution of Uniform Resource
Identifiers using the Domain Name System", RFC2168, February, 1997.
[3] R. Moats, "URN Syntax", RFC2141, January, 1997.
[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 Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
September, 1993. September, 1993.
[5] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a [5] Sollins, K., draft-ietf-urn-req-frame-02, "Guidelines and a
Framework for URN Resolution Systems", MIT/LCS, June, 1997. Framework for URN Resolution Systems", MIT/LCS, June, 1997.
[Note to RFC Editor: Please change this reference to point to the [Note to RFC Editor: Please change this reference to point to the
correct RFC number for the draft] correct RFC number for the draft]
skipping to change at page 11, line 15 skipping to change at page 11, line 15
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 This document expires 6 months from March, 1998
 End of changes. 22 change blocks. 
42 lines changed or deleted 43 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/