#495 WGLC: p4 editorial nits

Julian Reschke <julian.reschke@gmx.de> Fri, 13 September 2013 13:17 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF6721E80A6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Sep 2013 06:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level:
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 NXu+OoeCQ5Jz for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Sep 2013 06:17:01 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0111E8200 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Sep 2013 06:17:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1VKTDq-00063x-Ta for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Sep 2013 13:15:42 +0000
Resent-Date: Fri, 13 Sep 2013 13:15:42 +0000
Resent-Message-Id: <E1VKTDq-00063x-Ta@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1VKTDc-0005zR-Cu for ietf-http-wg@listhub.w3.org; Fri, 13 Sep 2013 13:15:28 +0000
Received: from mout.gmx.net ([212.227.15.18]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1VKTDX-0007df-Jd for ietf-http-wg@w3.org; Fri, 13 Sep 2013 13:15:28 +0000
Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MOOdZ-1VGuJG2mE1-005tso for <ietf-http-wg@w3.org>; Fri, 13 Sep 2013 15:14:55 +0200
Message-ID: <52330FCC.2010400@gmx.de>
Date: Fri, 13 Sep 2013 15:14:52 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ken Murchison <murch@andrew.cmu.edu>
CC: ietf-http-wg@w3.org
References: <5231CE0D.80309@andrew.cmu.edu>
In-Reply-To: <5231CE0D.80309@andrew.cmu.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:zMDAoxkSCeUg3N2sKO5JPET7VSAKZe0z6uuhUNC3VH2pHQwsACl WugXDJjLFDCmMo6artyems8DnAm5cyhdfe/08GwzbYBGjZA9GchYYPk/b3drejXfijVrIKD tnz2M7gAuz41xKTT8ATRcWlbdbDPV1wY9upLWGN+HK8+9PaIp4Y7oU1BUycvLaXu0Vz/8Fg 29IMnayh2S06GHhkpLNGg==
Received-SPF: pass client-ip=212.227.15.18; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.450, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1VKTDX-0007df-Jd 59c08bc773a5f710ff7963a4845b9367
X-Original-To: ietf-http-wg@w3.org
Subject: #495 WGLC: p4 editorial nits
Archived-At: <http://www.w3.org/mid/52330FCC.2010400@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/19611
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 2013-09-12 16:22, Ken Murchison wrote:
> Looking over the latest diffs I found a couple of typos:
>
> - Sec 3.4, 1st sent" "earlier or equal to" -> "earlier than or equal to"
>
> - Sec 3.4, para 5, 1st sent: "resource that resource" -> "resource that"
>
> - Sec 3.5, 1st para, 1st sent: "similar the If-Match and
> If-Unmodified-Since fields" -> "similar to the If-Match and
> If-Unmodified-Since header fields"

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2379>

> Now on to my nits.  Sections 3.1 - 3.4 aren't entirely uniform after the
> current rewrite, especially Section 3.3:
>
> - Sec 3.2, 1st para, 1st sent, 2nd clause (to match Sec 3.1): "current
> representation" -> "current representation of the target resource"
>
> - Sec 3.4, para 6, 2nd sent (to explicitly state when condition is false
> like in Sec 3.1 and 3.2): "the selected representation has been modified
> since the time specified in this field" -> "the selected
> representation's last modification date is more recent than the date
> provided in the field-value"
>
> - Sec 3.3, last para, 1st sent: "during a past run" isn't very
> descriptive for 1st time readers ("run" of what?).  Suggest changing
> this to something like "in a prior response"

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2387>.


> - Sec 3.3, 1st para not uniform with Sec 3.1, 3.2, 3.4.  Suggest
> changing it to something like the following:
>
>      The "If-Modified-Since" header field makes the GET or HEAD request
> method conditional on the selected representation's modification date being
>      more recent than the date provided in the field-value.  This
> accomplishes the same purpose as If-None-Match for cases where the user
> agent
>      does not have an entity-tag for the representation.

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2387> (partly).


I haven't done anything about the remaining items yet:

> Sec 3.3 is missing paragraphs like the last 2 in Sec 3.1, 3.2, 3.4.
> Suggest appending the following to Sec 3.3:
>
>      An origin server that receives an If-Modified-Since header field
> MUST evaluate the condition prior to performing the method (Section 5).
> The
>      condition is false if the selected representation's last
> modification date is earlier than or equal to the date provided in the
> field-value.
>
>      An origin server MUST NOT perform the requested method if the
> condition evaluates to false: instead, the origin server MUST respond
> with the
>      304 (Not Modified) status code.
>
> - Sec 3.3, para 4, 2nd sent: Should this sentence regarding use of
> Last-Modified/Date also be included of para 4 in Sec 3.4?
>
> - Sec 3.3, last 2 para: Should Sec 3.4 have a similar discussion of how
> to generate the field-value?
>
> - Should the 1st sentences of Sec 3.3 and 3.4 use "recipient cache or
> origin server" like Sec 3.1 and 3.2?
>
>
> And finally, one question for my own understanding:
>
> - Why STRONG comparison for If-Match and WEAK for If-None-Match?  Is
> this due to selection vs validation?


Best regards, Julian