- From: 陈智昌 <willchan@chromium.org>
- Date: Thu, 20 Jun 2013 20:01:33 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: Shigeki Ohtsu <ohtsu@iij.ad.jp>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYgLZVDvbyaXSLCURpiN2Qyj8kY627oB=zmskEitq7Uqog@mail.gmail.com>
While I agree with your conclusion, I disagree with your explanation. I think it's inappropriate to explain something as we hashed it out in the f2f, sorry you weren't there to argue it. This is also why I nitpick on commit messages that explain something as "decided at f2f" without an explanation of the rationale. On Thu, Jun 20, 2013 at 7:55 PM, James M Snell <jasnell@gmail.com> wrote: > -1... At the face to face we hashed this out. For the time being, for > the current implementation draft, 16/64 is good enough. > On Jun 20, 2013 7:43 PM, "Shigeki Ohtsu" <ohtsu@iij.ad.jp> wrote: > >> It seems that everyone agreed max 16K in HTTP but is not sure for use of >> 64K now. >> >> I think it is a bad idea to require for all implementers to suport 64K >> frame size because >> it is too early to discuss future extensions for non-HTTP protocols. >> >> I've just made two commits for >> >> 1. change the requirement of min size of frame to 8K as previous one >> (maybe 16K is okay) >> 2. write max frame size of 16K explicity when carrying HTTP >> >> https://github.com/shigeki/**http2-spec/compare/shigeki_**20130621<https://github.com/shigeki/http2-spec/compare/shigeki_20130621> >> >> If this is accepted, I will submit the PR. >> >> Regards, >> >> (2013/06/21 10:14), David Morris wrote: >> >>> >>> >>> On Fri, 21 Jun 2013, Amos Jeffries wrote: >>> >>> Which implies that server-push is a different protocol to HTTP already. >>>> >>> >>> Different from 1.1, but a new feature of 2.0 >>> >>> >>> IIRC: the 64K limit is for next-generation requirements of systems >>>> running >>>> HTTP at TB speeds. Allowing new frames to be added for those larger >>>> line rates >>>> is very useful given they are already on the horizon and HTTP/2.0 has >>>> long >>>> lifetime ahead. >>>> >>> >>> In the SF Interim, we agreed to 64K/16K (frame/vs HTTP) to allow for the >>> larger frame required to establish a TLS connection without added round >>> trips because the initial TLS setup exceeded a single frame. >>> >>> >> >>
Received on Friday, 21 June 2013 03:02:01 UTC