Subject: [Jmap] Ben Campbell's No Objection on draft-ietf-jmap-core-14: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 19:18:52 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-jmap-core-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-core/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the huge amount of work this involved.

I support Alissa's discuss point concerning device ids. Otherwise, I have a few
minor comments:

§1.1: Is there a reason not to use the updated boilerplate from RFC 8174?

§1.6.2:
- 2nd paragraph:  I think this means that any given piece of data belongs to
one account. But it could be read (nonsensically) to mean that one account owns
all the data.

§1.6.3: "The id of a record is immutable, and normally assigned by the
server.":  This seems to conflict with section 1. 2, which says all record lDs
are assigned by the server. (I take "normally" to mean "most of the time, but
sometimes not"

§1.7: "Support for common HTTP mechanisms such as redirection
and caching are assumed.":  I'm not sure what this means. Are they *required*
to be supported?

§2:
- "If the specification
includes new object type definitions, the server MUST include
it in the _hasDataFor_ array if, and only if, the user may use
those data types with this account."
 This would be more clear in the form of "MUST include... and MUST NOT..."

- "Servers MAY advertise vendor-specific JMAP
extensions, as described in section 1.7. To avoid conflict, the
identifiers for these MUST be a URL with a domain owned by the
vendor."
I think the cross reference should be to section 1.8. Also, the MUST is
redundant to normative text in that section.

§5:
- "Not all types may have all methods. ": Is that the same as saying some types
may not have all methods?  (It could be read to say not all types are allowed
to have all methods.)

---

From: "Neil Jenkins" <[email-masked]>
Date: Sun, 24 Feb 2019 23:30:11 -0500

Thanks for the detailed feedback.

> §1.1: Is there a reason not to use the updated boilerplate from RFC 8174?

No; this has now been updated.

> one account. But it could be read (nonsensically) to mean that one account owns

Yes, this could be clearer. looking at this again I think the sentence is redundant given the previous one, so I'll just cut it.

> are assigned by the server. (I take "normally" to mean "most of the time, but

I have removed the word "normally" here.

> and caching are assumed.": I'm not sure what this means. Are they *required*

This was from an early draft <https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-00> of the "Specifying the Use of HTTP" section of BCP56bis <https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/>. I see this has now been updated and no longer suggests using text like this; I will just remove it.

> This would be more clear in the form of "MUST include... and MUST NOT..."

OK, I've rewritten this to:

*If the specification includes new object type definitions, the server MUST include it in the *hasDataFor* array if the user may use those data types with this account. It MUST NOT include it in the *hasDataFor* array if the user cannot use those data types with this account.*

> I think the cross reference should be to section 1.8. 

Thanks, fixed.

> Also, the MUST is redundant to normative text in that section.

Redundant, but consistent so I don't think it hurts; someone scanning the document rather than reading in detail may not read both places so I think it's good to make this very clear.

> may not have all methods? (It could be read to say not all types are allowed

I agree this could be clearer; I have rewritten this to: *Some types may not have all these methods.*

Cheers,
Neil.