draft-hammer-hostmeta-08.txt		draft-hammer-hostmeta-09.txt
	Network Working Group E. Hammer-Lahav		Network Working Group E. Hammer-Lahav
	Internet-Draft Yahoo!		Internet-Draft Yahoo!
	Intended status: Informational May 11, 2010		Intended status: Informational May 24, 2010
	Expires: November 12, 2010		Expires: November 25, 2010
	host-meta: Web Host Metadata		host-meta: Web Host Metadata
	draft-hammer-hostmeta-08		draft-hammer-hostmeta-09
	Abstract		Abstract
	This memo describes a method for locating host metadata for Web-based		This memo describes a method for locating host metadata for Web-based
	protocols.		protocols.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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 any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		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."
	This Internet-Draft will expire on November 12, 2010.		This Internet-Draft will expire on November 25, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Namespace and Version . . . . . . . . . . . . . . . . . . 4		1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4
	1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 4		2. The host-meta Document Format . . . . . . . . . . . . . . . . . 4
	2. Metadata Scope . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. The 'Link' Element . . . . . . . . . . . . . . . . . . . . 4
	3. The host-meta Document Format . . . . . . . . . . . . . . . . 5		2.1.1. Template Syntax . . . . . . . . . . . . . . . . . . . . 5
	3.1. The 'hm:Host' Element . . . . . . . . . . . . . . . . . . 5		3. Obtaining host-meta Documents . . . . . . . . . . . . . . . . . 5
	3.2. The 'Link' Element . . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	3.2.1. Template Syntax . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	4. Obtaining host-meta Documents . . . . . . . . . . . . . . . . 7		5.1. The host-meta Well-Known URI . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		Appendix B. Document History . . . . . . . . . . . . . . . . . . . 7
	6.1. The host-meta Well-Known URI . . . . . . . . . . . . . . . 8		6. Normative References . . . . . . . . . . . . . . . . . . . . . 8
	Appendix A. host-meta XML Schema . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 9
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Web-based protocols often require the discovery of host policy or		Web-based protocols often require the discovery of host policy or
	metadata, where host is not a single resource but the entity		metadata, where host is not a single resource but the entity
	controlling the collection of resources identified by Uniform		controlling the collection of resources identified by Uniform
	Resource Identifiers (URI) with a common host as defined by		Resource Identifiers (URI) with a common URI host as defined by
	[RFC3986]. While these protocols have a wide range of metadata		[RFC3986]. While these protocols have a wide range of metadata
	needs, they often define metadata that is concise, has simple syntax		needs, they often define metadata that is concise, has simple syntax
	requirements, and can benefit from storing its metadata in a common		requirements, and can benefit from storing its metadata in a common
	location used by other related protocols.		location used by other related protocols.
	Because there is no URI or resource available to describe a host,		Because there is no URI or resource available to describe a host,
	many of the methods used for associating per-resource metadata (such		many of the methods used for associating per-resource metadata (such
	as HTTP headers) are not available. This often leads to the		as HTTP headers) are not available. This often leads to the
	overloading of the root HTTP resource (e.g. 'http://example.com/')		overloading of the root HTTP resource (e.g. 'http://example.com/')
	with host metadata that is not specific to the root resource, and		with host metadata that is not specific to the root resource, and
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	This memo registers the "well-known" URI suffix "host-meta" in the		This memo registers the "well-known" URI suffix "host-meta" in the
	Well-Known URI Registry established by [RFC5785], and specifies a		Well-Known URI Registry established by [RFC5785], and specifies a
	simple, general-purpose metadata document for hosts, to be used by		simple, general-purpose metadata document for hosts, to be used by
	multiple Web-based protocols.		multiple Web-based protocols.
	[[ Please discuss this draft on the apps-discuss@ietf.org [1] mailing		[[ Please discuss this draft on the apps-discuss@ietf.org [1] mailing
	list. ]]		list. ]]
	1.1. Example		1.1. Example
	The following is a simple host-meta document for the 'example.com'		The following is a simple host-meta document with a link providing
	and 'www.example.com' hosts with a link providing host-wide copyright		host-wide copyright information and a link template providing a URI
	information and a link template providing a URI for obtaining		for obtaining resource-specific author information for each resource
	resource-specific author information for each resource within the		within the host-meta document scope:
	host-meta document scope:
	<?xml version='1.0' encoding='UTF-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'		<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
	xmlns:hm='http://host-meta.net/ns/1.0'>
	<hm:Host>example.com</hm:Host>
	<hm:Host>www.example.com</hm:Host>
	<Link rel='license'		<Link rel='license'
	href='http://example.com/license'>		href='http://example.com/license'>
	<Title xml:lang='en-us'>Site License Policy</Title>		<Title xml:lang='en-us'>Site License Policy</Title>
	</Link>		</Link>
	<Link rel='author'		<Link rel='author'
	template='http://meta.example.com?uri={uri}'>		template='http://meta.example.com?uri={uri}'>
	<Title xml:lang='en-us'>Author Profile</Title>		<Title xml:lang='en-us'>Author Profile</Title>
	</Link>		</Link>
	</XRD>		</XRD>
	1.2. Namespace and Version		1.2. Notational Conventions
	The host-meta document uses the XRD 1.0 XML namespace URI
	[W3C.REC-xml-names-19990114]:
	http://docs.oasis-open.org/ns/xri/xrd-1.0
	The XML namespace URI for the host-meta specific extension elements
	defined in this specification is:
	http://host-meta.net/ns/1.0
	1.3. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Examples in this specification uses the namespace prefix "hm:" for
	the extension Namespace URI identified in Section 1.2. The "hm:"
	namespace prefix is arbitrary and not is semantically significant.
	Element names without a namespace prefix belong to the XRD 1.0 XML
	namespace identified in Section 1.2.
	This document uses the Augmented Backus-Naur Form (ABNF) notation of		This document uses the Augmented Backus-Naur Form (ABNF) notation of
	[RFC5234]. Additionally, the following rules are included from		[RFC5234]. Additionally, the following rules are included from
	[RFC3986]: reserved, unreserved, and host.		[RFC3986]: reserved, unreserved, and pct-encoded.
	2. Metadata Scope
	Each host-meta document describes one or more hosts, where a host is
	not a single resource but the entity controlling the collection of
	resources identified by URIs with a common host as defined by
	[RFC3986], across all ports and schemes.
	The scope MUST be expressed explicitly within the document using the
	"hm:Host" element as described in Section 3.1. The host-meta scope
	does not apply to any other hostname (or sub-domain) not explicitly
	declared. For example, 'example.net', 'example.com', and
	'www.example.com' all have different and non-overlapping scopes.
	3. The host-meta Document Format		2. The host-meta Document Format
	The host-meta document uses the XRD 1.0 document format as defined by		The host-meta document uses the XRD 1.0 document format as defined by
	[OASIS.XRD-1.0], which provides a simple and extensible XML-based		[OASIS.XRD-1.0], which provides a simple and extensible XML-based
	schema for describing resources. This memo defines additional		schema for describing resources. This memo defines additional
	elements and processing rules needed to describe hosts. Documents		processing rules needed to describe hosts. Documents MAY include any
	MAY include any XRD element not explicitly excluded.		XRD element not explicitly excluded.
	The host-meta document root MUST be an "XRD" element. The document		The host-meta document root MUST be an "XRD" element. The document
	SHOULD NOT include a "Subject" element, as at this time no URI is		SHOULD NOT include a "Subject" element, as at this time no URI is
	available to identify hosts. The use of the "Alias" element in host-		available to identify hosts. The use of the "Alias" element in host-
	meta is undefined and NOT RECOMMENDED.		meta is undefined and NOT RECOMMENDED.
	This memo defines the "hm:Host" element for declaring document scope.
	The subject (or "context resource" as defined by		The subject (or "context resource" as defined by
	[I-D.nottingham-http-link-header]) of the XRD "Property" and "Link"		[I-D.nottingham-http-link-header]) of the XRD "Property" and "Link"
	elements consists of the hosts included in the document scope.		elements is the host described by the host-meta document. However,
	However, the subject of "Link" elements with a "template" attribute		the subject of "Link" elements with a "template" attribute is the
	is the individual resources (included in the document scope) applied		individual resource whose URI is applied to the link template as
	to the link template as described in Section 3.2.		described in Section 2.1.
	3.1. The 'hm:Host' Element
	The 'hm:Host" element is used to declare the scope of the host-meta
	document and is defined as a child element of the root "XRD" element.
	The parent "XRD" element MUST include one but MAY include more
	"hm:Host" elements (order does not matter). If a host-meta document
	includes more than one "hm:Host" element, it does not signify any
	relationship between the individual hosts other than sharing the same
	metadata included in the document.
	The element value syntax ABNF:
	Host-Element-Value = host
	3.2. The 'Link' Element		2.1. The 'Link' Element
	The XRD "Link" element, when used with the "href" attribute, conveys		The XRD "Link" element, when used with the "href" attribute, conveys
	a link relation between the hosts described by the document and a		a link relation between the host described by the document and a
	common target URI.		common target URI.
	For example, the following link declares a common author for the		For example, the following link declares a common author for the
	entire scope:		entire scope:
	<Link rel='author' href='http://example.com/author' />		<Link rel='author' href='http://example.com/author' />
	However, a "Link" element with a "template" attribute conveys		However, a "Link" element with a "template" attribute conveys a
	relations whose context are the individual resources within the host-		relation whose context is an individual resource within the host-meta
	meta document scope, and whose target is constructed by applying each		document scope, and whose target is constructed by applying the
	context resource URI to the template. The template string MAY		context resource URI to the template. The template string MAY
	contain a URI string without any variables to represent a resource-		contain a URI string without any variables to represent a resource-
	level relation that is identical for every individual resource.		level relation that is identical for every individual resource.
	For example, a blog with multiple authors can provide information		For example, a blog with multiple authors can provide information
	about each article's author by providing an endpoint with a parameter		about each article's author by providing an endpoint with a parameter
	set to the URI of each article. Each article has a unique author,		set to the URI of each article. Each article has a unique author,
	but all share the same pattern of where that information is located:		but all share the same pattern of where that information is located:
	<Link rel='author' template='http://example.com?author={uri}' />		<Link rel='author'
			template='http://example.com/author?article={uri}' />
	3.2.1. Template Syntax		2.1.1. Template Syntax
	This memo defines a simple template syntax for URI transformation. A		This memo defines a simple template syntax for URI transformation. A
	template is a string containing brace-enclosed ("{}") variable names		template is a string containing brace-enclosed ("{}") variable names
	marking the parts of the string that are to be substituted by the		marking the parts of the string that are to be substituted by the
	corresponding variable values.		corresponding variable values.
	Before substituting template variables, any value character other		Before substituting template variables, any value character other
	than unreserved (as defined by [RFC3986]) MUST be percent-encoded per		than unreserved (as defined by [RFC3986]) MUST be percent-encoded per
	[RFC3986].		[RFC3986].
	This memo defines a single variable - "uri" - as the entire context		This memo defines a single variable - "uri" - as the entire context
	resource URI. Protocols MAY define additional relation-specific		resource URI. Protocols MAY define additional relation-specific
	variables and syntax rules, but SHOULD only do so for protocol-		variables and syntax rules, but SHOULD only do so for protocol-
	specific relation types, and MUST NOT change the meaning of the "uri"		specific relation types, and MUST NOT change the meaning of the "uri"
	variable. If a client is unable to successfully process a template		variable. If a client is unable to successfully process a template
	(e.g. unknown variable names, unknown or incompatible syntax) the		(e.g. unknown variable names, unknown or incompatible syntax) the
	parent "Link" element SHOULD be ignored.		parent "Link" element SHOULD be ignored.
	The template syntax ABNF:		The template syntax ABNF:
	URI-Template = *( uri-char | variable )		URI-Template = *( uri-char / variable )
	variable = "{" var-name "}"		variable = "{" var-name "}"
	uri-char = ( reserved | unreserved )		uri-char = ( reserved / unreserved / pct-encoded )
	var-name = "uri" | ( 1*var-char )		var-name = %x75.72.69 / ( 1*var-char ) ; "uri" or other names
	var-char = ALPHA / DIGIT / "." / "_"		var-char = ALPHA / DIGIT / "." / "_"
	For example:		For example:
	Input: http://example.com/r?f=1		Input: http://example.com/r?f=1
	Template: http://example.org?q={uri}		Template: http://example.org/?q={uri}
	Output: http://example.org?q=http%3A%2F%2Fexample.com%2Fr%3Ff%3D1		Output: http://example.org/?q=http%3A%2F%2Fexample.com%2Fr%3Ff%3D1
	4. Obtaining host-meta Documents		3. Obtaining host-meta Documents
	Clients obtain the host-meta document for a given host by making an		Clients obtain the host-meta document for a given host by making an
	HTTPS [RFC2818] GET request to the host's port 443 for the		HTTPS [RFC2818] GET request to the host's port 443 for the
	"/.well-known/host-meta" path. If the request fails to produce a		"/.well-known/host-meta" path. If the request fails to produce a
	valid host-meta document, clients make an HTTP [RFC2616] GET request		valid host-meta document, clients make an HTTP [RFC2616] GET request
	to the host's port 80 for the "/.well-known/host-meta" path.		to the host's port 80 for the "/.well-known/host-meta" path.
	Servers MUST support at least one but SHOULD support both ports. If		Servers MUST support at least one but SHOULD support both ports. If
	both ports are supported, they MUST serve the same document. Clients		both ports are supported, they MUST serve the same document. Clients
	MAY attempt to obtain the host-meta document from either port, SHOULD		MAY attempt to obtain the host-meta document from either port, SHOULD
	skipping to change at page 7, line 48 ¶		skipping to change at page 6, line 27 ¶
	If a representation is successfully obtained, but is not in the		If a representation is successfully obtained, but is not in the
	format described above, clients should infer that the path is being		format described above, clients should infer that the path is being
	used for other purposes, and not process the response as a host-meta		used for other purposes, and not process the response as a host-meta
	document. To aid in this process, authorities using this mechanism		document. To aid in this process, authorities using this mechanism
	SHOULD correctly label host-meta responses with the		SHOULD correctly label host-meta responses with the
	"application/xrd+xml" internet media type.		"application/xrd+xml" internet media type.
	If the server response indicates that the host-meta resource is		If the server response indicates that the host-meta resource is
	located elsewhere (a 301, 302, or 307 response status code), the		located elsewhere (a 301, 302, or 307 response status code), the
	client SHOULD try to obtain the resource from the location provided		client MUST try to obtain the resource from the location provided in
	in the response. This means that the host-meta document for one host		the response. This means that the host-meta document for one host
	MAY be retrieved from a another host. Likewise, if the resource is		MAY be retrieved from a another host. Likewise, if the resource is
	not available or does not exist (indicated respectively, by the 404		not available or does not exist (e.g. a 404 or 410 response status
	and 410 response status codes) at both ports, the client should infer		codes) at both ports, the client should infer that metadata is not
	that metadata is not available via this mechanism.		available via this mechanism.
	The scope declared within the host-meta document MUST match the
	desired host. Clients MUST NOT use host-meta documents when the
	desired host (used to obtain the document) is not listed in the
	document.
	5. Security Considerations		4. Security Considerations
	The metadata returned by the host-meta resource is presumed to be		The metadata returned by the host-meta resource is presumed to be
	under the control of the appropriate authority and representative of		under the control of the appropriate authority and representative of
	all the resources described by it. If this resource is compromised		all the resources described by it. If this resource is compromised
	or otherwise under the control of another party, it may represent a		or otherwise under the control of another party, it may represent a
	risk to the security of the server and data served by it, depending		risk to the security of the server and data served by it, depending
	on what protocols use it.		on what protocols use it.
	The host-meta scope is explicitly declared by the "hm:Host" elements
	listed in the document. Clients SHOULD evaluate the authority of a
	host-meta document obtained from one host to describe another host.
	Protocols that change the scope from the one declared in the document
	without careful consideration can incur security risks.
	Protocols using host-meta templates SHOULD evaluate the construction		Protocols using host-meta templates SHOULD evaluate the construction
	of their templates as well as any protocol-specific variables or		of their templates as well as any protocol-specific variables or
	syntax to ensure that the templates cannot be abused by an attacker.		syntax to ensure that the templates cannot be abused by an attacker.
	For example, a client can be tricked into following a malicious link		For example, a client can be tricked into following a malicious link
	due to a poorly constructed template which produces unexpected		due to a poorly constructed template which produces unexpected
	results when its variable values contain unexpected characters.		results when its variable values contain unexpected characters.
	Protocols MAY restrict document retrieval to HTTPS based on their		Protocols MAY restrict document retrieval to HTTPS based on their
	security needs. Protocols utilizing host-meta documents obtained via		security needs. Protocols utilizing host-meta documents obtained via
	other methods not described in this memo SHOULD consider the security		other methods not described in this memo SHOULD consider the security
	and authority risks associated with such methods.		and authority risks associated with such methods.
	6. IANA Considerations		5. IANA Considerations
	6.1. The host-meta Well-Known URI		5.1. The host-meta Well-Known URI
	This memo registers the 'host-meta' well-known URI in the Well-Known		This memo registers the 'host-meta' well-known URI in the Well-Known
	URI Registry as defined by [RFC5785].		URI Registry as defined by [RFC5785].
	URI suffix: host-meta		URI suffix: host-meta
	Change controller: IETF		Change controller: IETF
	Specification document(s): [[ this document ]]		Specification document(s): [[ this document ]]
	Related information: None		Related information: None
	Appendix A. host-meta XML Schema		Appendix A. Acknowledgments
	The following is the XML schema for the host-meta XRD extension
	elements:
	<?xml version="1.0" encoding="UTF-8"?>
	<schema
	xmlns="http://www.w3.org/2001/XMLSchema"
	xmlns:hm="http://host-meta.net/ns/1.0"
	targetNamespace="http://host-meta.net/ns/1.0"
	elementFormDefault="unqualified"
	attributeFormDefault="unqualified"
	version="1.0">
	<element name="Host" type="hm:HostType"/>
	<complexType name="HostType">
	<simpleContent>
	<extension base="string">
	<anyAttribute namespace="##other" processContents="lax"/>
	</extension>
	</simpleContent>
	</complexType>
	</schema>
	Appendix B. Acknowledgments
	The author would like to acknowledge the contributions of everyone		The author would like to acknowledge the contributions of everyone
	who provided feedback and use cases for this memo; in particular,		who provided feedback and use cases for this memo; in particular,
	Dirk Balfanz, DeWitt Clinton, Blaine Cook, Eve Maler, Breno de		Dirk Balfanz, DeWitt Clinton, Blaine Cook, Eve Maler, Breno de
	Medeiros, Brad Fitzpatrick, James Manger, Will Norris, Mark		Medeiros, Brad Fitzpatrick, James Manger, Will Norris, Mark
	Nottingham, John Panzer, Drummond Reed, and Peter Saint-Andre.		Nottingham, John Panzer, Drummond Reed, and Peter Saint-Andre.
	Appendix C. Document History		Appendix B. Document History
	[[ to be removed by the RFC editor before publication as an RFC ]]		[[ to be removed by the RFC editor before publication as an RFC ]]
			-09
			o Removed the <hm:Host> element due to lack of use cases (protocols
			with signature requirements can define their own way of declaring
			the document's subject for this purpose).
			o Minor editorial changes.
			o Changed following redirections to MUST.
			o Updated references.
	-08		-08
	o Fixed typo.		o Fixed typo.
	-07		-07
	o Minor editorial clarifications.		o Minor editorial clarifications.
	o Added XML schema for host-meta extension.		o Added XML schema for host-meta extension.
	o Updated XRD reference to the latest draft (no normative changes).		o Updated XRD reference to the latest draft (no normative changes).
	-06		-06
	o Updated well-known reference to RFC 5785.		o Updated well-known reference to RFC 5785.
	skipping to change at page 10, line 43 ¶		skipping to change at page 8, line 35 ¶
	value.		value.
	-01		-01
	o Editorial rewrite.		o Editorial rewrite.
	o Redefined scope as a scheme-authority pair.		o Redefined scope as a scheme-authority pair.
	o Added document structure section.		o Added document structure section.
	-00		-00
	o Initial draft.		o Initial draft.
	7. Normative References		6. Normative References
	[I-D.nottingham-http-link-header]		[I-D.nottingham-http-link-header]
	Nottingham, M., "Web Linking",		Nottingham, M., "Web Linking",
	draft-nottingham-http-link-header-06 (work in progress),		draft-nottingham-http-link-header-10 (work in progress),
	July 2009.		May 2010.
	[OASIS.XRD-1.0]		[OASIS.XRD-1.0]
	Hammer-Lahav, E. and W. Norris, "Extensible Resource		Hammer-Lahav, E. and W. Norris, "Extensible Resource
	Descriptor (XRD) Version 1.0 (work in progress)", <http://		Descriptor (XRD) Version 1.0 (work in progress)", <http://
	www.oasis-open.org/committees/download.php/37692/		www.oasis-open.org/committees/download.php/37692/
	xrd-1.0-wd16.html>.		xrd-1.0-wd16.html>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 11, line 29 ¶		skipping to change at page 9, line 22 ¶
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,
	April 2010.		April 2010.
	[W3C.REC-P3P-20020416]
	Marchiori, M., "The Platform for Privacy Preferences 1.0
	(P3P1.0) Specification", World Wide Web Consortium
	Recommendation REC-P3P-20020416, April 2002,
	<http://www.w3.org/TR/2002/REC-P3P-20020416>.
	[W3C.REC-xml-names-19990114]
	Hollander, D., Layman, A., and T. Bray, "Namespaces in
	XML", World Wide Web Consortium FirstEdition REC-xml-
	names-19990114, January 1999,
	<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
	[1] <https://www.ietf.org/mailman/listinfo/apps-discuss>		[1] <https://www.ietf.org/mailman/listinfo/apps-discuss>
	Author's Address		Author's Address
	Eran Hammer-Lahav		Eran Hammer-Lahav
	Yahoo!		Yahoo!
	Email: eran@hueniverse.com		Email: eran@hueniverse.com
	URI: http://hueniverse.com		URI: http://hueniverse.com
End of changes. 34 change blocks.
	166 lines changed or deleted		71 lines changed or added
This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff