Re: [Jmap] I-D Action: draft-ietf-jmap-jscontact-04.txt

Neil Jenkins <> Wed, 10 March 2021 05:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 188D03A1278 for <>; Tue, 9 Mar 2021 21:02:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=jniYXWfu; dkim=pass (2048-bit key) header.b=QVh/YJeN
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Kxw08cgm_24 for <>; Tue, 9 Mar 2021 21:02:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3EFB13A1275 for <>; Tue, 9 Mar 2021 21:02:20 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 3AF675C00AB for <>; Wed, 10 Mar 2021 00:02:19 -0500 (EST)
Received: from imap41 ([]) by compute3.internal (MEProxy); Wed, 10 Mar 2021 00:02:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=4VVj3Q0 5QQJI1jKymP6cDmUzvNURwYVX4wK/v/niL78=; b=jniYXWfuuJ/XcJzSBrjOzZZ MWd5WmENIEeadJgmI1KJ72nGRVPZObOvyX68cO502uibC/Bp/zELc7Qkiq7Rwi9R WDOqKK2HKeHinD0Tc5A4uJiXRVtCXpTAYRtNMH3yGM4Rj1awFDInvUITbYf+Y7OC ISmeS6AGkmMh7yolbOLA+vUgdsVnsNuYZZCKKztUL84uF+k5nhv4xg6Y85o3XcHR B1YDE6SxUee7Myf8daaNlVdpyPJddsTk9neyIzkQB8w0VtPgoPoLonVWuYvQM/QT hDNM7YILwo4RDfdBqjyMvorVmVQCNt/4xVXqHjApxEQ0zDwFAQV2DpNF7mRKcnA= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4VVj3Q 05QQJI1jKymP6cDmUzvNURwYVX4wK/v/niL78=; b=QVh/YJeNpKJlcgeT4jquKb UElKnKFzJEeicf0TVEpdBiC/MEHhDdP0nZnuChiTjg8/naxb97tA+4TO33DAB3Mv fNxc7278P6zptDvv1zfURPePQHky4tyOm0Gzzs+4Zkg6viJYtkwlBAXtJs5Hk5z3 A2dCgqP6qIoQyzpUHFHcVcKA3+m7VuRjPr5RoiqZrFOBpb50UPmUy4nwGDbwVRaC EY0ONgDJNgOpkAhxD1JV2tH0h1wORYRZgUvKCpbBDnQXlrssUJrX9vRUGAf3mutd VY8adMqtBla04S6BLVVUbGSXrai+IgdpvO+5z66jSXMHg3dL1pHw+3Os/KbqUXJA ==
X-ME-Sender: <xms:2lJIYAzG5V64_h4K5dvYIhCWsKRBQs0sX15FWuVCy_887kZ__8FOtg> <xme:2lJIYEQ3yhqcuLZf0RFrbGAkoB4RWNBgJ8AGUIO6a8V6B8Ln5JbWY0HC2-KiB5_7b tRVhsMWrjd1-A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddujedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeevvdetvdduleekhfeghfetfeettdelhfehfeevffevleek uddtudffieevjeevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:2lJIYCX40PfI2dA2_TL8oUmYClZGcyLZjOjQ6BPZy8HeSed0SaAmSQ> <xmx:2lJIYOhR6l9rKO00_xK5__eFuB3CLY4jiWjbnjVnAOo2q_YR6NZhpg> <xmx:2lJIYCAUf0qa1yYfWESO51xKEY5XhTASYyVnxASql9b9rjT2vo2CFQ> <xmx:21JIYFNmrJGRon-Br1Zq1KMPK8Q5ucMKz798x9Lp1r92JIoqqRfrPw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67D78260005C; Wed, 10 Mar 2021 00:02:18 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Wed, 10 Mar 2021 16:02:18 +1100
From: "Neil Jenkins" <>
To: "IETF JMAP Mailing List" <>
Content-Type: multipart/alternative; boundary=2bf282877639480aae1d375add98c8d8
Archived-At: <>
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-jscontact-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Mar 2021 05:02:22 -0000

I've read through this draft and I have a few comments:
 * The metadata section is missing a `created` timestamp. Also the type of this and updated should be `UTCDate`, not just String (this is more a notational comment, but I would recommend using exactly the same type system as JSCalendar).
 * The `fullName` description doesn't make it clear to me what its purpose is. Is it always the same as `name` joined together by spaces? (Presumably not, as that wouldn't be very useful.) Or is it to provide alternative versions of the name in different character sets for internationalisation? (It's a LocalizedString type so can have multiple variants, so maybe.) Or is to provide the preferred name to call someone? (Not at all what the description says, but perhaps useful.)
 * The idea of the `name` field is its an array of tagged components, so you can accurately represent names in locales where, for example, the family name comes first when written out. That's great, however I think `nickname` is not the same as one of these components and should be a separate field in JSContact; a nickname is not a subpart of a name, it's an alternate one.
 * I found the description of the `roles` property hard to understand; I don't really get it.
 * The value for `Resources` in the `emails` field should just be the email address. The spec currently says it can be this or a mailto: URI, but there's no reason to allow an alternate encoding of exactly the same data and the escaping/unescaping of characters to transform to/from a mailto URI is a pain to get right and likely to lead to incompatibilities.
 * For `phones` there's a kind of similar thing, although I do see the idea behind URIs here with `sip:` vs `tel:`. I wonder if uri should just be an optional extra property instead rather than the value being *either* a URI or the phone number.
 * The taxonomy of `type` doesn't feel quite right for phones: if I have a mobile (cell) phone number, is that "voice"? But it also accepts SMS. But type is single valued, so what type should it be?
 * I don't think the `labels` property of a Resource should be multi-valued (it should just be `label`, like it is in the `Address` data type). While there's always a tension here between allowing expressivity and keeping it easier to use, I think this veers too much into the former. It's not clear how you would be supposed to deal with multiple values; as they are just free form text, a single one should be sufficient.
 * I think the `Address` type needs thinking about more. The street/locality/region properties are not sufficient to accurately express many global addresses. An array of tagged components like in `name` is probably a better approach, allowing many more options for accurately describing the parts of the address without making it too unwieldy to use.
 * As with name, I think the purpose of `fullAddress` would need to be detailed more (if it is indeed needed at all).
 * I think the `notes` field should be single-valued rather than an array, for the same reason as with `labels`.