One small comment:

Section 9.1, last sentence:  Because RFC8620 has a MUST for transport security (TLS 1.2 or better), this can also be a MUST.

I agree with Warren, I hope calendar management across platforms becomes easier!!!

Thanks to Jean Mahoney for the ART ART Review.

And to the authors for addressing her feedback.

Thank you to Roni Even for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.

Thank you for writing this document (and the clear Shepherd Writeup). 

I subscribe to a whole heap of different calendars, and I'm hoping that this document makes my life / automation better :-)


[Edit: I had filled in the Ballot text box, but forgotten to click to button.... ]

# Éric Vyncke, INT AD, comments for draft-ietf-jmap-calendars-20

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Joris Baum for the shepherd's write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Title

s/JMAP for Calendars/JMAP for Calendar Synchronisation/ ?

## Abstract

The abstract is very short, should the lack of tasks/journal be mentioned ?

## Section 1.4

A graphic showing the relations between the object would be appreciated by the reader.

## Section 1.4.1

Should `uid` be consistently double-quoted throughout the text ?

## Section 1.5.1

`LocalDateTime` relates to which local time? I.e., client or server time zones ? (I am currently in Europe/Brussels, but my server is probably Europe/London or US/San Francisco)

## Section 3

`This SHOULD be true for exactly one participant identity` what are the consequence of bypassing the "SHOULD" ?

## Section 4

I am not an ART person, so I wonder whether `MUST NOT be greater than 255 octets in size when encoded as UTF-8` also applies for plain ASCII (which is a subset of UTF-8 of course).

Should there be a normative reference to `CSS Color Module` (it does not appear in my HTML rendering).

## Section 5.8

`the server MUST set the following properties to an appropriate value` should the 'appropriate value' be specified in the document ?

## Section 5.10

Is there any constraint (e.g., local/global uniqueness) on "id" in `a separate id will be returned for each instance` ?

## Section 5.10.1

In `Text should be matched in a case-insensitive manner` should it also be i18n sensitive (e.g., "eric" and "éric" being the same) ?

## Section 9.2

The comma before "DKIM" should probably be removed in `When receiving events via email, DKIM [RFC6376] and S/MIME`

## Section 9.3

While title DoS, it is not really about a DoS attack but more about "operational considerations", i.e., suggest move this section outside of section 9 into a new "operational considerations" section.

# NITS (non-blocking / cosmetic)

## Section 2.2

Suggest to use the same typography for the errors as the rest (i.e., in bold on my rendering)

## Section 5.8.1

Perhaps using a more recent date than `2018-01-08T09:00:00`? :-)

## Section 8.3

What about using aasvg for the "snooze alarm" ?