WGLC: p6 MUSTs
Alex Rousskov <rousskov@measurement-factory.com> Wed, 01 May 2013 04:59 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 2E60421F8689 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Apr 2013 21:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Level:
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 l1RUbgc3z5aF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Apr 2013 21:59:35 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E7F7F21F84B0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 30 Apr 2013 21:59:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UXP6j-0001qQ-Ln for ietf-http-wg-dist@listhub.w3.org; Wed, 01 May 2013 04:57:33 +0000
Resent-Date: Wed, 01 May 2013 04:57:33 +0000
Resent-Message-Id: <E1UXP6j-0001qQ-Ln@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <rousskov@measurement-factory.com>) id 1UXP6X-0001pY-0w for ietf-http-wg@listhub.w3.org; Wed, 01 May 2013 04:57:21 +0000
Received: from measurement-factory.com ([209.169.10.130]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <rousskov@measurement-factory.com>) id 1UXP6W-0001mg-CF for ietf-http-wg@w3.org; Wed, 01 May 2013 04:57:20 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) (authenticated bits=0) by measurement-factory.com (8.14.3/8.14.3) with ESMTP id r414uuBe070416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf-http-wg@w3.org>; Tue, 30 Apr 2013 22:56:58 -0600 (MDT) (envelope-from rousskov@measurement-factory.com)
Message-ID: <5180A090.9050608@measurement-factory.com>
Date: Tue, 30 Apr 2013 22:56:48 -0600
From: Alex Rousskov <rousskov@measurement-factory.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: IETF HTTP WG <ietf-http-wg@w3.org>
References: <D69329FD-7456-46C5-BE24-6E7EE7E48C39@mnot.net>
In-Reply-To: <D69329FD-7456-46C5-BE24-6E7EE7E48C39@mnot.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=209.169.10.130; envelope-from=rousskov@measurement-factory.com; helo=measurement-factory.com
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Hub-Spam-Report: RP_MATCHES_RCVD=-2.509, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UXP6W-0001mg-CF 1afeeaf4c7ac7132e6a323abf06ace1e
X-Original-To: ietf-http-wg@w3.org
Subject: WGLC: p6 MUSTs
Archived-At: <http://www.w3.org/mid/5180A090.9050608@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17744
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>
Hello, These comments are based on the "latest" snapshot dated Mon 29 Apr 2013 03:13:05 PM MDT at https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html I hope these comments are editorial in nature. > senders MUST NOT send delta-seconds with a value greater than 2147483648. Please use "MUST NOT generate" instead. The proxies should not be required to police these values. > For a presented request, a cache MUST NOT send a stored response This is awkward because many caches never actually send stored responses because they add or modify Connection, Transfer-Encoding, and other hop-by-hop headers to/in a store response. Please consider something like "a cache MUST NOT generate a reply using a stored response" instead. > A cache MUST NOT send a stale response Please use "MUST NOT generate". A cache may still send a stale response by forwarding it. There is already some text implying that later in the section (see below) but that text belongs to a Warning-generation context, so it is better to be explicit here. > the cache can forward it to the requesting client without adding a new Warning Use MAY instead of "can"? > If an implementation sends a message with one or more Warning header > fields to a receiver whose version is HTTP/1.0 or lower, then the > sender MUST include in each warning-value a warn-date that matches > the Date header field in the message > If a system receives a message with a warning-value that includes a > warn-date, and that warn-date is different from the Date value in the > response, then that warning-value MUST be deleted from the message > before storing, forwarding, or using it. Please note that the above MUST requirements can be interpreted to apply to all intermediaries, even those that do not support caching. We have received many complaints from non-caching proxy implementors unknowingly violating these MUSTs and having to implement these complex manipulations that are seemingly irrelevant to their products. You may also want to replace "implementation" and "system" with sender and recipient to use consistent terminology. If these rules are specific to response messages, then using "server" and "client" would be even better. If the above requirements are only meant for origin server and user agents, and not all senders and recipients, please fix the actors accordingly. > A system receiving this warning MUST NOT take any automated action, > besides presenting the warning to the user. In this case, the "system" is probably the "user agent" since "presenting the warning to the user" is mentioned. Same for 299 "Miscellaneous Persistent Warning". Please search the whole text for similar "implementation" and "system" terminology "sprawl". And here is a list of requirements that are missing an explicit actor on which the requirement is placed. Even though it is possible to guess the actor in most cases, these should be easy to rephrase to place the requirement on the intended actor explicitly (e.g., "A cache MUST" instead of "a response MUST"): > the new response MUST NOT be used to update any stored responses. > the no-cache request pragma-directive MUST have the same effect on > caches > warning-value MUST be deleted from the message before storing, > forwarding, or using it Thank you, Alex.
- Working Group Last Call on the HTTPbis document s… Mark Nottingham
- Re: Working Group Last Call on the HTTPbis docume… Julian Reschke
- WGLC: p1 MUSTs Alex Rousskov
- Re: WGLC: p1 MUSTs Willy Tarreau
- WGLC: p2 MUSTs Alex Rousskov
- Re: WGLC: p1 MUSTs Alex Rousskov
- Re: WGLC: p1 MUSTs Willy Tarreau
- Re: WGLC: p1 MUST NOT pipeline until connection i… Alex Rousskov
- WGLC: p4 MUSTs Alex Rousskov
- WGLC: p5 MUSTs Alex Rousskov
- WGLC: p6 MUSTs Alex Rousskov
- WGLC: p7 MUSTs Alex Rousskov
- WGLC p1: MUST fix Content-Length? Alex Rousskov
- Re: WGLC: p1 MUST NOT pipeline until connection i… Willy Tarreau
- Re: WGLC p1: MUST fix Content-Length? Willy Tarreau
- Re: WGLC: p1 MUST NOT pipeline until connection i… Alex Rousskov
- Re: WGLC p1: MUST fix Content-Length? Alex Rousskov
- Re: WGLC: p1 MUST NOT pipeline until connection i… Willy Tarreau
- Re: WGLC p1: MUST fix Content-Length? Willy Tarreau
- Re: WGLC: p1 MUST NOT pipeline until connection i… Alex Rousskov
- Re: WGLC p1: MUST fix Content-Length? Alex Rousskov
- Re: WGLC: p1 MUST NOT pipeline until connection i… Willy Tarreau
- Re: WGLC: p5 MUSTs Ken Murchison
- Re: WGLC: p1 MUST NOT pipeline until connection i… Alex Rousskov
- Re: WGLC: p5 MUSTs Alex Rousskov
- Re: WGLC: p7 MUSTs Mark Nottingham
- Re: WGLC p1: MUST fix Content-Length? Mark Nottingham
- Re: WGLC: p1 MUSTs Mark Nottingham
- Re: WGLC: p5 MUSTs Mark Nottingham
- #481, was: WGLC: p7 MUSTs Julian Reschke
- Re: #481, was: WGLC: p7 MUSTs Alex Rousskov
- Re: #481, was: WGLC: p7 MUSTs Julian Reschke
- Re: #481, was: WGLC: p7 MUSTs Alex Rousskov
- Re: #481, was: WGLC: p7 MUSTs Julian Reschke
- Re: #481, was: WGLC: p7 MUSTs Julian Reschke
- #483, was: WGLC p1: MUST fix Content-Length? Julian Reschke
- Re: WGLC: p1 MUSTs Roy T. Fielding
- Re: WGLC: p1 MUSTs Alex Rousskov
- Re: WGLC: p1 MUSTs Roy T. Fielding
- Re: WGLC: p1 MUSTs Roy T. Fielding
- Re: WGLC: p2 MUSTs Roy T. Fielding
- Re: WGLC: p2 MUSTs Amos Jeffries
- Re: WGLC: p4 MUSTs Roy T. Fielding