Skip to main content

Last Call Review of draft-ietf-jmap-contacts-06

Request Review of draft-ietf-jmap-contacts
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2024-04-04
Requested 2024-03-20
Authors Neil Jenkins
I-D last updated 2024-03-22
Completed reviews Secdir Last Call review of -06 by Shivan Kaul Sahib (diff)
Artart Telechat review of -09 by Tim Bray
Opsdir Last Call review of -06 by Linda Dunbar (diff)
Artart Last Call review of -06 by Tim Bray (diff)
Genart Last Call review of -06 by Meral Shirazipour (diff)
Assignment Reviewer Tim Bray
State Completed
Request Last Call review on draft-ietf-jmap-contacts by ART Area Review Team Assigned
Posted at
Reviewed revision 06 (document currently at 09)
Result Ready w/issues
Completed 2024-03-22
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) 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?