HTTP Status Code 308 (Permanent Redirect) to Proposed Standard
status-change-http-status-code-308-ps-01
Discuss
No Objection
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Ballot question: "Do we approve these RFC status changes?"
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Adrian Farrel Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2015-01-01)
Unknown
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.
Barry Leiba Former IESG member
(was Yes)
Discuss
Discuss
[Treat as non-blocking comment]
(2015-01-03)
Unknown
I've removed this from the telechat, and am likely to abandon it in favour of the bis document, to accommodate the minor change that Adrian is asking for: I agree that the change would be good, and, despite the appeal (in the good sense) of using status-change in this way, I think it's turning out to be impractical, as the chances that an Experimental document can really be moved to Standards Track with no changes to the body at all are pretty low.
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-01-02)
Unknown
We're already having a chat about the suitability of using a status change in this case, and I'm following that chat with interest, but I'm not going to get in the way if the rest of the IESG thinks this is OK.
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-01-02)
Unknown
I'm not sure if this route or a bis RFC is best in this case. Whichever works is fine by me though. I've a preference for less paper-work though so if this route works, it's a little better.