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

On 2012-01-14 16:18, Bjoern Hoehrmann wrote:
> * 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

- what's the problem with the title?
- why do I need to specify encoding? It's all US-ASCII
- validator.nu says it's happy once I had the HTML4 strict doctype; 
would that work for you?

>    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 RFC Editor rewrites this part upon publication.

> The RFC3986 reference seems non-normative to me.

May be.

> 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'll monitor what happens with draft-nottingham-http-new-status, just 
out of LC which looks similar to me. (It also has "invalid" HTML, why 
didn't you complain? :-)

> 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?

I'd prefer to use language consistent with RFC 2616.

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

Again, this is consistent with RFC 2616 and HTTPbis (for now).

We may want to tune the text in HTTPbis (please follow up over there), 
in which case I'll apply the same changes to the spec for 308.

Best regards, Julian

Received on Saturday, 14 January 2012 15:28:58 UTC