Last Call Review of draft-ietf-jmap-contacts-06
review-ietf-jmap-contacts-06-artart-lc-bray-2024-03-22-00

While I'm not a JMAP expert, I don't see anything wrong with the design.

I have some concerns with the repertoire of Unicode characters allowed, both in
this draft and the related draft-ietf-calext-jscontact.

In section 2. it says that the "name" field "may be any UTF-8 string". Really?
I recommend a look at PRECIS or the (still not adopted)
https://www.ietf.org/archive/id/draft-bray-unichars-07.html to consider some
restriction on the values you might want to use here. As written, it allows the
use of legacy Control Codes and Unicode noncharacters in names, which is almost
certainly incorrect.  Note that the "description" field just says "String" with
no further discussion, a little troubling because I wonder why "name"
emphasizes "any UTF-8 string" but "description" doesn't.

To help understnd this, I took a look at draft-ietf-calext-jscontat and I note
that similar issues apply. I quote 1.6.1 of that document: "Properties having
free-form text values MAY contain any valid sequence of Unicode characters…"
Later in 1.7.2 there is "IANA-registered property names MUST NOT contain
US-ASCII control characters", saying nothing about the Unicode C1 controls and
implying that in non-IANA-registered fields, any Unicode characters, including
control codes and noncharacters, may be used.

In both drafts, while the requirement to encode this data in UTF-8 in theory
should exclude the occurrence of Surrogate code points, in practice these are
observed to occur in otherwise-valid UTF-8 strings, so perhaps that issue
should be addressed.

Finally, I note that neither these drafts nor RFC8620 seem to have discussion
of Unicode-related issues in their Security Considerations. Possibly I just
missed this?