Re: [Cbor] CBOR-packed: comments and function tag suggestion

Hi Mikolai,

I’m finally getting to your detailed editorial comments.

> On 2024-02-19, at 13:52, Mikolai Gütschow <mikolai.guetschow@tu-dresden.de> wrote:
> […]
> 
> - The abstract is repeated literally as the first three paragraphs of the introduction. Not sure whether this is good practice, just wanted to point it out.

It is a good placeholder until we know what additional information beyond the abstract should be in the introduction.
We have published RFCs doing this, so it is not fundamentally wrong; it just turns out at some point one wants to write more, make use of references, etc. in the introduction, so it’s not normally the way things et published.

I have started a PR [1] for addressing the following suggestions:

[1]: 

> - The terminology section doesn't match the current draft very well:
>  - some terms are (almost) not used in the remaining document: "affix" (only mentioned in parenthesis in introduction),

Indeed, this now has been generalized into argument, so we don’t need this any more.

> "expansion" (only used once at the end of 3.1, while it is described as "reconstruction of the original data item" in 2.{2,3}),

I aligned that into using “reconstruction” everywhere.

> "function reference" (nowhere else used, and also specified to allow function tags for both the argument and the rump which contradicts the description in 2.3)

Well, it is allowed for both, just not at the same time (the function tag is extracted from the left hand side, which is the argument for straight references and the rump for inverted references).  Fixed.

We haven’t use the potential of the term “function reference” to simplify the wording in various places; I cleaned up the definition to define “function tag” for now.  We might still want to clean up the places using the phrase “involving a function tag” to use a term such as “function reference”.

>  - terms that appear quite frequently in the document are missing: "rump item" (interchangeably referred to as "rump"/"rump item"/"rump data item" throughout the draft), "function tag", "straight/inverted reference", "original data item"

I defined a few terms, also adding “packed data item”, and sticking with “rump” (which I think is still OK in the combinations you list).

>  - Renaming "Current Set" to something like "Active (Packing) Tables" would appear more straightforward to me.

I called it “active set” because that is grammatically easier to handle.

> - Section 2.3 states:
> > When reconstructing the original data item, such a reference is replaced by a data item constructed from the argument data item found in the table (argument, which might need to be recursively unpacked first) and the rump data item (rump, again possibly recursively unpacked).
> The rump data item might be recursively _packed_ or "need to be recursively _unpacked_"

Fixed.

> - Table 3 appears to make a distinction between "straight rump" and "inverted rump", although the distinction really comes from the involved tag ("straight/inverted reference"). Maybe just rename to "rump" (or the common term, cf. above) in the table.

Fixed.

> - straight/inverted and prefix/suffix seem to be used as synonyms, I would drop usage of prefix/suffix unless maybe for illustrative purpose in Appendix A (Examples).
> 
> - Section 3.1: I got a bit confused while reading the tag definitions for 113 and 1113 as they are described with almost identical words. I would suggest to add "respectively" to the definition of 1113.
> 
> - The examples in section 4.1 would result in the same original data item without usage of the join/ijoin function tags due to the definition of concatenation in 2.4. I think it would be worth pointing that out in 4.1.

TODO (bursting my timebox now…)

> - Section 6.1 registers the straight/inverted tags for "text string, byte string, array, map, tag" while Section 2.3 explicitly mentions an "integer rump" - should the enclosed data item just allow any type?

Tag 6 does allow any type, but does mean something different for integers and for other types — you need to use tag 224 for integers.

(Discussion of record tag skipped, as there is a separate PR for those.)

> In general, irrespective of whether the record tag is included in the document or not, I think it should refer to or mention other tags that have been defined with data compression in mind, potentially pointing out their weaknesses (e.g. undefined CBOR order in maps). I came across stringref [4] and cbor-records [2], not sure if there are more. In any case, people reading a CBOR packed RFC will probably be interested in those alternatives and their trade-offs, too.

Leaving this for another editorial round.

Grüße, Carsten

> Best
> Mikolai Gütschow
> 
> [1] https://github.com/mguetschow/NanoCBOR/tree/packed-cbor
> [2] https://github.com/kriszyp/cbor-records
> [3] https://mailarchive.ietf.org/arch/msg/cbor/IEfXAOBMYPfA8s5UACxCUNk0ddU/
> [4] http://cbor.schmorp.de/stringref
> 
> 
> --
> 
> Mikolai Gütschow
> TU Dresden, Chair of Distributed and Networked Systems
> https://tu-dresden.de/cs/netd/about/team/guetschow
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor