- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Mon, 20 Feb 2017 15:18:13 -0500
- To: Craig Pratt <craig@ecaspia.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNoeX7zYixhwprJpx7OzjPWh1L-7Nd=Dvm5L5FBXVUmG5Q@mail.gmail.com>
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 <craig@ecaspia.com> 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 > > craig@ecaspia.com > > 503.746.8008 > > > > > > > > > >
Received on Monday, 20 February 2017 20:19:01 UTC