Subject: Live Byte Ranges

From: Patrick McManus <[email-masked]>
Date: Tue, 22 Nov 2016 17:38:31 -0500

Dear HTTPbis denizens,

As I did with the 103-proposal, I have a request to the working group
implementors to offer a sign of their interest or opposition to the Random
Access and Live Content draft and presentation that we talked about in
Seoul[*]

To summarize briefly - this addresses the problem of addressing byte ranges
of dynamic (growing) content. A number of solutions have seen false starts
in this space previously, but this one has a shot at being compatible with
existing infrastructure.

This was published quite close to the meeting, and while the chairs had the
sense people generally really liked the solution it also seemed as if not
everyone had the chance to get familiar with it. Please do so with this
thread!

Particular comments on the draft are welcome here, as are general comments
along the line of "that would be good for the ecosystem" or "omg - I can't
stomach that because <<>>". If there is enough interest we'll proceed with
a CFA.

Thanks
-Patrick

[*] https://tools.ietf.org/id/draft-pratt-httpbis-rand-access-live-00.txt
and
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_HTTPBIS_II&chapter=chapter_1
at the 00:51 mark

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Nov 2016 10:05:23 +0100

On 2016-11-22 23:38, Patrick McManus wrote:
> implementors to offer a sign of their interest or opposition to the
> Random Access and Live Content draft and presentation that we talked
> about in Seoul[*]
>
> To summarize briefly - this addresses the problem of addressing byte
> ranges of dynamic (growing) content. A number of solutions have seen
> false starts in this space previously, but this one has a shot at being
> compatible with existing infrastructure.

Where "this one" IMHO is only one of the options mentioned in 
<https://tools.ietf.org/id/draft-pratt-httpbis-rand-access-live-00.txt>.

> This was published quite close to the meeting, and while the chairs had
> the sense people generally really liked the solution it also seemed as
> if not everyone had the chance to get familiar with it. Please do so
> with this thread!
>
> Particular comments on the draft are welcome here, as are general
> comments along the line of "that would be good for the ecosystem" or
> "omg - I can't stomach that because <<>>". If there is enough interest
> we'll proceed with a CFA.

"That would be good for the ecosystem" :-)

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 23 Nov 2016 10:25:02 +0100 (CET)

On Tue, 22 Nov 2016, Patrick McManus wrote:

> stomach that because <<>>". If there is enough interest we'll proceed with a 
> CFA.

We've had users ask for this kind of support in the curl project in the past 
so I think it'd be good to get it settled in a standard way.

-- 

  / daniel.haxx.se

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 28 Nov 2016 19:52:52 +0000

--------
In message <[email-masked]>

>in this space previously, but this one has a shot at being compatible with

Varnish will almost certainly implement whatever comes out of this.

Notes from our mumblings in the project:

The "Very Large Value" solution it is brittle in more ways than is
desirable, but try as we may, we don't see any simpler/better ways
of doing it without negotiation/hints.

We suggest to either put a "Quite Large" lower limit on "Very Large
Value", or better yet:  Make it a magic value large enough to not
be a problem relative to actual Range requests.  If we keep with
the 9's motif from the draft, we suggest 999999999999999999 which
doesn't needlessly provoke 64-bit sign issues.

Typo on page 3: "accessable"

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Craig Pratt <[email-masked]>
Date: Mon, 28 Nov 2016 13:06:13 -0800

Thanks much for the feedback.

Reply in-line.

cp

On 11/28/16 11:52 AM, Poul-Henning Kamp wrote:

--------

I should add that I'm going to submit a patch to Rygel (the Gnome
media streaming package) to support this draft as well.

Agreed. I wish there was a better way. Maybe the rust can be cleaned
off of Range Units by filing some bugs against implementations that
are making assumptions about Range Units. Even if it's not
used/helpful here, it might open the door for some other
applications.

I thought about the magic value approach. It's certainly more
deterministic to use a Quite Large Magic Value (QLMV?) - and easier
to specify and code. And it's entertaining to think up magic values
(e.g. 2^63 - 42) (but agreed that all 9s does a better job of
jumping out to us humans). I just couldn't suppress my engineering
gag reflex at the whole concept. This reflex has some adjustment,
but I'm presuming it's a common reaction.

I also didn't like the idea of forcing a limit. But 2^63 is a
crazy-large number. At 50Mb/s, the representation could cover over
46000 years, according to my quick math (with 999999999999999999
covering a mere 5073 years). And there's nothing preventing the
definition/addition of a VLMV now or later. I just can't help but
wonder if a Registry of Magic Values would then be in order (there's
that gag reflex again).

Anyway, I'm good either way so long as there's general consensus. I
tried to cover the issue of values larger than 2^63 in the Security
Considerations section. Perhaps a "should" or recommended QLMV/VLMVs
would be a way to go? Other thoughts/opinions appreciated here.

Thanks. It'll be corrected in the next version. (Somehow
"accessable" is in my mac's spelling dictionary)

cp

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008