Re: Gen-Art LC review: status-change-http-status-code-308-ps-01

On 2014-12-11 16:37, Robert Sparks wrote:
> -------------------------------------------------------------------
>
> I am the assigned Gen-ART reviewer for this
> draft^H^H^H^H^Hstatus-change. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: status-change-http-status-code-308-ps-01
> Reviewer: Robert Sparks
> Review Date: 11 Dec 2014
> IETF LC End Date: 29 Dec 2014
> IESG Telechat date: Not yet scheduled for a telechat
>
> Summary: While 308 should move to Proposed Standard, this status-change
> document has serious issues, and should be reconsidered.
>
> Major issues:
>
> There is a conflict between this status-change document's statement that
> "the experiment is, therefore, over, and was a success" and the
> instructions to republish RFC7238 without change except to the boilerplate.
>
> The status-change document argues that the successful implementation of
> 308 in the vast majority of deployed browsers is sufficient to end the
> experiment.
> If so, the guidance in a republished RFC7238 section 4 would be unclear
> (and inappropriate for general deployment on the Internet). Isn't the
> restriction in the second paragraph the essence of the experiment?
>
> Specifically:
> "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."
>
> The intent of this status change is to move us past this "initial use"
> and loosen this restriction on application deployment is it not?

Not really.

Just because we have now evidence that the new status code *can* be 
deployed doesn't necessarily mean that you can rely on it being 
supported. Think old browser versions, ancient command line tools, whatnot.

To me "Proposed Standard" means "we believe this can be implemented". It 
does not mean "it is implemented everywhere".

> While I support moving 308 to Proposed Standard, I don't think this is
> the right way to do it, and recommend a draft that updates section 4
> instead.

I agree that the text in Section 4 could use some fine-tuning, but I 
disagree that it should be dropped altogether,

> (It might be tempting to address this (if people agree with it) by
> adding an RFC Editor note to the status-change rather than using a
> draft. Please don't.)

Agreed. As a matter of fact we *did* start with a new draft 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-rfc7238bis-latest.html>), 
but this was put on hold to run the experiment with the status change 
document...

Best regards, Julian

Received on Thursday, 11 December 2014 16:28:49 UTC