HTTP Status Code 308 (Permanent Redirect) to Proposed Standard
status-change-http-status-code-308-ps-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-01-03
|
01 | Barry Leiba | RFC Status Change state changed to Dead from IESG Evaluation |
2015-01-03
|
01 | Barry Leiba | [Ballot discuss] I've removed this from the telechat, and am likely to abandon it in favour of the bis document, to accommodate the minor change … [Ballot discuss] 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. |
2015-01-03
|
01 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to Discuss from Yes |
2015-01-03
|
01 | Barry Leiba | Removed from agenda for telechat |
2015-01-02
|
01 | Spencer Dawkins | [Ballot comment] 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, … [Ballot comment] 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. |
2015-01-02
|
01 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-01-02
|
01 | Stephen Farrell | [Ballot comment] 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 … [Ballot comment] 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. |
2015-01-02
|
01 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-01-01
|
01 | Adrian Farrel | [Ballot 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 … [Ballot 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. |
2015-01-01
|
01 | Adrian Farrel | Ballot discuss text updated for Adrian Farrel |
2014-12-30
|
01 | Adrian Farrel | [Ballot discuss] I'd make an argument that the Standards Track version of this work should be an Update of 7231 since it changes a statement … [Ballot discuss] I'd make an argument that the Standards Track version of this work should be an Update of 7231 since it changes a statement made in that RFC. --- 7238 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. How is this text valid in the Standards Track revision of this document? --- 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. |
2014-12-30
|
01 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2014-12-29
|
01 | Barry Leiba | Placed on agenda for telechat - 2015-01-08 |
2014-12-29
|
01 | Barry Leiba | [Ballot comment] There has been some concern about two things here: 1. Using the status-change mechanism for this purpose in the first place. We can … [Ballot comment] There has been some concern about two things here: 1. Using the status-change mechanism for this purpose in the first place. We can argue about that, but I propose that we not, and that after this document is done we evaluate whether to use this mechanism in future or not. 2. The first two paragraphs of Section 4 (in RFC 7238) appear to be specific to the experimental status, so the question has been raised (by Adrian and by Robert in his Gen-ART review) whether that, itself, is a reason the document should be properly revised. The author, the httpbis working group, and I all think not: while the experiment is over and this is ready for Standards Track, it will be some time before there's wide deployment, and implementations will need to continue to be ready for spotty support of the 308 status code, so the warnings in Section 4 still apply to the Standards Track version, and a revision isn't needed at this time. |
2014-12-29
|
01 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2014-12-29
|
01 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2014-12-29
|
01 | Barry Leiba | Created "Approve" ballot |
2014-12-29
|
01 | Barry Leiba | RFC Status Change state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-12-29
|
01 | (System) | RFC Status Change state changed to Waiting for AD Go-Ahead from In Last Call |
2014-12-01
|
01 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (HTTP Status Code 308 (Permanent … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (HTTP Status Code 308 (Permanent Redirect) to Proposed Standard (from Experimental)) The IESG has received a request from the Internet Engineering Steering Group WG (iesg) to consider the following document: - 'HTTP Status Code 308 (Permanent Redirect) to Proposed Standard' from Experimental The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In 2012, when RFC 7238 was approved, we went for Experimental because it was, indeed, an experiment. Since then, it has been implemented in Firefox and Chrome, and Safari already supported it due to their default handling of 3xx + Location. The experiment is, therefore, over, and was a success. This action moves RFC 7238 to the Standards Track, as Proposed Standard. The file can be obtained via http://datatracker.ietf.org/doc/status-change-http-status-code-308-ps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/status-change-http-status-code-308-ps/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-12-01
|
01 | Cindy Morgan | RFC Status Change state changed to In Last Call from Last Call Requested |
2014-12-01
|
01 | Cindy Morgan | Last call announcement was changed |
2014-12-01
|
01 | Barry Leiba | Last call was requested |
2014-12-01
|
01 | Barry Leiba | Last call announcement was changed |
2014-12-01
|
01 | Barry Leiba | Last call announcement was changed |
2014-12-01
|
01 | Barry Leiba | Last call was requested |
2014-12-01
|
01 | Barry Leiba | Last call announcement was generated |
2014-12-01
|
01 | Barry Leiba | Ballot approval text was generated |
2014-12-01
|
01 | Barry Leiba | Ballot writeup was generated |
2014-12-01
|
01 | Barry Leiba | RFC Status Change state changed to Last Call Requested from AD Review |
2014-12-01
|
01 | Barry Leiba | New version available: status-change-http-status-code-308-ps-01.txt |
2014-07-23
|
00 | Barry Leiba | New version available: status-change-http-status-code-308-ps-00.txt |