Prefer Header for HTTP

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

(Barry Leiba) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-10-24 for -16)
No email
send info
-16 addressed my other comments, (thanks), not sure if these
were missed or not but don't think I saw any response

- Is "relation types" correct in section 4, 1st para?

- 4.3, where is delta-seconds defined?

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Pete Resnick) (was Discuss) No Objection

(Robert Sparks) No Objection

Comment (2012-10-23 for -15)
No email
send info
Given that the document points to the similarity between Prefer and Expect, consider being explicit about not using tokens defined for Prefer in Expect header fields and vice-versa. You might also provide guidance about whether to use the same token in both if you are defining a behavior that would make sense to use in both places.

Did you consider whether a client would ever need to say "I prefer thing X most, Y if you won't do that, and Z if you wont't do that"? Does anything here prevent adding something later that would capture that semantic? (I don't think so, parameters could be added to group preferences and give them weights for instance).

Why isn't the SHOULD in "The Prefer header field is end-to-end and SHOULD be forwarded unless" not a MUST?

Do you want to say anything about the order of parameters on a given header field value being significant or not? (Do you inherit a not from the base spec?)

(Martin Stiemerling) No Objection

(Sean Turner) No Objection