From 675d02f739735fbc387853e6bea102ec82013d58 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 29 Apr 2020 05:06:07 +1000 Subject: [PATCH 1/4] Fix references Take the regex (note leading space): ``` \(see([\n\s]+(?:(?:Section|Appendix)[\n\s]+\S+[\n\s]+of[\n\s]+)?(?:\{\{|\[)[^\}]+(?:\}\}|\]))\)\. ``` And replace with: ``` ; see$1. ``` All mechanical, no manual fixups. --- draft-ietf-quic-http.md | 42 ++++++++++---------- draft-ietf-quic-qpack.md | 2 +- draft-ietf-quic-recovery.md | 10 ++--- draft-ietf-quic-transport.md | 74 ++++++++++++++++++------------------ 4 files changed, 64 insertions(+), 64 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 70dc549c77..8963426e84 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -386,7 +386,7 @@ While connection-level options pertaining to the core QUIC protocol are set in the initial crypto handshake, HTTP/3-specific settings are conveyed in the SETTINGS frame. After the QUIC connection is established, a SETTINGS frame ({{frame-settings}}) MUST be sent by each endpoint as the initial frame of their -respective HTTP control stream (see {{control-streams}}). +respective HTTP control stream; see {{control-streams}}. ## Connection Reuse @@ -401,7 +401,7 @@ requests with multiple different URI authority components. In general, a server is considered authoritative for all URIs with the "https" scheme for which the hostname in the URI is present in the authenticated certificate provided by the server, either as the CN field of the certificate subject or as a dNSName in the -subjectAltName field of the certificate (see {{!RFC6125}}). For a host that is +subjectAltName field of the certificate; see {{!RFC6125}}. For a host that is an IP address, the client MUST verify that the address appears as an iPAddress in the subjectAltName field of the certificate. If the hostname or address is not present in the certificate, the client MUST NOT consider the server @@ -423,8 +423,8 @@ complete or terminate any necessary remaining tasks. A server that does not wish clients to reuse connections for a particular origin can indicate that it is not authoritative for a request by sending a 421 -(Misdirected Request) status code in response to the request (see Section 9.1.2 -of {{?HTTP2}}). +(Misdirected Request) status code in response to the request; see Section 9.1.2 +of {{?HTTP2}}. # HTTP Request Lifecycle @@ -436,8 +436,8 @@ A client MUST send only a single request on a given stream. A server sends zero or more interim HTTP responses on the same stream as the request, followed by a single final HTTP response, as detailed below. -Pushed responses are sent on a server-initiated unidirectional QUIC stream (see -{{push-streams}}). A server sends zero or more interim HTTP responses, followed +Pushed responses are sent on a server-initiated unidirectional QUIC stream; see +{{push-streams}}. A server sends zero or more interim HTTP responses, followed by a single final HTTP response, in the same manner as a standard response. Push is described in more detail in {{server-push}}. @@ -592,8 +592,8 @@ The following pseudo-header fields are defined for requests: : To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1.1 - request that has a request target in origin or asterisk form (see Section - 3.2 of {{?HTTP11}}). Clients that generate HTTP/3 requests directly SHOULD + request that has a request target in origin or asterisk form; see Section + 3.2 of {{?HTTP11}}. Clients that generate HTTP/3 requests directly SHOULD use the ":authority" pseudo-header field instead of the Host field. An intermediary that converts an HTTP/3 request to HTTP/1.1 MUST create a Host field if one is not present in a request by copying the value of the @@ -610,8 +610,8 @@ The following pseudo-header fields are defined for requests: "http" or "https" URIs that do not contain a path component MUST include a value of '/'. The exception to this rule is an OPTIONS request for an "http" or "https" URI that does not include a path component; these MUST - include a ":path" pseudo-header field with a value of '*' (see Section 3.2.4 - of {{?HTTP11}}). + include a ":path" pseudo-header field with a value of '*'; see Section 3.2.4 + of {{?HTTP11}}. All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT request ({{connect}}). @@ -631,7 +631,7 @@ HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line. For responses, a single ":status" pseudo-header field is defined that carries -the HTTP status code (see Section 9 of {{!SEMANTICS}}). This pseudo-header +the HTTP status code; see Section 9 of {{!SEMANTICS}}. This pseudo-header field MUST be included in all responses; otherwise, the response is malformed ({{malformed}}). @@ -754,7 +754,7 @@ A CONNECT request MUST be constructed as follows: The request stream remains open at the end of the request to carry the data to be transferred. A CONNECT request that does not conform to these restrictions -is malformed (see {{malformed}}). +is malformed; see {{malformed}}. A proxy that supports CONNECT establishes a TCP connection ({{!RFC0793}}) to the server identified in the ":authority" pseudo-header field. Once this connection @@ -812,7 +812,7 @@ same order, and both the name and the value in each field MUST be exact matches. Server push is only enabled on a connection when a client sends a MAX_PUSH_ID -frame (see {{frame-max-push-id}}). A server cannot use server push until it +frame; see {{frame-max-push-id}}. A server cannot use server push until it receives a MAX_PUSH_ID frame. A client sends additional MAX_PUSH_ID frames to control the number of pushes that a server can promise. A server SHOULD use Push IDs sequentially, starting at 0. A client MUST treat receipt of a push stream @@ -837,7 +837,7 @@ push stream, this MAY be treated as a stream error of type H3_STREAM_CREATION_ERROR. The server MUST include a value in the ":authority" pseudo-header field for -which the server is authoritative (see {{connection-reuse}}). A client SHOULD +which the server is authoritative; see {{connection-reuse}}. A client SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request for which it does not consider the server authoritative. If the pushed response arrives on a push stream, this MAY be treated as a stream error of type @@ -856,7 +856,7 @@ or DATA frames that reference the promised responses. This reduces the chance that a client requests a resource that will be pushed by the server. When a server later fulfills a promise, the server push response is conveyed on -a push stream (see {{push-streams}}). The push stream identifies the Push ID of +a push stream; see {{push-streams}}. The push stream identifies the Push ID of the promise that it fulfills, then contains a response to the promised request using the same format described for responses in {{request-response}}. @@ -976,7 +976,7 @@ can be cleanly shut down without losing requests. A client has more flexibility in the value it chooses for the Push ID in a GOAWAY that it sends. A value of 2^62 - 1 indicates that the server can continue fulfilling pushes which have already been promised, and the client can -continue granting push credit as needed (see {{frame-max-push-id}}). A smaller +continue granting push credit as needed; see {{frame-max-push-id}}. A smaller value indicates the client will reject pushes with Push IDs greater than or equal to this value. Like the server, the client MAY send subsequent GOAWAY frames so long as the specified Push ID is strictly smaller than all previously @@ -1316,8 +1316,8 @@ CANCEL_PUSH Frame { {: #fig-cancel-push title="CANCEL_PUSH Frame"} The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer. -The Push ID identifies the server push that is being cancelled (see -{{frame-push-promise}}). If a CANCEL_PUSH frame is received which references a +The Push ID identifies the server push that is being cancelled; see +{{frame-push-promise}}. If a CANCEL_PUSH frame is received which references a Push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type H3_ID_ERROR. @@ -1574,8 +1574,8 @@ MAX_PUSH_ID Frame { {: #fig-max-push title="MAX_PUSH_ID Frame Payload"} The MAX_PUSH_ID frame carries a single variable-length integer that identifies -the maximum value for a Push ID that the server can use (see -{{frame-push-promise}}). A MAX_PUSH_ID frame cannot reduce the maximum Push ID; +the maximum value for a Push ID that the server can use; see +{{frame-push-promise}}. A MAX_PUSH_ID frame cannot reduce the maximum Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than previously received MUST be treated as a connection error of type H3_ID_ERROR. @@ -1610,7 +1610,7 @@ outstanding requests before making this choice. Because new error codes can be defined without negotiation (see {{extensions}}), use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to H3_NO_ERROR. However, closing a stream -can have other effects regardless of the error code (see {{request-response}}). +can have other effects regardless of the error code; see {{request-response}}. This section describes HTTP/3-specific error codes which can be used to express the cause of a connection or stream error. diff --git a/draft-ietf-quic-qpack.md b/draft-ietf-quic-qpack.md index 42a269cad5..1777dc8353 100644 --- a/draft-ietf-quic-qpack.md +++ b/draft-ietf-quic-qpack.md @@ -204,7 +204,7 @@ evictable, the encoder MUST NOT insert that entry into the dynamic table (including duplicates of existing entries). In order to avoid this, an encoder that uses the dynamic table has to keep track of each dynamic table entry referenced by each header block until that header block is acknowledged by the -decoder (see {{header-acknowledgement}}). +decoder; see {{header-acknowledgement}}. #### Avoiding Prohibited Insertions diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 9f6cad8e19..b7ea893be8 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -218,7 +218,7 @@ forward progress without relying on timeouts. QUIC endpoints measure the delay incurred between when a packet is received and when the corresponding acknowledgment is sent, allowing a peer to maintain a -more accurate round-trip time estimate (see Section 13.2 of {{QUIC-TRANSPORT}}). +more accurate round-trip time estimate; see Section 13.2 of {{QUIC-TRANSPORT}}. ### Probe Timeout Replaces RTO and TLP @@ -676,7 +676,7 @@ all recovery state associated with those packets and MUST remove them from the count of bytes in flight. Endpoints stop sending and receiving Initial packets once they start exchanging -Handshake packets (see Section 17.2.2.1 of {{QUIC-TRANSPORT}}). At this point, +Handshake packets; see Section 17.2.2.1 of {{QUIC-TRANSPORT}}. At this point, recovery state for all in-flight Initial packets is discarded. When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is @@ -688,8 +688,8 @@ is expected to be infrequent. It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost. Initial secrets however might be destroyed -sooner, as soon as handshake keys are available (see Section 4.10.1 of -{{QUIC-TLS}}). +sooner, as soon as handshake keys are available; see Section 4.10.1 of +{{QUIC-TLS}}. # Congestion Control {#congestion-control} @@ -715,7 +715,7 @@ window in bytes. An endpoint MUST NOT send a packet if it would cause bytes_in_flight (see {{vars-of-interest}}) to be larger than the congestion window, unless the packet -is sent on a PTO timer expiration (see {{pto}}). +is sent on a PTO timer expiration; see {{pto}}. ## Explicit Congestion Notification {#congestion-ecn} diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b2c9734dbf..9eb91e1f30 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -190,8 +190,8 @@ QUIC packet: Ack-eliciting Packet: : A QUIC packet that contains frames other than ACK, PADDING, and - CONNECTION_CLOSE. These cause a recipient to send an acknowledgment (see - {{sending-acknowledgements}}). + CONNECTION_CLOSE. These cause a recipient to send an acknowledgment; see + {{sending-acknowledgements}}. Out-of-order packet: @@ -916,8 +916,8 @@ An endpoint MUST NOT send data on a stream at or beyond the final size. Once a final size for a stream is known, it cannot change. If a RESET_STREAM or STREAM frame is received indicating a change in the final size for the stream, -an endpoint SHOULD respond with a FINAL_SIZE_ERROR error (see -{{error-handling}}). A receiver SHOULD treat receipt of data at or beyond the +an endpoint SHOULD respond with a FINAL_SIZE_ERROR error; see +{{error-handling}}. A receiver SHOULD treat receipt of data at or beyond the final size as a FINAL_SIZE_ERROR error, even after a stream is closed. Generating these errors is not mandatory, but only because requiring that an endpoint generate these errors also means that the endpoint needs to maintain @@ -1660,8 +1660,8 @@ on its own. The primary defense against amplification attack is verifying that an endpoint is able to receive packets at the transport address that it claims. Address validation is performed both during connection establishment (see -{{validate-handshake}}) and during connection migration (see -{{migrate-validate}}). +{{validate-handshake}}) and during connection migration; see +{{migrate-validate}}. ## Address Validation During Connection Establishment {#validate-handshake} @@ -1701,8 +1701,8 @@ A server might wish to validate the client address before starting the cryptographic handshake. QUIC uses a token in the Initial packet to provide address validation prior to completing the handshake. This token is delivered to the client during connection establishment with a Retry packet (see -{{validate-retry}}) or in a previous connection using the NEW_TOKEN frame (see -{{validate-future}}). +{{validate-retry}}) or in a previous connection using the NEW_TOKEN frame; see +{{validate-future}}. In addition to sending limits imposed prior to address validation, servers are also constrained in what they can send by the limits set by the congestion @@ -2145,8 +2145,8 @@ congestion window's worth of data per estimated round-trip time (kMinimumWindow, as defined in {{QUIC-RECOVERY}}). In the absence of this limit, an endpoint risks being used for a denial of service attack against an unsuspecting victim. Note that since the endpoint will not have any round-trip time measurements to -this address, the estimate SHOULD be the default initial value (see -{{QUIC-RECOVERY}}). +this address, the estimate SHOULD be the default initial value; see +{{QUIC-RECOVERY}}. If an endpoint skips validation of a peer address as described in {{migration-response}}, it does not need to limit its sending rate. @@ -2925,13 +2925,13 @@ prematurely cancelled by either endpoint. QUIC endpoints communicate by exchanging packets. Packets have confidentiality and integrity protection (see {{packet-protected}}) and are carried in UDP -datagrams (see {{packet-coalesce}}). +datagrams; see {{packet-coalesce}}. This version of QUIC uses the long packet header (see {{long-header}}) during connection establishment. Packets with the long header are Initial ({{packet-initial}}), 0-RTT ({{packet-0rtt}}), Handshake ({{packet-handshake}}), and Retry ({{packet-retry}}). Version negotiation uses a version-independent -packet with a long header (see {{packet-version}}). +packet with a long header; see {{packet-version}}. Packets with the short header ({{short-header}}) are designed for minimal overhead and are used after a connection is established and 1-RTT keys are @@ -3486,8 +3486,8 @@ containing that information is acknowledged. * The HANDSHAKE_DONE frame MUST be retransmitted until it is acknowledged. Endpoints SHOULD prioritize retransmission of data over sending new data, unless -priorities specified by the application indicate otherwise (see -{{stream-prioritization}}). +priorities specified by the application indicate otherwise; see +{{stream-prioritization}}. Even though a sender is encouraged to assemble frames containing up-to-date information every time it sends a packet, it is not forbidden to retransmit @@ -4013,13 +4013,13 @@ contain these additional fields: Reserved Bits: : Two bits (those with a mask of 0x0c) of byte 0 are reserved across multiple - packet types. These bits are protected using header protection (see Section - 5.4 of {{QUIC-TLS}}). The value included prior to protection MUST be set to 0. + packet types. These bits are protected using header protection; see Section + 5.4 of {{QUIC-TLS}}. The value included prior to protection MUST be set to 0. An endpoint MUST treat receipt of a packet that has a non-zero value for these bits, after removing both packet and header protection, as a connection error of type PROTOCOL_VIOLATION. Discarding such a packet after only removing - header protection can expose the endpoint to attacks (see Section 9.3 of - {{QUIC-TLS}}). + header protection can expose the endpoint to attacks; see Section 9.3 of + {{QUIC-TLS}}. Packet Number Length: @@ -4028,7 +4028,7 @@ Packet Number Length: number, encoded as an unsigned, two-bit integer that is one less than the length of the packet number field in bytes. That is, the length of the packet number field is the value of this field, plus one. These bits are protected - using header protection (see Section 5.4 of {{QUIC-TLS}}). + using header protection; see Section 5.4 of {{QUIC-TLS}}. Length: @@ -4192,7 +4192,7 @@ when it receives its first Handshake packet. Though packets might still be in flight or awaiting acknowledgment, no further Initial packets need to be exchanged beyond this point. Initial packet protection keys are discarded (see Section 4.10.1 of {{QUIC-TLS}}) along with any loss recovery and congestion -control state (see Section 6.5 of {{QUIC-RECOVERY}}). +control state; see Section 6.5 of {{QUIC-RECOVERY}}. Any data in CRYPTO frames is discarded - and no longer retransmitted - when Initial keys are discarded. @@ -4290,8 +4290,8 @@ to the server. The Destination Connection ID field in a Handshake packet contains a connection ID that is chosen by the recipient of the packet; the Source Connection ID -includes the connection ID that the sender of the packet wishes to use (see -{{negotiating-connection-ids}}). +includes the connection ID that the sender of the packet wishes to use; see +{{negotiating-connection-ids}}. Handshake packets are their own packet number space, and thus the first Handshake packet sent by a server contains a packet number of 0. @@ -4381,8 +4381,8 @@ value from the Source Connection ID in the Retry packet. Changing Destination Connection ID also results in a change to the keys used to protect the Initial packet. It also sets the Token field to the token provided in the Retry. The client MUST NOT change the Source Connection ID because the server could include -the connection ID as part of its token validation logic (see -{{token-integrity}}). +the connection ID as part of its token validation logic; see +{{token-integrity}}. A Retry packet does not include a packet number and cannot be explicitly acknowledged by a client. @@ -4406,8 +4406,8 @@ A client MUST NOT reset the packet number for any packet number space after processing a Retry packet; {{packet-0rtt}} contains more information on this. A server acknowledges the use of a Retry packet for a connection using the -original_connection_id transport parameter (see -{{transport-parameter-definitions}}). If the server sends a Retry packet, it +original_connection_id transport parameter; see +{{transport-parameter-definitions}}. If the server sends a Retry packet, it MUST include the Destination Connection ID field from the client's first Initial packet in the transport parameter. @@ -4457,13 +4457,13 @@ as described in {{spin-bit}}. Reserved Bits: : The next two bits (those with a mask of 0x18) of byte 0 are reserved. These - bits are protected using header protection (see Section 5.4 of - {{QUIC-TLS}}). The value included prior to protection MUST be set to 0. An + bits are protected using header protection; see Section 5.4 of + {{QUIC-TLS}}. The value included prior to protection MUST be set to 0. An endpoint MUST treat receipt of a packet that has a non-zero value for these bits, after removing both packet and header protection, as a connection error of type PROTOCOL_VIOLATION. Discarding such a packet after only removing - header protection can expose the endpoint to attacks (see Section 9.3 of - {{QUIC-TLS}}). + header protection can expose the endpoint to attacks; see Section 9.3 of + {{QUIC-TLS}}. Key Phase: @@ -4478,7 +4478,7 @@ Packet Number Length: the length of the packet number, encoded as an unsigned, two-bit integer that is one less than the length of the packet number field in bytes. That is, the length of the packet number field is the value of this field, plus one. These - bits are protected using header protection (see Section 5.4 of {{QUIC-TLS}}). + bits are protected using header protection; see Section 5.4 of {{QUIC-TLS}}. Destination Connection ID: @@ -5218,8 +5218,8 @@ STREAM frames contain the following fields: Stream ID: -: A variable-length integer indicating the stream ID of the stream (see - {{stream-id}}). +: A variable-length integer indicating the stream ID of the stream; see + {{stream-id}}. Offset: @@ -5283,8 +5283,8 @@ the initial limits; see {{zerortt-parameters}}. The MAX_STREAM_DATA frame (type=0x11) is used in flow control to inform a peer of the maximum amount of data that can be sent on a stream. -A MAX_STREAM_DATA frame can be sent for streams in the Recv state (see -{{stream-send-states}}). Receiving a MAX_STREAM_DATA frame for a +A MAX_STREAM_DATA frame can be sent for streams in the Recv state; see +{{stream-send-states}}. Receiving a MAX_STREAM_DATA frame for a locally-initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR. An endpoint that receives a MAX_STREAM_DATA frame for a receive-only stream MUST terminate the connection @@ -5371,8 +5371,8 @@ includes streams that have been closed as well as those that are open. ## DATA_BLOCKED Frame {#frame-data-blocked} A sender SHOULD send a DATA_BLOCKED frame (type=0x14) when it wishes to send -data, but is unable to due to connection-level flow control (see -{{flow-control}}). DATA_BLOCKED frames can be used as input to tuning of flow +data, but is unable to due to connection-level flow control; see +{{flow-control}}. DATA_BLOCKED frames can be used as input to tuning of flow control algorithms; see {{fc-credit}}. The DATA_BLOCKED frame is shown in {{fig-data-blocked}}. From 86c3ad5a1b53e80e3d2c05155c87877166823118 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 29 Apr 2020 05:14:09 +1000 Subject: [PATCH 2/4] Manual fixes for -transport --- draft-ietf-quic-transport.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 9eb91e1f30..01b88b75bf 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -311,7 +311,7 @@ means of ensuring ordering between bytes on different streams. QUIC allows for an arbitrary number of streams to operate concurrently and for an arbitrary amount of data to be sent on any stream, subject to flow control -constraints (see {{flow-control}}) and stream limits. +constraints and stream limits; see {{flow-control}}. ## Stream Types and Identifiers {#stream-id} @@ -1418,9 +1418,9 @@ the first packet is of type Initial, with packet number 0, and contains a CRYPTO frame carrying the ClientHello. Note that multiple QUIC packets -- even of different packet types -- can be -coalesced into a single UDP datagram (see {{packet-coalesce}}), and so this -handshake may consist of as few as 4 UDP datagrams, or any number more. For -instance, the server's first flight contains Initial packets, +coalesced into a single UDP datagram; see {{packet-coalesce}}). As a result, +this handshake may consist of as few as 4 UDP datagrams, or any number more. +For instance, the server's first flight contains Initial packets, Handshake packets, and "0.5-RTT data" in 1-RTT packets with a short header. ~~~~ @@ -1866,7 +1866,7 @@ connection properties. Attackers could replay tokens to use servers as amplifiers in DDoS attacks. To protect against such attacks, servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time. Tokens that are provided in -NEW_TOKEN frames (see {{frame-new-token}}) need to be valid for longer, but +NEW_TOKEN frames ({{frame-new-token}}) need to be valid for longer, but SHOULD NOT be accepted multiple times in a short period. Servers are encouraged to allow tokens to be used only once, if possible. @@ -2857,7 +2857,7 @@ are sent; such failures might only be detected by other means, such as timers. An endpoint that detects an error SHOULD signal the existence of that error to its peer. Both transport-level and application-level errors can affect an -entire connection (see {{connection-errors}}), while only application-level +entire connection; see {{connection-errors}}. Only application-level errors can be isolated to a single stream; see {{stream-errors}}. The most appropriate error code ({{error-codes}}) SHOULD be included in the @@ -2924,18 +2924,18 @@ prematurely cancelled by either endpoint. # Packets and Frames {#packets-frames} QUIC endpoints communicate by exchanging packets. Packets have confidentiality -and integrity protection (see {{packet-protected}}) and are carried in UDP +and integrity protection; see {{packet-protected}}. Packets are carried in UDP datagrams; see {{packet-coalesce}}. -This version of QUIC uses the long packet header (see {{long-header}}) during -connection establishment. Packets with the long header are Initial +This version of QUIC uses the long packet header during connection +establishment; see {{long-header}}. Packets with the long header are Initial ({{packet-initial}}), 0-RTT ({{packet-0rtt}}), Handshake ({{packet-handshake}}), and Retry ({{packet-retry}}). Version negotiation uses a version-independent packet with a long header; see {{packet-version}}. -Packets with the short header ({{short-header}}) are designed for minimal -overhead and are used after a connection is established and 1-RTT keys are -available. +Packets with the short header are designed for minimal overhead and are used +after a connection is established and 1-RTT keys are available; see +{{short-header}}. ## Protected Packets {#packet-protected} @@ -4041,7 +4041,7 @@ Packet Number: : The packet number field is 1 to 4 bytes long. The packet number has confidentiality protection separate from packet protection, as described in Section 5.4 of {{QUIC-TLS}}. The length of the packet number field is encoded - in the Packet Number Length bits of byte 0 (see above). + in the Packet Number Length bits of byte 0; see above. ### Version Negotiation Packet {#packet-version} @@ -4598,8 +4598,8 @@ This section details the transport parameters defined in this document. Many transport parameters listed here have integer values. Those transport parameters that are identified as integers use a variable-length integer -encoding (see {{integer-encoding}}) and have a default value of 0 if the -transport parameter is absent, unless otherwise stated. +encoding; see {{integer-encoding}}. Transport parameters have a default value +of 0 if the transport parameter is absent unless otherwise stated. The following transport parameters are defined: @@ -6561,9 +6561,9 @@ Frame Name: In addition to the advice in {{iana-policy}}, specifications for new permanent registrations SHOULD describe the means by which an endpoint might determine that it can send the identified type of frame. An accompanying transport -parameter registration (see {{iana-transport-parameters}}) is expected for most -registrations. Specifications for permanent registrations also needs to -describe the format and assigned semantics of any fields in the frame. +parameter registration is expected for most registrations; see +{{iana-transport-parameters}}. Specifications for permanent registrations also +needs to describe the format and assigned semantics of any fields in the frame. The initial contents of this registry are tabulated in {{frame-types}}. From 49983b1f93846c871fa0ee39147b310a5b1b5156 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 29 Apr 2020 05:16:26 +1000 Subject: [PATCH 3/4] Manual fixes for -http --- draft-ietf-quic-http.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 8963426e84..4ca1481e95 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -602,9 +602,9 @@ The following pseudo-header fields are defined for requests: ":path": : Contains the path and query parts of the target URI (the "path-absolute" - production and optionally a '?' character followed by the "query" production - (see Sections 3.3 and 3.4 of [RFC3986]). A request in asterisk form - includes the value '*' for the ":path" pseudo-header field. + production and optionally a '?' character followed by the "query" + production; see Sections 3.3 and 3.4 of {{?URI=RFC3986}}. A request in + asterisk form includes the value '*' for the ":path" pseudo-header field. : This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a @@ -614,7 +614,8 @@ The following pseudo-header fields are defined for requests: of {{?HTTP11}}. All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", -and ":path" pseudo-header fields, unless it is a CONNECT request ({{connect}}). +and ":path" pseudo-header fields, unless it is a CONNECT request; see +{{connect}}. If the ":scheme" pseudo-header field identifies a scheme which has a mandatory authority component (including "http" and "https"), the request MUST contain @@ -749,8 +750,8 @@ A CONNECT request MUST be constructed as follows: - The ":method" pseudo-header field is set to "CONNECT" - The ":scheme" and ":path" pseudo-header fields are omitted - The ":authority" pseudo-header field contains the host and port to connect to - (equivalent to the authority-form of the request-target of CONNECT requests - (see Section 5.3 of {{?HTTP11}})) + (equivalent to the authority-form of the request-target of CONNECT requests; + see Section 5.3 of {{?HTTP11}}) The request stream remains open at the end of the request to carry the data to be transferred. A CONNECT request that does not conform to these restrictions @@ -826,8 +827,8 @@ This allows the server push to be associated with a client request. Not all requests can be pushed. A server MAY push requests which have the following properties: -- cacheable (see Section 7.2.3 of {{!SEMANTICS}}) -- safe (see Section 7.2.1 of {{!SEMANTICS}}) +- cacheable; see Section 7.2.3 of {{!SEMANTICS}} +- safe; see Section 7.2.1 of {{!SEMANTICS}} - does not include a request body or trailer section Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame From d1644e737c1bb358111cf490befa3246e13bad7a Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 30 Apr 2020 09:49:11 +1000 Subject: [PATCH 4/4] Revert cases of two different things Co-Authored-By: Mike Bishop --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 01b88b75bf..2c2bf7c920 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1660,8 +1660,8 @@ on its own. The primary defense against amplification attack is verifying that an endpoint is able to receive packets at the transport address that it claims. Address validation is performed both during connection establishment (see -{{validate-handshake}}) and during connection migration; see -{{migrate-validate}}. +{{validate-handshake}}) and during connection migration (see +{{migrate-validate}}). ## Address Validation During Connection Establishment {#validate-handshake} @@ -1701,8 +1701,8 @@ A server might wish to validate the client address before starting the cryptographic handshake. QUIC uses a token in the Initial packet to provide address validation prior to completing the handshake. This token is delivered to the client during connection establishment with a Retry packet (see -{{validate-retry}}) or in a previous connection using the NEW_TOKEN frame; see -{{validate-future}}. +{{validate-retry}}) or in a previous connection using the NEW_TOKEN frame (see +{{validate-future}}). In addition to sending limits imposed prior to address validation, servers are also constrained in what they can send by the limits set by the congestion