Update and status on JMAP spec

[Neil Jenkins]

Hi all,

If you're keeping an eye on the JMAP Spec repository 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, mail, contacts, and calendars. 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 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.):

Core

• 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.
  

Mail

• 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. :)

Cheers,

Neil.