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

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".)

  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?

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?