Re: [quicwg/base-drafts] Pull some H2 content into the introduction (#2683)

Lucas Pardue <notifications@github.com> Fri, 10 May 2019 14:41 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 1657F12021F for <quic-issues@ietfa.amsl.com>; Fri, 10 May 2019 07:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level:
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 kAdE_hqhFk9K for <quic-issues@ietfa.amsl.com>; Fri, 10 May 2019 07:41:25 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E751120221 for <quic-issues@ietf.org>; Fri, 10 May 2019 07:41:25 -0700 (PDT)
Date: Fri, 10 May 2019 07:41:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557499284; bh=R0Qrx7uFJWR36T0KwS3cNLPFwiyfK9/KGMlEbPL46ac=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SJid2/CHk0TF6t+tHu2t5W42TWU/bGaO1H+169ObT2c6byTFU91KeVnHUAGYn0Lcw nSl2T/ZuShGi222Eeulcy6FBBvFiU9fEBpx+OR6UY9CVdhE+uX1w8OFjbUHp4tez+2 yTP6K76p1q3kXK8cNAv6ZLGq4cbDy3ERVi2UoEmQ=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYIT4K7NPKMKAUCNRV24LABJEVBNHHBUX2AKM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2683/review/236135667@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2683@github.com>
References: <quicwg/base-drafts/pull/2683@github.com>
Subject: Re: [quicwg/base-drafts] Pull some H2 content into the introduction (#2683)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd58d946298d_5a8b3fc9b84cd968659d2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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/XPsi4kn12Gnwb0hMXqCGfWWgP1o>
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: Fri, 10 May 2019 14:41:33 -0000

LPardue requested changes on this pull request.

I think this is a good addition to the document. I left a few minor comments and suggestions.

>  
 This document defines a mapping of HTTP semantics over the QUIC transport
-protocol, drawing heavily on the design of HTTP/2. This document identifies
-HTTP/2 features that are subsumed by QUIC, and describes how the other features
-can be implemented atop QUIC.
+protocol, drawing heavily on the design of HTTP/2.  While delegating stream
+management and flow control issues to QUIC, a similar binary framing is used on

what does the term stream management mean in this case? In some perspectives, QUIC doesn't manage much other than ensuring the stream arrives and is presented in-order at the other end (as explained elsewhere in this doc). 

> -## Notational Conventions
+{{!HTTP2=RFC7540}}.
+
+# HTTP/3 Protocol Overview
+
+HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol
+and an internal framing layer similar to HTTP/2.
+
+An HTTP/3 endpoint is discovered using HTTP Alternative Services.  Once a client
+knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC
+connection. QUIC provides protocol negotiation, stream-based multiplexing, and
+flow control.
+
+Within each stream, the basic unit of HTTP/3 communication is a frame
+({{frames}}).  Each frame type serves a different purpose.  For example, HEADERS
+and DATA frames form the frames form the basis of HTTP requests and responses

```suggestion
and DATA frames form the basis of HTTP requests and responses
```

> +client:
+: The endpoint that initiates an HTTP/3 connection.  Clients send HTTP requests
+  and receive HTTP responses.
+
+connection:
+: A transport-layer connection between two endpoints, using QUIC as the
+  transport protocol.
+
+connection error:
+: An error that affects the entire HTTP/3 connection.
+
+endpoint:
+: Either the client or server of the connection.
+
+frame:
+: The smallest unit of communication within an HTTP/3 connection, consisting of

I know this comes from HTTP/2 but one could argue that frames are not the smallest unit in HTTP/3.

> +  {{QUIC-TRANSPORT}}. Where frames from {{QUIC-TRANSPORT}} are referenced, the
+  frame name will be prefaced with "QUIC."  For example, "QUIC CONNECTION_CLOSE
+  frames."  References without this preface refer to frames defined in
+  {{frames}}.
+
+peer:
+: An endpoint.  When discussing a particular endpoint, "peer" refers to the
+  endpoint that is remote to the primary subject of discussion.
+
+receiver:
+: An endpoint that is receiving frames.
+
+sender:
+: An endpoint that is transmitting frames.
+
+server:

disagree, the order is lexical and mirrors the ordering of terms in RFC 7540

> @@ -922,10 +1046,10 @@ implementation chooses.
 
 ## HTTP Message Exchanges {#request-response}
 
-A client sends an HTTP request on a client-initiated bidirectional QUIC
-stream. A client MUST send only a single request on a given stream.
-A server sends one or more HTTP responses on the same stream as the request,
-as detailed below.
+A client sends an HTTP request on a client-initiated bidirectional QUIC stream.
+A client MUST send only a single request on a given stream. A server sends zero
+or more non-final HTTP responses on the same stream as the request, followed by
+a single final HTTP response, as detailed below.

:+1: 

> @@ -1742,7 +1866,7 @@ assigned by IANA.
 
 --- back
 
-# Considerations for Transitioning from HTTP/2
+# Considerations for Transitioning from HTTP/2 {#h2-considerations}
 
 HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
 section describes the approach taken to design HTTP/3, points out important

Based on the evidence, the design changes seem to be motivated because we lost something we had, not because we are taking advantage of some new ability.

-- 
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/pull/2683#pullrequestreview-236135667