Skip to main content

Minutes interim-2021-jmap-02: Thu 03:00
minutes-interim-2021-jmap-02-202110210300-00

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

minutes-interim-2021-jmap-02-202110210300-00
## Minutes

Bron introduced the Note Well.
Agenda: CALEXT 40 minutes + JMAP 40 minutes

## CALEXT drafts

### CALEXT Tasks (Mike Douglass)

* Adrian from DHL was the main editor for tasks - unable to continue with it
* does a good job of aligning with needs of project management.
* some parts of the relations draft were from tasks initially, need to remove
those from tasks. * also: "Group" parameter.  Makes more sense to use
participant component. * Much better status reporting.  Maybe this is a good
opportunity for the auditing component (tracking progress of task/event). *
Maybe encapsulate data in the structured-data component.
    * Maybe include in the tasks draft, maybe a separate RFC for auditing.

Neil: should be aligned with JMAP tasks stuff.

ACTION: Mike will refresh the calext-tasks draft soon.

### JMAP Tasks! (Joris Baum)

(we decided to look at this immediately to keep the discussion for the two
tasks documents together)

* aligned with JMAP Calendars for rights.
* ongoing: survey of system capabilities -> will present at next IETF.
* relations from JSCalendar might not be sufficient.
    * e.g. ticketing systems "duplicate of" - may be able to be done with links.
* It's probably a registry, so we could extend it.
    * Talk about at next IETF?
* When we bring out a new icalendar update, it should also include changes to
JSCalendar.
    * maybe we need to do that with relations that's already in last call?
    * better to add to tasks draft in calext, which isn't so far along.

Mike and Joris will work together on making sure the documents work well
together.

Neil: for Tasks, "assignee" vs "participant"?
* Participants is the right place -> give them a role of "assignee".

Should we be merging calendar and tasks? definitely need a similar data model.
* Still waiting on the survey for the broader discussion.
* do we need heirarchical task lists?  depends on survey.

ACTION: Joris will present survey of existing systems at IETF112, further work
on jmap-tasks after that.

### Calext Subscription Upgrade!

* Not much change since last time.
* seems pretty much complete

ACTION: Mike look at calext-subscription-upgrade before IETF112.

### Server side subscription

Look at defining server side subscriptions -> if lots of people subscribe to
the same thing, there's opportunity to optimise.

Apple has something already, but it's not really server-side, it just creates
an alias in their home directory - stores a list of subscriptions on the server
so the clients can all fetch it, but the server doesn't cache.

Could extend what Apple already have, or just describe it.

What we have now is a MKCOL extension, but align with Apple.  Ping them and
check.

Unlikely to have updates before next IETF.

ACTION: Mike/Ken to contact Apple about calext-subscription-upgrade

### jscalendar-icalendar

* not much change since last IETF.
* will also include mapoping for all the currently in-progress RFCs.
* want more implementation experience before last call!
    * Fastmail isn't switched over yet
    * Mike has everything from the mapping implemented
* Robert and Mike will sync up.  Most major issues resolved.

* Is anyone else working on the mappings?
    * Bron is doing a Perl one
    * Joris openexport project -> icalendar to jscalendar (also want to have in
    the future the other way)

Robert and Mike have been doing a call, can bring Joris in too.

ACTION: All implementations to collect more experience with
jmap-jscalendar-icalendar mapping

### icalendar series

No progress yet.

### any other calext business?

No

## CALEXT milestones

* tasks: Mike will try to get an updated version along with auditing component.
 Apr 2022. * subs: should be OK * mapping: Apr 2022.

rest is in the future

## JMAP drafts

### jscontact

Robert and Mario

* Robert has promised to write up something for metadata and versioning.  Due
to bandwidth, not yet done. * All properties map already, which should provide
good compat with VCard. * If anybody is using free-form fields other than
what's supported, please let us know your use-case! * Still need implementation
experience.

Don't see any other reason than implementation experience.  If any, please let
us know!

Hans-Jorg: there's no gender in jscontact, but there was one in vcard.
* Robert: also got another comment on this.  Deliberately decided not to
include until discussion comes up.  Property in vcard is disputed topic.  Sure
there's a way to store the information, but it's not enough to have a single
string property - people would want a more structured field.

* Don't feel confident to come up with a solution -> should be a separate RFC.

* Use-case is just to avoid data loss from VCARD.  It's not sufficient, but
maybe just keep existing format. * Neil: honourific, or gender? * Hans-Jorg: at
least in German, there's honourific.  It changes the grammar more than just the
honourific.

* Mike: don't think we can skirt around the issue.  People care about this. 
There are already conventions being adopted.
    * Neil: Free-form text, or enum (registry) - if you're using it for
    automated then it needs to be a specified format. * There's not currently a
    Pronoun section in vcard, but it's likely to be of interest.

Solution for now - vendor extension until there's a spec?

Robert: to preserve gender from existing vcard -> have an extension property
that carries over values from vcard.

https://datatracker.ietf.org/doc/html/rfc6350#section-6.2.7

Later comment from Hans-Jörg: Some random/historic references for the gender
discussion: * http://microformats.org/wiki/gender *
https://wiki.mozilla.org/VCard4#divergence_from_GENDER_proposal

Q: test cases?  Maybe that's something for CalConnect.
  * do more of a collection of test cases for these conversions.  Would be nice
  to have a shared repository.

Note in chat from Ricki Hirner: Just wanted to add the note that there are
major platforms like Android that currently support RELATED-TO, but only as
free text (which I find very unuseful but thats how it is)

ACTION: Bron to find the right group inside or outside IETF to review gender
handling in jmap-jscontact.

### jmap calendars

Neil Jenkins:

* been trying to get implementation experience.  Almost ready to do that at
Fastmail. * Needs a bunch of examples. * Need to add a CalendarPreferences
object. * hopefully first half of next year * Big question: do we merge in
tasks?

It's hard not meeting in person that we don't have working sessions to figure
out some of these things. * having specific calls provides deadlines to keep
things moving along! * might help to have calls.  Can move the time to make
them more reasonable for everyone.

ACTION: Neil to get implementation experience for jmap-calendars

### jmap sieve

Ken Murchison:

* nothing more to report
* everything in the spec except Test method being used.  Going to test using
test, then WGLC.

Hans-Jorg: did an implementation as well.   Found a couple of things:
* (suggest take to mailing list too)
* binary storage of the rule -> store script and store metadata.
    * Can be resolved by Blob draft.
    * Hans-Jorg: Problem with implementing -> assumes that there's a blob store
    for the entire backend.  But, often separate systems. * Can work around
    with ID format. * Other option: use a separate JMAP account for different
    things, so you upload into the account that you need.
* Other things like filter names - no means in sieve to specify a filter name,
but many systems do it by writing into comments.  Also not addressed in JMAP. 
Would be useful to know the underlying system.
    * Horde groupware has a name in the UI for each filter.
    * Most sieve is written by some UI -> these systems use comments to
    describe metadata for rules.

Alexey: should discuss rule names on EXTRA.
* maybe special comments, or even a named item.

ACTION: Ken to open discussion on extra mailing list about named sieve rules
for jmap-sieve

### smime-advanced

nothing to report now

## JMAP milestones

* adopt JMAP addressbooks?  no draft yet.  Need jscontact first.
    * Who to author?  Neil or Robert
    * Adopt March 2022
    * Alexey can help.
* jmap-calendars: Mar 2022
* jmap-sieve: Mar 2022
* jscontact: also RDAP want to use it.  So Mar 2022 still.
* blob: Dec 2021 still