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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
