WGLC: p5 MUSTs

Alex Rousskov <rousskov@measurement-factory.com> Wed, 01 May 2013 01:20 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 2151121F8899 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Apr 2013 18:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.539
X-Spam-Level:
X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 EG8-iOQJ+uqN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 30 Apr 2013 18:20:43 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C4BA121F8825 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 30 Apr 2013 18:20:43 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UXLhg-0002dm-Rh for ietf-http-wg-dist@listhub.w3.org; Wed, 01 May 2013 01:19:28 +0000
Resent-Date: Wed, 01 May 2013 01:19:28 +0000
Resent-Message-Id: <E1UXLhg-0002dm-Rh@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 1UXLhX-0002d3-Ku for ietf-http-wg@listhub.w3.org; Wed, 01 May 2013 01:19:19 +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 1UXLhW-0002ZM-Ms for ietf-http-wg@w3.org; Wed, 01 May 2013 01:19:19 +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 r411IvOW053130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf-http-wg@w3.org>; Tue, 30 Apr 2013 19:18:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com)
Message-ID: <51806D79.6030002@measurement-factory.com>
Date: Tue, 30 Apr 2013 19:18:49 -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 1UXLhW-0002ZM-Ms dc2946bcbee33c01373b8a150475787e
X-Original-To: ietf-http-wg@w3.org
Subject: WGLC: p5 MUSTs
Archived-At: <http://www.w3.org/mid/51806D79.6030002@measurement-factory.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17743
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/p5-range.html

I hope these comments are "editorial in nature".


> Clients MUST NOT use an entity-tag marked as weak in an If-Range
> field value and MUST NOT use a Last-Modified date ...

Please replace "use" with "generate" to explicitly exclude proxies from
policing these headers (i.e., to allow proxies to forward these headers
"as is"). This was already done for other If-Range header rules, but
these two MUST NOTs have slipped through the cracks.


> A client that cannot process a multipart/byteranges response MUST NOT
> ask for multiple ranges in a single request.

A similar concern here for "MUST NOT ask". Please reword the above to
use "MUST NOT generate".

This is especially important because a proxy may not be able to fully
"process" a multipart/byteranges response (whatever that means) but it
can still forward a request for multiple ranges and correctly forward
the 206 response back to the client because HTTPbis no longer allows
multipart/byteranges media type to determine the message body length.


> 4.1 206 Partial Content

Since HTTPbis no longer allows multipart/byteranges media type to
determine the message body length, perhaps it would be a good idea to
explicitly mention that a server MAY generate a 206 Partial Content
response (with single or multiple ranges) without a Content-Length
header and may use chunked encoding? I bet many clients will break when
this starts happening, and there are currently no examples or warnings
that would prepare developers for that possibility.



Thank you,

Alex.