Re: Miscellaneous Comments on -14

Martin Thomson <martin.thomson@gmail.com> Wed, 13 August 2014 17:33 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FD51A032A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 13 Aug 2014 10:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.67
X-Spam-Level:
X-Spam-Status: No, score=-7.67 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 GpP4FQkPaYS8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 13 Aug 2014 10:33:03 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0E81A0217 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 13 Aug 2014 10:33:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XHcNe-0005gA-Vk for ietf-http-wg-dist@listhub.w3.org; Wed, 13 Aug 2014 17:30:35 +0000
Resent-Date: Wed, 13 Aug 2014 17:30:34 +0000
Resent-Message-Id: <E1XHcNe-0005gA-Vk@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XHcNI-00044f-9K for ietf-http-wg@listhub.w3.org; Wed, 13 Aug 2014 17:30:12 +0000
Received: from mail-wi0-f175.google.com ([209.85.212.175]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1XHcNC-0004sH-KR for ietf-http-wg@w3.org; Wed, 13 Aug 2014 17:30:12 +0000
Received: by mail-wi0-f175.google.com with SMTP id ho1so7769320wib.14 for <ietf-http-wg@w3.org>; Wed, 13 Aug 2014 10:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZNQ61IX5ZUpOFRaZjL+LJ5sLWn/an89IkISWmljxNxE=; b=RSM4XlRQYqzAJeUQM1Q9OvfvMUXg+uVLHd6VRTGJ+IO+5kIILOgNMLRKWJOkkRSKF+ JNxTVdMZIHVrviuzLCCczqxqyfi0QVRLJ/Oikd1B9yfqqR2aZHcYtagQW7+aGtd0M+G7 3ZqtpM5VCEYhsZnhKAYemEomcYLO8R/zp9+2Z6WZA0HK5QRrL5pgWBwJsU79T77iEeR9 XyrGyGaHt4LuZlxD3PxiWYv5Lr/0Pek3dmocoLsbSxE1R9ZKzn+xkD+qxbo9Two94nB7 NLBhsBm4zXU+L3Z24eWEp5V04d36NLOHDqRLy08OYtDMC5Je61qdflt1t00becSI6RqR bRbg==
MIME-Version: 1.0
X-Received: by 10.180.103.74 with SMTP id fu10mr6220435wib.47.1407950980493; Wed, 13 Aug 2014 10:29:40 -0700 (PDT)
Received: by 10.194.6.229 with HTTP; Wed, 13 Aug 2014 10:29:40 -0700 (PDT)
In-Reply-To: <D0055887.38B7F%Robby.Simpson@GE.com>
References: <D0055887.38B7F%Robby.Simpson@GE.com>
Date: Wed, 13 Aug 2014 10:29:40 -0700
Message-ID: <CABkgnnX3F-g2Ydm5aN6sHQ43NqVgj9hHe+XZQfDJx=yOqf2szA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.212.175; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f175.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.733, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1XHcNC-0004sH-KR d075bf6228244d309517637ec6726ddf
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Miscellaneous Comments on -14
Archived-At: <http://www.w3.org/mid/CABkgnnX3F-g2Ydm5aN6sHQ43NqVgj9hHe+XZQfDJx=yOqf2szA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26597
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>

I think that I got these.

On 4 August 2014 12:34, Simpson, Robby (GE Energy Management)
<robby.simpson@ge.com> wrote:
> Various ASCII art header figures show fields aligned on byte and word
> boundaries (e.g., "DATA Frame Payload", "HEADERS Frame Payload", "Setting
> Format", "PUSH_PROMISE Payload Format").  The text doesn't mention this at
> all.  Is byte and word alignment intended?

Byte, yes.  Word, no.

> The plurality of the phrase "header block fragment" is ambiguous to me and
> seems to vary in the text.  Can a HEADERS, PUSH_PROMISE, or CONTINUATION
> frame contain "fragments" or "a fragment"?

I went through and corrected one instance.  If you can be more
specific, then I can too.

> In 6.6, "PADDED (0x8):  Bit 4 being set indicates that the Pad Length
> field is present."  This needs to also indicate that "Padding" may also be
> present, dependent on the Pad Length.  Also "Padding: Padding octets"
> needs to state that it is only present if PADDING flag is set and Pad
> Length > 0.

OK.

> GOAWAY frame - does the "Additional Debug Data" count toward flow control?

No.

>  I think not, but I could see this field growing large.  I understand we
> may not wish to block GOAWAY frames, but there may be a hole here with an
> unbounded size.  (HEADERS, as a counter-example, at least has a limited
> size in SETTINGS).  Is it OK just to rely on MAX_FRAME_SIZE?

I think so.  There is plenty of incentive to keep this small already.
Realistically, MSS is likely to be a limiting factor.

> 9.2 states "Implementations of HTTP/2 MUST support TLS 1.2 [TLS12] for
> HTTP/2 over TLS." then "An implementation of HTTP/2 over TLS MUST use TLS
> 1.2 or higher with the restrictions on feature set and cipher suite
> described in this section." So which is it?  == 1.2 or >= 1.2

It's >= 1.2.  Supporting 1.2 is a natural prerequisite of all TLS
versions above 1.2.

> In 6.5.2, SETTINGS_MAX_FRAME_SIZE initial value is defined "The initial
> value is 2^14 (16,384) octets."  In 11.3 its 65536.

Someone caught that for me already.

> In 7, "Error codes share a common code space.  Some error codes apply only
> to either streams or the entire connection and have no defined semantics
> in the other context."  I would suggest re-wording as this could be
> misread.

Taking suggestions.