RE: Why allow empty STREAM frames when offset is zero?

Mike Bishop <mbishop@evequefou.be> Thu, 10 May 2018 18:26 UTC

Return-Path: <mbishop@evequefou.be>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6E12D94B for <quic@ietfa.amsl.com>; Thu, 10 May 2018 11:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 iM3Apw11rrwi for <quic@ietfa.amsl.com>; Thu, 10 May 2018 11:26:00 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0125.outbound.protection.outlook.com [104.47.32.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A4012D88D for <quic@ietf.org>; Thu, 10 May 2018 11:25:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eZ/bmSTiEQ0v3CUagFZ2vQ2XWtHBwiNTQXiN9WXYdUo=; b=VnQKVVBJbzwTgZpbm+FT8zwBLPNbxFc5p8JLYkGfrYzoQYdJj1c33ttOKkEevZTEMucosShAX0TseqBEH8aXUhSKiQfC3st/qSbwES+teUD/uyWiOx7PVInxvC31soZsSRfBXQsG+DKL+1ASOhQP7Dku+xUaeo9fCDSRggHgYFA=
Received: from SN1PR08MB1854.namprd08.prod.outlook.com (10.169.39.8) by SN1PR08MB1712.namprd08.prod.outlook.com (10.162.133.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Thu, 10 May 2018 18:25:56 +0000
Received: from SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::3c18:f60d:11c1:143d]) by SN1PR08MB1854.namprd08.prod.outlook.com ([fe80::3c18:f60d:11c1:143d%13]) with mapi id 15.20.0735.021; Thu, 10 May 2018 18:25:56 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Why allow empty STREAM frames when offset is zero?
Thread-Topic: Why allow empty STREAM frames when offset is zero?
Thread-Index: AQHT6ImL5mFkHkbJHUyy0/Pe1hIypaQpR13A
Date: Thu, 10 May 2018 18:25:55 +0000
Message-ID: <SN1PR08MB18543D4C234CC672616E37BFDA980@SN1PR08MB1854.namprd08.prod.outlook.com>
References: <20180510180509.GA2505@ubuntu-dmitri>
In-Reply-To: <20180510180509.GA2505@ubuntu-dmitri>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be;
x-originating-ip: [2001:4878:8103:102:100::308]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR08MB1712; 7:WY2kU+wgbrCMGY7auhN2yXOwmJb1y+5HiWpeqZtSQGNvg9abrmGvXoRE7GF9LuBJfEs25IJz54f3j3VFYg3Tmk5gGyVr1kM5IjSf10Or6nrnh3TEfxcNfyEOACfVRT9D+CKiJ1yzFBCsBldMwxYhKNigHyfX2oRUAu0Z4mJ6V16271UF55/FYgrqdfaf8Z4VqJV6uVQewr2aswUR/Sv3DgU86xw0qFHRvQoEvU+0KMtDi7YVr6MukL+lZpcdoOJS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(2017052603328)(7153060)(7193020); SRVR:SN1PR08MB1712;
x-ms-traffictypediagnostic: SN1PR08MB1712:
x-microsoft-antispam-prvs: <SN1PR08MB171295FC949CEBFE02B0FB86DA980@SN1PR08MB1712.namprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(2016111802025)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:SN1PR08MB1712; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1712;
x-forefront-prvs: 066898046A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39830400003)(396003)(346002)(39380400002)(199004)(189003)(13464003)(74482002)(7696005)(97736004)(86362001)(14454004)(6116002)(6436002)(5250100002)(7736002)(106356001)(3660700001)(105586002)(76176011)(478600001)(2906002)(3280700002)(229853002)(110136005)(305945005)(6246003)(33656002)(5660300001)(316002)(99286004)(25786009)(8676002)(81156014)(81166006)(186003)(446003)(102836004)(9686003)(476003)(2900100001)(8936002)(46003)(74316002)(55016002)(68736007)(53546011)(486006)(53936002)(6506007)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR08MB1712; H:SN1PR08MB1854.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-antispam-message-info: i3r7X37VKNX+MouAz3PK3jbvR453Y6mbwRn5/fZA9Gq0sU+oYeSUPlSbkeyeOM6NhlZMFz26kqDazjqZGxQCZQ6sAyXiN6cTiK6r7qfkgfP+7zWgMW6MW6ZaSw6Rd86Nt/lMDlIzCfNyGmJds2ES6oH8vPJ3yiOAHuceFSHHkY2BCJ5KZX0bd6zlsVm4VZJ9
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 7f504ffb-dff4-4696-c67e-08d5b6a378b6
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f504ffb-dff4-4696-c67e-08d5b6a378b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2018 18:25:55.2086 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1712
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KUY3Yt_S1xymtQzu6NQpBbc9C04>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 18:26:02 -0000

If you want to open a stream (e.g. permit data to be sent in the opposite direction of a bidirectional stream), but don't actually have data ready to send yet.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov
Sent: Thursday, May 10, 2018 11:05 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: Why allow empty STREAM frames when offset is zero?

[draft-ietf-quic-transport-11] says the following:

   A stream frame's Stream Data MUST NOT be empty, unless the offset is
   0 or the FIN bit is set.

Why allow empty STREAM frames when the offset is zero?  What is the purpose?

  - Dmitri.