Web Host Metadata
RFC 6415

Note: This ballot was opened for revision 17 and is now closed.

(Peter Saint-Andre) Yes

(Jari Arkko) No Objection

Comment (2011-07-14 for -)
No email
send info
 The JRD document format - a general purpose XRD 1.0 represenation -

s/represenation/representation/

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-07-13)
No email
send info
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//

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2011-07-11 for -)
No email
send info
  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.

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2011-07-11 for -)
No email
send info
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.