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.