Re: IETF LC comments on draft-ietf-httpbis-header-compression-10
Matthew Kerwin <matthew@kerwin.net.au> Sat, 10 January 2015 23:16 UTC
Return-Path: <phluid61@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4B51A1A23 for <ietf@ietfa.amsl.com>; Sat, 10 Jan 2015 15:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level:
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWlXziwc14eO for <ietf@ietfa.amsl.com>; Sat, 10 Jan 2015 15:16:57 -0800 (PST)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25871A1A20 for <ietf@ietf.org>; Sat, 10 Jan 2015 15:16:56 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id x3so13856450qcv.8 for <ietf@ietf.org>; Sat, 10 Jan 2015 15:16:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eUU8618ccFOxxSv4SfrIiO09Y7sm6FVjjA5djeB8hMU=; b=m3q9MCm1DGpR73+tT5OomFuakPokXdsLQYOR3Egd9vGkDOFhoOIwXdrhcM+3anW+2E moeGk2Wi5Z22nkGbZCpsVmofKUOYWkD4puz9j5LVQegQKKAXX6TwO8A4mveepPBc4sCI FeXBvgfZC0oaz5pbKo3dYazIfVRWgWIrHP4LCKNW1jy13GFbGkzXqbkBsi2/VNpehba0 Dszy05s/vw9+NzBwbP38lbbeoaUtVKM4oj8dxLjDJeVd/SiJXrh2Fw/iEx61yVmO5J7l xpMUjggTPOxuQSmik5ILtDazgeAIur4huO2i9ljhGNF4rWnOfiRipdZoyh/nXOEN/yDn mKkQ==
MIME-Version: 1.0
X-Received: by 10.140.35.114 with SMTP id m105mr36092307qgm.79.1420931815479; Sat, 10 Jan 2015 15:16:55 -0800 (PST)
Sender: phluid61@gmail.com
Received: by 10.140.93.98 with HTTP; Sat, 10 Jan 2015 15:16:55 -0800 (PST)
In-Reply-To: <54B15A46.8040604@greenbytes.de>
References: <20141231152757.1946.9441.idtracker@ietfa.amsl.com> <54B15A46.8040604@greenbytes.de>
Date: Sun, 11 Jan 2015 09:16:55 +1000
X-Google-Sender-Auth: uvU4iH7e86S-mAfCC6TbSM56f6c
Message-ID: <CACweHNAPwoCggR9jnCLiaU+daXY-vKGh5PGrTP=0URNaWwgaxg@mail.gmail.com>
Subject: Re: IETF LC comments on draft-ietf-httpbis-header-compression-10
From: Matthew Kerwin <matthew@kerwin.net.au>
To: Julian Reschke <julian.reschke@greenbytes.de>
Content-Type: multipart/alternative; boundary="001a11c003c01c9e5e050c5478e2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dCsP9KcklnmLHiNB9OZizI17bNo>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jan 2015 23:17:00 -0000
On 11 January 2015 at 02:58, Julian Reschke <julian.reschke@greenbytes.de> wrote: > > 5.1. Integer Representation > > > We have bad experience with making indentation in artwork significant; > maybe introducing brackets would be a good idea. > > > > > (And all the Python advocates cry) > > > This integer representation allows for values of indefinite size. It > is also possible for an encoder to send a large number of zero > values, which can waste octets and could be used to overflow integer > values. Excessively large integer encodings - in value or octet > length - MUST be treated as a decoding error. Different limits can > be set for each of the different uses of integers, based on > implementation constraints. > > Having a MUST here when we don't say what "excessive" is seems like a bad > idea. > > This seems like a MAY -- explaining the error you receive, rather than telling you when to raise one. > 5.2. String Literal Representation > > The figure could be interpreted as if the string length is always > expressed in 7 bits, which I believe is not true. > > 6.2.1. Literal Header Field with Incremental Indexing > > > See above. One can read this as "H" being bit 0 in the second octet; but > that's not always the case. I think it would be good to revise the figure > format. > > It could help to add a line of just: | ... | below any (N+) element. Maybe. -- Matthew Kerwin http://matthew.kerwin.net.au/
- IETF LC comments on draft-ietf-httpbis-header-com… Julian Reschke
- Re: IETF LC comments on draft-ietf-httpbis-header… Matthew Kerwin
- Re: IETF LC comments on draft-ietf-httpbis-header… Hervé Ruellan