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

[Carsten Bormann <[e-mail]>]

Hi Dale,

+1 to all your editorial points; this sure was written up quickly.

To the technical point: Yes, there is no reason tag 6 cannot be used deeper within the structure.  The interesting technical question is what happens if there are two or more packed structures: Do they sail like ships in the night, or is there interaction (e.g., for nested compression, do the tables get merged in some way?)?
We don’t have an answer for that (but probably should).

A related question is how to support CBOR sequences: is there a way for one of the data items to use a prefix/sharing table entry in another data item in the sequence?

Grüße, Carsten


> On 2020-07-29, at 08:53, Dale R. Worley <[e-mail]> wrote:
> 
> After a very quick look, these points about the draft stand out.  The
> abstract contains:
> 
>   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.
> 
> The first sentence is probably not exactly what you want to say, because
> of course, in order to make use of the content of any "compressed form"
> you first have to "unpack" it, in that you have to reverse whatever the
> compression was.  I *think* what you mean is that in order to make use
> of even a small portion of the data, the entire prefix from the start to
> that portion of the data must be unpacked.
> 
> The second sentence seems also to not state what you care about.  I can
> define "a simple transformation of a CBOR data item into another CBOR
> data item" that is *just as easy* to consume as the original:  the
> identity transformation.  I *think* what you mean is that the packed
> form can (in many cases) be significantly smaller than the original
> form, and yet "random access" of individual items in the packed form is
> only constant-factor-slower than it is in the original form.
> 
> Note that I'm depending on "random access" to mean extracting an item
> when the indexes into the nested arrays and keys of the nestd maps are
> provided.
> 
> Note that this isn't just nit-picking, you're explaining the
> characteristics that differentiate Packed CBOR, that is, the reason for
> this work.
> 
> The other thing that stands out is that the document is very terse.
> It promises to define the unpacking operation, but that definition is
> largely implicit.  E.g., 2.1 says:
> 
>   Shared items are stored in the third to last element of the array
>   used as tag content for tag number 6, numbered starting by 2.
> 
>   The shared data items are referenced by using the data items in
>   Table 1.  When reconstructing the original data item, such a
>   reference is replaced by the referenced data item, which is then
>   recursively unpacked.
> 
> I *think* what this means is, "Unpacking a packed-CBOR object is done by
> starting with the rump structure and replacing references within it
> copies of the referenced structure.  Within the rump structure, tag 6
> (which I think is CDDL #6.6) is used not to designate a packed-CBOR
> structure but rather a reference to one of the shared structures.  The
> tagged value in such a reference is either a simple value or an integer,
> interpreted according to Table 1.  Implicitly, each reference is
> replaced by a copy of the referended shared value.  The shared
> structures may themselves contain uses of tag 6, whose values are
> packed-CBOR structures."
> 
> The difference in the above description is that it is explicit about the
> operations that convert the packed-CBOR structure into its unpacked
> form.
> 
> Also, it's not clear to me whether a packed-CBOR (a value tagged with 6)
> can appear anywhere other than the top level of the CBOR structure.  I
> would expect by the nature of CBOR it can be, but section 2 isn't clear
> about it.
> 
> Dale
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor