Re: informal Last Call on draft-reschke-http-status-308-02

* Julian Reschke wrote:
>I just submitted a new revision of draft-reschke-http-status-308 - see 
>below (HTML version at 
><http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-02.html>).
>
>At this point, I'd like to solicit additional feedback before I submit 
>this to the IESG (which I plan to do in two weeks from now).

Your HTML example has a bad <title> and doesn't even validate, never
minding the lack of character encoding information in the sample re-
sponse. I would suggest something like

  HTTP/1.1 308 Permanent Redirect
  Content-Type: text/html;charset=utf-8
  Location: http://example.com/new

  ...
  <meta http-equiv='refresh' content='0; url=http://example.com/new'>
  ...

which would avoid the stylistic problems in addition to being much
shorter.

In the IANA Considerations I think it is better to say something like
"This document adds such and such to registry so and so" or whatever,
rather than the imperative, as the "shall" will be weird after IANA
added it, and not having to change such text is better than having to.

The RFC3986 reference seems non-normative to me.

Back when someone at the IETF secretariat checked internet drafts prior
to posting them, I had one rejected because the Abstract was too short.
Your Abstract is much shorter, it might be a good idea to add a sentence
what the status code is for.

I think you need a better term for "permanent URI". How about simply re-
moving the "permanent" and possibly adding "new" to the second instance?

The fallback requirement

  Unless the request method was HEAD, the representation of the response
  SHOULD contain a short hypertext note with a hyperlink to the new
  URI(s), since most user agents do not understand the 308 status code
  yet. Therefore, the note SHOULD contain the information necessary for
  a user to repeat the original request on the new URI.

strikes me as a bad idea. It's a transient problem so it should be con-
ditioned and how widely supported this is, and it's only useful if you
have some HTML implementation on the other end or an interactive user; a
web service not meant for interactive use where you can be sure that the
code is supported, because, say, you control the client, is unaffected,
and if you add that as another exception you basically end up saying you
can do this so your site works better with legacy clients in some situ-
ations and making your site work good is probably a good idea, so I'd
prefer just saying that. I don't really want to ponder whether I should
send this hypertext response in response to an OPTIONS request in 2015,
just because your specification says I should.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Saturday, 14 January 2012 15:19:27 UTC