[Last-Call] Artart last call review of draft-ietf-jmap-contacts-06

Tim Bray via Datatracker <noreply@ietf.org> Fri, 22 March 2024 15:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7494C180B6E; Fri, 22 Mar 2024 08:59:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Tim Bray via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-jmap-contacts.all@ietf.org, jmap@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171112316193.8644.5801107423421446407@ietfa.amsl.com>
Reply-To: Tim Bray <tbray@textuality.com>
Date: Fri, 22 Mar 2024 08:59:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/uW49z97qbLya8yOWpOcD-27Z5Z8>
Subject: [Last-Call] Artart last call review of draft-ietf-jmap-contacts-06
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 15:59:22 -0000

Reviewer: Tim Bray
Review result: Ready with Issues

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?