Jamie Lokier wrote: > Let's not get confused about what will and won't work. > > It doesn't matter whether WHATWG sanctions any new frame type or not: > you can't _use_ a frame type if the other end won't recognise it. > > That's because the message boundaries are determined by recognising > the frame type byte, then parsing the message in a type-specific way. Is this true? The high order byte is currently defined as selecting between sentinel or length encoding, and the 7 lower order bits are ignored. So as the spec is written - regardless of the value passed, it will be one of those 2 framing types. In essence, the byte is 1 bit framing type and 7 bits undefined. The 1 bit is also indicating content-type (or at least content-encoding), which is a strange mix of purposes. I hope I'm right because if what you say is true, a server might eventually have to implement up to 256 different framing types! ... and as much as I'm able to endlessly debate the benefits of one framing type over another, I really don't care that much. Can't we just pick one and use it! If the sentinel framing was good enough to carry anything, then I could live with it. But it's not, so let's just do length encoding. Note also that i think it is very valuable to have a known framing type, so that intermediaries can know what message boundaries are and treat them appropriately either with forwarding data, logging, debugging etc. regards
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.