Minutes IETF106: jmap
minutes-106-jmap-00

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!