idnits 2.17.1 draft-snell-httpbis-bohe-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 14, 2013) is 4087 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 267, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft February 14, 2013 4 Intended status: Informational 5 Expires: August 18, 2013 7 HTTP/2.0 Discussion: Binary Optimized Header Encoding 8 draft-snell-httpbis-bohe-02 10 Abstract 12 This memo describes a proposed alternative encoding for headers 13 within SPDY SYN_STREAM, SYN_REPLY and HEADERS frames. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 18, 2013. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Binary Optimized Header Encoding . . . . . . . . . . . . . . . 3 50 1.1. Example Headers . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 52 3. Normative References . . . . . . . . . . . . . . . . . . . . . 7 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 1. Binary Optimized Header Encoding 57 Binary Optimized Header Encoding is a proposed alternative 58 serialization for headers within SPDY SYN_STREAM, SYN_REPLY and 59 HEADERS frames that is designed to optimize generation, consumption 60 and processing of the most commonly used HTTP headers. 62 Alternate Header Block Serialization: 64 +-------+---------+ 65 | NUM | Headers | 66 +-------+---------+ 68 'NUM' is a single unsigned 8-bit value indicating the total number of 69 distinct headers contained in the encoded block. 71 'Headers' consists of the complete set of encoded headers. The 72 format for each header is determined by whether the header name (the 73 key) and the header value are included in the static "default 74 dictionary" defined by this specification. The first two bits of 75 each encoded header record identify the specific header format used. 77 Registered Key + Registered Value Pair 79 +--+---+--+ 80 |00|FLG|ID| 81 +--+---+--+ 83 If the header name and value are both included in the default 84 dictionary, the header is encoded using only three distinct fields: 85 the two-bit opcode (00) followed by six unused flag bits, followed by 86 the index of the header key+value pair as provided by the default 87 dictionary, encoded as a variable-length, unsigned integer. 89 Registered Key + Unregistered Value 91 +--+---+--+---+---+ 92 |01|FLG|ID|LEN|VAL| 93 +--+---+--+---+---+ 95 If the header name is included in the default dictionary, but the 96 value given is not, the header is encoded using five fields: the two- 97 bit opcode (01) followed by six flag bits as defined below, followed 98 by the numerically lowest index of the named header as provided by 99 the default dictionary encoded as a variable-length, unsigned 100 integer, followed by another variable-length, unsigned integer 101 specifying the length of the value, followed by the encoded value. 103 Unregistered Key + Value Pair 105 +--+---+------+---+------+---+ 106 |10|FLG|LENkey|key|LENval|val| 107 +--+---+------+---+------+---+ 109 If the header name and value are not included in the default 110 dictionary, the header is encoded using six distinct fields: the two- 111 bit opcode (10) followed by six flag bits as defined below, followed 112 by a variable-length, unsigned integer specifying the key length, 113 followed by the ISO-8859-1 encoded key name, followed by a variable- 114 length, unsigned integer specifying the value length, followed by the 115 encoded value. 117 Flags: 119 FLG = 000000 120 |||||| 121 ||||Reserved 122 |||Numeric (val is one or more uvarints) 123 ||Huffman-encoded 124 |UTF-8 or ISO8859-1 (1 or 0) 125 Binary | Text (1 or 0) 127 When the opcode is either 01 or 10, the six-bit FLG field is used to 128 specify additional properties about the header value. When the 129 opcode is 00, the FLG bits are unused and MUST NOT be set. 131 Moving from the most significant bit to the least, the flags are: 132 o Binary or Text (0x32) - When set, the value is to be interpreted 133 as binary data. When unset, the value is to be interpreted as 134 encoded-text. 135 o UTF-8 or ISO-8859-1 (0x16) - When set, indicates that the text- 136 encoded value is UTF-8 encoded. Otherwise, ISO-8859-1 is assumed. 137 Only used if the Binary or Text bit is unset. 138 o Huffman-encoded (0x08) - When set, indicates that the text-encoded 139 value has been static huffman encoded. The static dictionary used 140 for the encoding is dependent on whether the text is UTF-8 or ISO- 141 8859-1 encoded. Only used if the Binary or Text bit is unset. 142 o Numeric (0x04) - When set, indicates that the value is encoded as 143 a variable-length unsigned integer. Only used if the Binary or 144 Text bit is set (indicating a binary value). 145 o The final two bits (0x02 and 0x01) are reserved. 147 1.1. Example Headers 149 Assuming the following (incomplete) default dictionary: 151 +----+-----------------------------+------------+ 152 | ID | Key | Value | 153 +----+-----------------------------+------------+ 154 | 0 | date | | 155 | 1 | :scheme | | 156 | 2 | :scheme | http | 157 | 3 | :scheme | https | 158 | 4 | :scheme | ftp | 159 | 5 | :method | | 160 | 6 | :method | get | 161 | 7 | :method | post | 162 | 8 | :method | put | 163 | 9 | :method | delete | 164 | 10 | :method | options | 165 | 11 | :method | connect | 166 | 12 | :method | patch | 167 | 13 | :method | link | 168 | 14 | :path | | 169 | 15 | :path | / | 170 | 16 | :host | | 171 | 17 | cookie | | 172 | 18 | :status | | 173 | 19 | :status | 200 | 174 | 20 | :status | 201 | 175 | 21 | :status | 202 | 176 | 22 | :status | 204 | 177 | 23 | :status | 205 | 178 | 24 | :status-text | | 179 | 25 | :status-text | OK | 180 | 26 | :version | | 181 | 27 | :version | 1.0 | 182 | 28 | :version | 1.1 | 183 | 29 | :version | 2.0 | 184 | 30 | accept | | 185 | 31 | accept-charset | | 186 | 32 | accept-encoding | | 187 | 33 | accept-language | | 188 | 34 | accept-ranges | | 189 | 35 | allow | | 190 | 36 | authorizations | | 191 | 37 | cache-control | | 192 | 38 | content-base | | 193 | 39 | content-encoding | | 194 | 40 | content-length | | 195 | 41 | content-location | | 196 | 42 | content-md5 | | 197 | 43 | content-range | | 198 | 44 | content-type | | 199 | 45 | etag | | 200 | 46 | expect | | 201 | 47 | expires | | 202 | 48 | from | | 203 | 49 | if-match | | 204 | 50 | if-modified-since | | 205 | 51 | if-none-match | | 206 | 52 | if-range | | 207 | 53 | if-unmodified-since | | 208 | 54 | last-modified | | 209 | 55 | location | | 210 | 56 | max-forwards | | 211 | 57 | origin | | 212 | 58 | pragma | | 213 | 59 | proxy-authenticate | | 214 | 60 | proxy-authorization | | 215 | 61 | range | | 216 | 62 | referer | | 217 | 63 | retry-after | | 218 | 64 | server | | 219 | 65 | set-cookie | | 220 | 66 | status | | 221 | 67 | te | | 222 | 68 | trailer | | 223 | 69 | transfer-encoding | | 224 | 70 | transfer-encoding | gzip | 225 | 71 | upgrade | | 226 | 72 | user-agent | | 227 | 73 | vary | | 228 | 74 | via | | 229 | 75 | warning | | 230 | 76 | www-authenticate | | 231 | 77 | access-control-allow-origin | | 232 | 78 | content-disposition | | 233 | 79 | get-dictionary | | 234 | 80 | p3p | | 235 | 81 | x-content-type-options | | 236 | 82 | x-frame-options | | 237 | 83 | x-powered-by | | 238 | 84 | x-xss-protection | | 239 | 85 | connection | | 240 | 86 | connection | keep-alive | 241 +----+-----------------------------+------------+ 243 The header :version=2.0 would be encoded as: 245 00 1D |..| 247 The header :method=GET would be encoded as: 249 00 06 |..| 251 The header :method=foo would be encoded as: 253 01 76 05 05 00 03 66 6F |......fo| 254 6F |o| 256 The header foo=bar would be encoded as: 258 b6 03 66 6f 6f 05 00 |..foo...| 259 03 62 61 72 |.bar| 261 2. Security Considerations 263 TBD 265 3. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 Author's Address 272 James M Snell 274 Email: jasnell@gmail.com