Metalink/HTTP: Mirrors and Hashes
RFC 6249
Note: This ballot was opened for revision 22 and is now closed.
(Alexey Melnikov) (was Discuss, Yes, Discuss, Yes) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) (was Discuss) No Objection
Comment (2011-02-16)
No email
send info
send info
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.
(Lars Eggert) (was Discuss) No Objection
Comment (2011-03-10)
No email
send info
send info
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?
(Adrian Farrel) No Objection
Comment (2011-03-01 for -)
No email
send info
send info
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.
(Russ Housley) No Objection
(Tim Polk) No Objection
Comment (2011-02-16 for -)
No email
send info
send info
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.
(Dan Romascanu) (was Discuss) No Objection
Comment (2011-03-09)
No email
send info
send info
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.