Re: [hybi] Frame size

Thomson, Martin wrote:
> Responding to specific concerns on framing seems not especially productive.
>
> Proposal:
>
>  - Frame size is indicated up front.
>  - Frames are binary.
>  - Frame size be strictly limited (2 octets should suffice).
>  - Sub-protocol needed if messages are larger than the max frame.
>   
+1 as a good starting point for the framing. Details can be worked out 
from this proposal.

-- Scott
> Justification:
>
> Most use cases are for low latency bi-directional communications.  These don't need large messages.
>
> HTTP is (much) better suited to file transfers in the server->client direction and despite some historical shortcomings in the other direction, still arguably superior (chunked encoding, etc...).
>
> Limiting message size helps keep simple implementations simple; but isn't a burden on implementations that have more complex requirements.
>
> Binary frames isolate user-space (the payload) from the framing layer.  We had this discussion in the meeting (c.f. Pete Resnick's comments).  Thus, 
>  - binary frames are easier to process (intermediaries don't have to inspect every octet)
>  - kinder on implementations (framing component does not depend on UTF-8 component)
>  - isolates framing layer from the bugs of higher layers
>
> Shortcomings:
>
> Greg did have some use cases where larger messages were desired.  A trivial sub-protocol that consists of a continuation marker would solve this.
>
> IF used for UTF-8 AND implementer counts characters instead of octets THEN framing doesn't work.  (One solution to this problem is to start a frame with a known sequence of octets, so that this can be detected.  Another "solution" is to not worry about it.)
>
> --Martin
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>