Francis,
Ok, It shouldn't be a negotiation but an indication to accommodate
communication to each party.
Fair point.
Ok, it is important to note the peer is limiting max frame
size not the
message size which may be still infinite in practical terms (63
bits)....and we have fragmentation support to deal with this.
I understand. I was just pointing out that in your example, if the client
instead decided to limit the size of messages that it sent then then nothing
could cause any frames to be larger than that limit when they arrived at the
server.
1) Protocol problems should be solved on its layer, otherwise it will
cause next layer (application level in this case) to need to solve
them. It looks reasonable not forcing people to do so.
Agree.
2) In general, it has lot of benefits to fragment bigger messages into
smaller pieces to avoid sick interactions.
Agree.
3) No matter API style provided by a websocket stack (frame indication
or stream oriented), having framing running in the background
where the
sending peer and intermediaries can coalesce frames without any
indication of the upper level will cause problems that can't be solved
in practical terms by a receiving side.
Agree.
Len
www.lenholgate.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf