Hi all,

If you're keeping an eye on the JMAP Spec repository[1] over the last
few days, you'll notice there have been a few changes. Here's an outline
of what's new, and what's upcoming:

The main change is that JMAP has now been split into 4 specs: the core
protocol[2], mail[3], contacts[4], and calendars[5]. There are a few
reasons for this:
 * Not all implementors need the different data types. It's easier (and
   better for compatibility) to be able to say you fully implement  2
   specific specs (say), rather than part of 1 spec.
 * The core + mail parts are probably more stable than the
   contacts/calendars. The intention for the latter too is to use the
   JSON object formats being standardised by the CalConnect[6]
   consortium to represent events and contacts. The event object has
   therefore changed quite a lot over the last few months (but should be
   fairly stable now); the contact object may still need to change.
 * Most of the current implementation activity is focussed on core +
   mail, and we want to be able to get these finalised without having
   to have necessarily finalised the contacts/calendars part due to
   the above.
 * It means future datatypes that may be added in the future are on
   the same level as mail, calendars or contacts rather than second-
   class types.

Because of the split, I've removed the previous versioning mechanism
(which used to be JMAP version + vendor extensions versions). We need
something here, but I'm not sure what the best approach is.
Suggestions welcome!

Here's a quick summary of the other changes that have been made over the
last two weeks (there were also various fixes for minor copy-paste
errors etc.):

 * Information about accounts is now returned with the authentication
   information rather than via a getAccounts call. This feels a more
   logical place for it. The getAccounts method was always a bit odd, as
   it was really related to your authentication, whereas all the other
   data *belongs* to an account.
 * Capabilities are now also returned with the authentication
   information, separately to the accounts. Capabilities belong to the
   server, not the account.
 * The maxChanges argument to getFooUpdates MUST be respected by the
   server. This is so the client is always in control of how much data
   it's going to receive back over the network.
 * A number of changes have been made to ensure the server can
   reasonably restrict the client from overloading it (either
   accidentally or on purpose as a DOS attack), including:
   * A new HTTP error code (413) may be returned by the server if the
     client makes a request that's larger than it wants to process.
   * An error can be returned if an individual method call asks the
     server to fetch too many objects, or make changes to too many
     objects (and the limits can be discovered by the client in the
     server capabilities information).
 * The cannotCalculateChanges error no longer  returns the new state
   string. It's not actually very useful to the client, and it might be
   hard for some servers to calculate.

 * Servers SHOULD now disallow mailboxes with duplicate names at the
   same level. This was for compatibility with the requirements on most
   existing servers.
 * A cannotDoFilter error may now be returned if the client sends the
   server a message list request with a filter that's too complex, or
   can't be processed for whatever reason.
 * The client must now always specify the sort directions in a message
   list. The implicit "descending" is surprising to some implementors,
   and the JMAP philosophy is generally to be explicit. Saving a few
   bytes here is negligible.

Oh yeh, and the final change: because it's not just about mail and
hasn't been for some time, JMAP now stands for *JSON Meta Application
Protocol*. :)




  1. https://github.com/jmapio/jmap
  2. http://jmap.io/spec-core.html
  3. http://jmap.io/spec-mail.html
  4. http://jmap.io/spec-contacts.html
  5. http://jmap.io/spec-calendars.html
  6. http://calconnect.org

You received this message because you are subscribed to the Google Groups 
"JMAP" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jmap-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to jmap-discuss@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to