Additional HTTP Status Codes
RFC 6585

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

(Pete Resnick) Yes

Comment (2012-01-28 for -)
No email
send info
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) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-01-30 for -)
No email
send info
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.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-01-31 for -)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2012-01-29 for -)
No email
send info
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


(David Harrington) No Objection

(Russ Housley) No Objection

(Dan Romascanu) No Objection

Comment (2012-02-02 for -)
No email
send info
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. 

(Robert Sparks) No Objection

Comment (2012-01-31 for -)
No email
send info
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?

(Sean Turner) No Objection

Comment (2012-02-01 for -)
No email
send info
A total nit, should h1 match the title in s4?

<h1>Too many Requests</h1>

i.e., r/many/Many