idnits 2.17.1 draft-pratt-httpbis-bytes-live-range-unit-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 (April 18, 2016) is 2929 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4234' is defined on line 323, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4234 (Obsoleted by RFC 5234) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hypertext Transfer Protocol C. Pratt 3 Internet-Draft CableLabs 4 Intended status: Informational B. Stark 5 Expires: October 20, 2016 AT&T 6 D. Thakore 7 CableLabs 8 April 18, 2016 10 HTTP bytes-live Range Unit for Live Content 11 draft-pratt-httpbis-bytes-live-range-unit-01 13 Abstract 15 To accommodate byte range requests for content that has data appended 16 over time, this document defines a new HTTP range unit named "bytes- 17 live". The "bytes-live" range unit provides the ability for a client 18 to specify a byte range in a GET or HEAD request which starts at an 19 arbitrary byte offset within the representation and ends at an 20 indeterminate offset, represented by "*". 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 20, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. The "bytes-live" Range Request . . . . . . . . . . . . . . . 3 64 3. Responses to a bytes-live Range Request . . . . . . . . . . . 4 65 3.1. The "bytes-live" Content-Range header field . . . . . . . 4 66 3.2. The "bytes-live" 206 (Partial Content) response . . . . . 5 67 3.3. The "bytes-live" 416 (Range Not Satisfiable) response . . 6 68 4. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 Some Hypertext Transfer Protocol (HTTP) clients use Range requests 81 for random access to large representations. And in some cases these 82 representations have content continuously or periodically appended - 83 such as representations originating from live audio or video sources. 84 These types of clients cannot easily access the appended/live content 85 using a Range request with the bytes range unit. 87 HTTP clients have the ability to access appended content by 88 transfersferring the entire representation from the very beginning. 89 For large representations, however, newly appended content may never 90 be transferred due to bitrate limits. And even when the appended 91 content is reached, it will be at the cost of start-up latency and 92 wasted network bandwidth. HTTP clients can also attempt to access 93 appended content by sending periodic bytes Range requests using the 94 last-known end position. Performing periodic bytes Range requests 95 (polling) introduces latency since the client will necessarily be 96 somewhat behind the aggregated content - mimicking the behavior of 97 segmented content representations such as HLS or MPEG-DASH. And 98 performing these Range requests at higher frequency incurs more 99 processing overhead and HTTP traffic as the requests often return no 100 content - since content is usually aggregated in groups of bytes 101 (e.g. a video frame or audio sample). 103 To accommodate byte range requests on large representations which 104 have data appended over time, this document defines a new HTTP range 105 unit named "bytes-live". The "bytes-live" range unit adds the 106 ability for a client to specify a byte range in a GET or HEAD request 107 which starts at an arbitrary byte offset within the representation 108 and ends at an indeterminate offset, represented by "*". A client 109 can also specify a request that immediately starts transferring 110 aggregated/live content. 112 The server indicates supports for the "bytes-live" range unit via the 113 Accept-Ranges header. If a client performs a "bytes-live" Range 114 request on a dynamic representation (a representation that has data 115 appended over time), the server can provide a non-fixed-length 116 payload in response to one of these requests. For instance, a server 117 can use chunked transfer mode to return currently available data and 118 data that is appended to the representation as it becomes available. 119 Normal TCP flow control ensures new chunks are received by the client 120 as soon as they are added to the representation with very low latency 121 and overhead for the HTTP client and server. 123 2. The "bytes-live" Range Request 125 As with the "bytes" range unit, a "bytes-live" Range request allows a 126 client to designate a subset of bytes from the representation data to 127 be transferred in payloads as a sequence of octets. But the form of 128 a "bytes-live" request is focused on accessing data that may be 129 appended to the representation over time. 131 The bytes-live range unit has the following syntax: 133 bytes-live-range-specifier = "bytes-live=" bytes-live-range-spec 135 bytes-live-range-spec = [ first-byte-pos "-" ] "*" 137 first-byte-pos = 1*DIGIT 139 The first-byte-pos value in a byte-range-spec gives the byte-offset 140 of the first byte in a range. An asterisk character ("*") indicates 141 that the end of requested range is indeterminate and will include 142 appended data if/when available. 144 Examples of bytes-live-ranges-specifier values: 146 Bytes 50000 to the end of the representation (including appended 147 data, potentially unbound): 149 bytes-live=500000-* 151 All bytes appended to the end of the representation after the 152 request is processed: 154 bytes-live=* 156 All bytes currently in the representation and those appended to 157 the end of the representation after the request is processed: 159 bytes-live=0-* 161 A bytes-live-range-specifier is considered unsatisfiable if the 162 first-byte-pos is larger than the current length of the 163 representation. 165 3. Responses to a bytes-live Range Request 167 3.1. The "bytes-live" Content-Range header field 169 As with the "bytes" Content-Range response form, a "bytes-live" 170 Content-Range response indicates the satisfyable or unsatisfyable 171 range of a "bytes-live" range request. 173 The "bytes-live" Content-Range header is compliant with the Content- 174 Range header rules defined in Section 4.2 and has the following 175 syntax: 177 bytes-live-content-range = "bytes-live" SP bytes-live-range-resp 179 bytes-live-range-resp = bytes-live-range "/" ( complete-length / 180 "*" ) 182 bytes-live-range = "*" / ( first-byte-pos "-" ( last-byte-pos / 183 "*" ) ) 185 last-byte-pos = 1*DIGIT 187 complete-length = 1*DIGIT 189 For bytes-live range responses, the sender MUST indicate the offset 190 of the first available byte in the returned range using the first- 191 byte-pos. The sender MUST indicate the complete length of the 192 representation and the last byte position of the returned range if 193 the representation is no longer having data appended to it. 194 Otherwise an asterisk character ("*") MUST be used in place of the 195 last-byte-pos to indicate the returned range and any associated 196 payload is not bounded. As is the case with byte ranges, an asterisk 197 character ("*") in place of the complete-length indicates that the 198 representation length was unknown when the header field was 199 generated. 201 The following example illustrates when the last byte of the selected 202 representation is known by the sender to be 50000 bytes and is no 203 longer being appended to: 205 Content-Range: bytes-live 40000-49999/50000 207 This second example illustrates when the complete length of the 208 selected representation is unknown: 210 Content-Range: bytes-live 40000-*/* 212 As is the case with a bytes unit Content-Range field, the bytes-live 213 Content-Range field value is invalid if it contains a bytes-live- 214 range-resp that has a last-byte-pos value less than its first-byte- 215 pos value or a complete-length value less than or equal to its last- 216 byte-pos value. 218 3.2. The "bytes-live" 206 (Partial Content) response 220 The bytes-live 206 response MUST comply with section 4.1 of 221 [RFC7233]. 223 Additionally, responses to bytes-live requests that include an 224 asterisk character ("*") in place of the last-byte-pos of the bytes- 225 live Content-Range header field and precede a payload MUST use a 226 transfer encoding mode appropriate for transferring dynamically 227 generated payload, such as chunked transfer encoding for HTTP/1.1 228 clients. 230 Dynamic representations may stop being aggregated at any point in 231 time. So the transfer mode used for bytes-live 206 responses MUST 232 indicate when the end of a dynamic representation being transferred 233 is reached. For chunked mode transfer encoding in HTTP/1.1, this is 234 signaled with a 0-length chunk. For HTTP/1.0 clients, this can be 235 signaled by the server closing the connection. 237 3.3. The "bytes-live" 416 (Range Not Satisfiable) response 239 For bytes-live ranges, failing to overlap the current extent means 240 that the first-byte-pos of the byte-range-spec is greater than the 241 current length of the selected representation. When this status code 242 is generated in response to a bytes-live-range request, the sender 243 MUST generate a Content-Range header field specifying the currently 244 available range of the selected representation (Section 4.2 of 245 [RFC7233]). 247 For example, if the representation is no longer being appended: 249 HTTP/1.1 416 Range Not Satisfiable 251 Date: Wed, 23 Mar 2015 11:21:12 GMT 253 Content-Range: bytes-live 5000-97229/97230 255 And if the representation is still being appended: 257 HTTP/1.1 416 Range Not Satisfiable 259 Date: Wed, 23 Mar 2015 11:21:12 GMT 261 Content-Range: bytes-live 5000-97229/* 263 4. Accept-Ranges 265 The "Accept-Ranges" header field described in Section 2.3 of 266 [RFC7233] allows a server to indicate that it supports range requests 267 for the target resource. 269 An origin server that supports bytes-live range requests for a given 270 target resource MUST send 272 Accept-Ranges: bytes-live 274 to indicate it supports bytes-live range units. 276 5. IANA Considerations 278 5.1. Range Unit Registry 280 The "HTTP Range Unit Registry" defines the namespace for the range 281 unit names and refers to their corresponding specifications. The 282 registry has been created and is now maintained at 283 [RANGE-UNIT-REGISTRY]. 285 Registration of the bytes-live Range Unit is as follows: 287 +----------------+--------------------------------------+-----------+ 288 | Range Unit | Description | Reference | 289 | Name | | | 290 +----------------+--------------------------------------+-----------+ 291 | bytes-live | a range of octets with increasing | Section 2 | 292 | | length | | 293 +----------------+--------------------------------------+-----------+ 295 6. Security Considerations 297 There are no known security concerns introduced by use of the bytes- 298 live range unit. 300 7. Acknowledgements 302 8. References 304 8.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 312 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 313 RFC 7233, DOI 10.17487/RFC7233, June 2014, 314 . 316 8.2. Informative References 318 [RANGE-UNIT-REGISTRY] 319 IANA, "Hypertext Transfer Protocol (HTTP) Parameters", 320 2016, . 323 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 324 Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, 325 October 2005, . 327 Authors' Addresses 328 Craig Pratt 329 CableLabs 330 Portland, OR 97229-8910 331 US 333 Email: craig@ecaspia.com 335 Barbara Stark 336 AT&T 337 Atlanta, GA 338 US 340 Email: barbara.stark@att.com 342 Darshak Thakore 343 CableLabs 344 858 Coal Creek Circle 345 Louisville, CO 80027 347 Email: d.thakore@cablelabs.com