[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Hypertext Transfer Protocol                                     C. Pratt
Internet-Draft                                                 CableLabs
Intended status: Informational                                  B. Stark
Expires: October 20, 2016                                           AT&T
                                                              D. Thakore
                                                               CableLabs
                                                          April 18, 2016


              HTTP bytes-live Range Unit for Live Content
              draft-pratt-httpbis-bytes-live-range-unit-01

Abstract

   To accommodate byte range requests for content that has data appended
   over time, this document defines a new HTTP range unit named "bytes-
   live".  The "bytes-live" range unit provides the ability for a client
   to specify a byte range in a GET or HEAD request which starts at an
   arbitrary byte offset within the representation and ends at an
   indeterminate offset, represented by "*".

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 20, 2016.








Pratt, et al.           Expires October 20, 2016                [Page 1]


Internet-Draft         HTTP bytes-live Range Unit             April 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The "bytes-live" Range Request  . . . . . . . . . . . . . . .   3
   3.  Responses to a bytes-live Range Request . . . . . . . . . . .   4
     3.1.  The "bytes-live" Content-Range header field . . . . . . .   4
     3.2.  The "bytes-live" 206 (Partial Content) response . . . . .   5
     3.3.  The "bytes-live" 416 (Range Not Satisfiable) response . .   6
   4.  Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Range Unit Registry . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Some Hypertext Transfer Protocol (HTTP) clients use Range requests
   for random access to large representations.  And in some cases these
   representations have content continuously or periodically appended -
   such as representations originating from live audio or video sources.
   These types of clients cannot easily access the appended/live content
   using a Range request with the bytes range unit.

   HTTP clients have the ability to access appended content by
   transfersferring the entire representation from the very beginning.
   For large representations, however, newly appended content may never
   be transferred due to bitrate limits.  And even when the appended
   content is reached, it will be at the cost of start-up latency and
   wasted network bandwidth.  HTTP clients can also attempt to access



Pratt, et al.           Expires October 20, 2016                [Page 2]


Internet-Draft         HTTP bytes-live Range Unit             April 2016


   appended content by sending periodic bytes Range requests using the
   last-known end position.  Performing periodic bytes Range requests
   (polling) introduces latency since the client will necessarily be
   somewhat behind the aggregated content - mimicking the behavior of
   segmented content representations such as HLS or MPEG-DASH.  And
   performing these Range requests at higher frequency incurs more
   processing overhead and HTTP traffic as the requests often return no
   content - since content is usually aggregated in groups of bytes
   (e.g. a video frame or audio sample).

   To accommodate byte range requests on large representations which
   have data appended over time, this document defines a new HTTP range
   unit named "bytes-live".  The "bytes-live" range unit adds the
   ability for a client to specify a byte range in a GET or HEAD request
   which starts at an arbitrary byte offset within the representation
   and ends at an indeterminate offset, represented by "*".  A client
   can also specify a request that immediately starts transferring
   aggregated/live content.

   The server indicates supports for the "bytes-live" range unit via the
   Accept-Ranges header.  If a client performs a "bytes-live" Range
   request on a dynamic representation (a representation that has data
   appended over time), the server can provide a non-fixed-length
   payload in response to one of these requests.  For instance, a server
   can use chunked transfer mode to return currently available data and
   data that is appended to the representation as it becomes available.
   Normal TCP flow control ensures new chunks are received by the client
   as soon as they are added to the representation with very low latency
   and overhead for the HTTP client and server.

2.  The "bytes-live" Range Request

   As with the "bytes" range unit, a "bytes-live" Range request allows a
   client to designate a subset of bytes from the representation data to
   be transferred in payloads as a sequence of octets.  But the form of
   a "bytes-live" request is focused on accessing data that may be
   appended to the representation over time.

   The bytes-live range unit has the following syntax:

      bytes-live-range-specifier = "bytes-live=" bytes-live-range-spec

      bytes-live-range-spec = [ first-byte-pos "-" ] "*"

      first-byte-pos = 1*DIGIT

   The first-byte-pos value in a byte-range-spec gives the byte-offset
   of the first byte in a range.  An asterisk character ("*") indicates



Pratt, et al.           Expires October 20, 2016                [Page 3]


Internet-Draft         HTTP bytes-live Range Unit             April 2016


   that the end of requested range is indeterminate and will include
   appended data if/when available.

   Examples of bytes-live-ranges-specifier values:

      Bytes 50000 to the end of the representation (including appended
      data, potentially unbound):

         bytes-live=500000-*

      All bytes appended to the end of the representation after the
      request is processed:

         bytes-live=*

      All bytes currently in the representation and those appended to
      the end of the representation after the request is processed:

         bytes-live=0-*

   A bytes-live-range-specifier is considered unsatisfiable if the
   first-byte-pos is larger than the current length of the
   representation.

3.  Responses to a bytes-live Range Request

3.1.  The "bytes-live" Content-Range header field

   As with the "bytes" Content-Range response form, a "bytes-live"
   Content-Range response indicates the satisfyable or unsatisfyable
   range of a "bytes-live" range request.

   The "bytes-live" Content-Range header is compliant with the Content-
   Range header rules defined in Section 4.2 and has the following
   syntax:

      bytes-live-content-range = "bytes-live" SP bytes-live-range-resp

      bytes-live-range-resp = bytes-live-range "/" ( complete-length /
      "*" )

      bytes-live-range = "*" / ( first-byte-pos "-" ( last-byte-pos /
      "*" ) )

      last-byte-pos = 1*DIGIT

      complete-length = 1*DIGIT




Pratt, et al.           Expires October 20, 2016                [Page 4]


Internet-Draft         HTTP bytes-live Range Unit             April 2016


   For bytes-live range responses, the sender MUST indicate the offset
   of the first available byte in the returned range using the first-
   byte-pos.  The sender MUST indicate the complete length of the
   representation and the last byte position of the returned range if
   the representation is no longer having data appended to it.
   Otherwise an asterisk character ("*") MUST be used in place of the
   last-byte-pos to indicate the returned range and any associated
   payload is not bounded.  As is the case with byte ranges, an asterisk
   character ("*") in place of the complete-length indicates that the
   representation length was unknown when the header field was
   generated.

   The following example illustrates when the last byte of the selected
   representation is known by the sender to be 50000 bytes and is no
   longer being appended to:

      Content-Range: bytes-live 40000-49999/50000

   This second example illustrates when the complete length of the
   selected representation is unknown:

      Content-Range: bytes-live 40000-*/*

   As is the case with a bytes unit Content-Range field, the bytes-live
   Content-Range field value is invalid if it contains a bytes-live-
   range-resp that has a last-byte-pos value less than its first-byte-
   pos value or a complete-length value less than or equal to its last-
   byte-pos value.

3.2.  The "bytes-live" 206 (Partial Content) response

   The bytes-live 206 response MUST comply with section 4.1 of
   [RFC7233].

   Additionally, responses to bytes-live requests that include an
   asterisk character ("*") in place of the last-byte-pos of the bytes-
   live Content-Range header field and precede a payload MUST use a
   transfer encoding mode appropriate for transferring dynamically
   generated payload, such as chunked transfer encoding for HTTP/1.1
   clients.

   Dynamic representations may stop being aggregated at any point in
   time.  So the transfer mode used for bytes-live 206 responses MUST
   indicate when the end of a dynamic representation being transferred
   is reached.  For chunked mode transfer encoding in HTTP/1.1, this is
   signaled with a 0-length chunk.  For HTTP/1.0 clients, this can be
   signaled by the server closing the connection.




Pratt, et al.           Expires October 20, 2016                [Page 5]


Internet-Draft         HTTP bytes-live Range Unit             April 2016


3.3.  The "bytes-live" 416 (Range Not Satisfiable) response

   For bytes-live ranges, failing to overlap the current extent means
   that the first-byte-pos of the byte-range-spec is greater than the
   current length of the selected representation.  When this status code
   is generated in response to a bytes-live-range request, the sender
   MUST generate a Content-Range header field specifying the currently
   available range of the selected representation (Section 4.2 of
   [RFC7233]).

   For example, if the representation is no longer being appended:

           HTTP/1.1 416 Range Not Satisfiable

           Date: Wed, 23 Mar 2015 11:21:12 GMT

           Content-Range: bytes-live 5000-97229/97230

   And if the representation is still being appended:

           HTTP/1.1 416 Range Not Satisfiable

           Date: Wed, 23 Mar 2015 11:21:12 GMT

           Content-Range: bytes-live 5000-97229/*

4.  Accept-Ranges

   The "Accept-Ranges" header field described in Section 2.3 of
   [RFC7233] allows a server to indicate that it supports range requests
   for the target resource.

   An origin server that supports bytes-live range requests for a given
   target resource MUST send

      Accept-Ranges: bytes-live

   to indicate it supports bytes-live range units.

5.  IANA Considerations

5.1.  Range Unit Registry

   The "HTTP Range Unit Registry" defines the namespace for the range
   unit names and refers to their corresponding specifications.  The
   registry has been created and is now maintained at
   [RANGE-UNIT-REGISTRY].




Pratt, et al.           Expires October 20, 2016                [Page 6]


Internet-Draft         HTTP bytes-live Range Unit             April 2016


   Registration of the bytes-live Range Unit is as follows:

   +----------------+--------------------------------------+-----------+
   |   Range Unit   |             Description              | Reference |
   |      Name      |                                      |           |
   +----------------+--------------------------------------+-----------+
   |   bytes-live   |  a range of octets with increasing   | Section 2 |
   |                |                length                |           |
   +----------------+--------------------------------------+-----------+

6.  Security Considerations

   There are no known security concerns introduced by use of the bytes-
   live range unit.

7.  Acknowledgements

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
              "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
              RFC 7233, DOI 10.17487/RFC7233, June 2014,
              <http://www.rfc-editor.org/info/rfc7233>.

8.2.  Informative References

   [RANGE-UNIT-REGISTRY]
              IANA, "Hypertext Transfer Protocol (HTTP) Parameters",
              2016, <http://www.iana.org/assignments/http-parameters/
              http-parameters.xhtml#range-units>.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234,
              October 2005, <http://www.rfc-editor.org/info/rfc4234>.

Authors' Addresses








Pratt, et al.           Expires October 20, 2016                [Page 7]


Internet-Draft         HTTP bytes-live Range Unit             April 2016


   Craig Pratt
   CableLabs
   Portland, OR  97229-8910
   US

   Email: craig@ecaspia.com


   Barbara Stark
   AT&T
   Atlanta, GA
   US

   Email: barbara.stark@att.com


   Darshak Thakore
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027

   Email: d.thakore@cablelabs.com





























Pratt, et al.           Expires October 20, 2016                [Page 8]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/