WGLC: p4 editorial nits

Ken Murchison <murch@andrew.cmu.edu> Thu, 12 September 2013 14:24 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 4B35111E823A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 Sep 2013 07:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 Mc-HyHB4Q0QQ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 12 Sep 2013 07:24:28 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 57B9811E81AD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 12 Sep 2013 07:24:26 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1VK7nG-0008Et-F2 for ietf-http-wg-dist@listhub.w3.org; Thu, 12 Sep 2013 14:22:50 +0000
Resent-Date: Thu, 12 Sep 2013 14:22:50 +0000
Resent-Message-Id: <E1VK7nG-0008Et-F2@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1VK7n1-000896-4C for ietf-http-wg@listhub.w3.org; Thu, 12 Sep 2013 14:22:35 +0000
Received: from smtp.andrew.cmu.edu ([128.2.11.95]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1VK7n0-0004yS-06 for ietf-http-wg@w3.org; Thu, 12 Sep 2013 14:22:35 +0000
Received: from [192.168.137.22] (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id r8CEM7nY013276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf-http-wg@w3.org>; Thu, 12 Sep 2013 10:22:07 -0400
Message-ID: <5231CE0D.80309@andrew.cmu.edu>
Date: Thu, 12 Sep 2013 10:22:05 -0400
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: ietf-http-wg@w3.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.19.222118
X-SMTP-Spam-Clean: 8% ( BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_URI_FOUND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0)
X-SMTP-Spam-Score: 8%
X-Scanned-By: MIMEDefang 2.60 on 128.2.11.95
Received-SPF: none client-ip=128.2.11.95; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: AWL=-1.842, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.917
X-W3C-Scan-Sig: maggie.w3.org 1VK7n0-0004yS-06 08079b4fb3e26fb87f6386d8e0a96163
X-Original-To: ietf-http-wg@w3.org
Subject: WGLC: p4 editorial nits
Archived-At: <http://www.w3.org/mid/5231CE0D.80309@andrew.cmu.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/19603
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>

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"


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"

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

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?

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University