Subject: [Cbor] Question about CBOR padding

From: Matt Vollrath <[email-masked]>
Date: Tue, 6 Nov 2018 16:58:18 -0500

Hello list,

I'm finding CBOR extremely useful for moving large binary blobs 
(specifically: ROS point clouds) into browsers via WebSocket. While 
hacking on a CBOR integration, I ran into something that the spec 
doesn't seem to cover.

How should CBOR data be padded, if I were to do something weird like 
pack it into a PNG?  Believe it or not, the previous implementation 
packed JSON into PNG with \n padding to complete the last pixel.  I 
didn't see anything in the spec about padding, except the mention that 
UBJSON has an explicit noop code.

I don't intend to wrap CBOR in PNG (per-message deflate is a much better 
way to get the same compression over ws), but thought the lack of an 
explicit padding solution was worth asking about.

Thanks and keep up the good work,
Matt Vollrath
End Point Corp

---

From: Thiago Macieira <[email-masked]>
Date: Tue, 6 Nov 2018 14:25:11 -0800

> UBJSON has an explicit noop code.

CBOR has no need for padding and it does not have any byte sequence that can 
fill in for padding.

Some CBOR decoders will simply stop when they've finished reading the one 
element, ignoring anything remaining in the buffer. If you know this is your 
case, then simply append anything you want until you reach the boundary you 
ant.

Other decoders will report garbage at the end. If this is a possibility for 
your file format, you should design your container so you know where the 
actual CBOR data ends and so you can feed the decoder no padding.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Nov 2018 11:42:32 +0700

> CBOR has no need for padding and it does not have any byte sequence that can

True.

You could pad with a sized or series of indefinite length array that ended
with no items.  I think it's best to just read the first "element", and
ignore the rest though.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Nov 2018 12:24:27 +0700

When we did CBOR, we didn’t have a very good use case for padding.

I’m not sure we have one now; but let me mention that we have some free codes that could be set aside for padding.

So if the WG wants to define a version of CBOR that supports padding, I have a proposal to pull out of the drawer.

In this particular case, it sounds like a stop code (“no more data following”) would also do it.

Grüße, Carsten

> On Nov 7, 2018, at 11:42, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>