## 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