Re: [Tzdist-bis] [calsify] Notes from CalConnect in Zurich, Feb 2019

[Daniel Migault <[e-mail]>]

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 <[e-mail]>
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:
>
> 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]
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>