Subject: Re: [Jmap] JMAP Core

From: Neil Jenkins <[email-masked]>
Date: Fri, 12 Jan 2018 11:30:26 +1100

On Fri, 22 Dec 2017, at 10:43 PM, Alexey Melnikov wrote:
> I think value 1 is rather limiting and will prevent the protocol from
> being useful, because clients might have to potentially have multiple
> code paths to cope with maxCallsInRequest == 1 and more capable
> servers.
Based on the feedback in #86[1], I went with a minimum value of 32.
Based on our experience using the protocol, 16 would be fine for normal
usage, if you think 32 is too high?
> *#89*[2]* Do we need a registry of error types? *
> 
> Yes, I think we need to have a registry. I find IANA registries to be
> useful for implementing things and finding out what was already
> registered.
Hmm, the feedback I've had off-list is this is probably not necessary. I
have gone through RFC 5530[3] to make sure any relevant errors are
covered in the spec, and the consensus seemed to be that entirely new
classes of error were unlikely to appear. It greatly helps client
authors to know the complete set of errors that may be returned to
ensure everything is handled in an appropriate manner; this should make
that easier.
>> How do I go about creating a registry presuming we decide we do
>> need one?> I can suggest some text on this. I think the main thing to decide
> first is the registration policy. Do we want some kind of expert
> review for them?
If we do decide to create a registry, I think some kind of expert review
is reasonable, especially if it's meant to be a new generally applicable
error that any method could return.
Neil.

Links:

  1. https://github.com/jmapio/jmap/issues/86
  2. https://github.com/jmapio/jmap/issues/89
  3. https://tools.ietf.org/html/rfc5530

---

From: "Chris Newman" <[email-masked]>
Date: Thu, 11 Jan 2018 17:25:03 -0800

> ensure everything is handled in an appropriate manner; this should 

Errors are complex because there are conflicting goals. It's desirable 
to:

* provide machine readable codes to distinguish scenarios where a client 
may be interested in having a different behavior
* provide human readable text for sub-scenarios of a single machine 
readable code to help resolve problems faster
* provide a way to add new machine readable codes in the future without 
breaking clients, but we prefer not to add codes too often
* provide as complete a list as possible of machine readable codes
* provide examples of fault scenarios where clients need different 
behaviors to avoid support calls (e.g., bad user/password vs. service 
temporarily unavailable)
* avoid exposing data over protocol with privacy/security implications 
unless those implications are trumped by the cost of a support call

As long as clients MUST support error codes not defined in the base spec 
and the behavior for that scenario is documented, I'm ok with deferring 
registry creation to the first time an error code needs to be added. 
However, it's not that expensive to create an expert-review registry (a 
paragraph of text plus registry template) so doing it sooner may remove 
the need to publish an extra RFC in the future.

> error that any method could return.

My experience is that expert review works best for this sort of 
registry.

		- Chris