One document matched: draft-hammer-hostmeta-08.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<rfc category="info" ipr="trust200902" docName="draft-hammer-hostmeta-08">
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<front>
<title abbrev="host-meta">host-meta: Web Host Metadata</title>
<author initials="E" surname="Hammer-Lahav" fullname="Eran Hammer-Lahav">
<organization>
Yahoo!
</organization>
<address>
<email>eran@hueniverse.com</email>
<uri>http://hueniverse.com</uri>
</address>
</author>
<date year="2010"/>
<abstract>
<t>
This memo describes a method for locating host metadata for Web-based protocols.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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
Uniform Resource Identifiers (URI) with a common host as defined by
<xref target="RFC3986"/>. 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.
</t>
<t>
Because there is no URI or 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, and often has nothing to do it.
</t>
<t>
This memo registers the "well-known" URI suffix <spanx style="verb">host-meta</spanx> in
the Well-Known URI Registry established by <xref target="RFC5785" />, and specifies a
simple, general-purpose metadata document for hosts, to be used by multiple Web-based
protocols.
</t>
<t>
[[ Please discuss this draft on the
<eref target="https://www.ietf.org/mailman/listinfo/apps-discuss">apps-discuss@ietf.org</eref>
mailing list. ]]
</t>
<section title="Example">
<t>
The following is 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 author information for each resource within the
host-meta document scope:
</t>
<figure>
<artwork><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<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'
href='http://example.com/license'>
<Title xml:lang='en-us'>Site License Policy</Title>
</Link>
<Link rel='author'
template='http://meta.example.com?uri={uri}'>
<Title xml:lang='en-us'>Author Profile</Title>
</Link>
</XRD>
]]></artwork>
</figure>
</section>
<section title="Namespace and Version" anchor="ns">
<t>
The host-meta document uses the XRD 1.0 XML namespace URI <xref target="W3C.REC-xml-names-19990114" />:
</t>
<figure>
<artwork><![CDATA[
http://docs.oasis-open.org/ns/xri/xrd-1.0
]]></artwork>
</figure>
<t>
The XML namespace URI for the host-meta specific extension elements defined in this
specification is:
</t>
<figure>
<artwork><![CDATA[
http://host-meta.net/ns/1.0
]]></artwork>
</figure>
</section>
<section title="Notational Conventions">
<t>
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
<xref target="RFC2119" />.
</t>
<t>
Examples in this specification uses the namespace prefix <spanx style="verb">hm:</spanx>
for the extension Namespace URI identified in <xref target="ns" />. The
<spanx style="verb">hm:</spanx> 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 <xref target="ns" />.
</t>
<t>
This document uses the Augmented Backus-Naur Form (ABNF) notation of <xref target="RFC5234" />.
Additionally, the following rules are included from <xref target="RFC3986" />: reserved,
unreserved, and host.
</t>
</section>
</section>
<section title="Metadata Scope">
<t>
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 <xref target="RFC3986"/>, across all ports and schemes.
</t>
<t>
The scope MUST be expressed explicitly within the document using the
<spanx style="verb">hm:Host</spanx> element as described in <xref target="Host element" />.
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.
</t>
</section>
<section title="The host-meta Document Format">
<t>
The host-meta document uses the XRD 1.0 document format as defined by
<xref target="OASIS.XRD-1.0" />, which provides a simple and extensible XML-based schema
for describing resources. This memo defines additional elements and processing rules needed
to describe hosts. Documents MAY include any XRD element not explicitly excluded.
</t>
<t>
The host-meta document root MUST be an <spanx style="verb">XRD</spanx> element. The
document SHOULD NOT include a <spanx style="verb">Subject</spanx> element, as at this time
no URI is available to identify hosts. The use of the <spanx style="verb">Alias</spanx>
element in host-meta is undefined and NOT RECOMMENDED.
</t>
<t>
This memo defines the <spanx style="verb">hm:Host</spanx> element for declaring document
scope. The subject (or "context resource" as defined by
<xref target="I-D.nottingham-http-link-header" />) of the XRD
<spanx style="verb">Property</spanx> and <spanx style="verb">Link</spanx> elements consists
of the hosts included in the document scope. However, the subject of
<spanx style="verb">Link</spanx> elements with a <spanx style="verb">template</spanx>
attribute is the individual resources (included in the document scope) applied to the link
template as described in <xref target="Link element" />.
</t>
<section title="The 'hm:Host' Element" anchor="Host element">
<t>
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 <spanx style="verb">XRD</spanx> element. The
parent <spanx style="verb">XRD</spanx> element MUST include one but MAY include more
<spanx style="verb">hm:Host</spanx> elements (order does not matter). If a host-meta
document includes more than one <spanx style="verb">hm:Host</spanx> element, it does not
signify any relationship between the individual hosts other than sharing the same
metadata included in the document.
</t>
<figure>
<preamble>
The element value syntax ABNF:
</preamble>
<artwork><![CDATA[
Host-Element-Value = host
]]></artwork>
</figure>
</section>
<section title="The 'Link' Element" anchor="Link element">
<t>
The XRD <spanx style="verb">Link</spanx> element, when used with the
<spanx style="verb">href</spanx> attribute, conveys a link relation between the hosts
described by the document and a common target URI.
</t>
<figure>
<preamble>
For example, the following link declares a common author for the entire scope:
</preamble>
<artwork><![CDATA[
<Link rel='author' href='http://example.com/author' />
]]></artwork>
</figure>
<t>
However, a <spanx style="verb">Link</spanx> element with a
<spanx style="verb">template</spanx> attribute conveys relations whose context are the
individual resources within the host-meta document scope, and whose target is constructed
by applying each context resource URI to the 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.
</t>
<figure>
<preamble>
For example, a blog with multiple authors can provide information 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, but all share the same pattern of where that information
is located:
</preamble>
<artwork><![CDATA[
<Link rel='author' template='http://example.com?author={uri}' />
]]></artwork>
</figure>
<section title="Template Syntax" anchor="template_syntax">
<t>
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.
</t>
<t>
Before substituting template variables, any value character other than unreserved (as
defined by <xref target="RFC3986" />) MUST be percent-encoded per
<xref target="RFC3986" />.
</t>
<t>
This memo defines a single variable - <spanx style="verb">uri</spanx> - as the entire
context resource 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 <spanx style="verb">uri</spanx> variable. If a client is
unable to successfully process a template (e.g. unknown variable names, unknown or
incompatible syntax) the parent <spanx style="verb">Link</spanx> element SHOULD be
ignored.
</t>
<figure>
<preamble>
The template syntax ABNF:
</preamble>
<artwork><![CDATA[
URI-Template = *( uri-char | variable )
variable = "{" var-name "}"
uri-char = ( reserved | unreserved )
var-name = "uri" | ( 1*var-char )
var-char = ALPHA / DIGIT / "." / "_"
]]></artwork>
</figure>
<figure>
<preamble>
For example:
</preamble>
<artwork><![CDATA[
Input: http://example.com/r?f=1
Template: http://example.org?q={uri}
Output: http://example.org?q=http%3A%2F%2Fexample.com%2Fr%3Ff%3D1
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Obtaining host-meta Documents" anchor="obtain">
<t>
Clients obtain the host-meta document for a given host by making an
HTTPS <xref target="RFC2818" /> GET request to the host's port 443 for the
<spanx style="verb">/.well-known/host-meta</spanx> path. If the request fails to produce a
valid host-meta document, clients make an HTTP <xref target="RFC2616" /> GET request
to the host's port 80 for the <spanx style="verb">/.well-known/host-meta</spanx> path.
</t>
<t>
Servers MUST support at least one but SHOULD support both ports. If both ports are
supported, they MUST serve the same document. Clients MAY attempt to obtain the host-meta
document from either port, SHOULD attempt using port 443 first, and SHOULD attempt the
other port if the first fails.
</t>
<figure>
<preamble>
For example, the following request is used to obtain the host-meta document for the
'example.com' host:
</preamble>
<artwork><![CDATA[
GET /.well-known/host-meta HTTP/1.1
Host: example.com
]]></artwork>
</figure>
<t>
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 the
response as a host-meta document. To aid in this process, authorities using this mechanism
SHOULD correctly label host-meta responses with the
<spanx style="verb">application/xrd+xml</spanx> internet media type.
</t>
<t>
If the server response indicates that the host-meta resource is located elsewhere (a 301,
302, or 307 response status code), 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 another host. Likewise, if the resource is not available or does
not exist (indicated respectively, by the 404 and 410 response status codes) at both ports,
the client should infer that metadata is not available via this mechanism.
</t>
<t>
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.
</t>
</section>
<section title="Security Considerations" anchor="Security">
<t>
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.
</t>
<t>
The host-meta scope is explicitly declared by the <spanx style="verb">hm:Host</spanx>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="IANA Considerations">
<section title="The host-meta Well-Known URI">
<t>
This memo registers the 'host-meta' well-known URI in the Well-Known URI Registry as
defined by <xref target="RFC5785" />.
<list style="hanging">
<t hangText="URI suffix:">
host-meta
</t>
<t hangText="Change controller:">
IETF
</t>
<t hangText="Specification document(s):">
[[ this document ]]
</t>
<t hangText="Related information:">
None
</t>
</list>
</t>
</section>
</section>
<appendix title="host-meta XML Schema">
<figure>
<preamble>
The following is the XML schema for the host-meta XRD extension elements:
</preamble>
<artwork>
<![CDATA[
<?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>
]]>
</artwork>
</figure>
</appendix>
<appendix title="Acknowledgments">
<t>
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, Eve Maler, Breno de Medeiros, Brad Fitzpatrick, James Manger, Will Norris,
Mark Nottingham, John Panzer, Drummond Reed, and Peter Saint-Andre.
</t>
</appendix>
<appendix title="Document History">
<t>
[[ to be removed by the RFC editor before publication as an RFC ]]
</t>
<t>
-08
<list style="symbols">
<t>
Fixed typo.
</t>
</list>
</t>
<t>
-07
<list style="symbols">
<t>
Minor editorial clarifications.
</t>
<t>
Added XML schema for host-meta extension.
</t>
<t>
Updated XRD reference to the latest draft (no normative changes).
</t>
</list>
</t>
<t>
-06
<list style="symbols">
<t>
Updated well-known reference to RFC 5785.
</t>
<t>
Minor editorial changes.
</t>
<t>
Made HTTPS a higher priority (SHOULD) over HTTP.
</t>
</list>
</t>
<t>
-05
<list style="symbols">
<t>
Adjusted syntax to the latest XRD schema.
</t>
<t>
Added note about using a link template without variables.
</t>
</list>
</t>
<t>
-04
<list style="symbols">
<t>
Corrected the <hm:Host> example.
</t>
</list>
</t>
<t>
-03
<list style="symbols">
<t>
Changed scope to an entire host (per RFC 3986).
</t>
<t>
Simplified template syntax to always percent-encode values and vocabulary to a single 'uri' variable.
</t>
<t>
Changed document retrieval to always use HTTP(S).
</t>
<t>
Added security consideration about the use of templates.
</t>
<t>
Explicitly defined the root element to be 'XRD'.
</t>
</list>
</t>
<t>
-02
<list style="symbols">
<t>
Changed Scope element syntax from attributes to URI-like string value.
</t>
</list>
</t>
<t>
-01
<list style="symbols">
<t>
Editorial rewrite.
</t>
<t>
Redefined scope as a scheme-authority pair.
</t>
<t>
Added document structure section.
</t>
</list>
</t>
<t>
-00
<list style="symbols">
<t>
Initial draft.
</t>
</list>
</t>
</appendix>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nottingham-http-link-header-06.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-P3P-20020416.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-names-19990114.xml"?>
<reference anchor="OASIS.XRD-1.0" target="http://www.oasis-open.org/committees/download.php/37692/xrd-1.0-wd16.html">
<front>
<title>Extensible Resource Descriptor (XRD) Version 1.0 (work in progress)</title>
<author initials="E.H" surname="Hammer-Lahav" fullname="Eran">
<organization>Yahoo!</organization>
</author>
<author initials="W.N" surname="Norris" fullname="Will Norris">
<organization>Internet2</organization>
</author>
</front>
<format type="HTML" target="http://www.oasis-open.org/committees/download.php/37692/xrd-1.0-wd16.html" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:32:27 |