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

Robert Stepanek <rsto@fastmailteam.com> Thu, 11 March 2021 09:58 UTC

Return-Path: <rsto@fastmailteam.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3892F3A1791 for <jmap@ietfa.amsl.com>; Thu, 11 Mar 2021 01:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=T5rZ6Xzd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GKmej4m6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_AgzkfGY8qG for <jmap@ietfa.amsl.com>; Thu, 11 Mar 2021 01:58:32 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813853A178A for <jmap@ietf.org>; Thu, 11 Mar 2021 01:58:32 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BC8675C010C for <jmap@ietf.org>; Thu, 11 Mar 2021 04:58:31 -0500 (EST)
Received: from imap41 ([10.202.2.91]) by compute4.internal (MEProxy); Thu, 11 Mar 2021 04:58:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=wBhwG0y K3ImAbLF6K5YrSPYaoKiDbjheznu8SlEgYjY=; b=T5rZ6Xzd0kG2KPXwXV0ytUd ooMlCzGxA4l+B8XCmean9ghgveFoXkRUoA3y3sx06tV68160QYccq+UtNQdh3NKy /UhJ7ozBJ1khXhUqLLn/oyEAOMs69EPRBsa+Sw6LDhpsICyM3LkdiNwYOztQ5oFh ZoRFCQLeIaVDmpu1dquD7bZao4dbgP5F7bq3uEzLnE9c4WCOSibtE7mylM2PQDKX 7MClB6qncp2ZL/+ZTsYRrzaup+ugo9PhuHA+vYumBcn2GlOx2CAldxDal+s0pJqg ZfoWWjnPG5NlWoGm6vYrZOSlos2gf/cNkgAK3kpoktJy0KveXSUkqZcp34Qn7dw= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=wBhwG0 yK3ImAbLF6K5YrSPYaoKiDbjheznu8SlEgYjY=; b=GKmej4m6RXFQLRMzljQZbv 4s79f7gyrcrRbsW01c2RMuzMBinc8Qjh+bLA6kBC1p2eP1eDBAcPx48fGgwBIC0N PbbNc+JhuSJKTyXbpVeCCUbpyX0beo0D7kInnWtOWLPIEV6zDruCEClWncr/27JH AM4+geB0WWpER+YutvH88ZyzgV+tCw6CMmKgMkJRExcId660BBCkOpnUsTKHbLv3 tK1msD5VbIeZCylLC8D13cMeCLolaJ8LhxvwHqjX2S2Dmka+wx64O6jb+ThV5Gca sRPakbAsOsUVe/GwTV/RCiUHia0ogQ5Hh4TlH0Tza94MHuRxyq2ubEmyRxbS+G4g ==
X-ME-Sender: <xms:xulJYKCoR17pMLDmrmkq6iJYNvSLN4jhzLKWC5ATTreV0bzmhw8MEQ> <xme:xulJYEioeAEdKQjU56O7qklSIAImkuXFs53H-1KojYm_VxqkWO1co7vAywde2j1yD TjIxanfitIRAQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvtddguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepieeiffehle euiefhheefveegjefgkeelleefgefhgeehfffhieetvefgheduvdejnecuffhomhgrihhn pehivghtfhdrohhrghdpfihikhhiphgvughirgdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgv rghmrdgtohhm
X-ME-Proxy: <xmx:xulJYNmuUJGFzKGu5d8pKfgEjyMKYW3t6ZwUBCNHzfU7M1PaEWt52w> <xmx:xulJYIzUYP_PcGwYuA3SVVpoE7T-BH8u6XxsOKF8B7qw4e15MA1ePw> <xmx:xulJYPQLhFDwiN_1CI76-bX8E7endu0DL3D4yx21mCLpkyh-5wgQzw> <xmx:x-lJYGeHaPTtLzJ4DYzg73yFFeFFB_80JcglG9735mgeSfee7aDDRw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 76325260005D; Thu, 11 Mar 2021 04:58:30 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <623351b9-dd56-4a51-a273-9b565f37aea1@www.fastmail.com>
In-Reply-To: <fb914509-9037-4c5d-9be1-601611d14eee@dogfood.fastmail.com>
References: <161375338059.1324.4641187246320270178@ietfa.amsl.com> <fb914509-9037-4c5d-9be1-601611d14eee@dogfood.fastmail.com>
Date: Thu, 11 Mar 2021 10:57:51 +0100
From: "Robert Stepanek" <rsto@fastmailteam.com>
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=516ae2b4ecb745b9a2342944d1ff2b86
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/dqk97jAQ6VNsk0e7vSb6lMJQwns>
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-jscontact-04.txt
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 09:58:35 -0000

Hi Neil,

thanks for the feedback.

On Wed, Mar 10, 2021, at 6:02 AM, Neil Jenkins wrote:
> 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).

Agreed.

>  * 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.)

Its purpose is to both allow internationalisation and to preserve the FN property value of a VCARD value. The latter is especially important in case the VCARD does not also contain a N property.

>  * 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.

Agreed, nickname(s) should be a separate field.

>  * I found the description of the `roles` property hard to understand; I don't really get it.

We defined this property to make sure that we can cover the existing VCARD format, including the ROLE property. But now that I look at it, even the definition of the ROLE property isn't that clear to me (https://tools.ietf.org/html/rfc6350#section-6.6.2). It would interesting to understand how widely used this property is, and how people decide if to use TITLE or ROLE.

On a side-note it also bugs me that a jobTitle has no (optional) relation to an organization in the same card object. I think we should change that.

>  * 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.

Just be clear, you mean we should get rid of the mailto: URI, right? This makes sense to me as we want to keep any email addressee name in addition to the address itself. Rather than using a String, we could reuse the EmailAddress type as defined in the JMAP Mail spec.

>  * 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.

I'd say in that case only allowing an URI is the better choice. In contrast to emails, we don't lose any information by restricting the type to a URI.

>  * 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?

Agreed, it makes sense for phones to have multiple types (or however one might call it). Both this and the idea to have an EmailAddress typed value for emails suggests that the generic Resource object is too simplistic. We might better use a specific type for each of the "phones", "email", .. properties.

>  * 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.

Works for me.

>  * 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.

We had discussed internally if to use tagged components also for addresses, and we will also raise this discussion item at IETF 110 today. I initially vouched for tagged components, but now I am not as convinced anymore. 

The Wikipedia article on address formats suggests that the current scheme covers the majority of addresses in use globally (https://en.wikipedia.org/wiki/Address#Address_format). In addition, we cross-checked with the address APIs of services such as such as Google, Microsoft and Baidu, and came to realize that we can cover all of their address formats (except that we'll need to separate out the street number from the street field).

That being said, the current scheme might not be enough. It would be great to see examples of addresses it can't cover. Also, we are not experts on address schemes. I think we had a contact to a major delivery service once at CalConnect. I'll try to reach out to him. We are also aware of the ISO group efforts for a new address standard, but their approach seems to add considerably more complexity. It might be too much for a Contacts API. I think they will present at next CalConnect, so let's see what we can learn there.

>  * As with name, I think the purpose of `fullAddress` would need to be detailed more (if it is indeed needed at all).

We'll make clear that its main purpose it to allow for localized addresses.

>  * I think the `notes` field should be single-valued rather than an array, for the same reason as with `labels`.

Works for me.

Cheers,
Robert