idnits 2.17.1 draft-kerwin-http2-nak-frame-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 9, 2019) is 1723 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kerwin 3 Internet-Draft August 9, 2019 4 Intended status: Standards Track 5 Expires: February 10, 2020 7 HTTP/2 "Dropped Frame" Frame 8 draft-kerwin-http2-nak-frame-02 10 Abstract 12 This document defines an extension to the Hypertext Transfer Protocol 13 Version 2 (HTTP/2) that allows an endpoint to signal to its peer that 14 an unsupported extension frame was discarded. 16 Note to Readers 18 The issues list for this draft can be found at 19 22 The most recent (often unpublished) draft is at 23 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 10, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 61 2. Additions to HTTP/2 . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. DROPPED_FRAME . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. HTTP/2 Frame Type Registry Update . . . . . . . . . . . . 4 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 5.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 5 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 Out of the box, the Hypertext Transfer Protocol Version 2 (HTTP/2) 75 [RFC7540] makes provision for extension frames to be sent on a 76 connection, with or without prior agreement from either peer, with 77 the assertion that "implementations MUST discard frames that have 78 unknown or unsupported types" ([RFC7540], Section 5.5). However it 79 can be useful to explicitly notify the peer if such a frame is 80 discarded. 82 This document defines an extension to HTTP/2 that allows a peer to 83 signal that a received frame was discarded, without altering the 84 stream or connection state ([RFC7540], Section 5.1), and in 85 particular without triggering an error condition. 87 1.1. Notational Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 2. Additions to HTTP/2 97 This document introduces a new HTTP/2 frame type ([RFC7540], 98 Section 11.2). 100 2.1. DROPPED_FRAME 102 [[NOTE-1: This is an experimental value; if standardised, a permanent 103 value will be assigned. --MK]] 105 DROPPED_FRAME frames (type code=0xf1) can be sent on a connection at 106 any time after the connection preface except in the middle of a 107 header block ([RFC7540], Section 4.3) to indicate that a received 108 extension frame was discarded without any other action being taken. 110 +---------------+ 111 | Type (8) | 112 +---------------+ 114 DROPPED_FRAME Frame Payload 116 The DROPPED_FRAME frame contains a single 8-bit integer containing 117 the value of the Type field from the discarded frame. 119 The DROPPED_FRAME frame does not define any flags. 121 An endpoint SHOULD send a DROPPED_FRAME frame for an unknown or 122 unsupported extension frame type the first time it discards a frame 123 of that type. 125 An endpoint MAY send a DROPPED_FRAME frame for a particular frame 126 type only once, even if it discards multiple frames of that type. 128 An endpoint that receives a DROPPED_FRAME frame ought to take it as 129 an indication that the extension is not supported by the peer, and 130 MAY subsequently choose not to send further frames of that type or to 131 attempt extension negotiation with the peer. 133 Receipt of a DROPPED_FRAME frame does not necessarily mean that all 134 frames on that connection with the discarded type will be discarded 135 in future. A transparent intermediary that forwards an extension 136 frame in one direction and a corresponding DROPPED_FRAME frame in the 137 other direction MUST NOT intercept future frames of that type and 138 preemptively reply with a DROPPED_FRAME frame. 140 DROPPED_FRAME frames are not associated with any individual stream. 141 If a DROPPED_FRAME frame is received with a stream identifier field 142 value other than 0x0, the recipient MUST respond with a connection 143 error ([RFC7540], Section 5.4.1) of type PROTOCOL_ERROR. 145 Receipt of a DROPPED_FRAME frame with a length field value other than 146 1 MUST be treated as a connection error ([RFC7540], Section 5.4.1) of 147 type FRAME_SIZE_ERROR. 149 An endpoint MUST NOT send a DROPPED_FRAME frame with a Type of 150 DROPPED_FRAME (0xf1). If a DROPPED_FRAME frame is received with a 151 Type field value of 0xf1, the recipient MUST respond with a 152 connection error ([RFC7540], Section 5.4.1) of type PROTOCOL_ERROR. 154 Likewise, an endpoint MUST NOT send a DROPPED_FRAME frame for a type 155 it does not discard - including the frame types defined in [RFC7540], 156 Section 6, unless otherwise negotiated. If a DROPPED_FRAME frame is 157 received for a type that can not be discarded by the sending peer, 158 the recipient MUST respond with a connection error ([RFC7540], 159 Section 5.4.1) of type PROTOCOL_ERROR. 161 Extensions that define new HTTP/2 frame types MAY specify behaviours 162 in response to DROPPED_FRAME frames with those types, however 163 extensions that change the semantics of existing protocol components, 164 including those defined in this document, MUST be negotiated before 165 being used ([RFC7540], Section 5.5). 167 3. Security Considerations 169 Receipt of a DROPPED_FRAME frame does not guarantee that the sending 170 peer will send one for every frame type it drops, and the absence of 171 a DROPPED_FRAME frame does not imply that the peer has not discarded 172 a frame. Implementations MUST NOT depend on the use of DROPPED_FRAME 173 frames to indicate acceptance or rejection of extension frames. 175 4. IANA Considerations 177 This document updates the registry for frame types in the "Hypertext 178 Transfer Protocol (HTTP) 2 Parameters" section. 180 4.1. HTTP/2 Frame Type Registry Update 182 This document updates the "HTTP/2 Frame Type" registry ([RFC7540], 183 Section 11.2). The entries in the following table are registered by 184 this document. 186 +---------------+------+-------------+ 187 | Frame Type | Code | Section | 188 +---------------+------+-------------+ 189 | DROPPED_FRAME | TBD | Section 2.1 | 190 +---------------+------+-------------+ 192 5. References 194 5.1. Normative References 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, 198 DOI 10.17487/RFC2119, March 1997, 199 . 201 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 202 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 203 DOI 10.17487/RFC7540, May 2015, 204 . 206 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 207 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 208 May 2017, . 210 Appendix A. Changelog 212 Since -01: 214 o use experimental value for frame ID 216 o forbid sending a DROPPED_FRAME for any frame that isn't dropped 218 Since -00: 220 o Largely editorial; clarifications about when a frame can be 221 received and what it can reasonably contain. 223 Author's Address 225 Matthew Kerwin 227 Email: matthew@kerwin.net.au 228 URI: https://matthew.kerwin.net.au/