draft-nottingham-site-meta-01.txt		draft-nottingham-site-meta-02.txt
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft E. Hammer-Lahav		Internet-Draft E. Hammer-Lahav
	Intended status: Informational February 10, 2009		Intended status: Informational April 8, 2009
	Expires: August 14, 2009		Expires: October 10, 2009
	Host Metadata for the Web		Host Metadata for the Web
	draft-nottingham-site-meta-01		draft-nottingham-site-meta-02
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 14, 2009.		This Internet-Draft will expire on October 10, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document.
	to this document.
	Abstract		Abstract
	This memo describes a method for locating host-specific metadata for		This memo describes a method for locating host-specific metadata for
	the Web.		the Web.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3		2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
	3. The host-meta File Format . . . . . . . . . . . . . . . . . . 4		3. The host-meta File Format . . . . . . . . . . . . . . . . . . 4
	3.1. The Link host-meta Field . . . . . . . . . . . . . . . . . 5		3.1. The Link host-meta Field . . . . . . . . . . . . . . . . . 5
	4. Discovering host-meta Files . . . . . . . . . . . . . . . . . 5		4. Discovering host-meta Files . . . . . . . . . . . . . . . . . 5
	5. Minting New meta-fields . . . . . . . . . . . . . . . . . . . 6		5. Minting New meta-fields . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7.1. application/host-meta Media Type Registration . . . . . . 6		7.1. application/host-meta Media Type Registration . . . . . . 7
	7.2. The host-meta Field Registry . . . . . . . . . . . . . . . 7		7.2. The host-meta Field Registry . . . . . . . . . . . . . . . 7
	7.2.1. Registration Template . . . . . . . . . . . . . . . . 8		7.2.1. Registration Template . . . . . . . . . . . . . . . . 8
	7.2.2. The Link host-meta field . . . . . . . . . . . . . . . 8		7.2.2. The Link host-meta field . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
	Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 10		Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 10
	B.1. Is this mechanism appropriate for all kinds of		B.1. Is this mechanism appropriate for all kinds of
	metadata? . . . . . . . . . . . . . . . . . . . . . . . . 10		metadata? . . . . . . . . . . . . . . . . . . . . . . . . 10
	B.2. Why not use OPTIONS * with content negotiation to		B.2. Why not use OPTIONS * with content negotiation to
	discover different types of metadata directly? . . . . . . 10		discover different types of metadata directly? . . . . . . 10
	B.3. Why not use a META tag or microformat in the root		B.3. Why not use a META tag or microformat in the root
	resource? . . . . . . . . . . . . . . . . . . . . . . . . 10		resource? . . . . . . . . . . . . . . . . . . . . . . . . 10
	B.4. Why not use response headers on the root resource, and		B.4. Why not use response headers on the root resource, and
	have clients use HEAD? . . . . . . . . . . . . . . . . . . 10		have clients use HEAD? . . . . . . . . . . . . . . . . . . 10
	B.5. Why scope metadata to an authority? . . . . . . . . . . . 10		B.5. Why scope metadata to a single URI scheme, host and
			port combination? . . . . . . . . . . . . . . . . . . . . 10
	B.6. Why /host-meta? . . . . . . . . . . . . . . . . . . . . . 11		B.6. Why /host-meta? . . . . . . . . . . . . . . . . . . . . . 11
	B.7. Aren't you concerned about pre-empting an authority's		B.7. Aren't you concerned about pre-empting an authority's
	URI namespace? . . . . . . . . . . . . . . . . . . . . . . 11		control over their URI namespace? . . . . . . . . . . . . 11
	B.8. Why use link relations instead of media types to		B.8. Why use link relations instead of media types to
	identify kinds of metadata? . . . . . . . . . . . . . . . 11		identify kinds of metadata? . . . . . . . . . . . . . . . 11
	B.9. What impact does this have on existing mechanisms,		B.9. What impact does this have on existing mechanisms,
	such as P3P and robots.txt? . . . . . . . . . . . . . . . 11		such as P3P and robots.txt? . . . . . . . . . . . . . . . 11
	B.10. Why not (insert existing similar mechanism here)? . . . . 11		B.10. Why not (insert existing similar mechanism here)? . . . . 11
	Appendix C. Document History . . . . . . . . . . . . . . . . . . 11		Appendix C. Document History . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	It is increasingly common for Web-based protocols to require the		It is increasingly common for Web-based protocols to require the
	discovery of policy or metadata before making a request. For		discovery of policy or metadata before making a request. For
	example, the Robots Exclusion Protocol specifies a way for automated		example, the Robots Exclusion Protocol specifies a way for automated
	processes to obtain permission to access resources; likewise, the		processes to obtain permission to access resources; likewise, the
	Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-		Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-
	agents how to discover privacy policy beforehand.		agents how to discover privacy policy beforehand.
	skipping to change at page 3, line 25		skipping to change at page 3, line 25
	HTTP headers, WebDAV's PROPFIND [RFC4918]), the overhead associated		HTTP headers, WebDAV's PROPFIND [RFC4918]), the overhead associated
	with them often precludes their use in these scenarios.		with them often precludes their use in these scenarios.
	When this happens, it is common to designate a "well-known location"		When this happens, it is common to designate a "well-known location"
	for such metadata, so that it can be easily located. However, this		for such metadata, so that it can be easily located. However, this
	approach has the drawback of risking collisions, both with other such		approach has the drawback of risking collisions, both with other such
	designated "well-known locations" and with pre-existing resources.		designated "well-known locations" and with pre-existing resources.
	To address this, this memo proposes a single (and hopefully last)		To address this, this memo proposes a single (and hopefully last)
	"well-known location", /host-meta, which acts as a directory to the		"well-known location", /host-meta, which acts as a directory to the
	interesting metadata about a particular authority. Future mechanisms		interesting metadata about the resources that share a URI scheme,
	that require authority-wide metadata can easily include an entry in		host and port. Future mechanisms that require such widely-scoped
	the host-meta resource, thereby making their metadata cheaply		metadata can easily include an entry in the host-meta resource,
	available (indeed, because it can be cached, the more mechanisms that		thereby making their metadata cheaply available (indeed, because it
	use it, the more efficient it becomes) without impinging on others'		can be cached, the more mechanisms that use it, the more efficient it
	URI space.		becomes) without impinging on others' URI space.
	Note that the metadata provided by a host-meta resource is explicitly		Note that the metadata provided by a host-meta resource is explicitly
	scoped to apply to the entire authority (in the URI [RFC3986] sense)		scoped to apply to the resources associated with the same combination
	associated with it (using the process described in Section 4); it		of scheme, host and port (using the process described in Section 4);
	does not apply to a subset, nor does it apply to other authorities		it does not apply to a subset, nor does it apply to other resources
	(e.g., using another port, or a different hostname in the same		(e.g., using another port, or a different hostname in the same
	domain). However, individual mechanisms (e.g., a relation type in		domain). However, individual mechanisms (e.g., a relation type in
	the Link field) MAY reduce or expand this scope. This should only be		the Link field) MAY reduce or expand this scope. This should only be
	done after careful consideration of the consequences upon security,		done after careful consideration of the consequences upon security,
	administration, interoperability and network load.		administration, interoperability and network load.
	Please discuss this draft on the www-talk@w3.org [1] mailing list.		Please discuss this draft on the www-talk@w3.org [1] mailing list.
	2. Notational Conventions		2. Notational Conventions
	skipping to change at page 4, line 10		skipping to change at page 4, line 10
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This documnet uses the Augmented Backus-Naur Form (ABNF) notation of		This documnet uses the Augmented Backus-Naur Form (ABNF) notation of
	[RFC5234], and explicitly includes the following rules from it: CRLF		[RFC5234], and explicitly includes the following rules from it: CRLF
	(CR LF), OCTET (any 8-bit sequence of data), DIGIT, ALPHA, and WSP		(CR LF), OCTET (any 8-bit sequence of data), DIGIT, ALPHA, and WSP
	(white space).		(white space).
	3. The host-meta File Format		3. The host-meta File Format
	The host-meta file format is an extremely simple textual language		The host-meta file format is an extremely simple textual language
	that allows an authority to convey metadata about itself and its		that allows a set of resources to convey metadata about themselves.
	resources.
	Its syntax is similar to that of HTTP header-fields [RFC2616], but		Its syntax is similar to that of HTTP header-fields [RFC2616], but
	has a few differences:		has a few differences:
	o White space is permissible both before and after the block of		o White space is permissible both before and after the block of
	fields, and		fields, and
	o fields MUST NOT be folded across multiple lines.		o fields MUST NOT be folded across multiple lines.
	Furthermore, this format's use diverges from HTTP header-fields in a		Furthermore, this format's use diverges from HTTP header-fields in a
	number of ways:		number of ways:
	o The fields are transferred as the message body, not as headers,		o The fields are transferred as the message body, not as headers,
	and		and
	o rather than being related to a message, the fields in host-meta		o rather than being related to a message, the fields in host-meta
	pertain to the entire associated authority (see Section 4), and		pertain to the entire set of resources in scope (see Section 4),
			and
	o the permissible field-names are constrained by the host-meta field		o the permissible field-names are constrained by the host-meta field
	registry. This specification defines one such field, Link.		registry. This specification defines one such field, Link.
	host-meta = *( WSP / CRLF )		host-meta = *( WSP / CRLF )
	*( meta-field CRLF )		*( meta-field CRLF )
	*( WSP / CRLF )		*( WSP / CRLF )
	meta-field = field-name ":" [ field-value ]		meta-field = field-name ":" [ field-value ]
	field-name = 1*tchar		field-name = 1*tchar
	field-value = *( field-content / WSP )		field-value = *( field-content / WSP )
	field-content = <field content>		field-content = <field content>
	skipping to change at page 4, line 50		skipping to change at page 4, line 50
	For example,		For example,
	Link: </robots.txt>; rel="robots"		Link: </robots.txt>; rel="robots"
	Link: </w3c/p3p.xml>; rel="privacy"; type="application/p3p.xml"		Link: </w3c/p3p.xml>; rel="privacy"; type="application/p3p.xml"
	Link: <http://example.net/example>; rel="http://example.com/rel"		Link: <http://example.net/example>; rel="http://example.com/rel"
	As with HTTP headers, field-names are not case-sensitive,		As with HTTP headers, field-names are not case-sensitive,
	unrecognised field-names SHOULD be silently ignored when parsing this		unrecognised field-names SHOULD be silently ignored when parsing this
	format, and ordering of fields SHOULD NOT be considered significant		format, and ordering of fields SHOULD NOT be considered significant
	unless specified otherwise. Additionally, although the syntax does		unless specified otherwise. Note also that blank links are not
	not explicitly allow empty lines between fields, parsers SHOULD		permitted between fields.
	silently discard them (i.e., be permissive in what they accept).
	Field content is constrained by the specification indicated by its		Field content is constrained by the specification indicated by its
	associated field-name.		associated field-name.
	3.1. The Link host-meta Field		3.1. The Link host-meta Field
	The "Link" host-meta field uses the syntax of the Link HTTP header-		The "Link" host-meta field uses the syntax of the Link HTTP header-
	field [I-D.nottingham-http-link-header] to convey links whose context		field [I-D.nottingham-http-link-header] to convey links whose context
	is the entire authority, rather than a single resource. For example,		is the entire host, rather than a single resource. For example,
	Link: </terms>; rel="license"		Link: </terms>; rel="license"
	indicates that the URI "/terms" refers to a license for all resources		found at 'http://example.com/host-meta' indicates that the URI
	associated with the authority.		"/terms" refers to a license for all resources associated with
			'http://example.com'.
	The Link host-meta field differs from the Link header in the		The Link host-meta field differs from the Link header in the
	following respects:		following respects:
	o Its context is defined as all resources that share its authority,		o Its context is defined as all resources that share the same URI
	by default (although this MAY be overridden by a representation		scheme, host and port, by default (although this MAY be overridden
	obtained from the indicated resource), and		by a representation obtained from the indicated resource), and
	o When the link URI is relative, its base URI is the root resource		o When the link URI is relative, its base URI is the root resource
	of the authority. For example, in the example above, if the		of the authority. In the example above, if the authority is
	authority is "example.com", the full link URI would be		"example.com", the full link URI would be
	"http://example.com/me".		"http://example.com/terms".
	4. Discovering host-meta Files		4. Discovering host-meta Files
	The metadata for a given authority can be discovered by dereferencing		The metadata for a given authority can be discovered by dereferencing
	the path /host-meta on the same authority. For example, for an HTTP		the path /host-meta on the host and port, using the protocol
	URI [RFC2616], the following request would obtain metadata for the		indicated by the URI scheme. For example, the following request
	authority "www.example.com:80";		would obtain metadata for "http://www.example.com/";
	GET /host-meta HTTP/1.1		GET /host-meta HTTP/1.1
	Host: www.example.com		Host: www.example.com
	The semantics of the protocol used for access to the resource apply.		The semantics of the protocol used for access to the resource apply.
	Therefore, if the resource indicates the client should try a		Therefore, if the resource indicates the client should try a
	different request (in HTTP, the 301, 302, 303 or 307 response status		different request (in HTTP, the 301, 302, 303 or 307 response status
	code), the client SHOULD attempt to do so; note that this implies		code), the client SHOULD attempt to do so; note that this implies
	that the host-meta file for one authority MAY be retrieved from a		that the host-meta file for one authority MAY be retrieved from a
	different authority. Likewise, if the resource is not available or		different authority. Likewise, if the resource is not available or
	existent (in HTTP, the 404 or 410 status code), the client SHOULD		existent (in HTTP, the 404 or 410 status code), the client SHOULD
	infer that metadata is not available via this mechanism.		infer that metadata is not available via this mechanism.
	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 authority is		format described above, clients SHOULD infer that the authority is
	using this URI for other purposes, and not process it as a host-meta		using this URI for other purposes, and not process it as a host-meta
	file.		file.
	To aid in this process, authorities using this mechanism SHOULD		To aid in this process, host-meta responses SHOULD be labelled with
	correctly label host-meta responses with the "application/host-meta"		the "application/host-meta" internet media type.
	internet media type.
	5. Minting New meta-fields		5. Minting New meta-fields
	Applications that wish to mint new meta-fields for use in the host-		Applications that wish to mint new meta-fields for use in the host-
	meta format MUST register them in the host-meta field-registry,		meta format MUST register them in the host-meta field-registry,
	following the procedures in Section 7.2. Field-names MUST conform to		following the procedures in Section 7.2. Field-names MUST conform to
	the field-name ABNF Section 3, and field-value syntax MUST be well-		the field-name ABNF Section 3, and field-value syntax MUST be well-
	defined (e.g., using ABNF, or a reference to the syntax of an		defined (e.g., using ABNF, or a reference to the syntax of an
	existing header field-value). Field-values SHOULD use the ISO-859-1		existing header field-value). Field-values SHOULD use the ASCII
	character encoding. If a field-value applies to a scope other than		character encoding. If a field-value applies to a scope other than
	the entire authority, that scope MUST be well-defined.		the entire authority, that scope MUST be well-defined.
	6. Security Considerations		6. 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 resources contained by it. If this resource is compromised or		all resources contained by it. If this resource is compromised or
	otherwise under the control of another party, it may represent a risk		otherwise under the control of another party, it may represent a risk
	to the security of the server and data served by it, depending on		to the security of the server and data served by it, depending on
	what mechanisms use /host-meta.		what mechanisms use /host-meta.
	Scoping metadata to a single authority is the default in host-meta.		Scoping metadata to a single URI scheme, host and port is the default
	Thus "http://example.com/", "https://example.com" and		in host-meta. Thus "http://example.com/", "https://example.com" and
	"http://www.example.com/" all have different host-meta files with		"http://www.example.com/" all have different host-meta files with
	seperate and non-overlapping scopes of applicability. Applications		seperate and non-overlapping scopes of applicability. Applications
	that change the scope of metadata can incur security risks without		that change the scope of metadata can incur security risks without
	careful consideration.		careful consideration.
			An attacker with certain types of limited access to a server may be
			able to affect how the host-meta resource is served; for example,
			they may be able to upload a file at that location, but not affect
			its media type, or they may be able to cause a server to redirect
			/host-meta to a URI that they control.
	7. IANA Considerations		7. IANA Considerations
	7.1. application/host-meta Media Type Registration		7.1. application/host-meta Media Type Registration
	The host-meta format can be identified with the following media type:		The host-meta format can be identified with the following media type:
	MIME media type name: application		MIME media type name: application
	MIME subtype name: host-meta		MIME subtype name: host-meta
	Mandatory parameters: None.		Mandatory parameters: None.
	Optional parameters: None.		Optional parameters: None.
	Encoding considerations: field-values may specify any encoding for		Encoding considerations: field-values may specify any encoding for
	their contents, although it is expected that most will use ISO-		their contents, although it is expected that most will use ASCII
	8859-1 or a subset thereof (for both historic and interoperability		or a subset thereof (for both historic and interoperability
	purposes).		purposes).
	Security considerations: As defined in this specification. [[update		Security considerations: As defined in this specification. [[update
	upon publication]]		upon publication]]
	Interoperability considerations: There are no known interoperability		Interoperability considerations: There are no known interoperability
	issues.		issues.
	Published specification: This specification. [[update upon		Published specification: This specification. [[update upon
	publication]]		publication]]
	Applications which use this media type: No known applications		Applications which use this media type: No known applications
	currently use this media type.		currently use this media type.
	skipping to change at page 9, line 45		skipping to change at page 9, line 49
	April 2002.		April 2002.
	URIs		URIs
	[1] <http://lists.w3.org/Archives/Public/www-talk/>		[1] <http://lists.w3.org/Archives/Public/www-talk/>
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	We would like to acknowledge the contributions of everyone who		We would like to acknowledge the contributions of everyone who
	provided feedback and use cases for this draft; in particular, Phil		provided feedback and use cases for this draft; in particular, Phil
	Archer, Dirk Balfanz, Tim Bray, Paul Hoffman, Barry Leiba, Ashok		Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Paul
	Malhotra, Breno de Medeiros, and John Panzer. The authors take all		Hoffman, Barry Leiba, Ashok Malhotra, Breno de Medeiros, and John
	responsibility for errors and omissions.		Panzer, and Drummond Reed. The authors take all responsibility for
			errors and omissions.
	Appendix B. Frequently Asked Questions		Appendix B. Frequently Asked Questions
	B.1. Is this mechanism appropriate for all kinds of metadata?		B.1. Is this mechanism appropriate for all kinds of metadata?
	No. The primary use cases are described in the introduction; when		No. The primary use cases are described in the introduction; when
	it's necessary to discover metadata or policy before a resource is		it's necessary to discover metadata or policy before a resource is
	accessed, and/or it's necessary to describe metadata for a whole		accessed, and/or it's necessary to describe metadata for a whole site
	authority (or large portions of it), host-meta is appropriate. In		(or large portions of it), host-meta is appropriate. In other cases
	other cases (e.g., fine-grained metadata that doesn't need to be		(e.g., fine-grained metadata that doesn't need to be known ahead of
	known ahead of time), other mechanisms are more appropriate.		time), other mechanisms are more appropriate.
	B.2. Why not use OPTIONS * with content negotiation to discover		B.2. Why not use OPTIONS * with content negotiation to discover
	different types of metadata directly?		different types of metadata directly?
	Two reasons; a) OPTIONS is not cacheable -- a severe problem for		Two reasons; a) OPTIONS is not cacheable -- a severe problem for
	scaling -- and b) it is not well-supported in browsers, and difficult		scaling -- and b) it is not well-supported in browsers, and difficult
	to configure in servers.		to configure in servers.
	B.3. Why not use a META tag or microformat in the root resource?		B.3. Why not use a META tag or microformat in the root resource?
	This places constraints on the format of an authority's root resource		This places constraints on the format of a site's root resource to be
	to be HTML or similar. While extremely common, it isn't universal		HTML or similar. While extremely common, it isn't universal (e.g.,
	(e.g., mobile sites, machine-to-machine communication, etc.). Also,		mobile sites, machine-to-machine communication, etc.). Also, some
	some root resources are very large, which would place additional		root resources are very large, which would place additional overhead
	overhead on clients and intervening networks.		on clients and intervening networks.
	B.4. Why not use response headers on the root resource, and have		B.4. Why not use response headers on the root resource, and have
	clients use HEAD?		clients use HEAD?
	The headers on a root resource pertain to that resource, not the		The headers on a root resource pertain to that resource, not the
	whole site. While it is possible to mint new message headers that		whole site. While it is possible to mint new message headers that
	apply to the whole site, such a header would need to be sent on every		apply to the whole site, such a header would need to be sent on every
	response for the root resource, whether it was useful or not, with		response for the root resource, whether it was useful or not, with
	the potential for substantially increasing the size of those		the potential for substantially increasing the size of those
	responses (which are often popular, and not very cacheable).		responses (which are often popular, and not very cacheable).
	B.5. Why scope metadata to an authority?		B.5. Why scope metadata to a single URI scheme, host and port
			combination?
	The alternative is to allow scoping to be dynamic and determined		The alternative is to allow scoping to be dynamic and determined
	locally, but this has its own issues, which usually come down to a)		locally, but this has its own issues, which usually come down to a)
	an unreasonable number of requests to determine authoritative		an unreasonable number of requests to determine authoritative
	metadata, b) increased complexity, with a higher likelihood of		metadata, b) increased complexity, with a higher likelihood of
	implementation and interoperability (or even security) problems.		implementation and interoperability (or even security) problems.
	Besides, many mechanisms on the Web already presume a single
	authority scope (e.g., robots.txt, P3P, cookies, javascript		Besides, many mechanisms on the Web already presume a single scheme/
			host/port scope (e.g., robots.txt, P3P, cookies, javascript
	security), and the effort and cost required to mint a new URI		security), and the effort and cost required to mint a new URI
	authority is small and shrinking.		authority is small and shrinking.
	B.6. Why /host-meta?		B.6. Why /host-meta?
	It's short, descriptive and according to search indices, not widely		It's short, descriptive and according to search indices, not widely
	used.		used.
	B.7. Aren't you concerned about pre-empting an authority's URI		B.7. Aren't you concerned about pre-empting an authority's control over
	namespace?		their URI namespace?
	Yes, but it's unfortunately a necessary (and already present) evil;		Yes, but it's unfortunately a necessary (and already present) evil;
	this proposal tries to minimise future abuses.		this proposal tries to minimise future abuses.
	B.8. Why use link relations instead of media types to identify kinds of		B.8. Why use link relations instead of media types to identify kinds of
	metadata?		metadata?
	A link relation declares the intent and use of the link (or inline		A link relation declares the intent and use of the link (or inline
	content, when present); a media type defines the format and		content, when present); a media type defines the format and
	processing model for those bits.		processing model for those bits.
	skipping to change at page 11, line 39		skipping to change at page 11, line 44
	We are aware that there are several existing proposals with similar		We are aware that there are several existing proposals with similar
	functionality. In our estimation, none have gained sufficient		functionality. In our estimation, none have gained sufficient
	traction. This may be because they were perceived to be too complex,		traction. This may be because they were perceived to be too complex,
	or tied too closely to one use case.		or tied too closely to one use case.
	Appendix C. Document History		Appendix C. Document History
	[[RFC Editor: please remove this section before publication.]]		[[RFC Editor: please remove this section before publication.]]
			o -02
			* Changed preferred encoding to ASCII.
			* Disallow blank lines between fields.
			* Expanded scope beyond authority to include scheme.
			* Fixed relative URI example.
			* Added 'partial control' attack to security considerations.
	o -01		o -01
	* Changed "site-meta" to "host-meta" after feedback.		* Changed "site-meta" to "host-meta" after feedback.
	* Changed from XML to text-based header-like format.		* Changed from XML to text-based header-like format.
	* Remove capability for generic inline content.		* Remove capability for generic inline content.
	* Added registry for host-meta fields.		* Added registry for host-meta fields.
	* Clarified scope of metadata application.		* Clarified scope of metadata application.
	* Added security consideration about HTTP vs. HTTPS, expanding		* Added security consideration about HTTP vs. HTTPS, expanding
	scope.		scope.
	Authors' Addresses		Authors' Addresses
End of changes. 30 change blocks.
	65 lines changed or deleted		80 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/