* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Sedate Status Pages

Serialising Extended Data About Times and Events (Active WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2021-Jul-02 —  

IETF-113 sedate minutes


minutes-113-sedate-00 minutes

          # 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

Generated from PyHt script /wg/sedate/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -