Re: [Gen-art] Gen-ART review of draft-snell-http-prefer-14
Martin Thomson <martin.thomson@gmail.com> Fri, 12 October 2012 18:58 UTC
Return-Path: <martin.thomson@gmail.com>
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 BC7AA21F859A for <gen-art@ietfa.amsl.com>; Fri, 12 Oct 2012 11:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.899
X-Spam-Level:
X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlMMQ+du85Ww for <gen-art@ietfa.amsl.com>; Fri, 12 Oct 2012 11:58:35 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81F6A21F8574 for <gen-art@ietf.org>; Fri, 12 Oct 2012 11:58:34 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id k13so2525645lbo.31 for <gen-art@ietf.org>; Fri, 12 Oct 2012 11:58:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=u4YTPD6VzCaGTrqM94Wk4uve851K17W46D/PoXh+vqU=; b=CSLw53QsyGH6acAiNejiwYbMx1+HWCIMRS/w2XYq+C6n8hoKuEUG1RJVpnJJBYCv5/ u8mXi74TRJK+yqLZbq0wn3nka8BuXjeGA0h+r4afhE7bHHrr806VbWeKEYwGMQzvJZmN +Gr6blUkQOWyZbw9CDAtz9bq95Sc/qVNOQ28SlCBLVmxt3biud/ECh9xeNDqtpnA4gjs vYGuaH23JPZrqphhg0N68g6uIM9+9tofJfkwknMnE0bv+gdrFxR7k3ysR6GKfROj/qG4 kN+901CKN+Rlc4UgqLbwsnRt7nKa2tXg7b1pD3ok9FH4U6BPNPRTSCc2NfcVkuI1tE3W pQXw==
MIME-Version: 1.0
Received: by 10.112.47.228 with SMTP id g4mr1897421lbn.21.1350068313500; Fri, 12 Oct 2012 11:58:33 -0700 (PDT)
Received: by 10.112.83.2 with HTTP; Fri, 12 Oct 2012 11:58:33 -0700 (PDT)
In-Reply-To: <CABkgnnU7--Ad+YU3_puVkVfsoAjRCrqn0wd7BJ5j+GBWwPVcuw@mail.gmail.com>
References: <CABkgnnU7--Ad+YU3_puVkVfsoAjRCrqn0wd7BJ5j+GBWwPVcuw@mail.gmail.com>
Date: Fri, 12 Oct 2012 11:58:33 -0700
Message-ID: <CABkgnnUbBZpN1KHxzW91WGrPGhi2Dd=mNSaeUM=xRi1Weonagw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: gen-art@ietf.org, draft-snell-http-prefer.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [Gen-art] Gen-ART review of draft-snell-http-prefer-14
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: Fri, 12 Oct 2012 18:58:35 -0000
I have reviewed -15 of this draft and my major issues have been resolved. This document is ready. On 21 September 2012 16:43, Martin Thomson <martin.thomson@gmail.com> wrote: > Lucky you. 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>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-snell-http-prefer-14 > Reviewer: Martin Thomson > Review Date: 2012-09-21 > IETF LC End Date: 2012-10-12 > > Summary: This document is in pretty good shape. I have a concern over > how Prefer: wait might be implemented that I believe needs to be > addressed prior to publication as Proposed Standard. There are also a > number of additional concerns, though nothing particularly serious. > > Major issues: > > Section 3.4 specifies timing requirements that a server has to act > upon with no good way of gaining the information it needs. It assumes > clock synchronization. Given that terrible clock synchronization is > the default mode of operation for internet hosts, this seems to be a > poor choice. > > In any case, this design forces a server to wait less than the allowed > time in all cases, but gives the server no good information to choose > an appropriate time adjustment. A server has to assume that the > client has already expended some period waiting. Assuming that the > client is going to abandon the request at the identified time, then > the server is obliged to wait less than the entire period, lest the > response be wasted. Even if we assume that clocks are synchronized, > the resolution of Date and wait are capped at a second, so worst case > we have a 1 second window of uncertainty on when the request was sent. > This is worse if there are clock errors, particularly if the client > clock runs ahead of the server. > > I can't see how I would implement this feature so that it behaves > reliably for arbitrary hosts. > > On the other hand, the client has the ability to make its own > determination about clock synchronization and network transit delays. > A single request with wait=0 would provide a good measurement of total > non-server delays, without any quantization noise (Date is rounded or > trimmed to the second, which makes this determination difficult). The > client could then adjust the value of the wait preference to account > for what it learns, with the server being able to then concentrate on > the time elapsed between receipt and sending. Clock differences are > then irrelevant. > > Minor comments: > > In Section 3.2: > > When honoring the "return-representation" preference, the server MUST > include a Content-Location header field specifying the URI of the > resource representation being returned. > > This is a requirement that could be inadvertently violated by servers. > This really isn't what you are intending here. The idea is to ensure > that the returned representation doesn't get mistaken for a > representation of the request URI, *when it is not*. This does not > require 2119 language to convey, though I would agree that a reminder > is necessary here. How about: > > The returned representation might not be a representation for the > effective request > URI [[this is the term du jour, I believe]] when the request > affects another resource. > The Content-Location header can be used to identify the URI of the returned > representation. > > (I'd note that return-representation is less useful for PUT than POST > or PATCH. You don't mention PATCH at all.) > > In Sections 3.2 and 3.3, the mutual exclusivity of these parameters is > handled differently to the strict/lenient parameters. Instead of all > the 2119 stuff, how about: > > The "return-minimal" and "return-representation" preferences are > mutually exclusive directives. A request that contains both preferences > can be treated as though neither were specified. > > Alternatively, did you consider specifying a single preference here? > i.e., Prefer: return=minimal and Prefer: return=representation > > Section 3.5, is it useful to observe that the "strict" preference is > useful for ensuring that all aspects of a request are handled, so that > recoverable errors don't result in important parts of a request being > "missed" by a server? > > Did you consider a single preference here? i.e., Prefer: > processing=strict or Prefer: processing=lenient > > Regarding Section 3.5, which do we assume to be the existing behavior > for a server? strict or lenient? > > I'd ask an IANA considerations expert to look at Section 4.1. Did you > want something other than the strict letter of "Specification > Required"? > > Nits: > > The wording of Section 2.1 is a little contorted. The second > paragraph is a single sentence. "event just potentially" is a little > redundant. Suggest a reword to cover just the key points: > - Prefer is not intended to affect content negotiation. > - If a preference could affect what a cache stores or how it stores > it [httpbis-p6], then the server MUST use Vary: Prefer. This applies > even if the request does not include Prefer. > Caution is always good, but advising its application doesn't improve > the probability of it being applied. > > Example 3 in Section 2.2 implies semantics for the undefined "status" > argument. Doing this begs the question about whether this should have > been specified. Rather than invite such questions, try using a > generic argument with a nonsensical name. (Priority in the previous > example is OK, because it's inherently meaningless anyway.) > > You have a few references that aren't really necessary. I don't see > much relevance in httpbis-p7, for example.
- [Gen-art] Gen-ART review of draft-snell-http-pref… Martin Thomson
- Re: [Gen-art] Gen-ART review of draft-snell-http-… Martin Thomson