Re: Questions on Frame Size

[Martin Thomson <[e-mail]>]

I've made a few changes.  Let me know if the current spec is somehow inadequate.

On 20 June 2013 20:53, Shigeki Ohtsu <[e-mail]> wrote:
> Thanks for explaination.
>
> I would be glad if you add some editors notes or whatever on the draft for
> about it.
>
> I've amended the first commit to change the min frame size so that
> it becomes just editorial fixes. I think it's more clear than before.
>
> https://github.com/shigeki/http2-spec/compare/shigeki_20130621
>
> (2013/06/21 11:56), William Chan (陈智昌) wrote:
>>
>> On Thu, Jun 20, 2013 at 7:40 PM, Shigeki Ohtsu <[e-mail]
>> <mailto:[e-mail]>> 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 think this argument is invalid. I would find it valid to say that this
>> is unnecessary complexity (having a larger max frame size at the
>> framing layer) since that's for non-HTTP protocols and it's too early to
>> discuss them. But if your implementation only going to support HTTP
>> semantics anyway and plans to choke if someone tries to send a frame for a
>> non-HTTP application layer protocol, then I don't think there's any
>> additional implementation burden here.
>>
>>
>>     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.
>>
>>
>>
>>
>
>