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?