Subject: [Tzdist] Minutes of the interim-meeting 18/12/2014

From: Daniel Migault <[email-masked]>
Date: Thu, 18 Dec 2014 21:15:24 +0100

Dear Freinds and Colleagues,

Please find the minutes of the call conference. We would like to thank Mike
for taking the minutes.

The main action point for the WG are:
    - Solving the historical data issue
    - Solving the leap second issue

It would be good we fix these issues by the begining of next week to send a
WGLC on January 3.

Best Regards,

Daniel and Eliot
IETF meeting minutes

Going through open issues in order

Ticket #10 - We should truncate completely

Cyrus: issue dealt with by how it’s advertised in capabilities. Tim
(Parenti?) asked for further info in expand response. Dealt with.

Tim: I believe any issues have been addressed.

Marked as resolved.

Ticket 11 - Json schema

Cyrus: json schema author has been soliciting feedback. Progress being made
- but no firm deadline for submission. May need to coordinate with Ads and
Json working group. Believe we should still reference document and push for
publication.

Eliot Can’t approve this document without a decision. Will push Json
working group to make such a decision. Possible options in ticket.

Cyrus: 4th option to use completely different schema definition. Means a
rewrite to more like prose.

Importing full text into spec might cause issues?

Eliot - possibly not - might not require the same level of review.

Cyrus would prefer reorder of options: see ticket for final order.

Eliot will raise issue with Barry and will talk with son co-chair and try
to move draft along fast.

Cyrus - we have one other draft dependency
Normative because server has to return error responses in format defined
there.

Ticket 22

Cyrus: related to ticket 32.
Closed - will be addressed as part of ticket 32.

Ticket 32: Version

Cyrus: (Explaining posted proposal)
Goal is to address 2 competing element s for this issue. Lester wants tz
info in tz data to try to deal with race conditions.

Cyrus’ concern is to try to keep protocol efficient. Avoid download of
whole set of data.

Include publisher and version info in metadata. Clients may maintain and
store this metadata which may not actually appear in tzdata itself.

Trying to address issue caused by current ‘monolithic’ model in which all
data published at once. Incremental model would have version related to tz
itself. Trying to address both models.

This proposal avoids forcing clients to reload all the tz data just because
version changes.

Clients still get long list but clients only need to fetch tzs they care
about.

Lester has followed up - wants to be able to move to another tidiest server
without being forced to reload.

Question: how to get a diff

Cyrus changed the changed since token to be opaque - specific to tzdist
server that provided token. Version is the global synch token.

Separating out synch token for the data from the publisher and version.

Cyrus: allows a tidiest server to force a resynch if for e.g. data
conversion was faulty.

Daniel:? appear to have agreement with Lester?

Cyrus - a little pushback from Lester.

Eliot: One person should not hold back work.

   -
   - Cyrus: Mike had concerns about roaming devices believe this addresses
   this issue.

Eliot - would appendix with examples help

Daniel: would probably clarify

   - Cyrus: will try to put together examples for the list - could
   transcribe to spec. Don’t want to get too involved with consumer protocol
   issues.

Daniel: 1 line example may be enough

Ken: Document does not yet address retrieval of getting old versions

Eliot: resolution by January 9th. People should really read it - if more
time is needed for review might be possible

Cyrus: if we can come to consensus by early next week I will push out a new
spec.

Eliot: don’t think we an call it agreed upon until next year. No objections.

Ticket 23: Option parts of TIMEZONE tagged as required
Daniel: we should close.
Cyrus: agree - we have everything addressed

closed

Ticket 29: URL design

closed

Ticket 31: Include leap seconds
Cyrus: Ken did proof of concept in demo server.

Tim? does everything that tzdb does

Eliot: need to review - how is it being passed

Ken: made a pseudo timezone

Eiot - in draft or by convention

Cyrus: convention

Eliot: should we mention in draft.

Steve Allen: potential for confusion

Eliot: my feeling it should be documented.

Steve: db also includes “right” version of timezones -

Eliot: Updates ticket: discussion to continue. Try to resolve by Jan. 9th

Daniel: question is should it be documented?
Should we handle with pseudo timezone

Cyrus: if formalizing in tidiest probably better to define a data format
and make different resource.

Ken: use /leap - almost same form as observances.

Eliot: a pseudo publisher?

Cyrus: yes can still indicate source.

Eliot: need proposal.

Cyrus: Ken can you mock something up.

Ken: already there.

Steve: example of “right” timezone needed.

Eliot: all fine?

Yes

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58