IETF106 JMAP WORKING GROUP - Singapore 2019-11-19, 17:10-18:40 = AGENDA Intro, Note Well and Agenda: 5 min Current Drafts: - calendars: 30m - mdn: 10m - quotas: 10m - smime: 5m Proposed new work: - JSContact: 20m Other business: - More general push support? 5m - Milestone review: 5m = ACTIONS Bron: * follow up with authors and issue WGLC for MDN * kick off discussion on the list again and follow up with authors for QUOTA * prod authors to keep researching and updating text for JSContact * write up something with all the known drafts and look for potential author for a combined draft for PUSH * update WG milestones Jim: * submit JMAP over Websocket document to IESG for publication Neil: * issue revised draft for JMAP Calendars * collect implementation experience for JMAP Calendars = DETAILED NOTES == websocket Jim briefly mentioned that Ken has uploaded a revision to the draft which addresses the issues raised during last call, and he will now submit it for publication. ACTION: Jim to submit jmap over websocket document to IESG for publication == calendars Neil: * planning to add many more examples to the draft * examples are particularly useful for implemention, though the prose needs to cover detail too * current draft is based on review at the interim meeting a CalConnect in October * expect the next step to be gaining implementation experience * CalendarEventNotification and ShareNotification in different places for good reasons * Share needs to exist before/after access to accounts * Event Notification has to be per-user and stored in the account Specific items: * mayAddParticipants ACL? Not in CalDAV so we won't add it to jmap-calendars, adds complexity for unclear value * access to original name/colour? - Barry: mostly you won't care - Seph: maybe useful, but can't see a specific case - nobody else could a use case either - Bron: easy to add later in an extension if we find a need * Sharees act as -> wording change. Neil will do. * hideGuestList and allowForwarding - Bron: should it be in jscalendar instead? - Neil: it's only related to the jmap-calendars stuff here, we'll add it to the registry - Bron: good, will show registry use and make it not stale - delegation is in icalendar, but rarely used - likewise party crashing, but there's no formal method to say what the server will allow - likewise "take over", we should define it clearly in JMAP/jscalendar - counter proposals are in icalendar, but unused - we really want VPOLL / jspoll * maxSizeCalendarEvent - so long as there's a clear error code for itemTooBig, there's no point publishing the limit - can always add in an extension later! * Alerts using "psuedo-type", like with Mail for "new messages only" - but it's not a state change - nobody had a problem with this Implementations: * mostly interested in server first, but definitely be good to have many clients too! * ideally do interop testing at CalConnect and IETF Hackathons ACTION: Neil to issue revised draft, then implementations == mdn The author wasn't present, and nobody remembers anything since last time, where we said "basically ready". ACTION: Bron to follow up with authors and issue WGLC == quota Authors were not present, but we had some opinions in the room! Neil: * the separate scoping is weird and hard to present in a client Bron: * it doesn't specify quota setting, only "get" and "changes" * Alexey and Neil agree that it's probably OK to be only get, at least this draft - often quotas are managed out of band anyway Alexey: * We should share the registry which the EXTRA quota draft creates ACTION: Bron to kick off discussion on the list again and follow up with authors == smime Alexey: * should have time to work on this again soon * split into 2 docs, one for verify only and one for more complex server side key management and signing Bron: * so - make this the simple doc, get it done early next year, adopt the other one next year too Alexey: * sounds good! == jscontact Neither of the authors were present. Neil: * in some ways this is much simpler than calendars - no timezones, recurrences, etc * but - real people! Names and Addresses are complex * we think we have a neat solution - list of items with tags Barry: * is all this in the draft? Would have to see text and examples to see if it's good * would we have a registry of known tags? Neil: * yes, initial registry in document and ability to add new * registry may need to specify use of tags for sorting and other properties on them Bron: * do we need a way to tag name part items as "do not include in display"? Alexey: * doesn't look too horrible by this description - some discussion of LDAP and how this is more powerful * need to seek people with experience in other fields / other parts of the world for how they use names Barry: * Spanish names for example, there can be a lot of names and the "Surname" for sorting is somewhere in the middle Neil: * related - we need to handle alternative names (Stage name, Pen name, Formal name, etc) which is not the same as additional name parts * don't want to wind up with an array of arrays! complexity vs usability Jim: * we'll need to represent pronouns too Pete: * Apple does Name/Nick Name/Phonetic Name - even with just that, clients often get it wrong! * let's not get too far into the weeds with complexity Bron: * everybody loves this bikeshed! We know enough to have opinions... Barry: * let's wait for text and review it then Neil: * good news, the format will be the hard part here! JMAP Addressbooks should be very easy once the format is defined Bron: * people in CalConnect are also involve with ISO, and ISO are also working on formats for names and addresses, we will keep working with them! * NOTE: recharter is not yet through, so we won't adopt this document until the charter is adopted ACTION: Bron - prod authors to keep researching and updating text == Push Bron: * Push stuff was proposed in DISPATCH, and Alexey suggested maybe JMAP is the right home due to JMAP already having done the hard work on PUSH. * do we need to recharter AGAIN? * DISPATCH also mentioned RFC8599 - which is the same thing for SIP! Alexey: * please write up all the drafts and detail * maybe HTTPBIS will be interested if there's a draft that fits their charter ACTION: Bron to write up something with all the known drafts and look for potential author for a combined draft == Milestones JMAP mail RFC5322 translation guide document: * Barry : set it to 2099? * Alexy: NO! * Bron: will make it Dec 2020 and review then for drop if still no movement Websockets to IESG: Nov 2019 (now!) Calendars to IESG: Nov 2020 (need implementation experience) MDN to IESG: Dec 2019 (nearly done) Quota to IESG: Feb 2020 (still work to do) smime basic to IESG: Feb 2020 Adopt smime full: Feb 2020 Adopt JSContact: Jan 2020 (once charter lands) JSContact to IESG: Dec 2020 Adopt Contacts for JMAP spec: July 2020 ACTION: Bron to update milestones == Other business No other business Due to lack of authors being present, we only used 60 of our 90 minutes, but we think we did ask for the right amount of time. LESSON LEARNED: Bron to follow up with authors who might be attending remotely close to the event, to check if they're still able to join rather than assuming they will!