* 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 (Active WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2017-Mar-16 —  

IETF-112 jmap minutes


minutes-112-jmap-00 minutes

          # JMAP at IETF112
          Agenda bash: No changes
          # Blob
          Bron Gondwana presenting
          Bron introduced latest changes to the Blob draft
          Should 'expires' go away - yes
          Neil Jenkins: Everything else in jmap is case-sensitive, so leans toward
          lower case. Also preferes asHex, doubt anyone will use base32
          Ken Murchison: Do we need asHex?
          Bron: Can ditch it, base64 does everything you need.
          ACTION: Bron will upload a new blob draft, then ask Jim to issue a WGLC.
          # SMIME
          Alexey Melnikov presenting
          Alexey was not available for the JMAP session at last IETF, but lots
          done since then.
          Caching time:
          Neil: does it need to be specified.
          Alexey: would be good to have it be consistent, maybe SHOULD be no
          more than.
          Jim: revocation only happens rarely, but if it does then maybe you want
          to notice quickly!  Checking a CRL every 10 minutes is a lot.  Think a
          day is a good ballpark.
          Alexey: if you have opinions, please send on the mailing list, otherwise
          will change default to 1 day.
          ### IANA registry for smimeStatus?
          Bron: JMAP is designed so you have to opt in to extensions already,
          so you don't need to do either.
          Neil: agree, you need to opt in to the capability, so that's the
          extension point.
          Murray K: think IANA registry might be useful as an index to this.
          If you think that is unlikely, then don't bother.
          Alexey will propose some text, more like option 2 (no registry)
          ### make Email/get property available for query?
          Bron: for sure you don't want to allow Email/query across your entire
          store for "is valid now" if it needs to be caluculated, but at delivery
          time is good.
          Neil agrees.
          ### is "signed" useful if "status at Delivery" is needed?
          Jim: could `signed` mean signed by anybody?
          Alexey: spec says that it has to match from.
          Neil: proposal on slide seems fine.
          ### smimeStatusAtDelivery could go to valid
          Bron: what I want as a user is "should I trust this message", including
          20 years later when the key has expired.
          Barry: semantics of revoked and expired are different.
          Barry: does the CTL have a revocation date on it that can be pre-dated?
          Jim: CRL doesn't usually have entries for certificates that have expired.
          The user experience is terrible if all messages from the past lose
          their trustworthyness.
          Neil: Apple client profiles expire since they were signed with our old
          key when they installed it and that's now expired for example.
          Neil: if it changes, does this mean that the email shows up in
          Email/changes?  It should, if this changes.
          ACTION: Neil to remind Alexey of Email/changes issue with changing
          smime status.
          ACTION: Bron to think of other names for smimeStatusAtDelivery.
          ### just reference existing RFCs?
          Alexey: think it doesn't include "from must match".  Make sure to
          document that.
          ACTION: Alexey will publish a new draft for smime, then ask IESG to
          ## SMIME-ADVANCED (encryption)
          Two new attributes on Email/set.
          Need to control how S/MIME signing is done?
          Something changed in XMLRFC rendering.
          Bron: should we put this in identities?
          Alexey: probably don't want to store the key material on the identity.
          return blobId of decrypted message and let the client do Email/parse on
          it?  Does the client need to ask explicitly?  Maybe have it auto-decrypt
          on Email/get?
          ACTION: Bron to suggest a "decryptBody: true" parameter to Email/get
          for smime-advanced.
          # JMAP Calendars
          Neil Jenkins presenting
          Was talked about at the interim.  We were hoping to have experience by
          this meeting, but haven't yet deployed.
          ACTION: Neil to update jmap-calendars draft based on the feedback from
          previous meetings.
          # JMAP Tasks
          Joris Baum and Hans-Jörg Happel presenting.
          Unlike Email/Calendar/Contacts - there's more difference in tools that
          support tasks.
          Discussion about "what is the goal of JMAP" - e.g. that you need to have
          a Blob store!
          No system supports ALL of JMAP for tasks, so some features may need to
          be optional to get adoption.
          Suggestion: extend with support for extra features.
          ACTION: Joris and Hans-Jörg to continue refining surveys and contacing
          developers/vendors for jmap-tasks.
          Neil: data format is JSCalendar - JMAP Tasks is the server for it.
          Format is easy to extend.  They can register a new property easily.
          Common stuff we should try to register ourselves.
          Neil: Should complex stuff be a separate datatype?  Could require a
          core set of supporter capabilities, and have the server advertise which
          additional bits it supports in the capability.
          Joris: the History thing was already suggested as a generic thing.
          Mike Douglass: don't see anything which isn't applicable to regular
          events.  We want auditing/history.  Think all of these are features that
          we want.
          Bron: agree that the capability object is a great place to show which
          bits are supported (based on a survey of current systems) - it's going
          to be mapping into some internal thing.
          Robert: this 'history' stuff is something that might be useful generally,
          so will work on that.
          ACTION: Robert to work on a document for general way of doing history
          for JMAP objects.
          # jscontact
          Robert Stepanek and Mario Loffredo presenting
          Almost everybody here was at the interim - not much appears to have
          There's a subset of jscontact already implemented in RDAP.
          Naming from unicode -> formatting and sorting mostly, which is out of
          scope thankfully.
          Add an 'nth' property for all components, even if allows more than
          unicode covers with surname.
          ACTION: Robert will contact Unicode and let them know what we're doing
          with jscontact names.
          Pete Resnick: FYI: If some formal liaison stuff needs to happen with
          Unicode, Patrik Fältström is the liaison manager.
          At the interim meeting, we discussed the GENDER property.  We haven't
          yet come up with a solution for this.  Is there any discussion across
          the IETF?
          * In some languages, the gender changes syntax.
          * VCARD has Gender and Sexual Identity.
          Unicode also has this as an open issue.
          TODO: implemenation experience and deal with these issues before last
          # IMAP Partial
          Alexey Melnikov speaking
          No EXTRA group, so came here for questions!
          Extend SEARCH and FETCH to allow "fetch last N messages".
          Ken: did we already try this with "VIEW"?
          Partial is easier to implement.  View tried to do too much.  Alexey will
          look and see if there's anything work keeping from it though.
          ACTION: Bron will call for adoption in the EXTRA working group for
          # AOB
          Blob stuff - it's an issue that many might need to deal with, but can
          do it.
          * Ken on blob stuff - uploaded a new version of the sieve draft with
          an example of how to use Blob/get to fetch script content in a single
          round trip.
          This is also feedback on implementation experience.  Could be useful for
          many sieve servers who don't want to expose via Managesieve.  Adds some
          challenges for people who have rules on a local drive.
          Bron: with Email/get you can fetch the bodyValues as well - maybe we
          could also let you fetch.
          ACTION: Bron and Ken to re-visit inline options for sieve scripts in
          Discussion of sieve an mapping names of rules into and out of script.
          * Horde has names for the rules which are displayed in the UI.
          Ken: could we even manage this in sieve?
          HJ: technically these are sieve scripts.
          Bron: demonstrated how the Fastmail system works.
          This is an issue if we try to make these things exposed via managesieve
          or similar.
          Practical problem of doing JMAP for sieve where we need a way to know
          how to interpret the rule from the backend, so we can apply parsing logic.
          Can use JMAP capabilities to tell which implementation is on the backend,
          BUT - need to follow up in extra.
          ACTION: Bron and Alexey to reply on the EXTRA mailing list.
          # Milestones
          SMIME advanced is adopted.
          JMAP Addressbooks - after jscontact to WGLC, so... April 2022.
          Maybe March for sieve.
          QUOTA - maybe after EXTRA quota is done - Alexey will look.

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