Subject: Re: Call For Adoption Live Byte Ranges

From: Patrick McManus <[email-masked]>
Date: Mon, 20 Feb 2017 15:18:13 -0500

Craig - sorry again for the schedule on this one. We certainly have
consensus for adoption. Please upload an ietf-httpbis copy to the
datatracker when you're ready (it can be the same as your current revision
if you like).

Our WG drafts are normally managed through github at
https://github.com/httpwg/http-extensions - contact Mark or I out of band
and we'll help with the administration of the repo for whomever would like
to have primary responsibility for the document - or if you'd rather skip
that you can send us the markdown and we'll take care of it for you.

I think the primary remaining concern of the chairs is that the draft get a
thorough review from header field experts in our community.

-Patrick

On Mon, Jan 2, 2017 at 6:00 PM, Craig Pratt <[email-masked]> wrote:

> On 12/19/16 2:30 PM, Patrick McManus wrote:
>
>> Does anyone have any *additional* input on adopting this document? it
>> seems that there is strong support so far.
>>
>> We'll keep the our several CFAs open through the new year and then make a
>> determination. Thanks.
>>
>> -Patrick
>>
>> Thanks Patrick,
>
> In consideration of Poul-Henning Kamp's feedback and some evolution in my
> own preferences, I'm drafting a revision to the Live Bytes Range draft to
> define the "Very Large Value" as a specific numerical value - after
> realizing that 2^63 bytes doesn't really represent a practical limit.
>
> e.g. At 50Mb/s, a representation limited to 2^63 bytes representation
> could cover over 46000 years. Even at 1Gb/s, 2339 years could be
> represented.
>
> 2^63 is 9223372036854775808 (decimal). I've defined a smaller value to
> avoid potential conflicts and to make the value more easily identifiable:
> 9222999999999999999.
>
> I think having a clearly-defined Very Large Value such as this to
> represent the indeterminate end of content will be more
> deterministic/easily implemented than having a Server try to establish a
> VLV in each HTTP exchange. But I'd appreciate any thoughts prior to
> revising the draft.
>
> Thanks much - and Happy New Year,
>
> cp
> --
>
> craig pratt
>
> Caspia Consulting
>
> [email-masked]
>
> 503.746.8008
>
>
>
>
>
>
>
>
>
>

---

From: Craig Pratt <[email-masked]>
Date: Tue, 21 Feb 2017 11:27:45 -0800

np Patrick. I've been quite busy with
other things.

I do have some minor updates based on feedback. I'll try to get
the draft into the WG repo. It's already in my personal github
using Julian's scripts. So hopefully I'll be able to figure it
out. But I'll ping you if I need help.

Thanks,

cp

On 2/20/17 12:18 PM, Patrick McManus wrote:

Craig - sorry again for the schedule on this one. We
certainly have consensus for adoption. Please upload an
ietf-httpbis copy to the datatracker when you're ready (it
can be the same as your current revision if you like).

Our WG drafts are normally managed through github at https://github.com/httpwg/http-extensions
- contact Mark or I out of band and we'll help with the
administration of the repo for whomever would like to have
primary responsibility for the document - or if you'd rather
skip that you can send us the markdown and we'll take care of
it for you.

I think the primary remaining concern of the chairs is that
the draft get a thorough review from header field experts in
our community.

-Patrick

On Mon, Jan 2, 2017 at 6:00 PM, Craig
Pratt <[email-masked]>
wrote:

On
12/19/16 2:30 PM, Patrick McManus wrote:

Does anyone have any *additional* input on adopting this
document? it seems that there is strong support so far.

We'll keep the our several CFAs open through the new
year and then make a determination. Thanks.

-Patrick

Thanks Patrick,

In consideration of Poul-Henning Kamp's feedback and some
evolution in my own preferences, I'm drafting a revision to
the Live Bytes Range draft to define the "Very Large Value"
as a specific numerical value - after realizing that 2^63
bytes doesn't really represent a practical limit.

e.g. At 50Mb/s, a representation limited to 2^63 bytes
representation could cover over 46000 years. Even at 1Gb/s,
2339 years could be represented.

2^63 is 9223372036854775808 (decimal). I've defined a
smaller value to avoid potential conflicts and to make the
value more easily identifiable: 9222999999999999999.

I think having a clearly-defined Very Large Value such as
this to represent the indeterminate end of content will be
more deterministic/easily implemented than having a Server
try to establish a VLV in each HTTP exchange. But I'd
appreciate any thoughts prior to revising the draft.

cp

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008

--

craig pratt

Caspia Consulting

[email-masked]

503.746.8008