Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT

[Michael Richardson <[e-mail]>]

Brendan Moran <[e-mail]> wrote:
    >> Unless you mean that dictionaries should be sorted so that they always (can only)
    >> reference forward, and you can start at the current location in the current
    >> dictionary.

    > Possibly, but I’m not sure that’s universally advantageous. Remember
    > that we want high reference frequency items to be at the start. Suppose
    > that I have the prefixes [“https://“, “www.”, “files.”,
    > “domain.com”]. Clearly, I want to be able to compose these in one of
    > two ways:

I agree that sorting by frequency of us has CPU advantages.
I'm not sure that this is important enough ("premature optimization is the
root of all evil").

I think that I can put them together in any order in my CBOR, regardless of
the order.  The ordering just restrictions how the internal reference in the
dictionary can work, right?

    > I think we need to be very clear about what’s allowed because
    > otherwise, there will be a lot of varied implementations with varied
    > limitations.

Yes, as Carsten said, we need to tightly define the decoder :-)

    >>> - The compressor has to be aware of the dictionaries of packed CBOR
    >>> objects it traverses in order to pack anything that appears within an
    >>> already packed CBOR object.
    >>
    >> In the SUIT case, the compressor is "cloud" :-)

    > Yup. Let’s not make things hard for constrained nodes because it’s easier for unconstrained ones.

If you are saying that sometimes the compressor will be a constrained node,
because CBOR is used outside of SUIT (who knew?), then I would like to
retract my comment involving that five-letter word.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-