Metalink/HTTP: Mirrors and Hashes
draft-bryan-metalinkhttp-22

Section 1...

"extremely minimal" means what? It either minimal or it isn't.

---

Section 3.1

   Entries for mirror servers are listed in order of priority (from most
   preferred to least) or have a "pri" value, where mirrors with lower
   values are used first.

   This is purely an expression of the server's preferences; it is up to
   the client what it does with this information, particularly with
   reference to how many servers to use at any one time.

There is a contradiction between "are used first" and the second
paragraph that says the client can do what it likes. Maybe the word
"priority" and the "pri" value are poor choices since they reflect only
a preference.

If the draft is based on the experiences made in a project the community would like to know more on the project. It would be good to mention in the Introduction section of the draft the open source project, what it does and the experience made based on the project, and also provide a reference to the project in the references section.

My original comment said:

  The document is generally pretty sloppy in its use of
  RFC2119 terms; it would be very good if the authors would go over it
  once more.

The specific instances that I mentioned have been fixed, but I don't see
any other changes. Did the authors go over the document once more?

1) In section 2:

   ETags could be based on the file
   contents (cryptographic hash) and not server-unique filesystem
   metadata.

I'm not sure about the intention of this statement.  Perhaps:

   For example, it would be better to derive an ETag from a
   cryptographic hash of the the file contents than on server-unique
   filesystem metadata.

2) Is there a registry for the various attributes references in this
document, including "pri", "pref", "geo", etc.?  If not, in my opinion
it would be beneficial to give a list and some formal definitions of
the attriubtes; at least, some indication that the attributes are
defined in this document.

I support Sean's discuss on signature formats.  There is nothing wrong with OpenPGP, and it would be fine to make that the mandatory to implement, but the installed base with X.509 would seem to justify including S/MIME signatures.

I also share Robert's and Peter's concerns about amplification and DoS attacks.