Documents
Interim dates and AOB (5’, flex time)
Minute takers: MT, RH, more please
Jabber Scribe: Renzo
Navas
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-cbor-chairs-slides-01.pdf
CA doing introductions.
CB: We can drop the cddl-modules item. I'd need an hour, but such a
small time is not enough. Let's take it at an interim meeting.
CA: Fine with me
AP: Carsten mentioned something about YANG to CBOR discussions.
Happening here?
CA: Not planned for the agenda today.
CB: It's out there, please comment on the draft. Pointers exist on
slides from the CoRE session
CA: CBOR Tags for Time, Duration, and Period was published as RFC9581.
CA: CDDL Grammar update draft is in AUTH48
CA (p7): Further updates on various documents
CA: Worked on Packed CBOR during Hackathon. Implementing decompression
was no problem. Argument items took another hour. 200 lines of Python
code in total.
LL: Has anyone implemented packed CBOR in C or similar languages? A few
things are easy in Ruby or Python, but not really in C. CBOR is supposed
to be also for embedded systems.
CA: Was planned for Hackathon, didn't get to it. Have implementation
plan. AFAIK no constrained implementation exists, but having one would
be great.
MM: We plan to implement most of CBOR in BERT. Please keep me in the
loop.
ML: An extension for nanoCBOR exists in C.
CB: My CBOR C implementation needs 2-3 lines of code to do shared
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-cbor-carstens-slides-00.pdf
CB presenting.
CB (p2): Multiple agenda items related to CBOR. This slide shows an
overview of CBOR work and associated work (EDN & CDDL).
CB (p3): Comparison between cbor-pretty hex dump and EDN.
CB (p4): Overview of the presentation agenda
CB (p5): EDN because one can't read binary. Superset of JSON. Byte
strings, tags and general map keys are the big extensions. Having a
diagnostic notation form for specific Tags is good.
CB (p6): Current status of -edn-literals. Originally proposed some
extensions, then added ABNF, then request to roll back after the request
for publication, and instead build on RFC 8949 and RFC 8610. This is now
done in version -13.
CB (p7): A question is the notation for strings. Decided to have
different notation for text strings and byte strings. But one may want
to indicate a hex dump or base64 encoded data. Hex dumps can be
indicated with h'' and base64 with b64''. The comment syntax for these
is unusual.
CB (p8): Prefixed single-quoted string syntax is used for byte strings
in base16/64 encoding. Also enabled application-oriented literals "dt"
and "ip", e.g. ip'192.0.2.42'.
CB (p9): Own prefixes can be registered, registering its name and
semantics.
CB (p10): e'' can be used for accessing CDDL information. That is the
text in e'' refers to CDDL names, mapping them to numbers
RM: Some prefixes can become things that are not binary strings. Just be
aware of that.
CB: Yes. It's a notation.
CB (p11): cri'' is yet another extension, now defined in
draft-ietf-core-href. So cri'URI' is translated to its component
elements encoded in CBOR.
CB (p12): How do we put this in ABNF? Created new ABNF for edn-literals,
shown on slide.
CB (p13): One has to also define what to do with the quoted string,
which can be up to a dedicated document.
CB (p14): Parsers need to handle unknown prefixes.
CB (p15): Open point: define the ABNF of each new extension individually
to be edited into base ABNF? Downsides: risk of inconsistencies and
mistakes.
CB (p16): WG document uses pluggable architecture for its own ABNF. PR
CB (p17): Discussed also at the Hackathon. A tool might translate ABNF
as to the content of the quoted string into what is the final result to
consider in unicode escape code.
CB (p17): Tweak idea 1 (prefer not to do it): Change de-escaping rules
for unprefixed and prefixed strings, because it would break the
alignment with JSON.
CB (p18): Tweak idea 2: Special content de-escaping just for traditional
byte strings, although the users would have to remember and use
different, per context-rules.
CB (p20): PProposal: Stick with untweaked approah. Common syntax for
string literals. Ship existing ABNF with EDNC spec. Provide tools for
translating base ABNF combined with ABNF snippets for a number of
prefixed strings into 1 ABNF file
RM: Do you have comments in single-quoted strings? More slides on that?
CB: I haven't written the tool.
RM: Does your ABNF allow arbitrary comments into prefix single-quoted
strings?
CB: The comment syntax has to be specific to the prefix.
RM: Or disallow comments in future single quoted app strings?
CB: Does not mean anything as definition of comment is unclear for that
future time
RM: We can say "it does not have comments in the same style as previous
prefix".
CB: Could, but why restrict?
RM: So code coloring would work in comments combined with specific app
strings ???
CA (not as Chair): Those would be comments of that language. For
example, comments of the C++ syntax.
RM: EDN says that certain char sequences are comments and equivalent to
sequences of white space. If that should happen in to-be-defined app
strings I want to know if such functionality exists in future app
strings. If so I have a problem. Turning sequence of characters in
middle to single white space, which editor needs to understand, is a
problem.
CB: The defined extensions "dt" and "ip" do not admit comments. For
future ones, it's up to who defines those.
RM: Does future XYZ expect that the EDN processor will turn that into a
comment?
CB: The comment in the base comment syntax happens outside those
strings. Comments within strings are part of the context syntax of that
string. If I define something, I have to define if I want a certain
comment syntax or not.
CA: ... CRIs can't have comments
OS (as an individual): So, like in the "dt" extension, you can say that
it supports comments and how they work, or you can say that they are not
allowed. So every new extension has to consider whether comments would
work, if any.
CB: If we want to put TypeScript in EDN we'd include the whole syntax
including comments. (TypeScript's comments, not EDN's comments)
CA: Is this a good direction?
RM: Don't see further progress right here and now
CA: We have enough material to progress the discussion offline.
CB: Please read version -13 and send comments.
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-cbor-comments-on-aldr-00.pdf
LL presenting.
LL (p2): Showing serialization options in CBOR. Various degrees on
serialization restrictions. Most use cases need a preferred
serialization. Serialization variation does not affect data model. Data
model and serialization concepts are different, and important to be
clear about this difference. CDE uses cases are small to me. Use case:
Independant data construction on both ends, signing the data and then
not sending the data is where it's important (exact match is needed on
both sides).
CB: The CDE document is short on use cases and uses. There's a separate
document for that. The most important use case is about test cases
producing deterministic output. You have problems if the application
decides to encode things in a different way (like custom encodings of
CWTs where some things are forbidden).
Example: 8392 (CWT)
LL: That's a data model rule and not serialization rule
CB: Yes, it's the top half of your picture on page 2. From CDE and below
we are doing serialization.
LL (p2): ALDR from this document seems to apply only to CDE today. Rules
should be eliminated or broadened to all of CBOR.
LL (p3): Detailed comparison of eliminating vs. broadening rules. This
hasn't really been considered. I feel like as implementor I have to read
everything before implementing and there's a lot to read. I'd like to
eliminate things. If not that, then broadening so that one can rely on
something otherwise restricted for reasons I don't understand. Why
limiting exclusions and reductions only to CDE? I'd like to hear more
people supporting this.
CB: A lot of things happened, for instance FIDO CTAP2 document which had
to be built on shaky ground. So their section 4.2 needs felxibility for
appliations and the nice things with dCBOR is that we can live with a
common det. encoding (CDE) together with Application level rules. The
application level rules are needed. Point is that if dCBOR is needed
there's a place in the architecture to put your custom rules.
CA: We have to stop here. Can you continue offline?
CB: Laurence doesn't see the cases that I have in mind.
CA: What about broadening approach?
LL: Problem is that CTAP is 1 protocol, not a class like dCBOR.
CB: Where does it say to be a class of protocol.
LL: When it was profiles that was the case.
CB: We changed that.
CA: Please take it offline.
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-cbor-carstens-slides-00.pdf
(skipped, see above)
CA: Issues are under control and this document will progress.
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-cbor-a-concise-binary-object-representation-cbor-of-dns-messages-02.pdf
ML presenting.
ML (p2-8): Want smaller DNS messages using CBOR. Omit a lot of fields.
Uses CBOR packed. Also does on-the-fly name compression.
ML (p9): Summary of what has been achieved so far. Many updates from
IETF 118. EDNS options are still to be made a map as next step, feedback
welcome.
ML (p10-11): Implementation work done during the Hackathon. Many points
covered during the Hackatho, something more since then. Something still
left but close to completion. Not so complex to implement (~1 weekend).
Had lessons learned from the implementation work.
ML (p15-16, 26-28): The name compression already exists in DNS, that's
what I'm fundamentally using, by referring suffixes per
outside of -packed-cbor.
ML: What should T be? 1+0 or 1+1 byte tag?
ML (p30): Instead of resource records we could use resource records
sets. Saves overhead for many records, but costs 1 byte overhead for
single records. Use punycode labels vs. UTF8?
ML (p32): What should the content type be and what should the
corresponding integer Content-Format be (proposed 53 and 54 for when not
using or using packed-cbor)?
ML: WG adoption? Or better for DNSOP?
OS: We should talk with the DNSOP Chairs and then follow-up.
CB: Need expertise from both DNS and CBOR. Must get input from DNS
people and directorate.
CL: What he said. We can get DNS people here; the CBOR questions are
more difficult. Here it's fine.
CB: Last call requested on .....
AP: Looks like it's natural to happen here, but keep DNSOP in the loop
especially during the WG/IETF Last Calls.
ML: Welcoming input on other open points face-to-face
CA (as Chair): I'll confirm with the other Chairs, but it sounds good to
have it here in CBOR.
ML: As to the WG adoption, we may have another version coming up soon to
actually consider.
CA, prep: Is this not tag 25? (ML, later reading the notes: no, tag 25
just points back to one previous string, tag TBDt points back to a
sequence of text strings + might deref further TBDt)
CA, prep: If compression relies on sequence, interaction w/ maps should
be clear anyway.
CA: See slide 10 of chair slides for interim timings