Re: [Editorial Errata Reported] RFC7540 (4871)

Martin Thomson <martin.thomson@gmail.com> Wed, 30 November 2016 09:42 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 87FE4129D60 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 01:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Level:
X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 22LLSkt0IlY3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 01:42:34 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54694129D5E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 01:40:14 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cC1JO-0002rl-4N for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Nov 2016 09:36:22 +0000
Resent-Date: Wed, 30 Nov 2016 09:36:22 +0000
Resent-Message-Id: <E1cC1JO-0002rl-4N@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1cC1JC-0002qz-J1 for ietf-http-wg@listhub.w3.org; Wed, 30 Nov 2016 09:36:10 +0000
Received: from mail-qt0-f176.google.com ([209.85.216.176]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <martin.thomson@gmail.com>) id 1cC1J6-0000TI-BO for ietf-http-wg@w3.org; Wed, 30 Nov 2016 09:36:05 +0000
Received: by mail-qt0-f176.google.com with SMTP id n6so182461326qtd.1 for <ietf-http-wg@w3.org>; Wed, 30 Nov 2016 01:35:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8OliYWqh0LsSahfyvIKZZXx7VqXJV//MuFCKGK2zaRQ=; b=S8gW2/ADkKZUwS5mqaPBK3GjmCJSQxNaxTKauBem2myk4/m8WbdQaEvB/nY9sSvsqI 6VHr745ueBte4QYQKX9ps3z3wgt3MRCherebs0tMRfMLv+nuMofAIaH0BcpRa5IgCavb ebEulP3nce9eIDN9C9zdgTjXwcQZG5mFPjg8FEoLW8bbjOwOP4LnFymsOcsoB4brPnn4 L41EQGbCB1pOWHUtTMe52pPijU3NVf4qAk3mhtmYvGD0eKClYaxgeKYmCTe6ZUKyk+fK C8dz9qxcvwRaorvOchnTmyoMigHWYjN59hcw+N45kbNHLEYFNh104YBYsifd0Bm7v/cn IozA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8OliYWqh0LsSahfyvIKZZXx7VqXJV//MuFCKGK2zaRQ=; b=IL9VlDwW4a7BUOCfMYaPKXMZ2ApneiM3XqU4EzmRuS8wpd5wPnARLTksPJ9sKSEjpd uq7LDfRJCnsnozjPaYqM+V/m/EpeUlPc946ShXRrEbtOyDhUPK0oLNBLhY9Nhcptb9Rp AXOcL7XcV0Kdn4cxKdN+ZRXomFyVYcD0cf32IMUDWJ5thLw3xSTnaxSjxgl6dM39zHi3 2VpiJxMtIf2P5y1SSefS3fovtF0t5DJESABw7vNIgk1072Cg6aYqEmM/qLdelTGNLwqH x+QIH9SXSmdc8bUoC9ioLzzSoO07s4jLHhWLMRfPfeMJC5Za6TRDr52E0cFMJ72xPjgW ZLgg==
X-Gm-Message-State: AKaTC0051KzoLpCgD5jkNmeIuQJlPmr+wn2P2BYNp+IW2fgN96T8Q8PHHKfG/2d2Sno/gobhRNJQz1WJcRKINQ==
X-Received: by 10.200.48.28 with SMTP id f28mr31654143qte.247.1480498537488; Wed, 30 Nov 2016 01:35:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.38.233 with HTTP; Wed, 30 Nov 2016 01:35:37 -0800 (PST)
In-Reply-To: <1102C272-E8D6-40D3-9D39-7D4801ABD286@lukasa.co.uk>
References: <20161130043354.C786DB81319@rfc-editor.org> <1102C272-E8D6-40D3-9D39-7D4801ABD286@lukasa.co.uk>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 30 Nov 2016 20:35:37 +1100
Message-ID: <CABkgnnXYTi0uv=Dm7zPrA=oPam+Zyka-jujFT2bU8GvqvT5JPg@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Mike Belshe <mike@belshe.com>, Roberto Peon <fenix@google.com>, Ben Campbell <ben@nostrum.com>, Alissa Cooper <alissa@cooperw.in>, Alexey Melnikov <aamelnikov@fastmail.fm>, Patrick McManus <pmcmanus@mozilla.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.216.176; envelope-from=martin.thomson@gmail.com; helo=mail-qt0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-6.4
X-W3C-Hub-Spam-Report: AWL=0.353, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cC1J6-0000TI-BO e3c377b8850980f14b3bb0031051f5d8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Editorial Errata Reported] RFC7540 (4871)
Archived-At: <http://www.w3.org/mid/CABkgnnXYTi0uv=Dm7zPrA=oPam+Zyka-jujFT2bU8GvqvT5JPg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33035
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>

On 30 November 2016 at 19:41, Cory Benfield <cory@lukasa.co.uk> wrote:
> What happens if both stream A and B are blocked? Should my server endeavour to serve dependent streams in that case?

I guess so.  You don't want to completely stall out.  Obviously, if A
and B have a parent with siblings that aren't blocked, then you
continue there, but if everything is stalled, then I guess it's OK to
make progress on any stream.

You could probably devise some sort of scheme where you pick the
stream using some algorithm or other - maybe based on some best-fit
criteria.  But I'd say that it doesn't matter at that point: if we
assume that all streams that aren't blocked depend on blocked streams,
then none of them will be useful to the other side until those blocked
streams finish.  All you are doing is avoiding having a completely
wasted connection.