HTTP Status Code 308 (Permanent Redirect) to Proposed Standard
status-change-http-status-code-308-ps-01

[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.

[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.

[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.

[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.

[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.

[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.

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.