Subject: [Hls-interest] Question about RFC8673 reference in draft-pantos-hls-rfc8216bis-09

From: Andrew Ryan <[email-masked]>
Date: Wed, 5 May 2021 12:07:40 -0400

Greetings,
  I was hoping to gain clarification on the reference of RFC8673
(Experimental) in
https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-09#section-4.4.5.3

  Based on the previous discussions on this list, the use case for defining
the Very Large Number in the last-byte-pos is understood, and I can see the
reasoning behind referencing https://tools.ietf.org/html/rfc8673#section-4
in this case.

  After further review of RFC8673, there is a section which may present an
issue

  in RFC8673 at https://tools.ietf.org/html/rfc8673#section-2.1 it states:

    Determining if a representation is continuously aggregating ("live")
>     and determining the randomly accessible byte range can both be
>     performed using the existing definition for an open-ended byte-range
>     request. Specifically, Section 2.1 of [RFC7233] defines a byte-range
>     request of the form:
>
>     byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
>
>     which allows a client to send a HEAD request with a first-byte-pos
>     and leave last-byte-pos absent. A server that receives a satisfiable
>     byte-range request (with first-byte-pos smaller than the current
>     representation length) may respond with a 206 status code (Partial
>     Content) with a Content-Range header field indicating the currently
>     satisfiable byte range.
>

  If we look at RFC7233 at https://tools.ietf.org/html/rfc7233#section-3.1
it states

   A server MAY ignore the Range header field.  However, origin servers
>    and intermediate caches ought to support byte ranges when possible,
>    since Range supports efficient recovery from partially failed
>    transfers and partial retrieval of large representations.  A server
>    MUST ignore a Range header field received with a request method other
>    than GET.
>

  As I interpret the above section of RFC8673: It is intending to use a
HEAD request with a Range header with the goal of getting a 206 response
with a Content-Range response header to determine current asset length.
RFC7233 states that the Range request header MUST be ignored unless the
request is a GET. If my interpretation is correct, this seems to indicate
an incompatibility for what is being proposed in RFC8673 and what is
currently specified in RFC7233.

  The question I was hoping to gain clarification on is if RFC8673 is
referenced in draft-pantos-hls-rfc8216bis-09 specifically for the
last-byte-pos component or if there is an expectation of incorporating more
concepts from RFC8673 as well.

Thank you very much for your time.

-- 
 <https://www.limelight.com>
Andrew Ryan* Principal Architect*
EXPERIENCE FIRST.
+1 716 250 9882 <+1+716+250+9882>
www.limelight.com
 <https://www.facebook.com/LimelightNetworks>[image:
LinkedIn] <https://www.linkedin.com/company/limelight-networks>[image:
Twitter] <https://twitter.com/llnw>

---

From: "Law, Will" <[email-masked]>
Date: Wed, 5 May 2021 16:43:24 +0000

@Andrew – thanks for raising scrutiny on RFC8673. I did want to point out that the use case in RFC8673 concerning a HEAD request that you excerpt below is for a client that is a) wanting to find out if a representation is continuously aggregating and b) to discover what is the latest byte available. A LL-HLS player does not need to do either of these actions. It knows that a representation is aggregating (it is a consequence of byte-range addressing in the media playlist) and the media playlist very conveniently gives it the starting byte position of what it needs to request. So there is no need for the discovery HEAD request. It can immediately proceed to a GET request, using the first-byte value given to it by the playlist and the last-byte value of 9007199254740991 (per RFC 8673). In my interpretation then, this does not conflict with the RFC8216 restriction that a server MUST ignore a Range header field received with a request method other than GET, since a LL-HLS client will not need to execute a HEAD request.

Cheers
Will

From: Andrew Ryan <aryan=[email-masked]>
Date: Wednesday, May 5, 2021 at 9:08 AM
To: "[email-masked]" <[email-masked]>
Subject: [Hls-interest] Question about RFC8673 reference in draft-pantos-hls-rfc8216bis-09

Greetings,
  I was hoping to gain clarification on the reference of RFC8673 (Experimental) in https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-09#section-4.4.5.3<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-pantos-hls-rfc8216bis-09*section-4.4.5.3__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4UIeX2U4$>

  Based on the previous discussions on this list, the use case for defining the Very Large Number in the last-byte-pos is understood, and I can see the reasoning behind referencing https://tools.ietf.org/html/rfc8673#section-4<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8673*section-4__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4UVFZHsR$> in this case.

  After further review of RFC8673, there is a section which may present an issue

  in RFC8673 at https://tools.ietf.org/html/rfc8673#section-2.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8673*section-2.1__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4V9ngmQd$> it states:

  If we look at RFC7233 at https://tools.ietf.org/html/rfc7233#section-3.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7233*section-3.1__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4Y0qKZ7W$> it states

  As I interpret the above section of RFC8673: It is intending to use a HEAD request with a Range header with the goal of getting a 206 response with a Content-Range response header to determine current asset length. RFC7233 states that the Range request header MUST be ignored unless the request is a GET. If my interpretation is correct, this seems to indicate an incompatibility for what is being proposed in RFC8673 and what is currently specified in RFC7233.

  The question I was hoping to gain clarification on is if RFC8673 is referenced in draft-pantos-hls-rfc8216bis-09 specifically for the last-byte-pos component or if there is an expectation of incorporating more concepts from RFC8673 as well.

