[Interest] CBOR Questions

[Jason H]

> > So the protocol it expects to work with assumes a message-based upper bound,
> > and of trivial size. This is not good.  In light of this, I would suggest a
> > QCborDataStream class that implements efficient parsing.
> 
> No needed. You simply misunderstood the CoAP spec.

In what way? The spec continues:

 Implementation Note:  CoAP's choice of message size parameters works
      well with IPv6 and with most of today's IPv4 paths.  (However,
      with IPv4, it is harder to absolutely ensure that there is no IP
      fragmentation.  If IPv4 support on unusual networks is a
      consideration, implementations may want to limit themselves to
      more conservative IPv4 datagram sizes such as 576 bytes; per
      [RFC0791], the absolute minimum value of the IP MTU for IPv4 is as
      low as 68 bytes, which would leave only 40 bytes minus security
      overhead for a UDP payload.  Implementations extremely focused on
      this problem set might also set the IPv4 DF bit and perform some
      form of path MTU discovery [RFC4821]; this should generally be
      unnecessary in realistic use cases for CoAP, however.)  A more
      important kind of fragmentation in many constrained networks is
      that on the adaptation layer (e.g., 6LoWPAN L2 packets are limited
      to 127 bytes including various overheads); this may motivate
      implementations to be frugal in their packet sizes and to move to
      block-wise transfers [BLOCK] when approaching three-digit message
      sizes.