Minutes interim-2023-cbor-01: Wed 15:00
minutes-interim-2023-cbor-01-202301111500-00

CBOR working group conference call, 2023-01-11

Note taking: Marco Tiloca, Christian Amsüss

WG documents status and issues

time-tag (no discussion this time)

CB: I just submitted the PR that will be the basis of -03. Probably
no need for discussion at this point.

CB: The PR is done; still discussing around possible editorial fixes and
restructuring. Hoping to finish today.

DNS in CBOR (no discussion this time)

https://www.ietf.org/archive/id/draft-lenders-dns-cbor-00.html

?: Anything more to discuss on this?
CA: No current news; current considerations more on the DNS side.

CDDL 2.0 (no discussion this time)

https://datatracker.ietf.org/doc/html/draft-bormann-cbor-cddl-2-draft

CB: New tool functionality not quite ready for consumption yet, will
probably have to wait for next interim.
CB: We have a spec but not an implementation, though I'm working on one.

CBOR Object Type Extension (COTX)

Anders Rundgren has slides.

AR presenting. URIs as identifiers are de-facto standard in XML and
JSON. Any application can switch over to CBOR, and then it's nice if
transition is not too complicated and doesn't interfere with existing
ways. There are drawbacks, but it's de-facto standards, don't want to
discuss them, I didn't define them. Spec is simple.

CBOR: Semantic Tagging

(CA's personal opinion for the benefit of later note readers: This is CB
giving a general tutorial on CBOR tags and related concepts.)

CB has slides

(CB: Peripherally relevant: Deferenceable Identifiers.
Note that we went a different route when transforming XML/JSON RFC
7807 into CBOR 9290.)

CB: It's been 10 years since CBOR was designed, so this is all not
completely new -- slides are about where we are and why we are there.
CB: (How to pronounce: Use Catalan kotsch)
CB (p1): Two enhancements over CBOR
CB (p2): Tags as main extension point accompanied by JSON+binary as
basic data model.
CB (p3): Tag numbers allocated in an IANA registry, as 64-bit unsigned
integers. Single global namespace against the 4-tag-spaces in ASN.1 (its
UNIVERSAL space is comparable to CBOR's but smaller). CBOR chose to not
do application tags so that document can always be understood.
CB (p4): Lot of space to use, but need to be careful in assigning tags
with small value (as yielding less overhead and thus more precious).
AR: All completely right, understand the concept well -- but this is a
provision for people coming from high level systems with constantly
revised objects. They have many identifiers, and then it becomes less
tempting to use IANA for every new identifier. URL based identifiers
give you a root, and you can create own namespaces in there. For
example, with github, you get a stable point for own namespaces. You can
lose your account, but that is established. They have own URNs too. It
addresses different applications than original CBOR. I have lots of
objects, and don't want to register all of them externally, this would
create inflexibility.
CB: will come back to that.
AR: Yes, last page is relevant. There is already one precedent (RATS
EAT) which uses profile URL, could also be replaced wiht CBOR tag with
null argument, but they selected URL -- probably for same reason. I see
similar difficulties here. Reading schemas from online being a bad idea
is good input from the CBOR list.
CB: RATS claim is interesting because it also allows ASN OIDs.
AR: It's a good idea and it can be added.
CB: OID also relies on registration but you can still go into a private
space.
AR: Sure. The applications I'm talking about won't use OIDs unless
forced to do, but they work well too. I'd consider them overkill.
CB (continuing on p5): snapshot of currently allocated/available tags.
CB (p6): Different policy allocations, depending on the tag value and
(where it falls in) the range.
CB (p7): No extensibility in JSON, so JSON-LD has to use objects (maps)
in a non-transparent way. The alternative is using URIs an namespace,
with the related typical problems of dereferenceability.
CB (p8): Another case study is RFC 9290 (was -core-problem-details),
where type-tagging is used with URI reference. -7807-bis somehow went on
considering a registry. RFC 9290 focuses on integer, but with URIs as a
fallback.
CB (p9): COTX from Anders uses text strings. Easy to come up with, some
more difficult to handle in comparison to the CBOR tag ecosystem.
CB (p10): Prospective landing of COTX in CBOR: 1+2 tag (since URIs are
big already). Advised to not raise this as a replacement for tags.

CA: I concur that a Designated Expert would likely go for this outcome.

AR: If it looks like replacement ... it's an addition, merely aligning
with other things (verified credentials, ISO 20022, other systems with
URIs/URNs) to not force these people into something they don't want to
do -- otherwise they maybe don't transition, and I want them to.

CA: Any other CBOR users where this would have been convenient?

AR: I know of EAD where they use URLs instead of tags. Or you just
reject any object that with a tag you don't recognize.

CL: Authoring CBOR and CWT for common access token. Often have alternate
types that can be chosen (matching one of several variants). Scope of
tags would be dedicated to this particular context of that match
operation. So rather than registering a tag, we do like in COTX (?)
where we use array with first element indicating what follows.
CA: Do you know about the proposal on tags usable for enums? (minute
taker: See end of section)
CL: Vaguely recall it but don't remember specifics; would be interested
but it might not be available fast enough.
CB: Didn't we register tags for enums?
CA: Quite possibly; I'll double-check.

CA: Anyone interested, please check the COTX proposal and give specific
comments on the mailing list. Nothing should stop a request for
registration here, it should be able to progress.
AR: Who handles the registration?
CA: You send a mail to IANA asking for the tag assignment, and you can
possibly give a suggestion (reasonably in the 1+2 range). Then IANA
forwards this to Carsten and me as Designated Experts.
CB: There is a form at https://www.iana.org/form/protocol-assignment
CB: These are registered (101, 121-127, 1280-1400)

CL (on chat):
https://datatracker.ietf.org/doc/draft-bormann-cbor-notable-tags/
Section 9.1 looks to provide alternatives.

CBOR use in IETF and other SDOs

IETF 116 agenda (no discussion this time)

CA: Let the Chairs know if/when you have any topics to propose.

AOB

CA: We'll talk in two weeks for the next interim meeting. Please fill in
the notes with proposed agenda items for that.