Merge branch 'master' into alpn-alt-svc

quicwg · Dec 20, 2016 · bab7dd2 · bab7dd2
2 parents 39f2090 + ed81d4c
commit bab7dd2
Show file tree

Hide file tree

Showing 2 changed files with 24 additions and 32 deletions.
diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md
@@ -141,9 +141,9 @@ HTTP/2.
 
 # Connection establishment {#connection-establishment}
 
-HTTP-over-QUIC connections are established as described in {{QUIC-TRANSPORT}}.
-During connection establishment, HTTP/QUIC support is indicated by selecting the
-ALPN token "hq" in the crypto handshake.
+HTTP/QUIC connections are established as described in {{QUIC-TRANSPORT}}. During 
+connection establishment, HTTP/QUIC support is indicated by selecting the ALPN 
+token "hq" in the crypto handshake. 
 
 While connection-level options pertaining to the core QUIC protocol are set in 
 the initial crypto handshake, HTTP-specific settings are conveyed 
@@ -265,8 +265,8 @@ other reasons.
 
 ### Header Compression 
 
-HTTP-over-QUIC uses HPACK header compression as described in {{!RFC7541}}. HPACK 
-was designed for HTTP/2 with the assumption of in- order delivery such as that 
+HTTP/QUIC uses HPACK header compression as described in {{!RFC7541}}. HPACK was 
+designed for HTTP/2 with the assumption of in- order delivery such as that 
 provided by TCP. A sequence of encoded header blocks must arrive (and be 
 decoded) at an endpoint in the same order in which they were encoded. This 
 ensures that the dynamic state at the two endpoints remains in sync. 
@@ -289,22 +289,21 @@ do we need to retain compatibility with HTTP/2's HPACK?
 
 ## Stream Priorities {#priority}
 
-HTTP-over-QUIC uses the priority scheme described in {{!RFC7540}} Section 5.3. 
-In this priority scheme, a given stream can be designated as dependent upon 
-another stream, which expresses the preference that the latter stream (the 
-"parent" stream) be allocated resources before the former stream (the 
-"dependent" stream). Taken together, the dependencies across all streams in a 
-connection form a dependency tree. The structure of the dependency tree changes 
-as HEADERS and PRIORITY frames add, remove, or change the dependency links 
-between streams.
+HTTP/QUIC uses the priority scheme described in {{!RFC7540}} Section 5.3. In 
+this priority scheme, a given stream can be designated as dependent upon another 
+stream, which expresses the preference that the latter stream (the "parent" 
+stream) be allocated resources before the former stream (the "dependent" 
+stream). Taken together, the dependencies across all streams in a connection 
+form a dependency tree. The structure of the dependency tree changes as HEADERS 
+and PRIORITY frames add, remove, or change the dependency links between streams. 
 
 Implicit in this scheme is the notion of in-order delivery of priority changes 
 (i.e., dependency tree mutations): since operations on the dependency tree such 
 as reparenting a subtree are not commutative, both sender and receiver must 
 apply them in the same order to ensure that both sides have a consistent view of 
 the stream dependency tree. HTTP/2 specifies priority assignments in PRIORITY 
 frames and (optionally) in HEADERS frames. To achieve in-order delivery of 
-priority changes in HTTP-over-QUIC, PRIORITY frames are sent on the connection 
+priority changes in HTTP/QUIC, PRIORITY frames are sent on the connection 
 control stream and the PRIORITY section is removed from the HEADERS frame. The 
 semantics of the Stream Dependency, Weight, E flag, and (for HEADERS frames) 
 PRIORITY flag are the same as in HTTP/2. 
@@ -324,9 +323,9 @@ HTTP level.
 
 ## Server Push
 
-HTTP-over-QUIC supports server push as described in {{!RFC7540}}. During 
-connection establishment, the client indicates whether it is willing to receive 
-server pushes via the SETTINGS_ENABLE_PUSH setting in the SETTINGS frame (see 
+HTTP/QUIC supports server push as described in {{!RFC7540}}. During connection 
+establishment, the client indicates whether it is willing to receive server 
+pushes via the SETTINGS_ENABLE_PUSH setting in the SETTINGS frame (see 
 {{connection-establishment}}), which defaults to 1 (true). 
 
 As with server push for HTTP/2, the server initiates a server push by sending a 
@@ -561,8 +560,8 @@ bytes than would be used to transfer the maximum permitted value.
 #### Defined SETTINGS Parameters
 
 Some transport-level options that HTTP/2 specifies via the SETTINGS frame are 
-superseded by QUIC transport parameters in HTTP-over-QUIC. Below is a listing of 
-how each HTTP/2 SETTINGS parameter is mapped: 
+superseded by QUIC transport parameters in HTTP/QUIC. Below is a listing of how 
+each HTTP/2 SETTINGS parameter is mapped: 
 
   SETTINGS_HEADER_TABLE_SIZE:
   : An integer with a maximum value of 2^32 - 1.

diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md
@@ -231,15 +231,15 @@ A simplified TLS 1.3 handshake with 0-RTT application data is shown in
     Client                                             Server
 
     ClientHello
-   (0-RTT Application Data)
-   (end_of_early_data)        -------->
+   (0-RTT Application Data)  -------->
                                                   ServerHello
                                          {EncryptedExtensions}
                                          {ServerConfiguration}
                                                  {Certificate}
                                            {CertificateVerify}
                                                     {Finished}
                              <--------      [Application Data]
+   (EndOfEarlyData)
    {Finished}                -------->
 
    [Application Data]        <------->      [Application Data]
@@ -315,7 +315,7 @@ ensures that TLS handshake messages are delivered in the correct order.
                                            QUIC Frames <any> @1
                             <--------
 @1 QUIC STREAM Frame(s) <1>:
-     (end_of_early_data)
+     (EndOfEarlyData)
      {Finished}
                             -------->
 
@@ -728,7 +728,7 @@ NewSessionTicket.
 
 The second flight of TLS handshake messages from the client, and any TLS
 handshake messages that are sent after completing the TLS handshake do not need
-special packet protection rules.  This includes the end_of_early_data alert that
+special packet protection rules.  This includes the EndOfEarlyData message that
 is sent by a client to mark the end of its 0-RTT data.  Packets containing these
 messages use the packet protection keys that are current at the time of sending
 (or retransmission).
@@ -1034,9 +1034,8 @@ See {{useless}} for a discussion of these risks.
 
 To avoid receiving TLS packets that contain no useful data, a TLS implementation
 MUST reject empty TLS handshake records and any record that is not permitted by
-the TLS state machine.  Any TLS application data or alerts - other than a single
-end_of_early_data at the appropriate time - that is received prior to the end of
-the handshake MUST be treated as a fatal error.
+the TLS state machine.  Any TLS application data or alerts that is received
+prior to the end of the handshake MUST be treated as a fatal error.
 
 
 ## Use of 0-RTT Keys {#using-early-data}
@@ -1054,12 +1053,6 @@ server can send 0-RTT data until it receives all of the server's handshake
 messages.  A client SHOULD stop sending 0-RTT data if it receives an indication
 that 0-RTT data has been rejected.
 
-A client SHOULD send its end_of_early_data alert only after it has received all
-of the server's handshake messages.  In other words, a client is encouraged to
-use 0-RTT keys until 1-RTT keys become available.  This prevents stalling of the
-connection when there is packet loss or delay and allows the client to send
-continuously.
-
 A server MUST NOT use 0-RTT keys to protect packets.