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

["Law, Will" <[e-mail]>]

@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=[e-mail]>
Date: Wednesday, May 5, 2021 at 9:08 AM
To: "[e-mail]" <[e-mail]>
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:
    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<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7233*section-3.1__;Iw!!GjvTz_vk!EVXLogKl8pK9QJLuvxKpGGG6aldvMaZgyuG7-UOHPMl58hMwFx-l4Y0qKZ7W$> 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.

--
[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.][phone]<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$>