Subject: [Jmap] Handling of unknown properties in /get properties section

From: "Matthew Horsfall (alh)" <[email-masked]>
Date: Thu, 1 Mar 2018 10:14:33 -0500

How should unknown properties that the client hands in to a /get call
be handled?

The spec https://github.com/jmapio/jmap/blob/master/spec/jmap/api.mdown#get
says:

  properties: String[]|null If supplied, only the properties listed in
the array are returned for
  each Foo object. If null, all properties of the object are returned.
The id of the object is
  always returned, even if not explicitly requested.

Later, in the Security section:
https://github.com/jmapio/jmap/blob/master/spec/jmap/api.mdown#security
:

  As always, the server must be strict about data received from the
client. Arguments
  need to be checked for validity; a malicious user could attempt to
find an exploit through
  the API. In case of invalid arguments (unknown/insufficient/wrong
type for data etc.) the
  method MUST return an invalidArguments error and terminate.

To me this seems to say that:

  [["Mailboxes/get", {
    "ids": [ "m1" ],
    "properties": [ "name", "oops" ],
  }, "0"]]

should return invalidArguments because "oops" is unknown.

This would help consumers of the API find bugs in their code if they
typed "parentid" instead
of "parentId", for example.

-- Matthew Horsfall (alh)

---

From: Neil Jenkins <[email-masked]>
Date: Fri, 02 Mar 2018 13:47:17 +1100

On Fri, 2 Mar 2018, at 2:14 AM, Matthew Horsfall (alh) wrote:
> To me this seems to say that:…
> …should return invalidArguments because "oops" is unknown.

There are two options I think: you either silently ignore or reject with
invalidArguments error as you say. Given you have to opt-in to any
extensions you are using, the client should always know what properties
it can fetch, so I think the error seems the better option as it will
help developers not waste hours on bugs caused by small typos.
Unless anyone disagrees, I'll clarify this in the spec.

Neil.

---

From: Brad Kowalczyk <[email-masked]>
Date: Fri, 2 Mar 2018 15:10:35 +1100

On 02/03/18 13:47, Neil Jenkins wrote:

> There are two options I think: you either silently ignore or reject 
> with invalidArguments error as you say. Given you have to opt-in to 
> any extensions you are using, the client should always know what 
> properties it can fetch, so I think the error seems the better option 
> as it will help developers not waste hours on bugs caused by small typos.
>
> Unless anyone disagrees, I'll clarify this in the spec
>
> Neil.
>

I also prefer the invalidArguments error. This is how we currently have 
it implemented in our JMAP server and it's already helped us to 
immediately find those pesky typos when writing client code, preventing 
what could have become a more time wasting issue.

Brad

--

---

From: JFCM <[email-masked]>
Date: Fri, 02 Mar 2018 09:52:33 +0100

On 05:10 02/03/2018, Brad Kowalczyk said:
>This is how we currently have it implemented in our JMAP server and 
>it's already helped us to immediately find those pesky typos when 
>writing client code, preventing what could have become a more time 
>wasting issue.

We use e-mail as an intra-distributed-application vehicle. I think 
JMAP would bring me a lot of new possibilities and hence 
standardisation needs. Therefore we look for running code we could 
use for experimentation. Are there JMAP server open codes available 
we could use ?

jfcm

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 06 Mar 2018 17:51:00 +1100

On Fri, 2 Mar 2018, at 7:52 PM, JFCM wrote:
> Are there JMAP server open codes available we could use ?

The most complete/up-to-date open-source implementations I am currently
aware of are Cyrus[1] (which is a full JMAP/IMAP/CardDAV/CalDAV server)
and a Perl JMAP Proxy[2] (which sits in front of an IMAP/CardDAV/CalDAV
server to provide JMAP; this is currently more designed for testing
rather than production-level use).
Once the spec is finalised sometime in the next few months there will be
a stable target so hopefully we will see more.
Neil.

Links:

  1. https://www.cyrusimap.org/
  2. https://github.com/jmapio/jmap-perl