Minutes IETF113: sedate
minutes-113-sedate-00

# SEDATE Notes

## Intro and Note-Well

Chairs reminded all of the Notewell, and the process for using the meetecho
lite tool via QR code or datatracker link.

### ISO Liaison

ISO has a formal process.  The IAB have proposed a candidate, and ISO are
meeting next week at which time they should approve the candidate if they
passed the checks, expect an announcement next week.

# DRAFT

* 9 issues open in Github
* -03 [ Get rid of namespaces ]
* -04 [ Support offset timeones as in Java; Discuss meaning of named timezones ]

## Behaviour for conflicts

* Ujjwal: my understanding is that current draft says if there's a mismatch
between offset and TimeZone name, the offset wins. * Carsten: there's no answer
in the text.  It's application dependent.  So you need to ask the application
what the outcome should be. * Ujjwal: in the case where the application can't
ask.  For Temporal, the programmer can be required to choose behaviour.  My
intention is that the offset works.  The timezone name can be ignored if not
needed.
    * Suggest that if this group agrees, trusting the offset in case of
    conflict be the default behaviour if no way to check. * Means RFC3339
    implementations can easily support this format by ignoring everything after
    the current format.
* Mike Douglass: offset tells you what you believe the offset to be at the time
the timestamp was created.  If it's no longer correct at the time it's used.
    * Carsten: there's an indication that there's a problem.  It's not
    specified yet. * Applications may want to decide. * Mike: just want to
    write down exactly what should happen.  At least alerts you to the fact
    that there's a problem.  In calendaring, there's things you should do at
    that point (reschedule).
* Neil: what you do with a conflict HAS to be appication specific.  Which is
different than "always trust offset"
    * Bron: yes,
    * Neil: intent - why put a timezone.
* Ujjwal: disagree with Mike - that if there's a conflict then the offset is
necessarily wrong.  It could be either way.  If set an international meeting,
and the TZ rules change, still means that the meeting needs to happen at the
same time.  Of course, also the opposite case.
    * More about the case - daemon on a server somewhere, needs to make a
    decision about the timestamp.  No way to get clarification.
* Pete Resnick: disagree with Ujjwal and Carsten -> if you know you've
scheduled a meeting that you know is always at offset+800.  If the hint isn't
providing anything that's useful for a conflict, you should leave out the hint.
 Saying it should be in a timezone that might change is not useful.
    * If you're adding the hint of a textual timezone, then your intention is
    that it's at the zone. * Carsten: when I'm scheduling * Pete: if you
    scheduled in Pacific Daylight time, what is your intent?  Meaningful data
    or not? * Carsten: it's meaningful for the interface.  Acting as if not a
    problem. * Pete: the system needs an explicit marker. Making it a guess is
    the worst possible choice. * Carsten: don't think it's possible for the
    system to resolve any nonsense that the politicians come up with.
* Ken: agree with Pete.  The issue we have is that we're extending 3339, so we
can't strip off the numeric timezone, so we're stuck with this artifact.  Need
a marker of intent.  Perhaps we can steal from RFC8536 (use -0000 as the offset
to say "just a placeholder, use IANA timezone") * Mike: think people are saying
what I was going to say - treat it as an indicator "this is what I thought". 
Localtime is what matters to people.
    * Can't just say it's going to be at this UTC.  Comes down to need to
    reschedule
* Ujjwal: to answer Pete - need zone name when reading schedule, if you only
have an offset, when doing aritmetic you can't take timezone into account.
    * Issue with trust TZDB, you can't make sure everybody is on the same page.
     If I say we should trust TZ rules, and have a different version than
    another user, does it mean colleagues would be prompted with the wrong
    time? * Carsten: think we'll have to take to the list.

Bron SUMMARY: has to be either explicit in the spec, or a marker.

Pete: think that's close, the important bottom line is that you've got to
decide what the markers mean.  If you want a case where I'm giving you
something, but I'm not sure what it means - there needs to be a default
interpretation.  If the system wants to express both a numeric offset and a
timezone name, and I can't assess the creators intent, there must be a default
interpretation.  There's no point at which systems don't know the correct
intent, and are picking two different outcomes.

Carsten: first choice is RFC3339 timestamp, we're bound by RFC3339 for the
default choice, which is often the wrong choice!

## X-

We know people will do what they're told not to do, but this is the best we can?

## Do we have a way to say "MUST be understood" for extensions?

Need a syntax - want people to reply to the issue.

* Ujjwal: while it solves a lot of the problems, one of the goals was to allow
implementations that follow defacto spec would keep working.

* Carsten: damage doing this later would be worse than now.

* Ujjwal: that's fair, not against it.  Just pointing out drawbacks.

* Pete: Trying to understand what it means to reject the date.  In previous
discussion, might interpret the date differently.  If I get an event that has a
critical thing I don't understand, what am I meant to do?
    * Bron: treat as malformed.
    * Carsten: strong incentive not to send such things.

## The name!

Proposals?  There were no proposals in the room.

## Extension format

Carsten: Need at least one extension defined that people might want to use.

Propose that we define something!

Ujjwal: happy to do calendars, we need it for temporal. - will write a PR.

## ABNF

Top down or bottom up.

Maybe better to write top down, entry points not buried.

# MILESTONES

* Target June 2022.
* Interim at end of May if needed.

# ACTIONS:

* Ujjwal to do PR for u-ca - calendar systems
* Mailing list discussion about explicit marker for tz name vs offset
* Mailing list discussion for naming bikeshed