[calsify] Notes from CalConnect in Zurich, Feb 2019

["Bron Gondwana" <[e-mail]>]

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
 [e-mail]