Subject: Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00)

From: Mike Jones <[email-masked]>
Date: Wed, 29 Jul 2020 02:59:18 +0000

I am concerned that this will bifurcate CBOR into implementations that do and don't support this extra feature set.  If a call for adoption were held today, having thought about it, I would oppose adoption on this basis.  I'd rather that all CBOR implementations be interoperable than for some to add this fairly complicated compression feature.

				-- Mike

-----Original Message-----
From: CBOR <[email-masked]> On Behalf Of Carsten Bormann
Sent: Monday, July 13, 2020 12:48 PM
To: [email-masked]
Subject: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00)

This draft may seem a bit unusual, in that it allocates 268439585 tags, including one of the 12 remaining precious single-byte ones.
But if you read it, that will seem perfectly normal.

Please see
https://www.ietf.org/id/draft-bormann-cbor-packed-00.html#name-acknowledgements
for how this came to be.

I’m going to ask for WG adoption at IETF 108...

Grüße, Carsten

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-bormann-cbor-packed-00.txt
> Date: 2020-07-13 at 21:42:21 CEST
> To: "Carsten Bormann" <[email-masked]>
> 
> 
> A new version of I-D, draft-bormann-cbor-packed-00.txt has been 
> successfully submitted by Carsten Bormann and posted to the IETF 
> repository.
> 
> Name:		draft-bormann-cbor-packed
> Revision:	00
> Title:		Packed CBOR
> Document date:	2020-07-13
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-bormann-cbor-packed-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-bormann-cbor-packed/
> Htmlized:       https://tools.ietf.org/html/draft-bormann-cbor-packed-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-bormann-cbor-packed
> 
> 
> Abstract:
>   The Concise Binary Object Representation (CBOR, RFC 7049) is a data
>   format whose design goals include the possibility of extremely small
>   code size, fairly small message size, and extensibility without the
>   need for version negotiation.
> 
>   CBOR does not provide any forms of data compression.  CBOR data
>   items, in particular when generated from legacy data models often
>   allow considerable gains in compactness when applying data
>   compression.  While traditional data compression techniques such as
>   DEFLATE (RFC 1951) work well for CBOR, their disadvantage is that the
>   receiver needs to unpack the compressed form to make use of data.
> 
>   This specification describes Packed CBOR, a simple transformation of
>   a CBOR data item into another CBOR data item that is almost as easy
>   to consume as the original CBOR data item.  A separate decompression
>   step is therefore often not required at the receiver.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

_______________________________________________
CBOR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cbor

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jul 2020 07:11:59 +0200

On 2020-07-29, at 04:59, Mike Jones <[email-masked]> wrote:
> 
> I am concerned that this will bifurcate CBOR into implementations that do and don't support this extra feature set.  

Hi Mike,

that is of course true for any new tag.
When we designed CBOR, one main issue was whether the feature set should be static (as with JSON) or allow extensibility (using the tag concept); we chose the latter.

> If a call for adoption were held today, having thought about it, I would oppose adoption on this basis.  I'd rather that all CBOR implementations be interoperable than for some to add this fairly complicated compression feature.

Packing has been designed so that it can be used with “all CBOR implementations” (that do send unknown tags to the application); if a CBOR-based protocol opts for allowing the use packing, that is the same kind of decision as for allowing date tags.

Grüße, Carsten

---

From: Mike Jones <[email-masked]>
Date: Wed, 29 Jul 2020 17:08:27 +0000

Thanks for your reply, Carsten.  I hadn't looked at it that way.  At some point I'll try to do a full review of the document.

				Cheers,
				-- Mike

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Tuesday, July 28, 2020 10:12 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [Cbor] Packing CBOR (draft-bormann-cbor-packed-00)

Hi Mike,

Grüße, Carsten