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/