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

[Mike Jones <[e-mail]>]

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 <[e-mail]> On Behalf Of Carsten Bormann
Sent: Monday, July 13, 2020 12:48 PM
To: [e-mail]
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: [e-mail]
> Subject: New Version Notification for draft-bormann-cbor-packed-00.txt
> Date: 2020-07-13 at 21:42:21 CEST
> To: "Carsten Bormann" <[e-mail]>
> 
> 
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/cbor