[Jmap] Éric Vyncke's No Objection on draft-ietf-jmap-calendars-20: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-jmap-calendars-20: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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


# É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" ?