--
[Image removed by sender. Limelight Networks]<https://urldefense.com/v3/__https:/www.limelight.com__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4ZhD5ETA$>

Andrew Ryan Principal Architect
EXPERIENCE FIRST.
[Image removed by sender.][Image removed by sender.]+1 716 250 9882<tel:+1+716+250+9882>
www.limelight.com<https://urldefense.com/v3/__https:/www.limelight.com__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4ZhD5ETA$>

[Image removed by sender. Facebook]<https://urldefense.com/v3/__https:/www.facebook.com/LimelightNetworks__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4YKDKJN0$>[Image removed by sender. LinkedIn]<https://urldefense.com/v3/__https:/www.linkedin.com/company/limelight-networks__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4W8yr_OX$>[Image removed by sender. Twitter]<https://urldefense.com/v3/__https:/twitter.com/llnw__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4dv7kLaF$>

---

From: Andrew Ryan <[email-masked]>
Date: Wed, 5 May 2021 13:42:35 -0400

Will,
  Thank you for the response.  I agree with your position on the LL-HLS
player behavior in that it would not need to use the workflow described in
RFC8673 (HEAD with Range header), so that should circumvent this particular
concern with RFC8673.  This seems to then align with the idea that RFC8673
is only referenced for it's section pertaining to last-byte-pos and that
there isn't an expectation that other parts of RFC8673 should be considered
relevant.  Once again, Thank you for the reply and explanation.

On Wed, May 5, 2021 at 12:43 PM Law, Will <wilaw=[email-masked]>
wrote:

> @Andrew – thanks for raising scrutiny on RFC8673. I did want to point out
> that the use case in RFC8673 concerning a HEAD request that you excerpt
> below is for a client that is a) wanting to find out if a representation is
> continuously aggregating and b) to discover what is the latest byte
> available. A LL-HLS player does not need to do either of these actions. It
> knows that a representation is aggregating (it is a consequence of
> byte-range addressing in the media playlist) and the media playlist very
> conveniently gives it the *starting byte position *of what it needs to
> request. So there is no need for the discovery HEAD request. It can
> immediately proceed to a GET request, using the first-byte value given to
> it by the playlist and the last-byte value of 9007199254740991 (per RFC
> 8673). In my interpretation then, this does not conflict with the RFC8216
> restriction that a server MUST ignore a Range header field received with a
> request method other than GET, since a LL-HLS client will not need to
> execute a HEAD request.
>
>
>
> Cheers
>
> Will
>
>
>
>
>
> *From: *Andrew Ryan <aryan=[email-masked]>
> *Date: *Wednesday, May 5, 2021 at 9:08 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Hls-interest] Question about RFC8673 reference in
> draft-pantos-hls-rfc8216bis-09
>
>
>
> Greetings,
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-pantos-hls-rfc8216bis-09*section-4.4.5.3__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4UIeX2U4$>
>
>   Based on the previous discussions on this list, the use case for
> defining the Very Large Number in the last-byte-pos is understood, and I
> can see the reasoning behind referencing
> https://tools.ietf.org/html/rfc8673#section-4
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8673*section-4__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4UVFZHsR$>
> in this case.
>
>   in RFC8673 at https://tools.ietf.org/html/rfc8673#section-2.1
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8673*section-2.1__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4V9ngmQd$>
> it states:
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7233*section-3.1__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4Y0qKZ7W$>
> it states
>
> <https://urldefense.com/v3/__https:/www.limelight.com__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4ZhD5ETA$>
>
> *Andrew Ryan** Principal Architect*
> *EXPERIENCE FIRST.*
> +1 716
> <https://urldefense.com/v3/__https:/www.limelight.com__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4ZhD5ETA$>
>
>
>
> <https://urldefense.com/v3/__https:/www.facebook.com/LimelightNetworks__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4YKDKJN0$>[image:
> Image removed by sender. LinkedIn]
> <https://urldefense.com/v3/__https:/www.linkedin.com/company/limelight-networks__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4W8yr_OX$>[image:
> Image removed by sender. Twitter]
> <https://urldefense.com/v3/__https:/twitter.com/llnw__;!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4dv7kLaF$>
>
>
>