One document matched: draft-hammer-hostmeta-05.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-05">
<?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="2009"/>
<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
URIs 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 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.
</t>
<t>
This memo registers the "well-known" URI suffix 'host-meta' in the Well-Known URI Registry
established by <xref target="I-D.nottingham-site-meta" />, 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>
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:
</t>
<figure>
<artwork xml:space="preserve"><![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='describedby'
template='http://meta.example.com?uri={uri}'>
<Title xml:lang='en-us'>Resource Descriptor</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 xml:space="preserve"><![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 xml:space="preserve"><![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>
This specification uses the namespace prefix "hm:" for the extension Namespace URI
identified in <xref target="ns" />. 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 <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. The scope MUST be expressed explicitly
within the document using the <xref target="Host element">'hm:Host' elements</xref>. 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. XRD elements not explicitly mentioned in this memo are permitted and
used as defined in <xref target="OASIS.XRD-1.0" />.
</t>
<t>
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.
</t>
<t>
This memo defines the <xref target="Host element">'hm:Host' element</xref> for declaring
document scope. The subject (or "context resource" as defined by
<xref target="I-D.nottingham-http-link-header" />) 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 <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 '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.
</t>
<figure>
<preamble>
The element value syntax ABNF:
</preamble>
<artwork xml:space="preserve"><![CDATA[
Host-Element-Value = host
]]></artwork>
</figure>
</section>
<section title="The 'Link' Element" anchor="Link element">
<t>
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.
</t>
<figure>
<preamble>
For example, the following link declares a common author for the entire scope:
</preamble>
<artwork xml:space="preserve"><![CDATA[
<Link rel='author' href='http://example.com/author' />
]]></artwork>
</figure>
<t>
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.
</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 xml:space="preserve"><![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, '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.
</t>
<figure>
<preamble>
The template syntax ABNF:
</preamble>
<artwork xml:space="preserve"><![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 xml:space="preserve"><![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>
The host-meta document is obtained by making an HTTP <xref target="RFC2616" /> GET request
to the host's port 80, or an HTTPS <xref target="RFC2818" /> GET request to the host's
port 443 for the '/.well-known/host-meta' path.
</t>
<t>
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.
</t>
<figure>
<preamble>
For example, the following request is used to obtain the host-meta document for the
'example.com' host:
</preamble>
<artwork xml:space="preserve"><![CDATA[
GET /.well-known/host-meta HTTP/1.1
Host: example.com
]]></artwork>
</figure>
<t>
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.
</t>
<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 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.
</t>
<t>
The scope declared within the host-meta document MUST match the desired host.
</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 '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.
</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="I-D.nottingham-site-meta" />.
<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="Acknowledgments">
<t>
This memo was initially based on <xref target="I-D.nottingham-site-meta" />.
</t>
<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, Breno de Medeiros, Brad Fitzpatrick, James Manger, Will Norris,
Mark Nottingham, John Panzer, and Drummond Reed.
</t>
</appendix>
<appendix title="Document History">
<t>
[[ to be removed by the RFC editor before publication as an RFC ]]
</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/bibxml3/reference.I-D.draft-nottingham-site-meta-03.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/35274/xrd-1.0-wd10.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/34925/xrd-1.0-cd01.html" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:34:19 |