CBOR at IETF 114

Minute takers: Marco Tiloca, Christian Amsüss

Introduction, agenda (Chairs)

BL doing introductions.

WG documents

RFCs 9164 (network-addresses), RFC 9165 (cddl-control), file-magic (Chairs)

BL: 9164 and 9165 published. -file-magic is in the Editor's queue.

time-tag (Carsten Bormann)

• updated yesterday

Presented slides:
https://datatracker.ietf.org/meeting/114/materials/slides-114-cbor-carstens-slides-00.pdf

CB presenting.

CB (p1): CDDL 2.0 will need new road map dates.

CB (p2): tags registered and in use, now waiting for the SEDATE Working
Group extending RFC 3339.
Back during adoption discussion, wanted to wait for SEDATE output (who
work on text form) to be available (white is existing time stamp format,
turquise hints are new).
Time zone hint helps with time zones changed over time. u-ca refers to
Unicode calendar formats, here says that the date is expressed in
Gregorian time (because that's how RFC3339 dates work), but is best
displayed in Hebrew.
Wrote this up right after SEDATE meeting; sounds straightformat, and
only reason not to do it is overloading time tag -- but it's responsive
to people trying to add that information. I think it should be OK.

CB (p3): SEDATE sticks to RFC 3339 by definition and charter; no other
time zones than UTC.
Limits do not affect this work. Could have time stamps in local time
(without telling how time relates to UTC). Precedent in our tags: 100
zoneless date. Can be done at date level, why not also at time level.
Emile suggested this should be done.
RFC3339 does not affect us (because we don't encode these offsets,
nobody started doing it).

CB: (p4-5) Do we want to exercise our freedom on this? Showing a
possible way. New timescale with no offset?
CB: (p5) Proposal: Synchronize with SEDATE (WGLC at roughly the same
time). No need to wait for their completion to publish this document.
Alternative: cover floating time in a different tag than 1001.

IMD: NTPv5 even a stable draft is 1.5a away. Don't think we want to wait
that long.
CB: Understand this to be in sync with what I proposed.
IMD: Yes.

CA (not as Chair): even moving on this document as is, there's nothing
stopping additions later on.
CB: Correct, though additions can happen now, probably more easily.

packed (Carsten Bormann)

• including "equivalence principle"

Presented slides:
https://datatracker.ietf.org/meeting/114/materials/slides-114-cbor-carstens-slides-00.pdf

CB presenting.

CB (p6): Became a bit simpler than I thought it would be.
Function tag concept as an extension point. There is ongoing
implementation work.
I think we'll need a second WGLC, but chairs decide. (BL: Yes, we will.)

CB (p7): Came up in other discussions: Some sleight of hand used here
when saying "can be used in place of". See 8949 tag validity definition.
Tags can talk about their content, and that's recorded -- but tag can
not control validity "upwards". If the outer tag is defined before
inner, the outer can't make use of the inner even if it fits well. But
many tags are stand-ins for other data, and we can't express that.
(p8) Glossed over it in tagged arrays. A validator that operates before
unpacking will break.

BM: I see a logical flaw here, but there's no flaw.
But tag validator must validate the outer structure before, and must
have found tag setup.

CA: The reference tag might come from an already setup table.
BM: But it's still part of the context; just because it's implicit
doesn't mean it's there.
CB: That's allowed. It's about legacy generic decoders. They have some
tag processing.
CB: My implementation encountering a tag 2 will produce a number
(because my impl does not limit size of numbers). So when it finds a tag
2 on top of, eg., a data compressor, it will not be able to build a
number out of uncompressed data.
CB: The concept of these slides describes how that implementation of tag
validity is deficient, and it creates a new category of decoders that
can deal with this. (Old ones stay valid CBOR decoders but won't work
with packed environments).
CB: But you're right, there are some assumptions around about how you
reach this, and one is that the validity checker does not support the
table setup tag (and presents it to the application)
BM: It continues validating from there. That's the flaw. The validator
ignored the tag. Fair enough, sounds like a bad decision, but that's
what we've got.
CB: CBOR is designed to make that possible; idea was to share duties of
tag processing btwn generic decoder and application. If generic decoder
encounters something it thinks it should understand, it can blow up.
This should be made more explicit.

CB (continuing on p9): -07 defines concept of tag equivalence. Tags can
decide what they "look like" from tag validity PoV. Typed array could
say that it is an array.
CB: What a tag can not do is standing in for something in a different
domain. For example, tag 4 (floating point number) and 264 (float with
extended range of exponent) can not be handled with tag equivalence: A
surprising structure for environment can not be produced. Genericity
between 4 and 264 would need something else.

CB (p10): It's written up, and I think this is necessary for packed.
Christian pointed out caveats; now there's text, maybe needs more.
CB: How to handle? (Tag38 inside problem-details raised eyebrows; could
be same problem here, but prefer not to anticipate that but start with
one document). Would this update RFC 8949 (weird, proposed standard
updating internet standard)? Or not say "updates" which is a bit of a
white lie?
CB: How to express the tag equivalence in CDDL? (CDDL has same
structural approach, so doesn't allow this. I don't propose to wait with
packed until we have invented that new CDDL)

IMD: I thought a PS could not update a full standard, is that not true?
CB: Have not investigated, let's find out.
BL: It is allowed, also depending on what the update is.
BL: More extreme situation: 821 (full standard) obsoleted by (current
SMTP). The new feature would be on PS level, the rest would remain at
full S level.
IMD: Reason is that I agree with CB -- I don't like the "don't update" /
don't-admit.
BL: If we made a mistake, we need to correct that, starting at PS.

RFC 9254: YANG-CBOR

(added on short notice)

CB presenting (p11): Management for constrained devices. (Plus some more
background)
CB: With this, we can put YANG in CBOR, or in the other direction,
define CBOR data structures in YANG.
CB: We didn't try to compress everything -- IP addresses etc are still
text strings.
CB: YANG-SID complements with integer naming system for better
performance.
CB: New tool in toolkit. If someone doesn't want to use CDDL for their
CBOR, they can use YANG.
CB: Question: How do we make sure these parts of the CBOR ecosystem stay
on good terms? Maybe when we extend CDDL, we'll have a look at YANG side
and look at whether that creates hardships. (And this has happened:
CDDL's regex has been aligned with YANG's).
This leads to CDDL2 discussion...

Upcoming work:

CDDL 2.0 roadmap (Carsten Bormann)

Presented slides:
https://datatracker.ietf.org/meeting/114/materials/slides-114-cbor-carstens-slides-00.pdf

CB (p12): Think of how to keep moving the technical system forward as a
whole, but also CDDL. Understanding at 1.0 was that we'll want to
develop this.
CB (p13): CDDL has extension points; now extended in RFC 9090 and RFC
9165.
CB (p14): Diagnostic notation was also defined. How to make
implementation and use easier? More ABNF integration?
CB (p14): Right side is a full JSON syntax for interchanging CDDL in
easier-to-use-for-machines form. No concrete proposal at the moment,
just suggesting directions.

CB (p16): on composition, taking multiple file possibly from different
libraries. Think of an export and import interface.
(skipping namespaces on p17)

CB (p18): use of CDDL in different applications (e.g., JSON vs CBOR).
With .feature we do this better already. Translation is currently not
supported at all.
CB (p19): Library availability from different sources.

CB (p20): on syntax, a 1.0 processor should still be able to do some
useful things on a 2.0 file.
CB (p21): a pre-processor would help (not quite like a C one). Important
to have automation available early.

CB (p22): Annotation. Going from single outcome (it's valid or not) to
giving back data. Current annotation tool can not be told whether some
rule is just for line length shortening and what is giving valuable
information to the user.
CB (p23): Enriched / augmented version of instance. In which data model?

CB (p24): planned timeline is: first prototype of composition and first
element of annotation by IETF 115; CDDL 2.0 completed and implemented
for IETF 116, where to take decisions on how to publish (e.g., any
split).

CB (p25): Much data in registries is extracted manually for use in
specifications. CoRE-SID had multi-year discussion with IANA, we could
discuss with them about how we'd like to use it and what load we'd
generate.

CB (back to p24): Implementers, what tool kit elements would you like to
see to participate in this well?

Brian Sipos: Composition would be very helpful.
CB: Could you help out understanding the use cases?
BS: Yes.

CA (from the floor): Stuff in comments sounds scarily worse than the C
preprocessor. Could we use new syntax but define how to strip it off?
BM: I needed an extra control operator to represent sequences that are
key-value pairs but not encoded as a map but encoded as an array. The
solution I settled with was to not do anything in the CDDL, and use an
external document which paths in the CDDL had that information. At this
stage that seemed to be the simplest thing. How much of this belongs in
CDDL, and how much belongs in an external annotation?
CB: Any of that available?
BM: Very early stage, not ready yet.
CB: Curious to see how you reach the CDDL file and annotate additional
functionalities.

Laurence Lundblade: EAT's use for CBOR and JSON. Worked a lot with CDDL
that couldn't express data structures encoded in both CBOR and JSON; ran
into limitations with .feature. At some point I gave up on .feature,
that's where I was embedding CBOR in JSON and vice versa. Diagnostic
output from tool with .feature was hard to work with.
CB: Embedding is important and hasn't been addressed yet.

BL: Have to wrap up...
CB: Got good feedback, to be brought on the list, especially Laurence's
embedding.

Tag registry development and maintenance (Christian Amsüss)

Postponed to the next interim meeting.

AOB

BL: Interim meetings resume on August 24th.