Minutes interim-2020-calext-01: Tue 14:00
||Minutes interim-2020-calext-01: Tue 14:00
Minutes - CALEXT Virtual Interim, 21 Apr 2020 GMT 13:00 - 14:30
Welcome and Note Well: 5min (Bron)
* Agenda Bash
* Discussion of how we work without face-to-face meetings as a
Current Drafts: 45 min
* Subscription Upgrade
* VAlarm Extensions
New work: 20 min
* JSCalendar extensions?
* iSchedule upgrade
Any other business: 20 min
* Milestone review
* 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.
* 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.
* 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
* 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.
* 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,
* 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
* 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:
- 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
ACTION: Robert will answer Mike's email about implementation experience.
* pretty much where it was last time.
ACTION: Waiting for Mike to update it.
* No change since last time.
ACTION: Mike will look at again.
* 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
* 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.
* Have made the changes, but there's still iterating to do.
ACTION: Mike and Ken will continue iterating (again) and discuss on the list.
* 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.
* 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.