Minutes interim-2022-cbor-08: Wed 16:00
minutes-interim-2022-cbor-08-202205181600-00

CBOR working group conference call, 2022-05-18

Agenda:

• WG documents status and issues

  • cbor-packed: WGLC comment processing; issues to discuss?
  • file-magic?

• CBOR use in IETF and other SDOs

  • draft-ietf-core-problem-details: Tag 38
  • tag evolution in general

• AOB

Note taking: Marco Tiloca

cbor-packed

CB presenting

CB: Finished WGLC, got responses and offline feedback (there might even
be more points to it than listed here)
CB: Summary: Can be done as is, but several options for improvement

CB (p2): "deterministic packing" or "packing of deterministically
encoded cbor"? both possible. A packer producing suitable signer input
would be a whole new thing to consider. (But any document using this
might do that). Packing deterministic would be about the unpack ouput
being something suitable as a deterministic encoding -- that was not
really considered so far. Would like to hear what people think.

BM: Treat them separately. Unpacking and expecting deterministic does
not make sense.
BM: Packing post-signature makes no sense to me.
CB: When used for signing, actual signing input may not be transferred
representation, the input is built.
BM: Good, but those use cases don't look compatible with packed.
CB: So far packing was discussed w/rt generic packers (hard to make
deterministic); in application specific format (SUIT) there could be
well-defined points. Would be easier for the latter to be useful for
deterministic encoding.

BM: It'd be very difficult to accomplish.
CB: Depends on how much packing you want. No need to solve it now, we
can leave it for later thinking while warning that it's something the
application has to think about.
BM: Makes sense to me.
(via chat, CA): +1 on "define it when you need it"

CB (p7-9): how to handle sequences? You can pack a sequence: stash in
array, then pack, then unwrap. How do you do the latter?
Splicing is an option, not really expected to happen at the moment. At
first reading, the sequence has a wrong number of elements.
Do we have use cases related to redundancy in sequences that can relate
to it? Rikard, think of EDHOC where sequences are used.
MT: Might be useful depending on what an EDHOC message includes, e.g.,
many and similar EAD items. Maybe not the case for "regular" EDHOC
messages, but not to be excluded altogether either.
CB (summaryzing Marco's point): Sounds like a lukewarm "maybe".
CA: I'd do this separately, wait for use cases, and also look into
whether CBOR sequence users can "just" switch to arrays for things like
this.

CB (p10): how to handle composition
CB: Note that this is "mid-fix" and thus again different from
"circumfix".
CB: Status quo is we can't do anything here other than ad-hoc
dictionaries.
CB: Do we want to look at this?
CA: I care in general of the case, not of the particular composition
style. Good to have extensibility, and the example is good.
CB: Easy to define a specific tag to extend, eg. with a concatenating
tag.
CA: A concatenating tag would address both this and the previous
expand-inside-sequence case.
BM: In SUIT, I'd expect some used arrays to have common patterns to
inject in the middle of an array. SUIT might (pending experimentation)
use this, not top priority but could see it being useful, also if
combined with sequence unwrapping.
CB: So again, better discussed with specific application, provided we
have (see later slide) extensibility.

CB (p13): More to think around error handling.
CB: No new tags to enable this, but extending behavior from
prefix/suffix handling. Can't do this later without having thought about
it now.
CA: Examples of array+map?
CB: Looking at Krys' record types, you'll get ideas about arrays and
maps. For arrays and strings, Python's .join(). Also in CRI case,
combining things that are structurally unlike (but not well understood
yet). But no single natural way.
CA: Then it's like type/implementation specific, and complicated to
consider now.
CB: Can do something now if it becomes less of an issue?
CA: Pre- and post-fix could be merged. If generalized, it can be used to
describe a more flexible composition.
CB: So special behavior could be attached to referncing tag (expensive:
number of tags and compact encoding) or table entry (avoided so far).
Latter avoided so far as it's in additional data. Or attach semantics to
table (as it is now). Let's come to that in a minute.

CB (p14): Clear extension point is "new table setup tags" (esp. for
static dictionaries) -- item 1. More complex is item 2 -- define new
table types?
CA: Doesnt't matter if in the table entries (preferred) or in the data
item.

CB: What now? How define extension point without sacrificing bw compat?
E.g., one table is not a data item, but a functional, applied to the
content of the tags. Could hijack a table and say that default
functional is prefix or suffix. Right now can't prefix tags [?] ...
but maybe related to next item.

CB (p15): Real need for two different tables for suffix/prefix? A single
table would save a byte.
Also makes it easier to use same item in both prefix and suffix
position. (Currenlty would need concat with ""). Other question is why
separate prefix from sharing, but that's a stronger case (different
operation). Downside? Every time range is exceeded, encoding gets
longer.

CA: What you mean here by Merging the tables means distinguishing
prefix/suffix based on the tag?
CB: Yes. The alternative would need costly entry in the table (prefix?
suffix? functional?)
CA: Document already says prefix is the most common, so that could take
the cheap default place.
BM: Might make more sense to save space for simple cases, which most
often save a lot of space in simple cases. Would be nice if we could
quantify for actual cases, but don't think we have enough samples here.
Making argument for more test cases, do real measurements.

CB: If we merge the two tables, we might still avoid a few bytes by
keeping the suffix reference tag. Would then still be easy to share
string for a prefix and a suffix, and a tag in there could still tell a
more complex functional.
BM: Makes a lot of sense to me.
CA: And a functional would get a boolean argument for free ("am I being
called in prefix or postfix mode?")
CB: Yes, I see a direction, have to write it. Will make a PR and update
my implementation.

CB (p16): Editorial comments will need to be addressed. Pseudocode for
unpacker ... will be in Ruby unless someone steps up to write it in
another language ...?
BM (via chat): noncommitally offers to write pseudocode.

CB (p17): Profiling. Simple pointer-chasing of (1) ideal for very
constrained devices. Should we suggest thee as profiles?
CB: With merging, tag savings don't matter that much any more. (Still
... for profiling?)

CB: Still saying Informational but quite clear it should be Standards
Track.
BL: The Datatracker is up to date, please change the header in the draft

BL: ... (didn't quite get it) on Krys's Records?
BL: No changes to packed on the result though.
CB: Right.

tag 38

CB: particular detail from problem-details.

CB: "auto" direction?

CB: ... which in turn leads to the broader "evolution of tags", avoided
so far.
CA: For some languages, direction should not be specified at all, for
other languages it really should be.
CB: You may even have weak directionality.

CB (p4): Alternatives to amending tag 38 (or tags in general)?
CB: Any normative processes there will take very long.
CB: Keeping tag 38 unchanged, one can have tags dedicated to the
direction or define a new separate tag as enhanced version of current
tag 38.
CA: Preference for the approach in the CoRE document; also easier for
implementations that .

file magic

CA: To check where this is stucked; possibly getting back to it in 2
weeks.