Minutes interim-2020-cbor-08: Wed 17:00
minutes-interim-2020-cbor-08-202005061700-01

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.
<https://mailarchive.ietf.org/arch/msg/netmod/zaAtN5l8NuXUT1u3oj3qy9UG_m8>
FP: Should this be forwarded to the CBOR mailing lsit as well?
CB: Yes.