Skip to main content

Web Host Metadata
RFC 6415

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>
Subject: Protocol Action: 'Web Host Metadata' to Proposed Standard (draft-hammer-hostmeta-17.txt)

The IESG has approved the following document:
- 'Web Host Metadata'
  (draft-hammer-hostmeta-17.txt) as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Peter Saint-Andre.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

   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 URI host [RFC3986].

   While web protocols have a wide range of metadata needs, they often
   use metadata that is concise, has simple syntax requirements, and can
   benefit from storing their metadata in a common location used by
   other related protocols.

   Because there is no URI or representation 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. '')
   with host metadata that is not specific or relevant to the root
   resource itself.

   To solve those problems, this memo describes a method for locating 
   host metadata as well as information about individual resources 
   controlled by the host -- using an HTTP request to a specific path: 
   /.well-known/host-meta. This memo also registers the well-known URI 
   suffixes "host-meta" and 'host-meta.json' (for host-meta information in
   JSON format) in the Well-Known URI Registry established by RFC 5785.
   The information contained in host-meta consists of properties
   (name/value pairs) and web links with relations, using the XRD 1.0
   (Extensible Resource Descriptor) XML syntax.

   Finally, a new link relation 'lrdd' ("link-based resource 
   descriptor document") is defined to provide resource-specific 
   information outside of a resource itself.

Working Group Summary

   This document is not the product of an IETF working group.
   However, it has received extensive review and discussion in 
   a wide range of technical forums, including the IETF Applications 
   Area, WebFinger developer community, OASIS XRI Technical 
   Committee, and W3C www-talk discussion list.  Many discussions
   of alternative approaches for obtaining metadata about resources
   occurred, and will continue to occur in relation to specific information
   required by specific applications and protocols.  Host-meta (an HTTP-
   based mechanism with a well-known URI) emerged as a effective,
   web-scale, solution likely to be applicable in a variety of situations. 

Document Quality

   Host-meta is a straightforward extension of three existing 
   technologies: XRD 1.0 from OASIS; Web Linking, popularized 
   by HTML and Atom (RFC 4287); and Well-Known URIs (RFC 5785).

   The host-meta concept and document has been reviewed in multiple
   forums.  There are existing implementations (experimental, though
   operational) by major Internet properties (such as and  The WebFinger community have been actively working
   with host-meta for personal web discovery.  Host-meta is also being 
   considered for future enhancements to OpenID and OAuth.

   The document is sufficiently clear to enable the development of 
   multiple interoperable implementations and is suitable for publication 
   as a Proposed Standard.

   The document makes normative reference to the OASIS XRD 1.0
   specification, which is considered to be stable.

   The document makes normative references to RFC 2818 and
   RFC 4627, which are in the downref registry.


   The Document Shepherd is James Manger.

   The Responsible Area Director is Peter Saint-Andre.

   The IANA Expert for the registry in this document is
   Mark Nottingham.

RFC Editor Note