Subject: [Jmap] Foo/get "changes" result argument is unsafe in result references

From: Ricardo Signes <[email-masked]>
Date: Fri, 9 Mar 2018 13:33:48 -0500

I believe that we need to change the spec for Foo/changes.

I have filed this as https://github.com/jmapio/jmap/issues/179

> changed: String[]|null An array of ids for records which have been created or
> modified but not destroyed since the oldState, or null if none.

Null should be illegal.  Here's why:

    [ "Foo/changes", { "sinceState": "123" }, "a" ]
    [ "Foo/get",
      {
        "#ids": { "resultOf": "a", "name": "Email/changes", "path":"/changed" }
      },
      "b"
    ]

There are no changes to Foo since 123, so the response is:

    [ "Foo/changes", { "changes": null }, "a" ]

When the server evaluates the second sentence, it is effectively:

    [ "Foo/get", { "ids": null }, "b" ]

… rather than {"ids":[]}, which is semantically quite distinct!  It attempts to
fetch all Foos, which is wrong, and might lead to a resultTooLarge or worse.
Obvious options:

a. require Foo/changes's changes result argument to be an Array
b. add defaultIfMissing to result references

(a) seems simplest.

We should also consider whether any other variable-type return values have the
same type problems.

-- 
rjbs

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 10 Mar 2018 14:07:45 +1100

I agree with (a).  A query which returns no results should return the
empty array so the return type is the same across all queries.

On Sat, 10 Mar 2018, at 05:33, Ricardo Signes wrote:
>> changed: String[]|null An array of ids for records which have been
>> created or>> modified but not destroyed since the oldState, or null if none.
> 
>         "#ids": { "resultOf": "a", "name": "Email/changes",
>         "path":"/changed" }>       },
>       "b"
>     ]
> 
> … rather than {"ids":[]}, which is semantically quite distinct!  It
> attempts to> fetch all Foos, which is wrong, and might lead to a resultTooLarge
> or worse.> Obvious options:
> 
> We should also consider whether any other variable-type return values
> have the> same type problems.
> 
> --
> rjbs
> 
> _________________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]