Skip to main content

The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)
RFC 7238

Yes

(Peter Saint-Andre)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)
(Sean Turner)
(Stephen Farrell)
(Stewart Bryant)

Note: This ballot was opened for revision 05 and is now closed.

Peter Saint-Andre Former IESG member
Yes
Yes (for -05)

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-03-12 for -06)
I have no objection to the publication of this document.

In section 3 you have "ought".
It might be nice to use a RFC 2119 word for this.

---

Section 3 also contains two instances of "SHOULD". It would be good to
explain (often a "MAY") why these are not "MUST". (I think the exsiting
"MAY" applies as a varience to the "ought".)
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -06)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -06)

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -06)

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -06)

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -06)

                            
Russ Housley Former IESG member
No Objection
No Objection (2012-03-15 for -06)
  The Gen-ART Review by Ben Campbell on 12-Mar-2012 includes several
  minor issues.  They are:

  -- General: I see some discussion about existing UA behavior, but
     nothing about what a UA should do with a 308 other than as an
     implication the fact that this is a "permanent version of 307".
     It's probably worth describing that explicitly. (Or is that what
     the "clients with link-editing capabilities" statement is
     intended to do? If so, does that cover everything?)

  -- Section 1, last paragraph: The fact that a 308 can't change the
     method is left as an implication of being based on 307. It would
     be good to state that explicitly and normatively here.

  -- Section 3, 1st paragraph: "Clients with link-editing capabilities
     ought to..."  Should that be stated normatively?

  -- Section 3, third paragraph: "The new permanent URI SHOULD be
     given..."  I'm curious why that is not a MUST. Is there a
     reasonable (i.e. interoperable)  way to send a 308 _without_ a
     URI in the location field? Is the meta refresh directive something
     that can be used _instead_ of the Location header field?

  -- Section 4: The example uses _both_ the location field and the
     HTML <meta> refresh directive. Is this considered a recommended
     practice to the degree you might normatively recommend it in the
     text?
Sean Turner Former IESG member
No Objection
No Objection (for -06)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -06)

                            
Stewart Bryant Former IESG member
No Objection
No Objection (for -05)

                            
Wesley Eddy Former IESG member
No Objection
No Objection (2012-03-11 for -05)
The writeup doesn't mention why this isn't just part of the httpbis specifications, since it was apparently fine with the working group and received positive comments there.  Why did it have to be done as AD-sponsored, and why is the target Experimental?