draft-ietf-urn-resolution-services-06.txt   draft-ietf-urn-resolution-services-07.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 October1998 Ron Daniel Jr.
Intended category: Experimental Los Alamos National Laboratory Intended category: Experimental Los Alamos National Laboratory
draft-ietf-urn-resolution-services-06.txt draft-ietf-urn-resolution-services-07.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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
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 ftp.ietf.org (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) [1] 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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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 This operation is used to determine whether two given URIs are
considered to be equal by the server being asked the question. The considered to be equal by the server being asked the question. The
algorithm used to determine equality is opaque. No assertions are made algorithm used to determine equality is opaque. No assertions are made
about whether or not 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
[This section will be augmented or replaced by the registration of
the text/uri-list IMT once that registration has been performed].
Several of the resolution service requests, such as I2Ls, I2Ns, Several of the resolution service requests, such as I2Ls, I2Ns,
result in a list of URIs being returned to the client. The result in a list of URIs being returned to the client. The text/uri-list
text/uri-list Internet Media Type is defined to provide a simple format Internet Media Type is defined to provide a simple format for the
for the automatic processing of such lists of URIs. automatic processing of such lists of URIs.
The format of text/uri-list resources is as follows. This is a copy of the IANA registration of the text/uri-list Media Type.
1. Any lines beginning with the '#' character are comment lines and Date: Fri, 18 Apr 97 08:36:07 PDT
are ignored during processing. (Note that '#' is a character that From: Ron Daniel Jr. <rdaniel@lanl.gov>
may appear in URIs, so it only denotes a comment when it is the To: iana@iana.org, rdaniel@lanl.gov
Subject: Request for MIME media type Text/IETF Tree - uri-list
Name : Ron Daniel Jr.
E-mail : rdaniel@lanl.gov
MIME media type name : Text
MIME subtype name : IETF Tree -uri-list
Required parameters : none
Optional parameters : charset
Currently, URIs can be represented using US-ASCII. However, there are
many non-standard URIs which use special character sets. Discussion of
how to best achieve internationalization of URIs is underway. This
registration will be updated with a discussion of the 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 exceed those limits. Systems must therefore
be prepared to use a suitable content transfer encoding. This is
anticipated to be a rare occurance.
Security considerations :
Client software should be aware of the security considerations of
URIs. For example, accessing some URIs can result in sending a death
threat to a head of state, frequently prompting a visit from the
relevant protective service. Accessing other URIs may result in
financial obligations, or access to resources considered inappropriate
by one's employer.
While the legitimate provider of a uri-list could exploit these
properties for good or ill, it is more likely that uri-lists will be
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 also reveal
confidential information, such as the location of sensitive
information.
Because of these considerations, external confidentiality measures
should be available to protect uri-list responses when appropriate.
Interoperability considerations : none known
Published specification :
Uniform Resource Locators (URLs) and Uniform Resource Names (URNs) are
two instances of the more general class of identifiers known as Uniform
Resource Identifiers (URIs). URN resolution methods frequently wish to
return lists of URLs for a resource so that fault-tolerance and load
balancing can be achieved. The text/uri-list format is intended to be a
very simple format for communicating such lists of URLs (and URNs) in a
form suitable for automatic processing.
The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
and are ignored during processing. (Note that URIs may contain the
'#' character, so it is only a comment character 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),
encoded according to the URN [3] or URL [7] specification RFCs. 2) The remaining non-comment lines shall be URIs (URNs or URLs), encoded
Each URI shall appear on one and only one line. according to the URL or URN specifications (RFC2141, RFC1738 and
3. As for all text/* formats, lines are terminated with a CR LF pair, RFC2396). Each URI shall appear on one and only one line. Very long
although clients should be liberal in accepting lines with only URIs are not broken in the text/uri-list format.
one of those characters. Content-transfer-encodings may be used to enforce line length
4. The order of the URIs given MUST be preserved upon retransmission. limitations.
The client should not make any inferences about what the order of
the returned list means. 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, the
first line of the text/uri-list response SHOULD be a comment giving the
original URI.
An example of the format is given below:
# urn:isbn:0-201-08372-8
http://www.huh.org/books/foo.html
http://www.huh.org/books/foo.pdf
ftp://ftp.foo.org/books/foo.txt
Applications which use this media :
URN resolvers are the initial applications. Web clients and proxies are
applications that are likely to support this format in the future.
Additional information :
1. Magic number(s) : none at this time
2. File extension(s) : .uris or .uri recommended
3. Macintosh file type code : URIs recommended
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.gov
Intended usage : Limited Use
The text/uri-list media type is intended for use in applications which
utilize URIs for replicated resources.
Author/Change controller : Ron Daniel Jr.
Los Alamos National Laboratory
rdaniel@lanl.gov
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
example of such a result for 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
http://www.huh.org/cid/foo.html
http://www.huh.org/cid/foo.pdf
ftp://ftp.foo.org/cid/foo.txt
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 Communications with a server may be of a sensitive nature. Some
servers will hold information that should only be released to servers will hold information that should only be released to
authorized users. The results from servers may be the target of authorized users. The results from servers may be the target of
spoofing, especially once electronic commerce transactions are common spoofing, especially once electronic commerce transactions are common
and there is money to be made by directing users to pirate repositories and there is money to be made by directing users to pirate repositories
rather than repositories that pay royalties to rights-holders. Server rather than repositories that pay royalties to rights-holders. Server
requests may be of interest to traffic analysts. The requests may also requests may be of interest to traffic analysts. The requests may also
be subject to spoofing. be subject to spoofing.
skipping to change at page 11, line 15 skipping to change at page 12, line 42
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 March, 1998 This document expires 6 months from October, 1998
 End of changes. 11 change blocks. 
32 lines changed or deleted 117 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/