Skip to main content

Web Host Metadata
RFC 6415

Revision differences

Document history

Date Rev. By Action
2015-10-14
17 (System) Notify list changed from eran@hueniverse.com, draft-hammer-hostmeta@ietf.org to (None)
2012-08-22
17 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2011-11-01
17 Amy Vezza State changed to RFC Published from RFC Ed Queue.
2011-10-31
17 (System) RFC published
2011-09-27
17 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-09-27
17 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-09-27
17 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-09-23
17 (System) IANA Action state changed to In Progress
2011-09-20
17 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-09-19
17 Amy Vezza IESG state changed to Approved-announcement sent
2011-09-19
17 Amy Vezza IESG has approved the document
2011-09-19
17 Amy Vezza Closed "Approve" ballot
2011-09-19
17 Amy Vezza Approval announcement text regenerated
2011-09-19
17 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-09-15
17 Stephen Farrell
[Ballot discuss]
(1) Section 2 - Question - you say the client MUST follow redirects. Is
that the same as for HTTP generally? If not, …
[Ballot discuss]
(1) Section 2 - Question - you say the client MUST follow redirects. Is
that the same as for HTTP generally? If not, then I think it needs to be
justified. (Not sure, but I thought 30x wasn't a MUST follow generally.)
If you stick with the current MUST, then I think you need a security
consideration that a bad server could DoS a client via a redirect
loop and that clients SHOULD or MUST handle this gracefully.

(2) Section 2 - Are you saying that a client that gets a 404 on port 80
MUST also try 443 to see if the same thing happens? That seems onerous and
given you've said the server MUST give the same response, it also seems
fairly useless.

(3) Section 3 - are you saying that servers MAY include any old
element/attribute they want but that clients MUST ignore any they don't
understand? If so, please make that clear.

(4) Section 3 - "If there is any discrepancy between the content of the
XRD 1.0 XML representation and any other representation for the same
resource, the client MUST only use the XRD 1.0 XML representation." I
don't get that - how will the client end up with 2 representations to
compare? (Is it signalled via more than one Accept or what? Needs to be
stated.) Is a client supposed to actually compare all variants? e.g. if it
asks for XRD and JSON. If a client has two Accept values (headers or
values?) then how does the server return both? That all seems over complex
- why not just say that a client MUST ask for one and get one (or an
error) and then use that? (Or maybe I missed something.)

(5) The security considerations say that applications with sensitive
stuff MUST only send host-meta information via TLS. Doesn't that conflict
with the earlier statement that the same information MUST be sent
via both HTTP and HTTPS? (2nd para of section 2)
2011-09-15
17 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-09-15
17 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-09-15
17 (System) New version available: draft-hammer-hostmeta-17.txt
2011-07-14
17 Cindy Morgan Removed from agenda for telechat
2011-07-14
17 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-07-14
17 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-07-14
17 Jari Arkko [Ballot comment]
The JRD document format - a general purpose XRD 1.0 represenation -

s/represenation/representation/
2011-07-14
17 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
17 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
17 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
17 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-07-13
17 Stephen Farrell
[Ballot comment]
1) The term "host" is odd here, this is really talking about meta-data
for what I would call a web server.  Since a …
[Ballot comment]
1) The term "host" is odd here, this is really talking about meta-data
for what I would call a web server.  Since a single physical host can
serve up many virtual hosts with Apache for example, that'd be worth
clarifying in case someone thinks that host-wide refers to the physical
device.

(2) Intro: "This often leads to..." Just wondering - is there documented
evidence of this happening often somewhere?

(3) Intro: the description of link templates is entirely opaque to me.
(Actually, I think a rewrite of the entire section would be good.) An
example would help but I don't get the "hub" example in 1.1 - you say that
link templates are for more fine-grained information, but this one is not.
Is that just a badly chosen example? (When I understand this I may be able
to suggest a better wording.)

(4) 1.1.1 - you say "using an HTTP GET request: " but then present what I
think is a response.

(5) 1.1.1 - I don't get the reason for presenting the "together" version
of the URI specific meta-data. I think showing this as an xml document
just confuses, unless there's a way to make a request that leads to this
as a response, which you don't say.

(6) 1.1.1 - I don't get what having a higher priority means for the order
of links and you don't say.

(7) Section 2 - grammar: s/The decision which protocol is used to obtain
the host-meta document have significant security ramifications as
described in Section 5./The decision as to which protocol is used to
obtain the host-meta document can have significant security ramifications
as described in Section 5./

