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