CBOR WG Meeting - Interim 20-08 Wednesday, May 6, 2020, 17:00 - 18:00 CEST Chairs: Francesca Palombini, Jim Schaad Recordings: https://www.youtube.com/watch?v=FtWaUKZ5VI8&feature=youtu.be Attendees: Francesca Palombini Jim Schaad Barry Leiba, FutureWei Peter Yee, AKAYLA Michael Richardson, Sandelman Software Works Carsten Bormann, TZI Agenda: * Date and time tag document : Chairs https://tools.ietf.org/html/draft-jones-cbor-date-tag-01 - WG adoption call result The chairs have decided that the feedback means that the document has been adopted. CB: There were some tech comments on the document on the mailing list. Expect to be addressed in -01 * CBOR specification status : Carsten https://tools.ietf.org/html/draft-ietf-cbor-7049bis-13 A few comments - there are now pull requests on all of the comments. Three pull requests openned today #176/181 - Need some more text with allocation rather than just reserving this. Will require a new draft for this allocation, the security considerations will be complicated New draft will be information, might not make it to an RFC. MR: Why is a new draft needed? CB: In order to get the security considerations for the tag written down. Could be done on a wiki page, but preferes to reference draft. Problem with null tag is that multiple implementations could treat differently Need to indicate how it is implemented - I.e. reject parsing with the tag. If just changed the tag now to reject all content if seen, then all existing implementtions would be incorrect. MR: do an ignore of unknown tags CB: Have been moving away from ignore tags to atleast giving to program for processing. MR: Don't want to ignore it, don't want to reject. Is this changing processing for unknown tags in the current bis document? CB: No one right answer, are no longer considering tags to be ignorable decoration. MR: Needing a transition from don't know tag to presenting to implementations. But need to do this in a way to not invalidate all current implementations. Suggesting using a flag date for behavior change. Realizes will not work Suggesting a flag to the parser to control behavior of ignore vs reject. Application needs to opt in CB: Highlights the "may" word in text to indicate that this is optional behavior for the library MR: ACTION - to raise issue on github -- Issue #182 CB: Does this seem to be correct? FP: Yes, but need to get one version of the draft existing for public #177/180 - CB: Create a new consideration for IANA that deals with problems on using 64-bit nubmers Need to run past IANA to make sure it is fine. #178/179 - CB: Good of Peter to have raised this issue even if simple Simple change to deal with this FP: Wait a couple of days for other feedback and then allow the merge to occur CB: Normally Paul does the merges on this and it takes a couple of days CB: Will try and come up with pull requrest on #182 CB: Will this need a new WGLC. JS and FP: Don't think this will be necessary. CB: Will need to look at final version before final decision of course FP: Question on reproting of implementation review CB: Nothing has happened since last meeting. AOB: CB: Like to point to bitset in YANG cbor discussion on the CORE/YANG mailing lists. Need to make sure we are doing this correctly. FP: Should this be forwarded to the CBOR mailing lsit as well? CB: Yes.