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

Andrew Ryan <aryan@llnw.com> Wed, 05 May 2021 16:08 UTC

MIME-Version: 1.0
From: Andrew Ryan <aryan@llnw.com>
Date: Wed, 05 May 2021 12:07:40 -0400
Message-ID: <CAGw2CfPQegoU5zK=yrE77kNgFqyeggjd=tnULg4dnq9y8DBCYg@mail.gmail.com>
To: hls-interest@ietf.org
Content-Type: multipart/alternative; boundary="000000000000757d4f05c197661d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/Wdk5cj-E4tBU16xM5IHczvYgFAE>
Subject: [Hls-interest] Question about RFC8673 reference in draft-pantos-hls-rfc8216bis-09
Precedence: list

 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.

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

[Hls-interest] Question about RFC8673 reference i… Andrew Ryan
Re: [Hls-interest] Question about RFC8673 referen… Law, Will
Re: [Hls-interest] Question about RFC8673 referen… Andrew Ryan