Subject: [calsify] Notes from CalConnect in Zurich, Feb 2019

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 13 Feb 2019 10:55:15 -0500

Hi All,

Sorry for the delay in summarising all this. I thought I should email here with a summary of the key CALEXT related things we discussed at CalConnect last week.

*TimeZones:*

See also: https://mm.icann.org/pipermail/tz/2019-February/027503.html for the discussion on the TZ list.

We have RFC7808 and RFC8536 for standard representations of timezone data, but there aren't public servers or a standard practice of vendors providing fast updates, leading to the ongoing problem of late-stage political updates causing software and devices to be out of sync.

 * ISO is working on their own process for timezones per country and a non-country "community zones".
 * IANA have already taken over the Olsen zones and keep them updated (see RFC6557)
 * Microsoft have their own separate database
 * IATA already have a database which is government provided and verified and used by airlines

The main issues with any faster update process are oversight and verification - somebody could do things like attack the stock market by interfering with timezone data updates.

There are also issues with location -> zone mapping and timezone naming, mostly political (eg: disputed territories).

There's a proposal to give zones non-name IDs rather than names, and also accurate geo boundaries. Using that, people could choose between zones which were verified to be used within or claimed to cover any particular area, and vendors could ship their own names or even localised names for any particular zone ID.

Next steps: see if IANA is interested in running a tzdata server that can be used for direct lookups (and how that would be funded), and talk to the tz group about working with ISO.

*JSCalendar:*

 * Robert will follow up on that! There were a few last minute clarifications
 * I did a Perl implementation which I will publish shortly.

*IETF and CalConnect:*

I did a presentation about taking documents to IETF and why CalConnect should continue to do that! There's a known cultural mismatch which I am attempting to bridge! I have uploaded my slides here:

http://talks.brong.fastmail.fm/calconnect-feb2019/calconnect-ieft.pdf

I didn't take notes during my talk (obviously), but it was a good kickoff for the discussion about our exisiting drafts, which I'll paste below:

 * Managed Attachments - nearly complete
   * *Ken* will finish
 * VPOLL
   * Need to lock down poll
   * *Mike*! (Ken can help with)
 * VALARM Extensions
   * Draft written by Cyrus Daboo
   * Main one we want to keep is acknowledgement - Apple, Thunderbird support
   * Probably *Ken*? (currently co-author)
   * Considering removing Apple’s “default alarms” hack.
     * Avoid server putting defaults back on!
   * Proximity alarm (Apple already using)
     * If close to supermarket, fire an alarm!
   * Specify if you want an alarm, and how important the event is for you.
   * "Is it really important for me to get to this event?"
   * Spend time in TC-CALENDAR debating if we want to change behaviour?
   * SECOND DRAFT
   * ALARM AGENT → client/server.
   * Related events →
   * alarm tied to multiple events?
   * X-travel-time? Client side will decide when to notify, not server side at all with Android
   * Proprietary API anyway.
 * Subscription Upgrade
   * Smart updates to an ICS feed
   * Conditional request with a prefer header.
   * Adds “Status DELETED”.
   * OPTIONS → can specify what’s available.
   * Is “eTag” being used? Need to use weak eTag.
   * Does it support pagination? NO!
     * A header that says “still more changes”.
   * A way to say “there’s been a change” → aka push.
   * Author: *Mike* - individual submission (rev 3)
   * Ask HTTPBIS to look at it.
 * CalDAV Sharing →
   * what Apple has already implemented
   * is 3 drafts
   * DAV Notifications
   * DAV sharing
   * CALDAV sharing
   * Author: Evert wrote originally (*Ken* to take on authorship?)
   * MAY WANT TO STANDARDISE Per-USER write capability
   * Put into DAV namespace (also useful for Contacts/CardDAV and maybe more?)
   * *Go via Dispatch*?
   * Per user notes on a vcard?
   * TODO: organizer, owner, etc in the caldav part.
 * VPATCH
   * Cyrus Daboo originated
   * Reduce client/server chatter.
   * Describes how to use it with RFC PATCH method.
   * ENHANCED CalDAV sync
 * VINSTANCE
   * Effort to reduce size of recurring events with a bunch of overrides. 
   * Suggestion: Punt these three in favour of JSCalendar.
   * Informational draft → or DEVGUIDE. List all the resources a developer needs for a caldav client/server.
 * SCHEDULING CONTROLS
   * *Bron *wrote this
   * draft submitted to IETF already
   * will propose to calext that it gets adopted

