Informational                                             R. Pantos, Ed.Internet-Draft                                                E. VershenIntended status: Informational                                Apple Inc.Expires: 21 February 2026                                 20 August 2025                            Content Steering                    draft-pantos-content-steering-01Abstract   This document describes a mechanism for servers to communicate their   preferences to clients about utilizing alternate servers for   streaming content.  These alternate servers are typically distinct   Content Delivery Networks or any other servers that offer similar   distribution services.  The mechanism described in this document is   designed to be universally applicable and independent of any specific   Content Delivery Protocol.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 https://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 21 February 2026.Copyright Notice   Copyright (c) 2025 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 (https://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.Pantos & Vershen        Expires 21 February 2026                [Page 1]Internet-Draft              Content Steering                 August 2025   This document may not be modified, and derivative works of it may not   be created, except to format it for publication as an RFC or to   translate it into languages other than English.   This Informational Internet-Draft is submitted as an RFC Editor   Contribution and/or non-IETF Document (not as a Contribution, IETF   Contribution, nor IETF Document) in accordance with BCP 78 and BCP   79.Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   2.  Definitions and Abbreviations . . . . . . . . . . . . . . . .   3   3.  CDP Responsibilities  . . . . . . . . . . . . . . . . . . . .   4   4.  Steering Manifest . . . . . . . . . . . . . . . . . . . . . .   5   5.  Pathway Cloning . . . . . . . . . . . . . . . . . . . . . . .   6   6.  Steering Query Parameters . . . . . . . . . . . . . . . . . .   8   7.  Steering Client Responsibilities  . . . . . . . . . . . . . .   9   8.  Content Steering Manifest Examples  . . . . . . . . . . . . .  10     8.1.  Content Steering Manifest . . . . . . . . . . . . . . . .  10     8.2.  Content Steering Manifest with Pathway Clone  . . . . . .  10   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11     11.1.  vnd.apple.steering-list  . . . . . . . . . . . . . . . .  11   12. Security Considerations . . . . . . . . . . . . . . . . . . .  12   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13     13.1.  Normative References . . . . . . . . . . . . . . . . . .  13     13.2.  Informative References . . . . . . . . . . . . . . . . .  14   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  141.  Introduction   Content Steering provides a simple mechanism for content delivery   systems to apportion Content Servers among clients.  The Steering   Server can divide clients for simple A/B testing, for load balancing,   for geographic diversity, or any other criteria.  Content Steering is   an extension of a Content Delivery Protocol (CDP) and cannot be   implemented separately from a specific CDP.   The purpose of this document is to facilitate the use of Content   Steering by a variety of Content Delivery Protocols.  While this   document describes the basic structure of Content Steering, each   Content Delivery Protocol using Content Steering is required to   elaborate some aspects in their own specifications.Pantos & Vershen        Expires 21 February 2026                [Page 2]Internet-Draft              Content Steering                 August 2025   Data SHOULD be carried over HTTP [RFC9112], but, in general, a URI   can specify any protocol that can reliably transfer the specified   resource on demand.  In the case of HTTP URIs the request SHOULD be a   GET request.   This document is not an Internet Standards Track specification; it is   published for informational purposes.  It is not an Internet   Standard.  It is a focus of the IETF hls-interest group, but has not   been shown to have the consensus of the wider IETF community.2.  Definitions and Abbreviations   *  Base Pathway: an original Pathway used to generate a Pathway      Clone.   *  Content Delivery Network (CDN): a geographically distributed      network of Content Servers.   *  Content Delivery Protocol (CDP): an application-layer protocol      that specifies how digital content is delivered between a server      and a client optimizing content delivery for efficient data      transfer.   *  Content Description: a document (or group of documents) that the      CDP uses to specify the URIs used to obtain a particular set of      content from a server.   *  Content Server: a specialized server designed to store, manage and      deliver digital content to clients.   *  Content Steering: is a mechanism that enables servers to      communicate their preferences to clients regarding the use of      alternate Content Servers for streaming content, optimizing      delivery based on factors such as network conditions and server      load.   *  Pathway: a predetermined route for content delivery, typically      through a particular Content Server.   *  Pathway Clone: A Pathway produced by applying Pathway Cloning to a      Base Pathway.   *  Pathway Cloning: a process that takes an existing Pathway and a      set of modifiers and generates a new Pathway Clone that is not      explicitly defined in the original Content Description.Pantos & Vershen        Expires 21 February 2026                [Page 3]Internet-Draft              Content Steering                 August 2025   *  Pathway ID: an identifier for a Pathway.  A Pathway ID is a non-      empty string containing characters from the set [a-z], [A-Z],      [0-9], '.', '-', and '_'.   *  Steering Manifest: a JSON document that serves as a dynamic guide      for the client.  It contains steering instructions and identifies      the available Pathways and their priority order.   *  Steering Manifest URI: a unique URI that identifies a specific      Steering Manifest on a Steering Server.   *  Steering Server: an endpoint that returns Steering Manifests.   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and   "OPTIONAL" in this document are to be interpreted as described in BCP   14 [RFC2119] [RFC8174] when, and only when, they appear in all   capitals, as shown here.3.  CDP Responsibilities   A Content Delivery Protocol (CDP) that supports Content Steering   MUST:      Associate a distinct Pathway ID with each Pathway.      Define which content is subject to Content Steering and how to      associate a particular content URI with a particular Pathway ID.      Declare an initial Steering Manifest URI in each Content      Description.      If the CDP allows Pathway Cloning, define how to incorporate      Pathway Clones into the Content Description.   A CDP that allows Content Steering MAY also specify:      An initial active Pathway in each Content Description.      CDP specific extensions to URI-REPLACEMENT object within the      Pathway Clone object.  See Pathway Cloning (Section 5).      CDP specific query parameters.  See Steering Query Parameters      (Section 6).   Whether clients must support Content Steering is a design decision   left to the CDP implementation.Pantos & Vershen        Expires 21 February 2026                [Page 4]Internet-Draft              Content Steering                 August 2025   Two widely-used CDPs that implement Content Steering are: HTTP Live   Streaming (HLS [RFC8216bis]) and Dynamic Adaptive Streaming over HTTP   (DASH [ISO_23009_1]).4.  Steering Manifest   Content Steering is accomplished by having clients periodically read   a Steering Manifest from a Steering Server.  The Steering Manifest   identifies the available Pathways and their priority order.   The Steering Manifest response is a JSON [RFC8259] object.  In   keeping with the JSON standard the text MUST be encoded using UTF-8   [RFC3629].  The JSON object has the form:   {       "VERSION": number,       "TTL": number,       "RELOAD-URI": string,       "PATHWAY-PRIORITY":       [           One or more Pathway IDs in order of preference       ],       "PATHWAY-CLONES":       [           One or more Pathway Clone objects.       ]   }   The JSON object MAY contain other key:value pairs.  In particular, a   CDP MAY define additional keys, including in any contained objects.   Keys defined by a CDP MUST be defined with reference to a specific   Steering Manifest VERSION number defined by this document.  A client   MUST ignore any key of the Steering Manifest that it does not   recognize.  Note that keys are case-sensitive.   *VERSION*: An integer that specifies the version of Steering   Manifest.  This specification defines Steering Manifest VERSION 1.  A   client MUST refuse to use Steering Manifest if the VERSION is missing   or the VERSION number is unrecognized.  This element is REQUIRED.   *TTL*: An integer that specifies the number of seconds the client   MUST wait after loading the Steering Manifest before reloading it.   The recommended value is 300 seconds (5 minutes).  The Steering   Server MAY vary the TTL per client to distribute server load.  This   element is REQUIRED.Pantos & Vershen        Expires 21 February 2026                [Page 5]Internet-Draft              Content Steering                 August 2025   *RELOAD-URI*: A string that specifies the URI the client MUST use for   future Steering Manifest requests.  The RELOAD-URI MAY be relative to   the current Steering Manifest URI.  Certain URI schemes (such as   "data") cannot act as base URIs for relative URIs.  Attempting to   specify a relative URI in that case MUST produce an error.  This   element is OPTIONAL.   *PATHWAY-PRIORITY*: An array of string elements, where each string   represents a Pathway ID.  Elements in the PATHWAY-PRIORITY array are   ordered by Pathway preference, with the first being most preferred.   A Steering Manifest MUST contain at least one Pathway.  A Pathway ID   in the PATHWAY-PRIORITY array MUST NOT appear more than once.   Clients MUST ignore unrecognized Pathway IDs in the PATHWAY-PRIORITY   array.  This element is REQUIRED.   Note that it is important for the most-preferred Pathway of the   initial Steering Manifest to agree with the initial Pathway in the   Content Description.  Immediately redirecting a client to a different   Pathway on startup will delay content delivery and increase network   utilization.   *PATHWAY-CLONES*: An array of Pathway Clone objects.  See Pathway   Cloning (Section 5).  If present, the array must contain at least one   element.  This element is OPTIONAL.5.  Pathway Cloning   A Steering Server can introduce novel Pathways by cloning existing   ones.  A Pathway Clone is produced by taking an existing Pathway and   applying well-defined replacements to the URIs of every Pathway   member.   A Pathway Clone object is a JSON object that has the following form:   {       "BASE-ID": string,       "ID": string,       "URI-REPLACEMENT":       {           "HOST": string,           "PARAMS":           {               key:value pairs for query parameters           }       }   }Pantos & Vershen        Expires 21 February 2026                [Page 6]Internet-Draft              Content Steering                 August 2025   As part of the Steering Manifest, the Pathway Clone object MAY   contain other key:value pairs, see Section 4.   *BASE-ID*: A string that specifies the Pathway ID of the Base   Pathway.  This element is REQUIRED.   *ID*: A string that specifies the Pathway ID for the Pathway Clone.   The ID specified for a Pathway Clone MUST NOT match any other Pathway   ID.  This element is REQUIRED.   *URI-REPLACEMENT*: An object that defines URI modifications to apply   during the cloning process.  This element is REQUIRED.   *HOST*: A string that specifies the Hostname for cloned URIs.  This   element is OPTIONAL.   *PARAMS*: A JSON object that specifies query parameters for cloned   URIs.  The keys represent query parameter names, and the values   correspond to the associated parameter values.  This element is   OPTIONAL.   Clone a Pathway by following these steps:   1.  Identify the Base Pathway by matching its ID to the value of the       BASE-ID key in the Pathway Clone object.   2.  Duplicate the Base Pathway.   3.  Set the ID of the new Pathway to the value of the ID key in the       Pathway Clone object.   4.  For each URI belonging to the new Pathway:       A.  Resolve the URI against its base if necessary and then           replace its hostname with the URI-REPLACEMENT HOST string (if           present).       B.  Append each name/value pair of the PARAMS object (if           present), in the UTF-8 order of the names, as a query           parameter of the URI.  If a parameter of the same name is           already present in the URI, replace it with the one from the           PARAMS object.       C.  Replace the URI in the new Pathway with the modified URI.   A CDP that extends the URI-REPLACEMENT element MUST modify the above   process to include its extensions.Pantos & Vershen        Expires 21 February 2026                [Page 7]Internet-Draft              Content Steering                 August 2025   A Pathway Clone MAY use another Pathway Clone as its base if it   appears earlier in the PATHWAY-CLONES array.   The Pathway ID that is defined by a Pathway Clone MAY appear in the   PATHWAY-PRIORITY list, in any position.   The HOST string of a Pathway Clone MUST be non-empty if it is   present.   The name of a PARAMS object name/value pair MUST be non-empty.  The   names and values in a PARAMS object MUST be able to form a valid URI   query parameter.  Any reserved characters in those strings MUST be   percent-encoded [RFC3986].   A client that does not have the definition of a Pathway specified by   the BASE-ID string of a Pathway Clone object MUST ignore the Pathway   Clone.  The client has the definition of a Pathway if it appears in   the original Content Description, or appears in the Pathway Clones   array from the current Steering Manifest.   Client support of Pathway Cloning is OPTIONAL, unless determined   otherwise by the CDP.  A steering server SHOULD ensure that the   PATHWAY-PRIORITY list always contains at least one Pathway defined in   the original Content Description.6.  Steering Query Parameters   The client sends a request with the Steering Manifest URI to obtain   the Steering Manifest.  Each CDP can define query parameters that the   client SHOULD add to the URI.   To support stateless processing by the Steering Server the following   client state SHOULD be provided:      The ID of the Pathway currently applied by the client.      A current prediction of content download throughput made by the      client for the currently applied Pathway.  The exact method of bit      rate estimation will vary by client, but the units (such as bits      per second) SHOULD be specified by the CDP.   HTTP proxy caches SHOULD be configured to exclude highly variable   query parameters from their cache keys, or treat the Steering   Manifest response as non-cacheable.Pantos & Vershen        Expires 21 February 2026                [Page 8]Internet-Draft              Content Steering                 August 20257.  Steering Client Responsibilities   A Pathway is applied by first choosing a particular Pathway ID.  The   set of URIs to which the client is allowed to use is then restricted   to those belonging to that Pathway.  If a client is currently using a   content URI that does not belong to the applied Pathway, it MUST   switch to using one that does.   A client that supports Content Steering MUST implement the following   algorithm.  In this algorithm the exact meaning of "being penalized"   is specific to the particular CDP, but its general meaning is that   the Pathway will not be used by the client for some period.  A CDP   SHOULD add clarifications and/or changes to this algorithm as is   appropriate for its Content Delivery Protocol:   1.  When using a Content Description that contains an initial       Steering Manifest URI, load the Steering Manifest.  A client that       wishes to use the content before it obtains the Steering Manifest       SHOULD apply the initial Pathway of the Content Description.  If       the Content Description does not contain a initial Pathway, the       client MAY use any Pathway until it obtains the Steering       Manifest.   2.  When a Steering Manifest is received, perform Pathway Cloning on       any members of the PATHWAY-CLONES array.  Then, perform a Content       Steering evaluation (step 5).   3.  If all the URIs from the current Pathway fail with a network       error, or if the lowest-bitrate URI or combination of URIs cannot       be downloaded quickly enough to support real-time use, the client       MAY mark the current Pathway as penalized, and perform a Content       Steering evaluation (step 5).   4.  If the client decides that the Pathway has been penalized long       enough that it may have recovered, it SHOULD un-penalize the       Pathway and perform a Content Steering evaluation (step 5).   5.  Content Steering evaluation: If no Pathway is currently applied,       or the current Pathway is not the first in the PATHWAY-PRIORITY       list, or is no longer on the list, or is being penalized, then       apply the first non-penalized Pathway on the list.  If no such       Pathway is available, the client SHOULD remain on the current       Pathway.Pantos & Vershen        Expires 21 February 2026                [Page 9]Internet-Draft              Content Steering                 August 2025   6.  When the current Steering Manifest expires, as defined by the TTL       attribute, issue a new Steering Manifest request for the URI       specified by RELOAD-URI or the previous server URI if none.  The       RELOAD-URI may be absolute or relative to the previous server       URI.   7.  When the Steering Manifest cannot be loaded or parsed correctly:       A.  If the client receives HTTP 410 Gone in response to a           manifest request, it MUST NOT issue another request for that           URI for the remainder of the session.  It MAY continue to use           the most-recently obtained set of Pathways.       B.  If the client receives HTTP 429 Too Many Requests with a           Retry-After header in response to a manifest request, it           SHOULD wait until the time specified by the Retry-After           header to reissue the request.       C.  Otherwise, the client SHOULD continue to use the previous           values and attempt to reload it after waiting for the           previously-specified TTL.  If no Steering Manifest has been           successfully parsed, a TTL of 5 minutes SHOULD be used.8.  Content Steering Manifest Examples8.1.  Content Steering Manifest   This example shows a Content Steering Manifest.   {     "VERSION": 1,     "TTL": 300,     "RELOAD-URI": "https://example.com/steering?video=00012&session=123",     "PATHWAY-PRIORITY": [       "CDN-A",       "CDN-B"     ]   }8.2.  Content Steering Manifest with Pathway Clone   This example extends the previous example with a Steering Manifest   that includes a Pathway Clone.Pantos & Vershen        Expires 21 February 2026               [Page 10]Internet-Draft              Content Steering                 August 2025   {       "VERSION": 1,       "TTL": 300,       "PATHWAY-PRIORITY": [          "CDN-A-CLONE",          "CDN-A"       ],       "PATHWAY-CLONES": [           {               "BASE-ID": "CDN-A",               "ID": "CDN-A-CLONE",               "URI-REPLACEMENT":               {                   "HOST": "backup2.example.com",                   "PARAMS":                   {                       "token": "dkfs1239414"                   }               }           }       ]   }9.  Acknowledgements   Thanks to the members of the IETF hls-interest mailing list for   feedback.10.  Contributors   Significant contributions to the design of this protocol were made by   Naiwei Zheng and Jordan Schneider.11.  IANA Considerations11.1.  vnd.apple.steering-list   IANA has registered the following media type [RFC2046]:   Type name: application   Subtype name: vnd.apple.steering-list   Required parameters: none   Optional parameters: nonePantos & Vershen        Expires 21 February 2026               [Page 11]Internet-Draft              Content Steering                 August 2025   Encoding considerations: encoded as JSON (UTF-8), which is 8-bit   text.  This media type may require encoding on transports not capable   of handling 8-bit text.  See Section 4 for more information.   Security considerations: See Section 12.   Compression: this media type does not employ compression.   Interoperability considerations: There are no byte-ordering issues   since files are 8-bit text.  Applications could encounter   unrecognized keys, which SHOULD be ignored.   Published specification: see Section 4.   Applications that use this media type: streaming media content   delivery protocols such as HLS and DASH, including media servers and   media players.   Fragment identifier considerations: no Fragment Identifiers are   defined for this media type.   Query parameter considerations: this specification does not define   any query parameters, however any CDP using Content Steering may   define query parameters.  (See Section 6.)   Additional information:      Deprecated alias names for this type: none      Magic number(s): none      File extension(s): .json (see Section 4)      Macintosh file type code(s): none   Person & email address to contact for further information: Dimitri   Podborski, dpodborski AT apple.com.   Intended usage: LIMITED USE   Restrictions on usage: none   Author: Roger Pantos   Change Controller: Dimitri Podborski12.  Security Considerations   Since the protocol generally uses HTTP to transfer data, most of the   same security considerations apply.  See Section 15 of HTTP   [RFC9112].Pantos & Vershen        Expires 21 February 2026               [Page 12]Internet-Draft              Content Steering                 August 2025   Parsers are typically subject to "fuzzing" attacks.  Implementors   SHOULD pay particular attention to code that will parse data received   from a server and ensure that all possible inputs are handled   correctly.   Content Description files contain URIs, which clients will use to   make network requests of arbitrary entities.  Clients SHOULD range-   check responses to prevent buffer overflows.  See also the Security   Considerations section of "Uniform Resource Identifier (URI): Generic   Syntax" [RFC3986].   Apart from URI resolution, this format does not employ any form of   active content.   HTTP requests often include session state ("cookies"), which may   contain private user data.  Implementations MUST follow cookie   restriction and expiry rules specified by "HTTP State Management   Mechanism" [RFC6265] to protect themselves from attack.  See also the   Security Considerations section of that document, and "Use of HTTP   State Management" [RFC2964].13.  References13.1.  Normative References   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail              Extensions (MIME) Part Two: Media Types", RFC 2046,              DOI 10.17487/RFC2046, November 1996,              <https://www.rfc-editor.org/info/rfc2046>.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/info/rfc2119>.   [RFC2964]  Moore, K. and N. Freed, "Use of HTTP State Management",              BCP 44, RFC 2964, DOI 10.17487/RFC2964, October 2000,              <https://www.rfc-editor.org/info/rfc2964>.   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November              2003, <https://www.rfc-editor.org/info/rfc3629>.   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform              Resource Identifier (URI): Generic Syntax", STD 66,              RFC 3986, DOI 10.17487/RFC3986, January 2005,              <https://www.rfc-editor.org/info/rfc3986>.Pantos & Vershen        Expires 21 February 2026               [Page 13]Internet-Draft              Content Steering                 August 2025   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,              DOI 10.17487/RFC6265, April 2011,              <https://www.rfc-editor.org/info/rfc6265>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/info/rfc8174>.   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data              Interchange Format", STD 90, RFC 8259,              DOI 10.17487/RFC8259, December 2017,              <https://www.rfc-editor.org/info/rfc8259>.   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,              June 2022, <https://www.rfc-editor.org/info/rfc9112>.13.2.  Informative References   [ISO_23009_1]              International Organization for Standardization,              "Information technology - Dynamic adaptive streaming over              HTTP (DASH) - Part 1: Media presentation description and              segment formats", ISO/IEC International              Standard 23009-1:2022, August 2022,              <https://www.iso.org/standard/83314.html>.   [RFC8216bis]              Pantos, R., Ed., "HTTP Live Streaming 2nd Edition",              February 2025, <https://datatracker.ietf.org/doc/html/              draft-pantos-hls-rfc8216bis-17>.Authors' Addresses   Roger Pantos (editor)   Apple Inc.   Cupertino, California   United States   Email: http-live-streaming-review@group.apple.com   Eryk Vershen   Apple Inc.   Cupertino, California   United States   Email: content-steering-review@group.apple.comPantos & Vershen        Expires 21 February 2026               [Page 14]