[calsify] Minutes of Interim Meeting and action points.

[Bron Gondwana <[e-mail]>]

The minutes are up - canonical URL:
https://datatracker.ietf.org/meeting/interim-2020-calext-01/materials/minutes-interim-2020-calext-01-202004211400

Action Points from the meeting are as follows:

*Barry:**
*
* Barry to review EVENTPUB updated security wording from Mike

*Bron:**
*
* Bron to issue WGLC for VAlarm Extensions
* Bron to issue Call for Adoption of Serverside Subscription draft.
* Bron to update milestones for CALEXT working group

*Henk:**
*
* Henk to prepare CDDL spec for JSCalendar format and send to the mailing list

*Ken:**
*
* Ken to work with Mike on iterating VPoll spec

*Mike:**
*
* Mike to put information in the security section of eventpub and add text to each of the URIs referencing it - and check that change directly with Barry
* Mike to look at subscription upgrade draft again
* Mike to update series draft
* Mike to work with Ken on iterating VPoll spec

*Robert:*
* Robert to reply to Mike's email to the list about JSCalendar implementation experience


Full minutes pasted below for your convenience:

Minutes - CALEXT Virtual Interim, 21 Apr 2020 GMT 13:00 - 14:30

Agenda:
=

Welcome and Note Well: 5min (Bron)
 * Agenda Bash
 * Discussion of how we work without face-to-face meetings as a
 forcing factor
Current Drafts: 45 min
 * Eventpub
 * Series
 * JSCalendar
 * Subscription Upgrade
 * VAlarm Extensions
 * VPoll
New work: 20 min
 * https://tools.ietf.org/html/draft-douglass-serverside-subscriptions-00
 * JSCalendar extensions?
 * iSchedule upgrade
Any other business: 20 min
 * Milestone review

Minutes:
=

Agenda Bash:
==

* Henk Leaving early and wants to talk about JSCalendar,
 so we'll promote JSCalendar to earlier.
* Forcing factor - we acknowledged that it's an issue, but
 didn't get time at the end to discuss further.

Eventpub:
==

* Notes from Singapore were: "put the data in, URI for updates" - or maybe
 even wait for a BCP on usage of URIs in data formats.
* Mike:
 * The extended question is how to handle URI in general. There is
 no one rule fits all to determine if the URI needs to be
 downloaded or not.
 * The situation is similar to CONTACT in RFC5545 - a link to a VCARD
 would be more likely to be always uptodate (Bron: but it is also
 more likely to change or go away - bad for archival, maybe we don't
 care in every use case)
* Can we say "URLs SHOULD NOT be automatically downloaded unless the
 user has turned on an option". Also talk about phishing and tracking
 in the security considerations.
* It would be better to have a BCP to refer to, but we don't want to
 block this.
* There may be things in eventpub which would be good to change for
 jscalendar too, we'll see when we get there.
* Barry: should not wait for a BCP on it, though we probably should
 work on a document. Recommending at a non normative level that the
 use be request. The problem is clearly to the use of URI to
 distribute malware. It doesn't need to be heaps, just a few paragraphs.

ACTION: Mike will put information in the security section and add
 text to each of the URIs referencing it - and check that
 change directly with Barry.

JSCalendar:
==

* Mike has been working on a library for jscalendar similar to ical4j.
* Maping does not seem explicit enough with many more MUST. The conversion
 needs to be deterministic because both formats will co-exist for the
 next 10+ years, so data will roundtrip between them multiple times.
* Issues like: "where do you put the location property" and if you have
 more than one, which one is the default. The one associated to GEOLOC
 should be tagged explicitly.
* Similar issues with contact property. There needs to be something on
 the one which is the default to say "this is the one that is special
 in icalendar" - they have to be a participant in JSCalendar, but then
 how do you know which was the contact in the original ICalendar?
* Robert: very keen to define an exact set of mapping. Don't want it to
 be part of JSCalendar, should be a separate doc. Would very much not
 like to bake into the JSCalendar format translation guidelines.
* Mike: agree we have to be able to move on, but also have to coexist.
 Anything new in ICALENDAR has to be compatible with JSCalendar - but
 it needs to be able to round-trip for now.
* We must at least reserve some rel types and add flags to participant,
 etc.
