host-meta: Web Host Metadata
Yahoo!
eran@hueniverse.comhttp://hueniverse.com
This memo describes a method for locating host metadata for Web-based protocols.
Web-based protocols often require the discovery of host policy or metadata, where host is
not a single resource but the entity controlling the collection of resources identified by
URIs with a common host as defined by . While these protocols have
a wide range of metadata needs, they often define metadata that is concise, has simple
syntax requirements, and can benefit from storing its metadata in a common location used by
other related protocols.
Because there is no URI or a resource available to describe a host, many of the methods
used for associating per-resource metadata (such as HTTP headers) are not available. This
often leads to the overloading of the root HTTP resource (e.g. 'http://example.com/') with
host metadata that is not specific to the root resource (e.g. a home page or web
application), and which often has nothing to do it.
This memo registers the "well-known" URI suffix 'host-meta' in the Well-Known URI Registry
established by , and specifies a simple,
general-purpose metadata document for hosts, to be used by multiple Web-based protocols.
Please discuss this draft on the
apps-discuss@ietf.org
mailing list.
A simple host-meta document for the 'example.com' and 'www.example.com' hosts with a link
providing host-wide copyright information and a link template providing a URI for obtaining
resource-specific metadata for each resource within the host-meta document scope:
The host-meta document uses the XRD 1.0 XML namespace URI :
The XML namespace URI for the host-meta specific extension elements defined in this
specification is:
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 in
.
This specification uses the namespace prefix "hm:" for the extension Namespace URI
identified in . Note that the choice of namespace prefix is arbitrary
and not semantically significant. Element names without a namespace prefix belong to the
XRD 1.0 XML namespace identified in .
This document uses the Augmented Backus-Naur Form (ABNF) notation of .
Additionally, the following rules are included from : reserved,
unreserved, and host.
Each host-meta document describes one or more hosts. The scope MUST be expressed explicitly
within the document using the 'hm:Host' elements. 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.
The host-meta document uses the XRD 1.0 document format as defined by
, which provides a simple and extensible XML-based schema
for describing resources. This memo defines additional elements and processing rules needed
to describe hosts. XRD elements not explicitly mentioned in this memo are permitted and
used as defined in .
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 available to identify hosts. The use of the
'Alias' element in host-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
) of the XRD 'Property' and 'Link' elements
are the hosts included in the document scope, with the exception of 'Link' elements with a
'template' attribute for which the subject are individual resources included in the
document scope as defined in .
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.
The XRD 'Link' element, when used with the 'href' attribute, conveys a link relation
between the host (or hosts) described by the document and a common target URI.
However, a 'Link' element with a 'template' attribute conveys relations whose
context are individual resources within the host-meta document scope, and whose target is
constructed by applying the context URI to a template. The template string MAY contain a
URI string without any variables to represent a resource-level relation that is identical
for every individual resource.
This memo defines a simple template syntax for URI transformation. A template is a
string containing brace-enclosed ("{}") variable names marking the parts of the string
that are to be substituted by the corresponding variable values.
Before substituting template variables, any value character other than unreserved (as
defined by ) MUST be percent-encoded per
.
This memo defines a single variable, 'uri', as the entire context URI. Protocols MAY
define additional relation-specific variables and syntax rules, but SHOULD only do so
for protocol-specific relation types, and MUST NOT change the meaning of the 'uri'
variable. If a client is unable to successfully process a template (e.g. unknown
variable names, unknown or incompatible syntax) the parent 'Link' element SHOULD be
ignored.
The host-meta document is obtained by making an HTTP GET request
to the host's port 80, or an HTTPS GET request to the host's
port 443 for the '/.well-known/host-meta' path.
Servers MUST support at least one but SHOULD support both ports unless restricted by
other considerations. If both ports are supported, they MUST serve the same document.
Clients MAY attempt to obtain the host-meta document from either port, and SHOULD
attempt the other port if the first fails, unless restricted by other considerations.
If the server response indicates that the host-meta resource is located elsewhere (a 301,
302, or 307 response status codes), the client SHOULD try to obtain the resource from the
location provided in the response. This means that the host-meta document for one host
MAY be retrieved from a different host. Likewise, if the resource is not available or
does not exist (indicated respectively, by the 404 and 410 response status codes), the
client SHOULD infer that metadata is not available via this mechanism.
If a representation is successfully obtained, but is not in the format described above,
clients SHOULD infer that the path is being used for other purposes, and not process it as
a host-meta document. To aid in this process, authorities using this mechanism SHOULD
correctly label host-meta responses with the "application/xrd+xml" internet media type.
The scope declared within the host-meta document MUST match the desired host.
The metadata returned by the host-meta resource is presumed to be under the control of the
appropriate authority and representative of all the resources described by it. If this
resource is compromised 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 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 any other 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 of their templates as
well as any protocol-specific variables or syntax to ensure that the templates cannot be
abused by an attacker. For example, a client can be tricked into following a malicious link
due to a poorly constructed template which produces unexpected results when its variable
values contain unexpected characters.
Protocols MAY restrict document retrieval to HTTPS based on their security needs.
Protocols utilizing host-meta documents obtained via other methods not described in this
memo SHOULD consider the security and authority risks associated with such methods.
This memo registers the 'host-meta' well-known URI in the Well-Known URI Registry as
defined by .
host-meta
IETF
[[ this document ]]
None
This memo was initially based on .
The author would like to acknowledge the contributions of everyone who
provided feedback and use cases for this memo; in particular, Dirk Balfanz, DeWitt Clinton,
Blaine Cook, Breno de Medeiros, Brad Fitzpatrick, James Manger, Will Norris,
Mark Nottingham, John Panzer, and Drummond Reed.
[[ to be removed by the RFC editor before publication as an RFC ]]
-05
Adjusted syntax to the latest XRD schema.
Added note about using a link template without variables.
-04
Corrected the <hm:Host> example.
-03
Changed scope to an entire host (per RFC 3986).
Simplified template syntax to always percent-encode values and vocabulary to a single 'uri' variable.
Changed document retrieval to always use HTTP(S).
Added security consideration about the use of templates.
Explicitly defined the root element to be 'XRD'.
-02
Changed Scope element syntax from attributes to URI-like string value.
-01
Editorial rewrite.
Redefined scope as a scheme-authority pair.
Added document structure section.
-00
Initial draft.
Extensible Resource Descriptor (XRD) Version 1.0 (work in progress)Yahoo!Internet2