idnits 2.17.1 draft-kerwin-http2-nak-frame-01.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 (October 12, 2017) is 2387 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 October 12, 2017 4 Intended status: Standards Track 5 Expires: April 15, 2018 7 HTTP/2 "Dropped Frame" Frame 8 draft-kerwin-http2-nak-frame-01 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 April 15, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 Out of the box, the Hypertext Transfer Protocol Version 2 (HTTP/2) 73 [RFC7540] makes provision for extension frames to be sent on a 74 connection, with or without prior agreement from either peer, with 75 the assertion that "implementations MUST discard frames that have 76 unknown or unsupported types" ([RFC7540], Section 5.5). However it 77 can be useful to explicitly notify the peer if such a frame is 78 discarded. 80 This document defines an extension to HTTP/2 that allows a peer to 81 signal that a received frame was discarded, without altering the 82 stream or connection state ([RFC7540], Section 5.1), and in 83 particular without triggering an error condition. 85 1.1. Notational Conventions 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 2. Additions to HTTP/2 95 This document introduces a new HTTP/2 frame type ([RFC7540], 96 Section 11.2). 98 2.1. DROPPED_FRAME 100 DROPPED_FRAME frames (type code=0xTBA) can be sent on a connection at 101 any time after the connection preface except in the middle of a 102 header block ([RFC7540], Section 4.3) to indicate that a received 103 extension frame was discarded without any other action being taken. 105 +---------------+ 106 | Type (8) | 107 +---------------+ 109 DROPPED_FRAME Frame Payload 111 The DROPPED_FRAME frame contains a single 8-bit integer containing 112 the value of the Type field from the discarded frame. 114 The DROPPED_FRAME frame does not define any flags. 116 An endpoint SHOULD send a DROPPED_FRAME frame for an unknown or 117 unsupported extension frame type the first time it discards a frame 118 of that type. 120 An endpoint MAY send a DROPPED_FRAME frame for a particular frame 121 type only once, even if it discards multiple frames of that type. 123 An endpoint that receives a DROPPED_FRAME frame ought to take it as 124 an indication that the extension is not supported by the peer, and 125 MAY subsequently choose not to send further frames of that type or to 126 attempt extension negotiation with the peer. 128 Receipt of a DROPPED_FRAME frame does not necessarily mean that all 129 frames on that connection with the discarded type will be discarded 130 in future. A transparent intermediary that forwards an extension 131 frame in one direction and a corresponding DROPPED_FRAME frame in the 132 other direction MUST NOT intercept future frames of that type and 133 preemptively reply with a DROPPED_FRAME frame. 135 DROPPED_FRAME frames are not associated with any individual stream. 136 If a DROPPED_FRAME frame is received with a stream identifier field 137 value other than 0x0, the recipient MUST respond with a connection 138 error ([RFC7540], Section 5.4.1) of type PROTOCOL_ERROR. 140 Receipt of a DROPPED_FRAME frame with a length field value other than 141 1 MUST be treated as a connection error ([RFC7540], Section 5.4.1) of 142 type FRAME_SIZE_ERROR. 144 An endpoint MUST NOT send a DROPPED_FRAME frame with a Type of 145 DROPPED_FRAME (0xTBA). If a DROPPED_FRAME frame is received with a 146 Type field value of 0xTBA, the recipient MUST respond with a 147 connection error ([RFC7540], Section 5.4.1) of type PROTOCOL_ERROR. 149 Extensions that define new HTTP/2 frame types MAY specify behaviours 150 in response to DROPPED_FRAME frames with those types, however 151 extensions that change the semantics of existing protocol components, 152 including those defined in this document, MUST be negotiated before 153 being used ([RFC7540], Section 5.5). 155 3. Security Considerations 157 Receipt of a DROPPED_FRAME frame does not guarantee that the sending 158 peer will send one for every frame type it drops, and the absence of 159 a DROPPED_FRAME frame does not imply that the peer has not discarded 160 a frame. Implementations MUST NOT depend on the use of DROPPED_FRAME 161 frames to indicate acceptance or rejection of extension frames. 163 4. IANA Considerations 165 This document updates the registry for frame types in the "Hypertext 166 Transfer Protocol (HTTP) 2 Parameters" section. 168 4.1. HTTP/2 Frame Type Registry Update 170 This document updates the "HTTP/2 Frame Type" registry ([RFC7540], 171 Section 11.2). The entries in the following table are registered by 172 this document. 174 +---------------+------+-------------+ 175 | Frame Type | Code | Section | 176 +---------------+------+-------------+ 177 | DROPPED_FRAME | TBD | Section 2.1 | 178 +---------------+------+-------------+ 180 5. References 182 5.1. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, 186 DOI 10.17487/RFC2119, March 1997, 187 . 189 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 190 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 191 DOI 10.17487/RFC7540, May 2015, 192 . 194 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 195 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 196 May 2017, . 198 Author's Address 200 Matthew Kerwin 202 Email: matthew@kerwin.net.au 203 URI: https://matthew.kerwin.net.au/