Re: [Cbor] I-D Action: draft-ietf-cbor-packed-03.txt

Carsten Bormann <cabo@tzi.org> Fri, 13 August 2021 13:22 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4803A1885 for <cbor@ietfa.amsl.com>; Fri, 13 Aug 2021 06:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWjQjZ6lkogw for <cbor@ietfa.amsl.com>; Fri, 13 Aug 2021 06:22:14 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9888F3A1882 for <cbor@ietf.org>; Fri, 13 Aug 2021 06:22:13 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GmPNg2zN2z2xHx; Fri, 13 Aug 2021 15:22:11 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <162886072892.842.1028533935992555518@ietfa.amsl.com>
Date: Fri, 13 Aug 2021 15:22:11 +0200
X-Mao-Original-Outgoing-Id: 650553730.859328-2880f05e5db28a5318fbe01d008354c2
Content-Transfer-Encoding: quoted-printable
Message-Id: <64D5FDDC-4974-4FED-93E3-5BC4CA8225E2@tzi.org>
References: <162886072892.842.1028533935992555518@ietfa.amsl.com>
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/WGHV-2hsSzaOBRChY75Z7tNwvHk>
Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-packed-03.txt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2021 13:22:20 -0000

cbor-packed expired today, so I made a -03 with the various small edits that have accrued since -02.  As we said at IETF111, we are collecting implementation experience at this point, going forward once enough such experience is available.

Grüße, Carsten


>        Title           : Packed CBOR
>        Author          : Carsten Bormann
> 	Filename        : draft-ietf-cbor-packed-03.txt
> 	Pages           : 18
> 	Date            : 2021-08-13
> 
> Abstract:
>   The Concise Binary Object Representation (CBOR, RFC 8949) 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) can work well for CBOR encoded data items, 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.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-cbor-packed/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-cbor-packed-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-packed-03