CBOR working group conference call, 2022-07-13

## WG documents status and issues   {#wg-documents-status-and-issues}

*   draft-ietf-cbor-packed

CB presenting

Presented slides:
https://datatracker.ietf.org/meeting/interim-2022-cbor-12/materials/slides-interim-2022-cbor-12-sessa-carstens-slides-00.pdf

CB (p2): following-up from the previous interim meeting; just submitted
v -06. Now only shared table and argument table (merging the old prefix
and suffix tables). Concatenation is the default function, function tag
is the specific function.  
CB (p3-5): Defined join function (akin to Python join), which is not
commutative (hence two function tags needed, see p5). Examples updated
accordingly (those on p4 are not correct).  
CB (p6): The previous items are consolidated. What to do with others
like sequences (no strong opinion on where); further function tags
(e.g., CURIE but better in the CoRE WG where CRIs are developed in the
HREF document); further CBOR type pairings. Next step is to update my
implementation, for more related discussion at IETF 114.

CB (p7): Early discussions on tag validity, i.e., check the "shape" of
the tag content to be as expected to be considered valid. Example with
an array including two arrays, which can lead to extensibility problems
when considering tags for typed arrays.  
CB (p8-9): This would not work together with cbor-packed: reference tags
stand in for something else. Possible way forward: define equivalence
principle so that a tag can define the shape of its valid tag content
(i.e., what shape it stands in for). This is already around, but in a
very limited way (e.g., for typed array).  
CB (p10): How practically? Just say in the tag definition? Means
updating RFC 8949 as its definition of validity? Can one opt-in?
Preferred to take care of this in the -cbor-packed document, but open to
alternatives.

KC: Would opt-in be on a per-tag basis as part of its definition? Or
otherwise automatic on all tags?  
CB: We have 100+ tags registered, can't cover all of them all together. 

KC: So it is on the decoder side.  
CB: Yes. If there is an equivalence, it is tag-specific.  
KC: Do we allow this only for typed arrays and multi-dimensional arrays?

CB: That becomes a quadratic problem.  
KC: Right, don't make it a per-tag opt-in. It can be at the level of
deterministic encoding, then each encoder can take a decision.  
CB: Just need to be careful to not fragment. Need to ask for a wholesale
of opt-in.  
KC: Can you have recursive packed?  
CB: Yes.  
KC: Use case?  
CB: No use case per se, just a mechanism. Sometimes we have complicated
JSON structures that we need to collapse. "Nested" is more accurate than
"recursive" here. You still do validity checks.

KC: How would one correctly express a tag for typed arrays in the
bfloat16 case?  
CB: A good editorial exercise; possible in the next few weeks.  
KC: Maybe good to have all this framework in a new RFC so that tag
authors have a document to refer to. Not sure it's a good idea.  
KC: And how should error handling work on a decoder to opt-in?  
CB: Good point. Looks like need for clarifying the equivalence principle
in -cbor-packed, and then have a separate document considering the
bfloat16 case etc about the tag registration process.

KC: How does it work procedurally?  
CB: Need a WGLC on -cbor-packed once clarified the equivalence/stand-in
principle. The tag registration is defined and will be extended/revised
in the -notable-tags document.

CB: I will add a section to -cbor-packed about the equivalence/stand-in
principle, to submit once the submission systems reopen.

## CBOR use in IETF and other SDOs   {#cbor-use-in-ietf-and-other-sdos}

### Potential discussion about extending domain of multi-dimensional array tags (RFC 8746)   {#potential-discussion-about-extending-domain-of-multi-dimensional-array-tags-rfc-8746}

### Progress on alternative/union tags: [Section 9.1 of draft-bormann-cbor-notable-tags-06.txt][1]   {#progress-on-alternativeunion-tags-section-91-of-draft-bormann-cbor-notable-tags-06txt}

## IETF 114 agenda   {#ietf-114-agenda}

*   CDDL 2.0
*   packed
*   Tag registry development and maintenance (how do we evolve, how do
    we comment, do we deprecate, and how does that all fit with IANA
    workflows?)

## AOB   {#aob}

CB: We might get input on the time tag, based on progress on the SEDATE
WG.  
CB: The CDDL work should also progress; I have material collected to
kick-start an Internet Draft, it might happen before the 24th.  
BL: We meet late during the IETF week; that gives time to catch up on
submissions.

### CBOR fall interim meetings?   {#cbor-fall-interim-meetings}

Proposal from CoRE WG chairs:

\[CBOR\]:

*   2022-08-24
*   2022-09-07
*   2022-09-21
*   2022-10-05
*   2022-10-19

This leaves alternate weeks for \[CoRE\]:

*   2022-08-31
*   2022-09-14
*   2022-09-28
*   2022-10-12
*   2022-10-26

BL: It should work. Any attendee today having an issue with that?  
(none heard)  
BL: I will post this on the CBOR mailing list to confirm.

Note taking: Marco Tiloca



[1]: https://datatracker.ietf.org/doc/html/draft-bormann-cbor-notable-tags-06.txt#section-9.1
*[CB]: Carsten Bormann


*[BL]: Barry Leiba


*[FP]: Francesca Palombini


*[IMD]: Ira McDonald


*[MCR]: Michael Richardson


*[CA]: Christian Amsüss


*[MT]: Marco Tiloca


*[PP]: Philip Prindeville


*[ST]: Sean Turner


*[BM]: Brendan Moran


*[KC]: Kal Conley