[Cbor] WGLC comments on cbor-packed

[Christian Amsüss <[e-mail]>]

Hello -packed authors,
hello CBOR group,

with chair hat off, I've had a look at this document, here's a few
notes:

* "are rendered as a hyphen": I share the sentiment, but there might be
  processes where that comment is placed better. (But maybe it can stay
  in here for some while...).

* The explicit separation of the prefix and the suffix table makes it
  hard to later extend to other affixes, e.g. the one we're considering
  for the use with CRIs where the tagged infix gets pushed several
  layers down into the circumfix from the table.

  One way to keep that open is that the various circumfix forms gain
  their own tags (probably none around the 216..223 / 225-255 range, but
  from a later range). An alternative design would be to just have a
  single list of affix tags and decide whether it's pre- or suffix by
  the kind of item in the affix list.

* "A maliciously crafted Packed CBOR data item might contain a reference
  loop" in section 2.4: That this is possible only follows when one sees
  the ways the tables can be set up in section 3 (because it can only
  happen with setups that set the Current Set already during item
  definition).

* "Packed item references in the newly constructed (low-numbered) parts
  of the table need to be interpreted": Given how long it took me to
  find that paragraph, it'd help if it used the term "Current Set".

  Suggestion:

  > The Current Set relevant for the newly constructed (low-numbered)
  > parts of the table is the new table (which includes the, now
  > higher-numbered, inherited parts). If any existing, inherited
  > (higher-numbered) parts contain packed reference, their Current Set
  > stays unmodified; these references still go to the inherited (more
  > limited) number space.

  There's one odd detail about shifting the Current Set early of which
  I'm not sure whether it will impact zero-copy embedded devices: By the
  time the Current Set is used the first time (i.e. when seeing the
  shared items), the amount by which the old set was shifted is not yet
  known (because the prefix and suffix lengths were not seen yet). It's
  probably OK because the items aren't evaluated yet anyway, but I ask
  you to think this through as well.

* "By the application environment, e.g., a media type".

  Does this also happen implicitly when using a tag from file-magic?

  (If so, should a media type also describe what happens to existing
  entries inside the table?)

* ad dictionary referencing: I think that a good way to do this would
  also to us an own registered tag (any discussions that pop up on tag
  evolvability will certainly help there). Referencing the dictionary
  via URI is probably too impractical to go into this document, but
  dictionary setup by custom tag might deserve a hint.

* This is currently informational. While that's enough to exercise the
  extension points (tag 6 is in 'standards action range', ie. BCP is
  enough), if other documents are to use this in any official manner
  (CoRAL will likely say "are compressed using", "the dictionary is
  defined in terms of", and not "using any additional mechansisms such
  as" when referring to packed, to ensure good interoperability and not
  require another SDO that picks the right components), it'd be helpful
  if this were standards track from the onset. 

  The datatracker "intended status" already reflects that.


BR & see you all soon
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom