draft-ietf-jmap-core: need to define minimum allowed maxCallsInRequest value

[aamelnikov]

In Section 2.2.2:

• maxCallsInRequest: "Number" The maximum number of method
  calls the server will accept in a single request to the API
  endpoint.

For interoperability the document should define the minimum value that has to be supported, which is likely to be >1.

[neilj]

A client could function with maxCallsInRequest = 1, it just couldn't make as efficient use of the network (no batching stuff together).

@aamelnikov Do you still think we should require a minimum >1 here? If so, what value is reasonable (it's going to be arbitrary either way). I'm inclined not to specify something here, although perhaps put a recommendation in the Deployment Considerations section, as it affects efficiency?

[dehart]

One thing to keep in mind is that if the maxCallsInRequest is set to 1 the client is not able to use the ResultReference object so >1 is definitely recommended

[arnt]

Reasoning: It should not be 1, because ResultReference is at least arguably useful. It also should not be so large as to allow an accidental or wilful denial of service. The common use cases seem to be in the single digits, the DoS start not below three, so a minimum maximum should have two digits, somewhere in the zone between what's considered useful and what may be wee bit DoSy.

Dijkstra's law specifies that if you have to have an arbitrary numeric limit, you should choose a power of two or that minus 1, because people will assume there's some deep binary logic that they don't understand behind the choice and complain less. 32 is a compliant two-digit number. As is 64. Shrug.

[cjnewman]

+1 for Arnt's reasoning and suggestion.

Assurance that maxCallsInRequest > 1 so ResultReference is useful is important so clients only need to implement one code path when using ResultReference. One of the common flawed arguments behind various optional IMAP behaviors was that clients could work around them. Well, yes they can but in practice most clients either avoid features with optional behaviors because implementing and testing multiple code paths to perform the same function is harms productivity and increases risk or they only implement one of the two code paths and break with servers with the behavior they don't test. Making it easier for clients is a key design goal difference between IMAP and JMAP. Either set a minimum maxCallsInRequest that's necessary for ResultReference to work, or remove ResultReference from the base spec. I think the former is the better option.

[neilj]

Works for me. Unless I get any significant objections, I'll go with 32.