Skip to main content

Minutes interim-2021-jmap-01: Thu 03:00

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2021-04-15 07:00
Title Minutes interim-2021-jmap-01: Thu 03:00
State Active
Other versions plain text
Last updated 2021-04-15

CALEXT/JMAP interim meeting - combined with CalConnect

Thursday 2021-04-15T03:00:00[America/New_York] for 90 minutes


Intro and Note Well: 5 min
Bluesheets: since this isn't using meetecho, we will need to take a list of
names. We'll also capture what we can from the Zoom attendees list.


Submitted documents: 5 min

* draft-ietf-calext-jscalendar
* draft-ietf-calext-eventpub-extensions
* draft-ietf-calext-valarm-extensions

Discussion of current work items: 30 min

* draft-ietf-calext-ical-relations - 5 min
* draft-ietf-calext-jscalendar-icalendar - 5 min
* draft-ietf-calext-icalendar-series - 5 min
* draft-ietf-calext-serverside-subscriptions - 5 min
* draft-ietf-calext-subscription-upgrade - 5 min
* draft-ietf-calext-vpoll - 5 min


* draft-ietf-jmap-calendars: 5 min
* draft-baum-jmap-tasks: 10 min
* draft-jenkins-jmap-sharing: 5 min
* draft-ietf-jmap-jscontact+vcard: 15 min

Milestone review: 5 min

Other Business: 10 min


no agenda bashing

## ical-relations:

* Mike, haven't had a chance to check.
* ACTION: Mike will check tomorrow, then get back to Bron

## jscalendar-icalendar:

* Robert, don't think we're close to last call.
* Mike concurs
* Did the easy part of defining mapping from icalendar to jscalendar, but will
need to come up with new property definitions for the other way. * Timeframe: 6
months plus. * Mike: need interop tests, only the two for now - need to get
someone else to implement too. * Bron: will do a Perl implementation. * Robert:
haven't decided if we should come up with a new RFC for ITIP impacts.  Should
it be a separate document? * Bron: concur, separate document is good.

## series:

* Neil, format defined but it should be server support rather than format. 
Should be a caldav extension rather than having to add extra properties.
    * Should be "created this event in my server, but marked it as a generator"
    * Could implement whole spec, and no idea how I'd use it as a client.
* Mike: there's no requirement that the client do anything, could just generate
the whole series in one go. * If something will be auto-generating it, then it
probably does need a protocol update somewhere.  Maybe that should be separated
out into a section? * Neil: if not, most of this is redundant, don't get the
point of all the S-properties. * Mike: largely to distinguish it from
older-style recurrence. * Neil: but you're generated individual instances, so
only the template needs it.  Is master an instance itself, think it shouldn't
be. * Bron: maybe make it not a VEVENT, make it a VEVENT-TEMPLATE instead or
something. * Marten: entire purpose is making it an easy upgrade.  Existing
clients/servers don't need to be aware of this.  If at least one client/server
is aware, it can do the expansion and then everything else just works. *
Marten: option is recurring events that are generated themselves. * Like this
spec because as a client you don't have to care, you can still see all the
instances, can still modify instances, and everything just magically works. *
Can extend it easily to support: this event is recurring every week, but only
if it doesn't overlap and instance in this other calendar (e.g. not during
school holidays).  Since they're not known that far in advance, you need a way
to expand when you know. * Neil: that would be great, but it's not in the
current spec. * Bron: still need a data format that allows it to be
transportable between systems. * Mike: didn't address in this spec how the
auto-generation would be handled in (e.g.) CalDAV. * Neil: don't think it's
much use without that. * Mike: auto-generation is optional anyway.  Having a
series generated at time of creation is totally fine. * Neil: if generated up
front, why do you even need this spec? * Mike: recurrences right now are a
giant object with many overrides. * Neil: understand the motivation.  Just this
isn't currently doing anything for interoperability.  It's not useful with just
what's in there now.  Only interesting bit is "single UID that links them all".
 The interesting bit is "what's doing the generating".
    * Would much rather not create a bunch of duplicate definitions.
* Mike: there's data portability issues - how do you transfer this?
* Bron: so what's the next steps?
    * Mike: like the idea of redefining the master as a template approach
    * Neil: VEVENT-TEMPLATE or something would be great, and don't need to
    redefine all the properties. * Properties like: who does generation, how
    far ahead, etc - fewer new properties. * SERIES-UID property into each of
    the events, can be the UID of the event template.
* Marten: be good to write down some more use-cases and see how they would work.

ACTION: Mike will take another look with that in mind.

## serverside-subscriptions:

* Ken and Mike talked with Apple about what they're doing.
* Currently - server just maintains a list of subscriptions, doesn't download
the data. * But interested in doing so. * Asked Apple to provide a spec about
what they're currently doing, and see if current draft matches. * Hopefully
hear from them in the next week or so.

ACTION: review draft based on Apple feedback

## subscription-upgrade:

ACTION: Bron should just WGLC

## vpoll

* Notes - lots to do, unlikely to happen for a while
* Mike: did work, rewrote to use participant component
* Probably need to re-implement stuff.
* Good to do JSCalendar alignment too


## jmap-calendars

* Neil, don't have much to say here yet.
* Getting JSCalendar published is an essential part, so great that it's
happening soon. * Mike: intend implementing ASAP, but got stuck in mapping.

## tasks

* Joris, incorporated most changes from the last IETF meeting
* Will upload a new draft soon
* Survey: have started, not sure how to present it.
    * Make a survey of various task systems and see what they need
    * Neil: there's no official pattern, just write it up in a way that can be
    emailed to list.
* Survey is partly done, but could use more detail.
* Jim: do we have a wiki somewhere?
* Bron: no
* Jim: sounds like IETF is about to change how they do it.
* Bron: if you want to crowdsource data, put up a wiki somewhere and tell us
where it is!

ACTION: keep surveying and upload new draft.

## sharing

* Neil: don't have much to add until we get more feedback or more
implementation experience.  Hopefully will have some by next full IETF meeting.
* Make sure it's generically adapatable to sharing for all JMAP objects.

ACTION: get more experience.

## jscontact + vcard

* Robert: New draft yesterday.
* For those not at CalConnect - TC-VCARD is doing similar work.

### addresses

* last IETF discussed format that's versatile enough, but isn't too complex.
* This is still work in progress
* Got these from wikipedia plus universal post document.
* Jim: is there a concept of line break?
* Neil: value itself should contain the line endings if needed.
* Jim: suggested a "separator" type
* Neil: sure, but should contain the separator text too.
* Neil: requires somebody to manually tag the bits of the address - which won't
happen if the user is entering it.  How would that work - a single field with
type "unknown"? * Robert: maybe a "full address" field? * using unknown, people
might put tags too. * Neil: sometimes you could have that - parts that don't
fit this format plus fields that do. * Neil: agree this is a reasonably nice

### groups:
* simple collection vs full blown card
* Opinion at last IETF, strongly preferred simple model.
* Haven't yet, because agreed to discuss here at CalConnect.
* Argument for not making it a full-blown card, didn't discuss why it's complex.
    * Neil: where to display in UI is one issue.
    * Stepping back -> does this get used ever?
    * Is it just "did it because they could"?
* Robert: not many here who weren't at IETF, but still ask -> does anyone do it?
* Jim Fenton: there's a capability in the iPhone address book to link cards
    * Neil: that just needs a list of UIDs and a name.
    * Marten: if you need, you could create a card that references the group
    and make it special somehow. * Neil: yes, like that - could add a property
    that has the UID of the "group card". * In JSON -> make it an optional sub

### localisations

* Currently has "localizations" section which is a patch.
* clutters the model a lot with 'value' properties using the different type.
* JMAP-style patch objects don't allow overriding single entries in an array.
* Neil and Mike: both agree that strongly prefer to keep JSCalendar style
similar. * Bron: how would we extend it to support arrays? * Neil: don't know
if you would want to update sub components -> would be more likely to override
the whole thing. * Mostly arrays are only specific things -> override the
entire array, which you can do in a patch.  Might have right-to-left changes,
etc - so it makes sense to always override the whole thing anyway.

### timezones:

* do we require Olson names - if so, require applications to map.
* If non-standard, should we map to non-standard Etc/GMT names that have
minutes in them? * Neil: not convinced. * If actual timezones, there's actual
zones with 30 min.  There's even one out there with 15 min. * VCARD discourages
use of UTC offsets, but we need to work out what to do. * Neil: be inclined to
do the same as JSCalendar.  Can specify custom timezone if you have to. *
Robert: so pull timezone option from JSCalendar.
    * Neil, just reference it.  Don't need to change it.
* Mike: with calendar data, UTC offset works because you've got a point in
time.  With VCards you're saying "I'm in this timezone", and that doesn't make
sense. * Neil: yet but if it exists, here's how to map it.

### milestones - Bron to update
* tasks to be added - submit early next year
* blobs - list to submit July.

### any other business?
* nope!
* adjourned 04:07 [America/New York]