Skip to main content

Minutes interim-2020-calext-01: Tue 14:00

Meeting Minutes Calendaring Extensions (calext) WG
Title Minutes interim-2020-calext-01: Tue 14:00
State Active
Other versions plain text
Last updated 2020-04-22

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
      forcing factor
Current Drafts: 45 min
    * Eventpub
    * Series
    * JSCalendar
    * Subscription Upgrade
    * VAlarm Extensions
    * VPoll
New work: 20 min
    * JSCalendar extensions?
    * iSchedule upgrade
Any other business: 20 min
    * Milestone review


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.


* 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.


* 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
        CDDL spec.

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


* 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.


* 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.

  * 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.