Sieve support

[Matthieu Baechler]

Hi,

Did you already considered adding sieve support to JMAP to avoid the use of "managed sieve" protocol ?
We (at Linagora) plan to build our webmail on top of JMAP but the first iteration needs vacation support and we don't feel like using another protocol to do this.

Cheers,

--
Matthieu Baechler

[Neil Jenkins]

Rules and vacation response support have been mentioned by a few vendors now as something they would like to see in the JMAP specification. I was planning to look at this this week; the tricky bit is finding something that's generic enough to be implementable in a wide variety of back ends (not just those using sieve) while still being expressive enough to be useful.

 

Do you have more specifics on what types of rules and/or vacation response features you would like to build into your webmail? More information on the various requirements different vendors have would be useful in helping define this.

 

Cheers,

 

Neil.

[D David]

Hi Neil,

As a first step, we need at least:

* Ability to read a stored vacation message. This would map to the GETSCRIPT managesieve command

* Ability to define a vacation message. This would map to the PUTSCRIPT managesieve command

* Ability do enable the vacation message.

* Ability to disable the vcation message. These two would map to the SETACTIVE command.

Cheers,

David

[Neil Jenkins]

So as a first-pass, I've defined a really simple object that represents features all vacation responses have: on/off + a text response. This could easily be extended with properties to describe start/end dates, html bodies etc., but I'm not sure of the best way to do this since these features may not be available on every service, and we want something that can be widely implemented. Thoughts on this welcome!

 

The other unusual thing compared to existing API methods is that the VacationResponse object is a singleton: there's always exactly one object of this type in an account. This is a pattern that may well be reused for other settings-style APIs in the future. I've made the format of the get/set consistent with the standard used for multiple items, since this should be simpler for most clients to deal with (they can use the same code path as everything else). I've defined that the object MUST have an id of "singleton" since there can only ever be one.

 

Anyway, here's the API I'm proposing. I'm posting here first for comments and feedback before adding to the spec proper. If you're interested in using this, please take a look and let me know what you think!

 

Cheers,

 

Neil.

 

----

Vacation Response

The VacationResponse object represents the state of vacation-response related settings for an account. It has the following properties:

• id: String The id of the object. This property is immutable. There is only ever one vacation response object, and its id is "singleton".
• isEnabled Boolean Is the vacation response enabled?
• textBody: String The message to send in response to messages when the vacation response is enabled.

getVacationResponse

There MUST only be exactly one VacationResponse object in an account. It MUST have the id "singleton".

To fetch the vacation response object, make a call to getVacationResponse. It takes the following argument:

• accountId: String|null The Account to get the vacation response for. If null, the primary account is used.

The response to getVacationResponse is called vacationResponse. It has the following arguments:

• accountId: String The id of the account used for the call.
• list: VacationResponse[] An array containing the single VacationResponse object.

setVacationResponse

Sets properties on the vacation response object. It takes the following arguments:

• accountId: String|null The Account to set the vacation response for. If null, the primary account is used.
• update: String[ContactGroup]|null A map of id (“singleton”) to the VacationResponse object with new values for the properties you wish to change. The object may omit any property; only properties that have changed need be included.

If any of the properties in the update are invalid (immutable, wrong type), the server MUST reject the update with a SetError of type invalidProperties. The SetError object SHOULD contain a property called properties of type String[] that lists all the properties that were invalid. The object MAY also contain a description property of type String with a user-friendly description of the problems.

The response is called vacationResponseSet. It has the following arguments:

• updated: String[] Contains the single id (“singleton”) if the vacation response was successfully updated.
• notUpdated: String[SetError] A map of id (“singleton”) to a SetError object if the update failed.

A SetError object has the following properties:

• type: String The type of error.
• description: String|null A description of the error to display to the user.

The following errors may be returned instead of the vacationResponseSet response:

invalidArguments: Returned if one of the arguments is of the wrong type, or otherwise invalid. A description property MAY be present on the response object to help debug with an explanation of what the problem was.