(8) "only canonical representation" is superfluous s/only//
2011-07-13
17 Stephen Farrell
[Ballot discuss]
(1) Section 2 - Question - you say the client MUST follow redirects. Is
that the same as for HTTP generally? If not, …
[Ballot discuss]
(1) Section 2 - Question - you say the client MUST follow redirects. Is
that the same as for HTTP generally? If not, then I think it needs to be
justified. (Not sure, but I thought 30x wasn't a MUST follow generally.)
If you stick with the current MUST, then I think you need a security
consideration that a bad server could DoS a client via a redirect
loop and that clients SHOULD or MUST handle this gracefully.

(2) Section 2 - Are you saying that a client that gets a 404 on port 80
MUST also try 443 to see if the same thing happens? That seems onerous and
given you've said the server MUST give the same response, it also seems
fairly useless.

(3) Section 3 - are you saying that servers MAY include any old
element/attribute they want but that clients MUST ignore any they don't
understand? If so, please make that clear.

(4) Section 3 - "If there is any discrepancy between the content of the
XRD 1.0 XML representation and any other representation for the same
resource, the client MUST only use the XRD 1.0 XML representation." I
don't get that - how will the client end up with 2 representations to
compare? (Is it signalled via more than one Accept or what? Needs to be
stated.) Is a client supposed to actually compare all variants? e.g. if it
asks for XRD and JSON. If a client has two Accept values (headers or
values?) then how does the server return both? That all seems over complex
- why not just say that a client MUST ask for one and get one (or an
error) and then use that? (Or maybe I missed something.)

(5) The security considerations say that applications with sensitive
stuff MUST only send host-meta information via TLS. Doesn't that conflict
with the earlier statement that the same information MUST be sent
via both HTTP and HTTPS? (2nd para of section 2)
2011-07-13
17 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-07-12
17 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-07-12
17 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-07-11
17 Russ Housley
[Ballot comment]
The Gen-ART Review by Suresh Krishnanon 26-Jun-2011 points out that
  this document has two downrefs that have not been called out in …
[Ballot comment]
The Gen-ART Review by Suresh Krishnanon 26-Jun-2011 points out that
  this document has two downrefs that have not been called out in the
  writeup: RFC 2818 and RFC 4627.
2011-07-11
17 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-07-11
17 Sean Turner
[Ballot comment]
It's okay to use "NOT RECOMMENDED" in the context of RFC 2119, but you need to add it to the notation section: …
[Ballot comment]
It's okay to use "NOT RECOMMENDED" in the context of RFC 2119, but you need to add it to the notation section:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL"
  in this document are to be interpreted as described in [RFC2119].

Making this change would fix an ID nit.
2011-07-11
17 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-07-11
17 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-07-09
17 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-07-08
17 Peter Saint-Andre [Ballot Position Update] New position, Yes, has been recorded for Peter Saint-Andre
2011-07-08
17 Peter Saint-Andre Ballot has been issued
2011-07-08
17 Peter Saint-Andre Created "Approve" ballot
2011-07-08
17 Peter Saint-Andre
DOCUMENT SHEPHERD WRITE-UP BY JAMES MANGER


[1.a] The document shepherd is James Manger .

I have personally reviewed draft-hammer-hostmeta-16. It is ready to be forwarded …
DOCUMENT SHEPHERD WRITE-UP BY JAMES MANGER


[1.a] The document shepherd is James Manger .

I have personally reviewed draft-hammer-hostmeta-16. It is ready to be forwarded to the IESG for publication.


[1.b] The document has been extensively reviewed in a number of forums:

* The IETF Applications Area apps-discuss@ietf.org mailing list;

* The WebFinger community (http://code.google.com/p/webfinger/ and the associated mailing list http://groups.google.com/group/webfinger);

* The OASIS Extensible Resource Identifier (XRI) Technical Committee (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri), which (though not as open as the IETF) does include a public review process (http://lists.oasis-open.org/archives/xri-comment/) that has led to changes in the XRD format that host-meta uses;

* The W3C www-talk@w3.org mailing list discussed the pre-cursor to host-meta (site-meta) from late 2008 (http://lists.w3.org/Archives/Public/www-talk/).

I have no concerns about the breadth or depth of reviews.


[1.c] I have no concerns that further review from specific perspectives are required.

The document specifies a fairly simple concept. It is just 18 pages long, including lots of examples and boilerplate text.

Each application or protocol that considers using host-meta to convey specific information will need to consider the nature of that information, its authoritative source, and the security of that information. However, those reviews must be part of those applications’ specifications, not the host-meta document.


[1.d] I have no specific concerns or issues with this document.

It has evolved from an earlier “site-meta” draft (draft-nottingham-site-meta) over an 18 month period with numerous versions addressing issues to reach a state ready for publication.


[1.e] The document is an individual submission, not a working group product, so there isn’t a specific IETF WG in which to gauge consensus. The document have been discussed on apps-discuss@ietf.org, where an open discussion has resolved a handful of issues. There has been strong consensus in the WebFinger community and the parts of the Internet identity community interested in host-meta. The strongest evidence is perhaps experimental (but operational) implementations by GMail (Google), Yahoo, and others.

The document has explicitly dropped a number of features during its development (such as a special  element, and more complex URI templates) that didn’t achieve consensus. The resulting document reflects decent consensus.


[1.f] There are no known threats to appeal. There has been no extreme discontent.


[1.g] I have verified that the document satisfies all ID nits.


[1.h] The document has no informative references so there is only a normative references section.

There are no references to Internet-drafts.

There is 1 non-IETF reference: to an OASIS standard (XRD-1.0), which can be considered stable.


[1.i] An “IANA considerations” section exists and is consistent with the body of the document.

Two well-known URIs (“host-meta” and “host-meta.json”) are registered in the Well-Known URI Registry.

A relation type (“lrdd”) is registered in the Link Relation Type Registry.

No new registries are created.


[1.j] The ABNF in the document validates correctly.

The XML examples in the document validate correctly.


[1.k] DOCUMENT ANNOUNCEMENT WRITE-UP

Technical Summary

  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.

  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. An alternative JSON
  syntax is also defined.

  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 is not a WG product. Open discussion occurred in the
  IETF (Applications Area), W3C (www-talk list), OASIS (XRI group),
  WebFinger community, and OpenID community. Many discussions
  on 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

  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 yahoo.com
  and gmail.com). The WebFinger community have been actively working
  with host-meta for personal web discovery. Host-meta is being considered
  for future enhancements to OpenID.

  Host-meta is primarily the combination of three existing specifications:
  XRD 1.0 from OASIS; Web Linking (popularised by HTML and Atom); and
  Well-Known URIs [RFC5785].

Personnel

  James Manger is the document shepherd.

  Peter Saint-Andre is the responsible Area Director.

  The Designated Expert for the IANA registry referenced in this
  document is Mark Nottingham.
2011-06-30
17 Peter Saint-Andre Ballot writeup text changed
2011-06-27
17 Peter Saint-Andre Telechat date has been changed to 2011-07-14 from 2011-06-30
2011-06-23
17 Peter Saint-Andre State changed to IESG Evaluation from In Last Call.
2011-06-23
17 Peter Saint-Andre Telechat date has been changed to 2011-06-30 from 2011-07-14
2011-06-23
17 Peter Saint-Andre [Note]: 'The Document Shepherd is James Manger .' added
2011-06-23
17 Cindy Morgan Telechat date has been changed to 2011-07-14 from 2011-06-30
2011-06-23
17 Peter Saint-Andre Telechat date has been changed to 2011-06-30 from 2011-07-14
2011-06-17
17 Samuel Weiler Assignment of request for Last Call review by SECDIR to Kurt Zeilenga was rejected
2011-06-15
17 Amanda Baber
Upon approval of this document, IANA understands it must complete three
actions.

First, in the Well Known URI registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

the following well-known …
Upon approval of this document, IANA understands it must complete three
actions.

First, in the Well Known URI registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

the following well-known URI will be added to the registry:

URI suffix: host-meta
Change controller: IETF
Specification document(s): [ RFC-to-be ]
Related information: The "host-meta" documents obtained from the same
host using the HTTP and HTTPS protocols (using default ports) MUST be
identical.

Second, also in the Well Known URI registry located at:

http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

the following well-known URI will be added to the registry:

URI suffix: host-meta.json
Change controller: IETF
Specification document(s): [ RFC-to-be ]
Related information: The "host-meta.json" documents obtained from the
same host using the HTTP and HTTPS protocols (using default ports) MUST
be identical.

Third, in the Link Relations registry located at:

http://www.iana.org/assignments/link-relations/link-relations.xhtml

the following link relation will be added to the registry:

Relation Name: lrdd

Description: Refers to further information about the link's context,
expressed as a LRRD ("Link-based Resource Descriptor Document")
resource. See [ RFC-to-be ] for information about processing this
relation type in host-meta documents.
When used elsewhere, it refers to additional links and other metadata.
Multiple instances indicate additional LRRD resources. LRRD resources
MUST have an "application/xrd+xml" representation, and MAY have others.

Reference: [ RFC-to-be ]

IANA understands that these three actions are the only ones that need to
be completed upon approval of the document.
2011-06-03
17 Peter Saint-Andre Placed on agenda for telechat - 2011-07-14
2011-06-03
17 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2011-06-03
17 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2011-06-01
17 Cindy Morgan Last call sent
2011-06-01
17 Cindy Morgan
State changed to In Last Call from Publication Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: …
State changed to In Last Call from Publication Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Second Last Call:  (Web Host Metadata) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Web Host Metadata'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification describes a method for locating host metadata as
  well as information about individual resources controlled by the
  host.

Editorial Note (to be removed by RFC Editor)

  Please discuss this draft on the apps-discuss@ietf.org [1] mailing
  list.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-hammer-hostmeta/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-hammer-hostmeta/


No IPR declarations have been submitted directly on this I-D.


2011-06-01
17 Cindy Morgan Last Call text changed
2011-06-01
17 Peter Saint-Andre Ballot writeup text changed
2011-06-01
17 Peter Saint-Andre Status Date has been changed to None from 2010-06-24
2011-06-01
17 Peter Saint-Andre State changed to Publication Requested from Waiting for AD Go-Ahead::AD Followup.
2011-05-20
16 (System) New version available: draft-hammer-hostmeta-16.txt
2011-05-09
15 (System) New version available: draft-hammer-hostmeta-15.txt
2011-04-16
17 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-04-16
14 (System) New version available: draft-hammer-hostmeta-14.txt
2010-11-08
17 Peter Saint-Andre State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Peter Saint-Andre
2010-07-30
17 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Kurt Zeilenga.
2010-07-23
17 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2010-06-28
17 Amanda Baber
IANA comments:

Upon approval of this document, IANA understands it must complete two
actions.

First, in the Well Known URI registry located at:
http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
the …
IANA comments:

Upon approval of this document, IANA understands it must complete two
actions.

First, in the Well Known URI registry located at:
http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
the following well-known URI will be added to the registry:

URI suffix: host-meta
Change controller: IETF
Specification document(s): [RFC-hammer-hostmeta-13]
Related information: None

Second, in the Link Relations registry located at:
http://www.iana.org/assignments/link-relations/link-relations.xhtml
the following link relation will be added to the registry:

Relation Name: lrdd

Description: "lrdd" (pronounced 'lard') is an acronym for Link-based
Resource Descriptor Document. It is used by the host-meta document
processor to locate resource-specific information about individual
resources.

Reference: [RFC-hammer-hostmeta-13]

Note: When used elsewhere (e.g. HTTP "Link" header fields or HTML
elements), it operates as an include directive, identifying the location
of additional links and other metadata. Multiple links with the 'lrdd'
relation indicate multiple sources to include, not alternative sources
of the same information. An "application/xrd+xml" representation MUST be
available, and this media type MAY appear in a link's "type" attribute.
Additional representations MAY be available (using HTTP content
negotiation), in which case the link's 'type' attribute SHOULD be omitted.

IANA understands that these actions are the only ones that need to be
completed upon approval of the document.
2010-06-25
17 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2010-06-25
17 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2010-06-25
17 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2010-06-24
17 Peter Saint-Andre Status date has been changed to 2010-06-24 from
2010-06-24
17 Peter Saint-Andre Last Call was requested by Peter Saint-Andre
2010-06-24
17 Peter Saint-Andre State Changes to Last Call Requested from Publication Requested by Peter Saint-Andre
2010-06-24
17 (System) Ballot writeup text was added
2010-06-24
17 (System) Last call text was added
2010-06-24
17 (System) Ballot approval text was added
2010-06-15
17 Peter Saint-Andre Intended Status has been changed to Proposed Standard from None
2010-06-15
17 Peter Saint-Andre Note field has been cleared by Peter Saint-Andre
2010-06-15
13 (System) New version available: draft-hammer-hostmeta-13.txt
2010-06-09
12 (System) New version available: draft-hammer-hostmeta-12.txt
2010-06-08
11 (System) New version available: draft-hammer-hostmeta-11.txt
2010-05-25
10 (System) New version available: draft-hammer-hostmeta-10.txt
2010-05-24
09 (System) New version available: draft-hammer-hostmeta-09.txt
2010-05-11
08 (System) New version available: draft-hammer-hostmeta-08.txt
2010-05-10
07 (System) New version available: draft-hammer-hostmeta-07.txt
2010-05-03
17 Peter Saint-Andre State Changes to Publication Requested from AD is watching by Peter Saint-Andre
2010-05-03
17 Alexey Melnikov Area acronymn has been changed to app from gen
2010-04-30
17 Peter Saint-Andre Draft Added by Peter Saint-Andre in state AD is watching
2010-04-30
06 (System) New version available: draft-hammer-hostmeta-06.txt
2009-11-20
05 (System) New version available: draft-hammer-hostmeta-05.txt
2009-11-10
04 (System) New version available: draft-hammer-hostmeta-04.txt
2009-11-09
03 (System) New version available: draft-hammer-hostmeta-03.txt
2009-10-26
02 (System) New version available: draft-hammer-hostmeta-02.txt
2009-10-23
01 (System) New version available: draft-hammer-hostmeta-01.txt
2009-10-19
00 (System) New version available: draft-hammer-hostmeta-00.txt