Documents that are in the queue and we think should go to the IETF:
 * scheduling
 * valarm
 * vpoll (there’s some iTIP stuff, but it’s our domain)
 * subscription upgrade - needs http input
 * caldav sharing - same

My suggestion to the group was - submit ALL of these to calext and get initial drafts published within the working group, then progress each of them as there is interest and time to work on them.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]

---

From: Steve Allen <[email-masked]>
Date: Wed, 13 Feb 2019 10:37:36 -0800

On Wed 2019-02-13T10:55:15-0500 Bron Gondwana hath writ:
> I thought I should email here with a summary of the key CALEXT
> related things we discussed at CalConnect last week.

> Next steps: see if IANA is interested in running a tzdata server
> that can be used for direct lookups (and how that would be funded),
> and talk to the tz group about working with ISO.

Do you mean a tzdist server?

Following along that, in the discussion I believe I heard folks
ruminating that it might be about a half-day of hacking to create an
application that could query data from a tzdist server and convert it
into information for /usr/share/zoneinfo on a Linux system, and that
could become a prototype for other similar systems that want to get
new zone info without needing an operating system patch.

Did I actually hear that, who was suggesting it, and does it seem
likely that someone will write code like that?

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Michael Douglass <[email-masked]>
Date: Wed, 13 Feb 2019 14:07:54 -0500

I think we (Ken) were challenged to modify a linux distribution to use a 
tzdist server to get the tz info.

And yes - I think it was felt a simple script using curl could do the job

On 2/13/19 13:37, Steve Allen wrote:
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Feb 2019 12:05:55 -0500

ccing our tzdist collegues,

The possibility of requesting IANA to host a public server has been raised
at the time of RFC 7808 publication . I do not recall any issue raised by
IANA at that time. I believe distributing tzdata is one service with
probably less potential contentions than binding geographic boundaries to a
time zone. In that sense it might be good to keep these services separate.

Please feel free to share your thoughts on IANA serving the tzdata with
tzdist, our our position toward other organizations as well as envisioned
future steps.

Yours,
Daniel

On Wed, Feb 13, 2019 at 10:55 AM Bron Gondwana <[email-masked]>
wrote:

