Re: [quicwg/base-drafts] Why do control streams need to be typed? (#2224)

Mike Bishop <notifications@github.com> Mon, 07 January 2019 21:17 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290E112D4F0 for <quic-issues@ietfa.amsl.com>; Mon, 7 Jan 2019 13:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 VtzFWofTnsQZ for <quic-issues@ietfa.amsl.com>; Mon, 7 Jan 2019 13:17:15 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F4912D7F8 for <quic-issues@ietf.org>; Mon, 7 Jan 2019 13:17:14 -0800 (PST)
Date: Mon, 07 Jan 2019 13:17:12 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546895832; bh=CFQCkIge4tuikRHFzwuKrG1GgpZiD9NbmKYOzaJIEQU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qU8SFqmIMB5eQCkChbjHhDuQF7IiivClFd0einaAv2VRZtTaELGAO+HTU8v5apzAK FJho9Psu/yS5gqNj3bIH1SUBN5A8nvjmdGD4WBQBrxXIjG4Tv6sebNqkCbDGeFMuLi 2D9Icoa1JSQfhDEBy4RpuFQuXBkitfqrwaU9rBIo=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7d6b191f42a73c8ac0b5bfd7121b850f3d499ace92cf00000001184b83d892a169ce17706d7a@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2224/452084827@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2224@github.com>
References: <quicwg/base-drafts/issues/2224@github.com>
Subject: Re: [quicwg/base-drafts] Why do control streams need to be typed? (#2224)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c33c1d8977bf_3eb83fae74cd45bc165242"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/pwFMpT5ZVC72YWZ83hsYeRpW0Ro>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 21:17:17 -0000

I think it's been established that we have consensus to have typed streams.  It would be possible to pre-assign Stream IDs to the control streams and only use a type byte on higher stream IDs.  However, it seems more consistent to use a single mechanism for all unidirectional streams than creating such a hybrid scheme.

> Is this isolation principle formulated anywhere btw., transport, or a companion governance'ish draft?

The principle I've attempted to maintain is that a stream, once received from the transport, has properties which include the ID, uni/bidi, direction, etc.  However, any relationship between those things is the transport's business and the HTTP layer doesn't make assumptions about them.  Likewise, the application shouldn't ever have to go to the transport and get a particular stream by ID, because that encodes implicit assumptions about the type, direction, etc.

That's primarily been articulated in discussions; it's not a formal protocol property.  However, it helps to ensure that HTTP/3 doesn't have to be revved for future versions of the transport which might change those relationships.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2224#issuecomment-452084827