Web Host Metadata
draft-hammer-hostmeta-17

[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)

[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//

[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)

[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.

[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.

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.

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.

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.

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.