Re: Call For Adoption Live Byte Ranges

[Craig Pratt <[e-mail]>]

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" rel="nofollow">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 <[e-mail]> 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

[e-mail]

503.746.8008

       


       

--

craig pratt Caspia Consulting [e-mail] 503.746.8008