> Hi All,
>
> Sorry for the delay in summarising all this. I thought I should email here
> with a summary of the key CALEXT related things we discussed at CalConnect
> last week.
>
> *TimeZones:*
>
> See also: https://mm.icann.org/pipermail/tz/2019-February/027503.html
> <https://mm.icann..org/pipermail/tz/2019-February/027503.html> for the
> discussion on the TZ list.
>
> We have RFC7808 and RFC8536 for standard representations of timezone data,
> but there aren't public servers or a standard practice of vendors providing
> fast updates, leading to the ongoing problem of late-stage political
> updates causing software and devices to be out of sync.
>
>
>    - ISO is working on their own process for timezones per country and a
>    non-country "community zones".
>    - IANA have already taken over the Olsen zones and keep them updated
>    (see RFC6557)
>    - Microsoft have their own separate database
>    - IATA already have a database which is government provided and
>    verified and used by airlines
>
>
> The main issues with any faster update process are oversight and
> verification - somebody could do things like attack the stock market by
> interfering with timezone data updates.
>
> There are also issues with location -> zone mapping and timezone naming,
> mostly political (eg: disputed territories).
>
> There's a proposal to give zones non-name IDs rather than names, and also
> accurate geo boundaries.  Using that, people could choose between zones
> which were verified to be used within or claimed to cover any particular
> area, and vendors could ship their own names or even localised names for
> any particular zone ID.
>
> Next steps: see if IANA is interested in running a tzdata server that can
> be used for direct lookups (and how that would be funded), and talk to the
> tz group about working with ISO.
>
> *JSCalendar:*
>
>
>    - Robert will follow up on that!  There were a few last minute
>    clarifications
>    - I did a Perl implementation which I will publish shortly.
>
>
> *IETF and CalConnect:*
>
> I did a presentation about taking documents to IETF and why CalConnect
> should continue to do that!  There's a known cultural mismatch which I am
> attempting to bridge!  I have uploaded my slides here:
>
> I didn't take notes during my talk (obviously), but it was a good kickoff
> for the discussion about our exisiting drafts, which I'll paste below:
>
>
>    - Managed Attachments - nearly complete
>    - *Ken* will finish
>       - VPOLL
>    - Need to lock down poll
>       - *Mike*!  (Ken can help with)
>       - VALARM Extensions
>    - Draft written by Cyrus Daboo
>       - Main one we want to keep is acknowledgement - Apple, Thunderbird
>       support
>       - Probably *Ken*?  (currently co-author)
>       - Considering removing Apple’s “default alarms” hack.
>       - Avoid server putting defaults back on!
>          - Proximity alarm (Apple already using)
>       - If close to supermarket, fire an alarm!
>          - Specify if you want an alarm, and how important the event is
>       for you.
>       - "Is it really important for me to get to this event?"
>       - Spend time in TC-CALENDAR debating if we want to change behaviour?
>       - SECOND DRAFT
>       - ALARM AGENT → client/server.
>       - Related events →
>       - alarm tied to multiple events?
>       - X-travel-time?  Client side will decide when to notify, not
>       server side at all with Android
>       - Proprietary API anyway.
>       - Subscription Upgrade
>    - Smart updates to an ICS feed
>       - Conditional request with a prefer header..
>       - Adds “Status DELETED”.
>       - OPTIONS → can specify what’s available.
>       - Is “eTag” being used?  Need to use weak eTag.
>       - Does it support pagination?  NO!
>       - A header that says “still more changes”.
>          - A way to say “there’s been a change” → aka push.
>       - Author: *Mike* - individual submission (rev 3)
>       - Ask HTTPBIS to look at it.
>       - CalDAV Sharing →
>    - what Apple has already implemented
>       - is 3 drafts
>       - DAV Notifications
>       - DAV sharing
>       - CALDAV sharing
>       - Author: Evert wrote originally  (*Ken* to take on authorship?)
>       - MAY WANT TO STANDARDISE Per-USER write capability
>       - Put into DAV namespace (also useful for Contacts/CardDAV and
>       maybe more?)
>       - *Go via Dispatch*?
>       - Per user notes on a vcard?
>       - TODO: organizer, owner, etc in the caldav part.
>       - VPATCH
>    - Cyrus Daboo originated
>       - Reduce client/server chatter.
>       - Describes how to use it with RFC PATCH method.
>       - ENHANCED CalDAV sync
>       - VINSTANCE
>    - Effort to reduce size of recurring events with a bunch of overrides.
>
>       - Suggestion: Punt these three in favour of JSCalendar.
>       - Informational draft → or DEVGUIDE.  List all the resources a
>       developer needs for a caldav client/server.
>       - SCHEDULING CONTROLS
>    - *Bron *wrote this
>       - draft submitted to IETF already
>       - will propose to calext that it gets adopted
>
>
>    - scheduling
>    - valarm
>    - vpoll (there’s some iTIP stuff, but it’s our domain)
>
>
>    - subscription upgrade - needs http input
>
>
>    - caldav sharing - same
>
>
> My suggestion to the group was - submit ALL of these to calext and get
> initial drafts published within the working group, then progress each of
> them as there is interest and time to work on them.
>
>
>
> --

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 14 Feb 2019 15:25:12 -0500

Thanks for doing this Daniel! I was preparing to write to tzdist as well, but I ran out of time before spending 24 hours in small aeroplane seats. Back in Australia for now until the 21st of March when I fly to Prague.

I know a few people from tzdist were already on the call, so heard the discussion about both tzdist and potential involvement of ISO to provide a pathway for countries to officially provide their timezone data through an organisation that has treaty obligations with their country standards bodies.

Cheers,

Bron.

On Fri, Feb 15, 2019, at 04:06, Daniel Migault wrote:
> The possibility of requesting IANA to host a public server has been raised at the time of RFC 7808 publication . I do not recall any issue raised by IANA at that time. I believe distributing tzdata is one service with probably less potential contentions than binding geographic boundaries to a time zone. In that sense it might be good to keep these services separate. 
> 
> Please feel free to share your thoughts on IANA serving the tzdata with tzdist, our our position toward other organizations as well as envisioned future steps. 
> 
> Yours, 
> Daniel
> 
>  
> 
> On Wed, Feb 13, 2019 at 10:55 AM Bron Gondwana <[email-masked]> wrote:
>> __
>> Hi All,
>> 
>> See also: https://mm.icann.org/pipermail/tz/2019-February/027503.html <https://mm.icann..org/pipermail/tz/2019-February/027503.html> for the discussion on the TZ list.
>> 
>>    * Conditional request with a prefer header..
>>    * Adds “Status DELETED”.