Comment by camgunz

> I admit I've only skimmed the RFC, but it seems to explicitly allow receivers to refuse to deal with lots of features.

That's true but like, at what point are people disappointed your library doesn't support functionality that they think is pretty core? I'm not saying libraries can or should support everything, just that specs that ask a lot of implementations are inviting this kind of thing, and that while MP considers this, CBOR pretty clearly does not.

> In that you may preallocate a (large enough) buffer in the latter case, and bail out when the incoming message grows out of it but still be able to skip to the rest of the message as opposed to not being able to re-synchronize because the minimally needed parsing context grows without bound?

Neither of these are recoverable because you don't know how much to skip to resync (assuming skipping a bunch of data isn't by itself fatal):

- Stack: Maps and arrays only tell you their elements/pair counts, not how many bytes to skip in a stream, so to skip them you have to parse them fully, because they may be nested.

- Stream: By definition you don't know how much to skip.

Again these are the kinds of issues you'd address in a protocol definition. Though it kind of tries to pose as one, CBOR is not a protocol definition. A more reasonable thing to do would be to stream MP over HTTP, because you get so many things for free (connection management, caching and TLS to name a few).