Adrian Farrel's Discuss on status-change-http-status-code-308-ps-01: (with DISCUSS)

Adrian Farrel has entered the following ballot position for
status-change-http-status-code-308-ps-01: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/status-change-http-status-code-308-ps/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Discussion with Barry helps me understand that this is genuinely NOT an
update of 7231. He says that new implementations of HTTP 1.1 may freely
choose to not support 308 and that that is in the spirit of 7231 and of
this work.

This leads, however and supported by discussions with Julian, to an
increased opinion that the word "initial" is not appropriate in a
standards track version of 7238 where it says:

   Therefore, initial use of status code 308 will be restricted to cases
   where the server has sufficient confidence in the client's
   understanding the new code or when a fallback to the semantics of
   status code 300 is not problematic. 

In fact, it sounds as though this restriction will effectively be for all
time, or at least until our understanding of the deployed base indicates
that the restriction can be lifted. Thus, I think this paragraph should
be rewritten in more current terms such as:

   Therefore, the use of status code 308 is restricted to cases
   where the server has sufficient confidence in the client's
   understanding of the code or when a fallback to the semantics of
   status code 300 is not problematic. 

But I would prefer even more deliberate language (maybe even 2119
language) because "sufficient confidence" is a term implying
quantification of assessment. While an AI might achieve that, I think a
spec can be clearer about what process is used by the server to determine
the client's understanding of 308.

---

And for IESG consideration...

I really wish the IESG would complete the work on documenting the use of
"status-change documents" before using them. All I can see is the IESG
Statement at 
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
yet that statement doesn't mention any transition except to Historic. 
Case law is all well and good, and this approach of using a status-
change document may be very applicable in this case, but it would not be
hard to make an IESG statement on the general applicability of status-
change documents so that everyone knows what is going on.

Received on Wednesday, 14 January 2015 08:11:44 UTC