Additional HTTP Status Codes
draft-nottingham-http-new-status-04
Yes
(Peter Saint-Andre)
No Objection
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Wesley Eddy)
Note: This ballot was opened for revision 04 and is now closed.
Pete Resnick Former IESG member
Yes
Yes
(2012-01-28)
Unknown
Section 3: Responses using this status code SHOULD explain how to resubmit the request successfully. For example: The SHOULD seems a little overdone. There's no protocol interoperability issue here AFAICT. Perhaps just, "The body of the response is used for an explanation of how to resubmit the request successfully." Or just lowercase the should. Section 4: The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request. Same issue as above, for both the SHOULD and the MAY. Also, I'm not sure I know what a "response representation" is. Term of art? Section 5: ...the response representation SHOULD specify which header field was too large. Same issue as above. Section 6: The response representation SHOULD indicate how to do this; e.g., with an HTML form for submitting credentials. Similar issue to the above, however made a bit stranger by the text in 6.1: Note that the 511 response can itself contain the login interface, but it may not be desirable to do so, because browsers would show the login interface as being associated with the originally requested URL, which may cause confusion. Those two seem to conflict.
Peter Saint-Andre Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-01-31)
Unknown
This Comment does not quite merit a Discuss, but I hope the authors will think about whether they can address it. I would have liked to see some discussion of backward compatibility. Obviously, legacy implementations may receive these new codes in the normal course of affairs. I am sure that default behavior for unknown codes is described somewhere, so one line of text with a reference will cover the default case. However, this document appears to define some mandatory behavior for nodes that see the new codes - it would be good to show how this is consistent with legacy implementations.
Dan Romascanu Former IESG member
No Objection
No Objection
(2012-02-02)
Unknown
Robert and Adrian made already the point in the COMMENTs - if backwards compatibility is not a prblem it would be good to be explicit why - i.e. describe or refer to text that describes what happens at the reception of an unknown status code.
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2012-01-31)
Unknown
It would help to call out why these codes can be deployed into the existing base without disruption (existing implementations treat unknown messages in a class as the x00 in that class - RFC2616 6.1.1) and explain how the restrictions on not caching these responses are related to RFC2616 13.4. Given the potential consequence called out for including a login interface in a 511 at the end of section 6.1, I'm surprised this language is "may not be desirable". Why isn't this SHOULD NOT?
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2012-02-01)
Unknown
A total nit, should h1 match the title in s4? <h1>Too many Requests</h1> i.e., r/many/Many
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-01-29)
Unknown
You might note that the 511 code doesn't help to avoid the problem of an intercepting proxy having to fake out the X.509 certificate of the user's target server. (I don't mind if you don't add that.) Please also continue the discussion started from Steve Hanna's secdir review. [1] I believe some of those changes are agreed but not yet made, while others are still being discussed. [1] https://www.ietf.org/ibin/c5i?mid=6&rid=48&gid=0&k1=933&k3=10932&tid=1327720307
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-01-30)
Unknown
The term substrate protocol is not a term I have seen in the lower layers of the net. Perhaps the authors should provide a reference to a definition of the term.
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown