* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Jmap Status Pages

JSON Mail Access Protocol (Concluded WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2017-Mar-16 —  

IETF-111 jmap minutes


minutes-111-jmap-00 minutes

          # JMAP Working Group - IETF 111
          Tuesday, July 27, 2021 16:00-18:00 PDT (23:00-01:00 UTC)
          Chairs: Bron Gondwana, Jim Fenton
          Minute takers: Bron and Jim
          ## Agenda
          ## Intro and Note Well: 5 min
          Neil Jenkins: Asks about errata that have been filed for core spec.
          Bron will check on that.
          ACTION: Bron to check who needs to approve errata for core spec.
          ## Core: 10 min
          ### draft-gondwana-jmap-blob - 10 min
          Bron presented the blob draft, now adopted by the WG.
          Adds concatenation support, named datatypes, IANA registry for datatypes
          Still needs implementation experience!
          Ken Murchison says Blob/set has been implemented in Cyrus JMAP, but may
          need tweaks to catch up with latest draft
          IANA registry details, in fine print.
          Do we need an IANA registry for this, or redundant with capabilities
          Limits, e.g., MaximumBlobSize? MaxSizeUpload?
          Ken: push uses datatype names.
          Neil: Need to forbid duplicate datatype names?
          Bron to ask IANA if duplicate names (keys) are allowed.  Will add some
          additional text describing this to next revision of the draft.
          Q: Do we need a separate draft to create the registry?
          A: everyone said no.
          Q: Lookup capability separate from get/set? Or boolean?
          A: discussion settled on "list of datatypes for which lookup is supported
          in the capabilities object"
          ACTION: Bron to publish new jmap-blob draft with capability information
          and registry instructions
          ## Mail: 5 min
          ### draft-melnikov-jmap-smime-advanced - 5 min
          Alexey is chairing another session so Bron presenting.
          Not actually all that "advanced"
          Bron will issue call for adoption to mailing list.
          Neil: Should probably return what the new body structure is, as all JMAP
          methods do when the server makes a change to the object being created.
          ACTION: Bron to issue a call for adoption for
          ## Calendar: 30 min
          ### draft-ietf-jmap-calendars - 20 min
          Neil Jenkins presenting
          Small update submitted. Some implementation experience but would like
          Spec seems to be holding up well.
          Interesting case: deleting instances as an invitee. How to handle updates
          to recurring events if an invitee has deleted an instance?
          - Add extra property if user deleted it
          - Just forbid it
          Jim Fenton: what about if the event was updated to a new time?  Maybe the
          user wants an offer to attend again.
          Mike Douglass: as an attendee, you don't own the event, so you can't
          delete it!  The correct thing is to not let them do it, you can only
          update your attendence to it.
          Neil: yes, but existing systems appear to let you do it.
          Ken Murchison: agree that declined is the right thing.  E.g. with Apple
          calendar a delete turns into a decline.
          Neil: see a consensus for forbid the user from deleting individual
          Event ownership: Should you be alllowed to update an event so you are
          no longer the owner? (transferred ownership)
          Event ownership edge case:
          * if no owner, "may update own" allows.
          Joris Baum: should just allow the change.
          Mike: if you can't undo, you can't undo!  Let things fall as they may!
          Default identity:
          * could put on a per-client basis, but if we're going to store on the
          server we need a place!
          add 'isDefault' property?  But have to make sure exactly one has true.
          Or put on capabilities, but only if it's read-only.
          Mike: suggest a general preferences object - there will be other
          Fastmail has something internally for this -> Mike, you probably want
          that synchronised.
          You may want different preferences per account.
          Mike: if we go through the list of the DAV properties, that would
          be a good starting point.  Good to have it as a fetchable object.
          At the start of any caldav session is a fetch of a bunch of properties.
          Can have an object with its own last modified, etc.
          Can use standard JMAP update logic.
          ACTION: ALL keep working jmap-calendars design on the list, hopefully
          finalise by end of the year.
          Robert Stepanek: 3 things.
          #### 1. CalendarEvent/query expansions
          CalendarEvent/query allows for expand recurrences.  This creates synthetic
          events.  Need to make clear that these will NOT be reported in changes.
          Only the master event ID will be included in changes.
          Bron: do we need a property on the synthetic events?
          Robert: common property would be UID, but that doesn't tell what the
          JMAP ID is.
          Neil: that would allow invalidating all the events.
          Robert: alternative would be relation parent/child, but parentId would
          be better choice.
          ACTION: Neil to add property for parent JMAP ID to server-side expanded
          event recurrences
          #### 2. inbox role: right now optional
          Robert: idea, make `inbox role` mandatory.  If the server supports
          scheduling it can indicate it with a capability.  If removed, we have
          nowhere to put calendar invites.
          Neil: if we're going to create the calendar preferences object, we can
          move it there.
          Robert: how do we deal with not requiring all implementations to support
          Neil: allow `null` if you don't support scheduling.
          Mike: can see situations where the server might allow certain accounts
          to have scheduling disabled.
          Bron: if you remove it, then you're turning off scheduling!
          Robert: so long as we say that the server can reject it, that's OK.
          #### 3. Invited to a recurrence instance only (or multiple)
          Robert: What if you're invited to a recurrence first, then to the
          full event?  What happens?
          Mike: if the master event arrives, you throw away the individual instance.
          Robert: maybe it has a different resource?
          Neil: you can either have a master event, or 1 or more individual
          recurrences.  This is mostly a problem for the iTIP handler (it needs
          to merge all your local alerts, etc)
          ### draft-baum-jmap-tasks - 10 min
          Joris Baum:
          Not much has happened since the interim, been busy with other things!
          Collecting implementation experience with various JMAP specs.
          Still need to publish a survey about various task systems.
          Be happy to hear of others who have collected experience.
          Bron: any requests from the group?
          Joris: not right now - next time will present notes and experience.
          Not in a very finished stage yet.
          Neil: don't have any questions right now, but will make sure to review
          it again.  Agree that server capability research is important to cover
          use-cases that people have.
          ## Contacts: 30 min
          ### draft-ietf-jmap-jscontact (+vcard) - 30 min
          Robert Stepanek presenting
          Localising content - preference of most participants was patch object
          (same as jscalendar).  Will wait on mailing list for feedback.
          * If nothing else, we have consensus from those who have an opinion!
          Intend to add `@type` property.  Speak up if you object!
          Per-field metadata (e.g. update time.)  Unsure exact use-cases, but
          could do with a patch-object path.  Does anyone else have an opinion?
          Mike: has been raised for both calendar and contacts.  Some kind of
          standard audit-trail.
          Neil: this isn't an audit trail, it's just the "last updated".
          Mike: in this form, yet - but a change-log would give an audit trail
          Bron: so a "reverse changes" log?  Would be great.
          Mike: there's already a model in caldav-sharing, a "change reporting
          mechanism".  Used by Apple Calendar application to show changes too.
          Only thing missing is not attached to the changed object.
          Neil: allow only server-set, truncate over time, etc.  Not a default
          Robert: so this might be a general extension RFC for any datatype?
          Use for JSCalendar, JSContact, etc
          Mike: same format could be used to report changes too!  Look at this
          across both calendars and contacts.
          ### Multi-sourced contact
          Allow providing a unified view for a contact from multiple sources.
          Neil: that's a client thing, not a data format thing.  Same UID or
          "match on things".
          Bron: tricky thing is where to write updates to.
          Neil: again, needs to be a client thing.
          Mike: the Apple client does that, unified view.
          Robert: yes, but client does that.
          Mike: indication of source would be good.
          Joris: concept is interesting.  UID is randomly generated so could be
          different on different systems, could be clashes between sources.
          Neil: very unlikely to get a clash unless it's the same object.
          Bron: sometimes users edit things in different systems in different ways
          without realising that they have the same object identifier!
          Robert: that's all.
          Mario: no additional points.
          Field metadata approach has interest -> start definining under umbrella
          of JSContact but make general.  Robert will write up before next meeting.
          ACTION: Robert to write a draft for storing metadata/history on JMAP
          ## Discussion topic: the large email problem (20 min)
          Bron presented slides from DISPATCH yesterday.
          Problem: want to send large files in email, also attach to events and
          Problem: files keep getting biger
          Current solutions: Google Drive, Mail Drop (iCloud)
          Problems to solve:
          * Upload of large files
          * ownership/responsibility
          * discoverability and embeddability (attachment/inline, virus checking,
          search for attachments)
          * Also privacy issues
          Global ID for attachments needed?
          Ned Freed: Hash of reference object defined in RFC 1864
          Discoverability: Following links from emails is dangerous, hard to know
          what links are attachments, lifetime uncertain, content changes
          John Levine: consider sending pieces and reassemble, ala Usenet. This
          is a problem we need to solve, because users are running into this.
          Neil: prefer pull model rather than push, so users aren't overwhelmed
          by data.
          John: Would also like to write down the threat model.
          Jamey Sharp: Could encrypt the attachment and send a symmetric key in
          the email with the link
          (+digest for integrity).
          Ned: This also allows AS/AV scanning
          Hans-Jörg Happel: Need to standardize URL-based sharing, then apply
          to email
          Ned: If content can't be scanned, enterprises with security concerns
          will not deploy.
          Ned: URL type that wraps existing URL plus hash may already exist. Larry
          Masinter maybe?
          ACTION: Bron to follow up with DISPATCH about large file problem work
          ## Milestone review: 5 min
          Blobs is adopted
          Sieve had some feedback, so is still to be submitted - Dec 2021
          Calendars - now December 2021. Needs examples, etc.
          Blobs - December 2021 if we get implementation experience
          Quotas - status unclear. Has expired. April 2022.
          S/MIME - submit in July (this month!)
          Key management: Adoption in August 2021
          jscontact: December at earliest
          Informational document on guidance: No progress, now April 2022
          ACTION: Bron to update milestones for JMAP WG
          ## Any other business: 15 min
          Jamey Sharp: Any interest in JMAP for RSS?
          John Levine: Watch out for collision between XML and json
          Bron: Generally yes, if you bring it we're interested in considering it,
          but not much RSS experience in this group.  If JMAP can be helpful then
          we're happy to help!

Generated from PyHt script /wg/jmap/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -