Subject: I-D Action: draft-ietf-httpbis-rfc7238bis-02.txt

From: [email-masked]
Date: Wed, 14 Jan 2015 01:00:35 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Working Group of the IETF.

        Title           : The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)
        Author          : Julian F. Reschke
	Filename        : draft-ietf-httpbis-rfc7238bis-02.txt
	Pages           : 6
	Date            : 2015-01-14

Abstract:
   This document specifies the additional Hypertext Transfer Protocol
   (HTTP) status code 308 (Permanent Redirect).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc7238bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpbis-rfc7238bis-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rfc7238bis-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Jan 2015 10:51:41 +0100

On 2015-01-14 10:00, [email-masked] wrote:
> ...

So we gave up on trying to change the status of RFC 7238 in place 
(<https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0020.html>), 
thus a new draft.

Except for boilerplate changes, the differences compared to RFC 7238 are:

> Section 1., paragraph 4:
> OLD:
>
>     Section 6.4.7 of [RFC7231] states that HTTP does not define a
>     permanent variant of status code 307; this specification adds the
>     status code 308, defining this missing variant (Section 3).
>
> NEW:
>
>     Section 6.4.7 of [RFC7231] states that it does not define a permanent
>     variant of status code 307; this specification adds the status code
>     308, defining this missing variant (Section 3).
>
>     This specification contains no technical changes from the
>     experimental RFC 7238, which it obsoletes.

One clarification, one additional statement explaining what's going on.

> Section 4., paragraph 2:
> OLD:
>
>     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.  Server implementers are advised
>     not to vary the status code based on characteristics of the request,
>     such as the User-Agent header field ("User-Agent Sniffing") -- doing
>     so usually results in code that is both hard to maintain and hard to
>     debug and would also require special attention to caching (i.e.,
>     setting a "Vary" response header field, as defined in Section 7.1.4
>     of [RFC7231]).
>
> NEW:
>
>     Therefore, the use of status code 308 is 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.  Server implementers are advised not to vary the
>     status code based on characteristics of the request, such as the
>     User-Agent header field ("User-Agent Sniffing") -- doing so usually
>     results in code that is both hard to maintain and hard to debug and
>     would also require special attention to caching (i.e., setting a
>     "Vary" response header field, as defined in Section 7.1.4 of
>     [RFC7231]).

Rephrased because this advice continues to be true (thus not really 
about "initial" use anymore).

> Section 4., paragraph 3:
> OLD:
>
>     Note that many existing HTML-based user agents will emulate a refresh
>     when encountering an HTML <meta> refresh directive ([HTML]).  This
>     can be used as another fallback.  For example:
>
> NEW:
>
>     Note that many existing HTML-based user agents will emulate a refresh
>     when encountering an HTML <meta> refresh directive ([HTML], Section
>     4.2.5.3).  This can be used as another fallback.  For example:
>
>
> Section 4., paragraph 7:
> OLD:
>
>       HTTP/1.1 308 Permanent Redirect
>       Content-Type: text/html; charset=UTF-8
>       Location: http://example.com/new
>       Content-Length: 454
>
> NEW:
>
>       HTTP/1.1 308 Permanent Redirect
>       Content-Type: text/html; charset=UTF-8
>       Location: http://example.com/new
>       Content-Length: 356
>
>
> Section 4., paragraph 8:
> OLD:
>
>       <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>                             "http://www.w3.org/TR/html4/strict.dtd">
>       <html>
>          <head>
>             <title>Permanent Redirect</title>
>             <meta http-equiv="refresh"
>                   content="0; url=http://example.com/new">
>          </head>
>          <body>
>             <p>
>                The document has been moved to
>                <a href="http://example.com/new"
>                >http://example.com/new</a>.
>             </p>
>          </body>
>       </html>
>
> NEW:
>
>       <!DOCTYPE HTML>
>       <html>
>          <head>
>             <title>Permanent Redirect</title>
>             <meta http-equiv="refresh"
>                   content="0; url=http://example.com/new">
>          </head>
>          <body>
>             <p>
>                The document has been moved to
>                <a href="http://example.com/new"
>                >http://example.com/new</a>.
>             </p>
>          </body>
>       </html>

Updated to use HTML 5.

> Section 6., paragraph 1:
> OLD:
>
>     The registration below has been added to the "Hypertext Transfer
>     Protocol (HTTP) Status Code Registry" (defined in Section 8.2 of
>     [RFC7231] and located at
>     <http://www.iana.org/assignments/http-status-codes>):
>
> NEW:
>
>     The "Hypertext Transfer Protocol (HTTP) Status Code Registry"
>     (defined in Section 8.2 of [RFC7231] and located at
>     <http://www.iana.org/assignments/http-status-codes>) needs to be
>     updated with the registration below:

Administrative.

> Section 7., paragraph 2:
> OLD:
>
>     Furthermore, thanks to Ben Campbell, Cyrus Daboo, Eran Hammer-Lahav,
>     Bjoern Hoehrmann, Subramanian Moonesamy, Peter Saint-Andre, and
>     Robert Sparks for feedback on this document.
>
> NEW:
>
>     Furthermore, thanks to Ben Campbell, Cyrus Daboo, Adrian Farrell,
>     Eran Hammer-Lahav, Bjoern Hoehrmann, Barry Leiba, Subramanian
>     Moonesamy, Peter Saint-Andre, and Robert Sparks for feedback on this
>     document.

...and thanks for feedback!

>
> Section 8.2., paragraph 1:
> OLD:
>
>     [HTML]     Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
>                Specification", W3C Recommendation REC-html401-19991224,
>                December 1999,
>                <http://www.w3.org/TR/1999/REC-html401-19991224>.
>
>                Latest version available at
>                <http://www.w3.org/TR/html401>.
> NEW:
>
>     [HTML]     Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle
>                Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C
>                Recommendation REC-html5-20141028, October 2014,
>                <http://www.w3.org/TR/2014/REC-html5-20141028/>.
>
>                Latest version available at <http://www.w3.org/TR/html5/>.

Updated reference.

Side-by-side diffs are here: 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-rfc7238bis-latest-from-rfc7238.diff.html>>

Best regards, Julian