Re: [Gen-art] Gen-ART LC/Telechat review of draft-reschke-http-status-308-05

Peter Saint-Andre <stpeter@stpeter.im> Mon, 12 March 2012 17:48 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDAE21F89AD; Mon, 12 Mar 2012 10:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.418
X-Spam-Level:
X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NjfTDQbFlfY; Mon, 12 Mar 2012 10:48:29 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 436C821F89AC; Mon, 12 Mar 2012 10:48:29 -0700 (PDT)
Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A3FEE40058; Mon, 12 Mar 2012 12:00:44 -0600 (MDT)
Message-ID: <4F5E36EA.3080309@stpeter.im>
Date: Mon, 12 Mar 2012 11:48:26 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <27FD8C7A-7636-4D60-A65E-C2B264857A0E@nostrum.com> <4F5E2F65.1000706@gmx.de>
In-Reply-To: <4F5E2F65.1000706@gmx.de>
X-Enigmail-Version: 1.3.5
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ben Campbell <ben@nostrum.com>, "gen-art@ietf.org Review Team" <gen-art@ietf.org>, The IETF <ietf@ietf.org>, draft-reschke-http-status-308.all@tools.ietf.org
Subject: Re: [Gen-art] Gen-ART LC/Telechat review of draft-reschke-http-status-308-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Mar 2012 17:48:30 -0000

On 3/12/12 11:16 AM, Julian Reschke wrote:
> On 2012-03-12 17:15, Ben Campbell wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>gt;.
>>
>> Please wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>>
>> Document: draft-reschke-http-status-308-05
>> Reviewer: Ben Campbell   
>> Review Date: 2012-03-12
>> IETF LC End Date: 2012-03-16
>> IESG Telechat date: 2012-03-15
>>
>> Summary: This draft is basically ready for publication as an
>> experimental RFC. I have a few minor comments that might be worth
>> considering whether they would improve the document prior to publication.
>>
>> Note: Since this draft is on a Telechat that precedes the end of the
>> IETF Last Call, this review serves as both the LC and Telechat review.
> 
> Thanks.
> 
>> Major issues:
>>
>> None:
>>
>> Minor issues:
>>
>> -- 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?)
> 
> The draft uses *exactly* the same words as the base spec (HTTPbis),
> except that it combines aspects of 302 (permanence) with those of 307. I
> thought that's clear enough.
> 
>> -- 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.
> 
> We don't state it in HTTPbis either. 301, 302, and 303 are exceptions.
> See the new introduction in
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.7.3>.
> 
> 
>> -- section 3, 1st paragraph: "Clients with link-editing capabilities
>> ought to..."
>>
>> Should that be stated normatively?
> 
> No. Again, this is consistent with the text in HTTPbis for status code 302.
> 
>> -- 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?
> 
> Again, consistency with RFC 2616 and HTTPbis.
> 
>> -- 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?
> 
> No, it's a hack that makes deployment easier until all UAs do the right
> thing; we don't want to make that permanent.
> 
>> Nits/editorial comments:
>>
>> None
> 
> Note that I have an updated version waiting to be submitted in two weeks
> (or earlier, if the AD allows me to). It updates references, and adds an
> informative ref to the HTML spec, as suggested during LC. See
> <http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest.html>.

<hat type='AD'/>

Julian, I think it would be helpful for you to submit your latest copy
before the deadline today, so that we don't need to wait until March 26.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/