Minutes interim-2021-sedate-01: Wed 12:00
minutes-interim-2021-sedate-01-202110201200-00

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.