[apps-discuss] APPSDIR review of draft-ietf-httpbis-p6-cache-24
S Moonesamy <sm+ietf@elandsys.com> Wed, 30 October 2013 04:47 UTC
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961AD21F9A4A; Tue, 29 Oct 2013 21:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.409
X-Spam-Level:
X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 B4+lmJQ0Wr7g; Tue, 29 Oct 2013 21:47:51 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 592F611E81CB; Tue, 29 Oct 2013 21:44:49 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U4gwbn023165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 21:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383108206; bh=jEDwl6HgFuazbOmphFeLDKl24kHI17FGzOxBa4UXlho=; h=Date:To:From:Subject:Cc; b=4BFChIctuK0lSPKushnd1+u892DT0S5fxQXZaBt+AfTH4cVM11M+3wfiZn+3GSykB ePIFD5ju49waZPuq1Ap2Pb4t8fSmByDPBhr/c7jjuvHfonjowuzEH3Z/93eofNaqaB eY51aFmtFH5XWKQ+uLvmhAHZY6aCZiqMbXSvMqZQ=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383108206; i=@elandsys.com; bh=jEDwl6HgFuazbOmphFeLDKl24kHI17FGzOxBa4UXlho=; h=Date:To:From:Subject:Cc; b=yAPpcd3gqeZZkoTYjiBxlF4AyuhfxPLYsRwaKomEqMxHL5Ls5V3Q5I/22ljnIGTAt I2ZRQ3fqCap1KcTasDDis9Hwz/siZuQqOh0hxTrRHNrsBXsEW5/2SlRWGoINkxxKHd lw46z188Eb+hBkHAtCJc8kFmlzhHJjbu4Wp1wGUA=
Message-Id: <6.2.5.6.2.20131029070026.0c491228@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 29 Oct 2013 15:19:25 -0700
To: apps-discuss@ietf.org, draft-ietf-httpbis-p6-cache.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p6-cache-24
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 04:47:51 -0000
I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-httpbis-p6-cache-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Caching Reviewer: S. Moonesamy Review Date: October 29, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is almost ready for publication as a Proposed Standard This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. Caching is an optional feature of HTTP. The document is clear and well-written. Major Issues: None Minor Issues: In Section 1: "Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel." I suggest not using the RFC 2119 "may" in the Introduction section. In Section 1.2.1: "If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.." Shouldn't the largest value be 2147483647 (see MAX_INT)? It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not". In Section 5.2.2.2: "Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)." I suggest not having RFC 2119 key words as part of a note. In Section 5.2.2.3: 'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best- effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.' There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement. In Section 5.2.2.6: "Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)." I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9. Nits: In Section 4.2: "o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time. o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration." Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that: "An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)." If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that. Regards, S. Moonesamy