* Mike has started building a list.
 * Discussion of "ATTACH" becoming a link type, and what it means to
 update just an attachment on an override. Talked about deep patches.
* Daniel: we've already got things as two documents with the translation
 guide.
* Mike: doesn't matter if it's one document or two. But they're linked
 and we need to complete them together. There's many years of dealing
 with the upgrade issues in ICalendar. Think it would be better in one
 document - but either way, think we can't say JSCalendar is done until
 we've got the mapping.
* Best way to find issues is to go through RFC5545 and try mapping each
 property and see what comes up.
* Lots of discussion about versioning and whether it's necessary:
 * Mike says yes
 * Many others "you can always add new properties, if you're updating
 existing then it's fraught regardless of version numbers".
 * Bron: if your software only knows about 3.2 and 3.3 comes along, can
 you process anything at all if you don't know what semantics have
 changed? Better to add new fields (extend the API) and deprecate
 existing ones so software can generate one or the other.
* Henk is interesting in JSCard - doing IETF versions of schemas
 for JSON (CBOR):
 * Big fan of ical and vcard.
 * Interested in this work in general.
 * Maybe we would be interested in having this in a formal data language?
 * Would be able to have a well definied structure.
 * At the moment it's complex and maybe ambiguous wording.
 * Mike: short answer: yes we're interested. How it's packaged matters.
 * Robert: any machine readable description is always good.
 * Don't know if it would be need to be put into the spec?
 * Effort is definitely of value.
 * Mike: would be great if the IETF didn't treat these documents
 as immutable! (we got sidetracked into that chestnut for a while)
 * Henk: data definition could include extension points. The formal
 definition can handle extensions.
 * Daniel: when do you think you could do it by?
 * Henk: Took about 3 hours to create a specific definition for JSContact:
 - https://hackmd.io/Cyjqhux8SYaEIkf4ylPImg?edit
 - Written in RFC8610 CDDL.
 * Robert: are there any RFCs written in it yet?
 * Henk: So far only COSE, but it wasn't an RFC yet. There are about
 40 drafts now using it.
 * Bron: main risk is which one is the normative if there's a difference.
 * Alexey: we can specify which in the document.

Discussion of versioning: with objects you can avoid items that you don't
know. From the WG discussions, there is not a consensus on whether the
version needs to be added or not. This needs to be discussed in more
detail on the list.

ACTION: Henk will send something to the list in the next few days with a
 CDDL spec.

ACTION: Robert will answer Mike's email about implementation experience.

Series:
==

* pretty much where it was last time.

ACTION: Waiting for Mike to update it.


Subscription Upgrade:
==

* No change since last time.

ACTION: Mike will look at again.

VAlarm Extensions:
==

* Ken updated with initial text back in December.
* Also re-introduced the "related-to" property to snoozed reltype.
* Daniel: main aspect is "don't ignore privacy concerns" but nothing
 more we can do. Just need to acknowledge that there is a risk.
* Bron: Should we just do a WGLC and see if any objections come up.
* Robert: were there default alarms defined?
* Ken: we removed it, because there wasn't a way to tell. Apple does
 something crazy with alarms set back in the past as a hacky way to
 override default alarms.
* Robert - agree that we shouldn't add it back. Also messy with old
 default alarms.
* Suggest - separate draft to handle default alarms.
* Mike: default alarms is nice - could implement it if you don't have
 icalendar baggage. We could do it nicely in JSCalendar. Don't need
 to update this draft.

ACTION: Bron to issue WGLC.

VPoll:
==

* Have made the changes, but there's still iterating to do.

ACTION: Mike and Ken will continue iterating (again) and discuss on the list.

Serverside Subscription:
==

* Apple already have an implementation
* This is still a personal draft - we should adopt the work and see
 if we can get Apple to help us make it match their implementation.

ACTION: Bron to do Call for Adoption with existing draft starting point.

Milestones:
=
 * JSCalendar - if we push on, June 2020
 * VAlarm - May 2020
 * Scheduling Controls - May 2020
 * VPoll - Oct 2020
 * Series - leave at June 2020.
 * Subscription Upgrade - July 2020.
 * Server Side Subscription - do by Oct 2020.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [e-mail]