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

Robert Sparks <rjsparks@nostrum.com> Thu, 11 December 2014 15:37 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06F21A1BE3; Thu, 11 Dec 2014 07:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaeGwFdF8WPK; Thu, 11 Dec 2014 07:37:23 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16DD71A1BCB; Thu, 11 Dec 2014 07:37:23 -0800 (PST)
Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBBFbGLq004207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 09:37:17 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local
Message-ID: <5489BA27.4060401@nostrum.com>
Date: Thu, 11 Dec 2014 09:37:11 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, julian.reschke@gmx.de
Subject: Gen-Art LC review: status-change-http-status-code-308-ps-01
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/vs0xps2VmLMdpaquea5ZXNApmuQ
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Dec 2014 15:37:25 -0000

-------------------------------------------------------------------

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?

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.

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

RjS