Bron explained the note-well and introduced the history of the group.

During the call, issues were created in the github tracker for each discussed item:

https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/issues

## NOTES FROM THE MEETING

Discussion: here's the example:

* https://tc39.es/proposal-temporal/docs/persistence-model.svg 

The idea is to have a generalised extension format for all future things.

### limit to ASCII or do UTF-8?

Ned Freed: the value part of name-value pairs is limited to alnum, would a more general syntax be appropriate?
* Ujjwal -> though ambitious to make things general, not many suggested use-cases.
* Calendars, timescales, alternate zone formats (cldr timezone names)
* None have needed anything beyond alnum yet, but to make things as permissive as possible, wouldn't mind relaxing the syntax.

Mike: what about quoting?  Only thing you need to escape is the quote itself.  If UTF8, if ever, need to have it now.  May want a quoting syntax.
Shane F Carr: also security and spoofing problems (UTS39-looks same, behaves different)
* might want to look into IDNA.
John K:
* likewise, agree - but it's only a start.

Carsten: is this for humans, or for internal programming?
* advantage of specifying encoding, allows us to say "future must deal with this"

Ned: encourage authors to define an extension mechanism and put an example in!

Ujjwal: do include calendar extension with an example., because researched the most.

Punycode for IDNs is an example of what's bad with DNS.

Example: IANA timezone names and cldr timezone names -> could theoretically be non-ASCII.  IANA are ASCII, but other timezone systems may not be.

ACTION: an issue on encoding (ASCII vs full UNICODE codepoints somehow)

### largely for humans, or for interchange format?

This is a serialisation format -> it's fine to have key-value pairs that don't make sense to a human reading them.  Mostly for between computers.

### timezone vs offset

Mike: if you name a timezone by an ID, it probably means you want the time to be in that zone!

To encode the intention: if you only care about the point in time, you can skip the IANA timezone.

Mike: Perhaps use the same language that we use in ICALENDAR -> default to Olson unless there's a prefix.

Ujjwal: if defining from scratch, would maybe not use IANA, but want compat with existing.  And we don't use them for offsets right now, so it's OK to ignore.

### the x- problem (RFC6648)

* one way would be improve the procedure for including more extensions and just remove the x-.  Just remove all namespacing?  Just put all keys in the RFC.

Bron: suggest we define an IANA registry with all the existing ones in the draft.  John agrees.

### Floating times?

Ujjwal: current stance on floating time is that if we were to have a de-facto floating time format, it would be to say "just ignore the offset".

Existing 3339 doesn't allow TZ offset to be excluded.

Option - special-case 'Z' to mean "no offset rather than zero offset".

Mike: this does make it incompatible with icalendar, which does allow the format without the offset and without the Z.

It does tend to get overused.  different cases are covered in icalendar.  Could say "any existing format could be suffixed with this".

John: ingenious plans are bad!  Make it clear and simple if we're doing it.

### Question: do we have people here interested in timescales?

Carsten: yes, CBOR tab 1001.