CBOR WG Meeting - Interim 20-12
Wednesday, July 1, 2020, 17:00 - 18:00 CEST
Chairs: Francesca Palombini, Jim Schaad
Recordings: https://www.youtube.com/watch?v=Qyr9PsKwHI8
Etherpad:
https://codimd.ietf.org/notes-ietf-interim-2020-cbor-12-cbor
Attendees:
Agenda:
Status of draft-ietf-cbor-709bis : Barry (if present)
No Barry present so no status update
CBOR Tag for Date status : Mike
https://tools.ietf.org/html/draft-jones-cbor-date-tag-02
MJ: Saw some discussions on timezones this morning. Addressed issues that have been raised in latest version
Still need to read the rest of the mailing list from today.
Unless other discussions needed then think ready to go to IESG
CB: Need to be clear that this is calendar dates and not 24-hour periods anchored on a time scale.
JS: Did send some information on requested security considersation.
8:38
MJ: Read the threads. Can add a sentence about calendar dates not point in time.
JS Provided some decision making text that look good for a starting point
Publish a new draft today and the chairs can look at the state and possibly push forward.
HB: Don’t need to be overly verbose on the distinction.
FP: What was Jurgen comment/email
MJ: Statement about calendar date not time will addres this. Can be more explicit than what is currently in the document.
This is exactly for the passport/drivers license use case.
FP: Sounds good. Will still need to do the shepherding work.
New CBOR OID draft : Carsten
https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.html
CB: Draft has been stuck because co-author put in stuff that was beyond what a tag document normally does.
Refocused the document to defining some tags for OID identifiers. Removed things that should be in different documents
Kept the tag factoring to allow for tag to be applied to an array or map keys.
Need to review to make sure did not go overboard on tossing things.
JS: On the keys or the values of the map?
CB: Good question - on the keys for things like mapping X.520 items into a map.
FP: Request working group to look at the document
CB: Wanted to verify general direction is correct. Will submit -07 later to have a proper draft to look at.
MR: Allows to put an OID as ASN.1 tag in not encode as CBOR array.
CB: Yes - also added twist to relative OID, also added RFC 6256 (SDNV) which is the same format so can reuse the same tag
Will request an adoption after -07 is published
CDDL Module design
https://mailarchive.ietf.org/arch/msg/cbor/BayziLDbvL8zghvYYqsdJpiTp-0/
JS: Modules is a high request item. I sent out a mail to look for discussions.
JS: Suggest that the first issue be global namespace vs not global namespace
CB: Yes I think that we do have one (…) difference between names and references.
JS: Did not get that from the mail.
CB: we need to define that terminology. SDF we have a global namespace there too, but we use the CuRIe construct in SDF.
JS: In SDF you could have 2 different modules that internally define the same name within the same namespace
CB: Not sure that would be useful. No way to stop people from defining names. We will have several definition of the same name, and we will need to disambiguate.
JS: in SDF, is the module itself named?
CB: yes but not relevant. The module has a default namespace which looks like URI in which the module exports names.
JS: namespace declaration in ASN.1 or Python. ASN.1 every module is named with an unique name.
CB: YANG people are trying to do something similar + versioning. Version is part of the name. We should be looking at YANG because they just went through the process of naming.
HB: don’t think it’s super elegant.
MCR: would rather not do it like YANG. Currently there is a sed scrhipt that uses a string in the document to extract and correctly name it.
CB: interesting spectrum: completely deterministic system, in which best name is a hash, but also very hard to work with. in OS we have package system that do the work for us. On the other hand, reference system, so an expression and a process that resolve that reference.
MCR: Python does that well. Think well enough for our purpose.
CB: Python has feature called from future import, versioning is sometimes weird.
HB: we are not talking about files, and YANG think about files mostly.
JS: why do you think CDDL specs do not directly map to files?
HB: There is an order to the rules in CDDL.
JS: that’s true
CB: order comes later. Not sure we will have that one we have a naming system.
HB: there might be dependencies here that you need to import.
CB: import and export interfaces are the important part. The way they interact with the global namespace we can import from SDF. Important thing from SDF is that it uses URIs but these URIs are not meant to be dereferenced.
JS: in SDF are the URIs used … ?
CB: yes.
JS: common trope.
CB: yes.
JS: don’t like the word export as you defined it.
CB: already agreed with you. It should be called contribute. What is the opposite of contribute?
HB: augment? dependency
CB: like CDDL sockets, where anybody can contribute to CDDL.
HB: …rootless specifications…
CB: prelude is the first rootles specification.
HB: good example. Second level prelude should be a viable module.
CB: yes. That is something that should be selectable.
JS: it allows us to select between JSON prelude and CBOR prelude
HB: CBOR prelude, some types are not allowed in JSON, so it might not work.
HB: namespace, versioning, features are interconnected.
HB: Jim do you want to steer the discussion in the email?
JS: Yes, going through one by one is going to be useful. Comments about if this should be part of the native language or not. Carsten: is it possible to justify a prelude for the language rather than rewrite the whole CDDL?
CB: reformulte if we can get a clear layering? it would be useful to have but maybe not absolutely necessary.
[CB: If a module has switches and depends on other modules that have similar switches, throw them in synchrony]
– abrupt stop for timing reasons –
8:42
JS: it might be useful for a module to identify what feature it thinks it needs as well as for a module to identify what features it provides.
HB: If not sure if the feature notation itself requires any spec itself.
CB: what can you do with features? In CDDL tool I was going to put a feature to select which feature are enabled, disabled, or not influenced by the command line interface. But maybe this is overloading the feature mechanism too much. Maybe we want a different mechanism.
JS: features in terms of compiler/language features, not as “we have added this to this module”
CB: 3 levels: compiler, specifications, implementations. Not possible to do with one feature.
JS: example?
CB: update to the resolution process. “I only can be compiled by CDDL that has this feature” --> language feature
specification features: a specification evolves and you want to reference a dependency on the spec that is one step behind us. Not all systems will have the same revision of a module available
implementation: some implementation can do JSON and CBOR, and other only JSON, so you need to know which one are supported.
JS: would you consider the JSON/CBOR as specification feature?
CB: it can appear on specification or implementation level.
CB: need to consider part of the specification may not be updated yet, and that the implementation might only support one.
HB: Good example
CB: At CDDL level we managed to avoid feature, except the control operators. we probably want to refine that a little bit.
JS: that also seem to imply that you tightly tie together the compiler and validator.
CB: Good point. No we shouldn’t.
JS: compiler can have a feature that the validator does not have.
CB: Right.
FP: How to progress? What are the next steps?
CB: It might be useful to define new terms. Once we have done that, we might be want to identify invariants. Then someone should generate a lot of examples.
JS: have to throw away my draft response.
JS: Set up terminology, people can start thinking about examples that they think it would be useful to express.
FP: Continue discussion at the next interim
Other items for that would be status update from Barry, OID document and this topic.
IETF 108 scheduling
https://datatracker.ietf.org/meeting/108/agenda/
8:56
FP: Currently scheduled for Monday session. Looks like it works but wanted to check that nobody has conflicts.
FP: Need to submit a draft agenda - due on the 15th of July - Please give us what agenda items you want
CB: Interest in getting a JSON path specification done. Might be applicable to CBOR as well. The DISPATCH might have an idea on how this should be done.
Already tried with a different specification to apply to CBOR, but it was too hard. JSON path is simplier so it might be easier to add.
JS: When are you planning to submit starting dates for new interims? (Chair request)
FP: after IETF108
AoB