Skip to main content

Liaison statement
Liaison Statement on the use of HTTP headers for DASH improvements

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2015-11-03
From Group ISO-IEC-JTC1-SC29-WG11
From Contact Shinji Watanabe
To Group IETF
To Contacts The IETF Chair <>
Cc The IESG <>
The IETF Chair <>
Stephan Wenger <>
Response Contact Watanabe Shinji <>
Purpose For information
Attachments (None)
MPEG has defined the DASH standard for adaptive media streaming over HTTP.
Adaptation is achieved by offering several alternative Representations of the
content that are encoded at different bitrates or resolutions. The DASH client
can then select and switch between Representations based on its available

As part of DASH enhancements, MPEG is working on optimizing the media delivery
following two approaches: -       Studying inter-working between DASH client
and DASH aware HTTP proxies. -       Studying DASH over bi-directional
protocols, in particular HTTP/2 and its push feature. Each approach makes use
or defines HTTP header onto which MPEG would like to receive feedbacks and
guidelines from IETF.

For inter-working between DASH client and DASH aware HTTP proxies, one of the
DASH enhancement consists of a client indicating a list of representations that
it is willing to accept as an alternative response to the current request. This
is done through a new “Accept-Alternatives” header field containing the URLs
for each possibility.

In case an alternative representation of the resource is already cached, Vary
and Warning headers are added to change the identity of the response and
prevent it from being served as a response to a regular request. The
Content-Location header in the response indicates the URL of the actual
representation that was served (see example of use below).

We would like to kindly ask you the following:
•       Is this type of HTTP request/response conformant?
•       Are there any implications of such type of HTTP transactions (for
example on intermediate proxies)? •       Are there alternatives provided by
HTTP 1.1 to achieve similar results?

On the use of HTTP/2 push in DASH, MPEG is defining a set of messages that
allow clients to exchange push strategies with DASH servers (various strategies
are under consideration). For this, MPEG intends to define a new
Accept-Push-Policy header in order to convey the type of push strategy desired
by the client (see example below). The type of the push strategy is, optionally
followed by push-strategy-specific parameters. The syntax could look like:

Accept-Push-Policy: <unique_name> [ ’;’ <policy-specific-param>*]

The message corresponding to the server response would optionally contain a
similar header enabling the server to acknowledge the strategy indicated by the
client. We’re interested in receiving feedback from IETF experts, in particular
on the following aspects: •       Do IETF experts have recommendations and/or
guidelines on “extending” the list of HTTP Accept headers especially on exact
syntax definition: recommended separators, unique naming scheme, parameters
passing •       Should such header be defined at IETF level?

MPEG would appreciate your responses to any of the above-mentioned questions.

Our future meetings:
-       The 114th MPEG meeting, 22 February 2015, San Diego
-       The 115th MPEG meeting, 30 May 2015, Geneva

Example of use for alternative response:
Let’s assume the DASH client selects the following as its normal request:
and it considers 2 alternative representations of the same video segment as
acceptable: The http request from the DASH client
would be:

[See document]

Example of use for push strategy exchange:
In live streaming scenario, a DASH client requesting a given media segment (ex:
segment_1.mp4) would like the server to push the 5 next segments in the same
Representation. Then, the client request would contain the new defined header
“accept-push-policy” with as value the push strategy type “push-next” and as
parameter the value for “5” next segments. The header in the HTTP/2 HEADER
frame would be:

[See document]