From nobody Mon Mar 1 22:22:40 2021 Return-Path: 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 0B2B03A26B7 for ; Mon, 1 Mar 2021 22:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FfvlfIQm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oIONxqs5 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 V1TcmGBAIwLr for ; Mon, 1 Mar 2021 22:22:37 -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 A0B2E3A26B6 for ; Mon, 1 Mar 2021 22:22:37 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 288A85C0140 for ; Tue, 2 Mar 2021 01:22:36 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 02 Mar 2021 01:22:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=Rtwsu7oWLC1dqyxqdUjnmInHU7eAzSwRFB5SsV+ +01g=; b=FfvlfIQmbDIZ6+AP/WwljRfV6BTyuhZo0VyMEYgq8HAnc8PmaWNTdS/ qJ/La83UsK/A9y4swItP7cyRppf2lEIVJqr+hhy6XuysFG+r5V6eKMU1UZbbB49E APATyLBRh9Z1zKY3I4rU6JiBAYlGBmCqbSk+vO2N1Y++Zq4/5m7whF9UpIEbafrg /HUxiVwl2LvTlEfVBMQUzN6XENDW77fif5fx4TfxQsWiUQhKyPGhAzkfqvvIjohU CA/3N1iQ4RZtarTAD/AZni7KrW6tivdrhgrFV+yPxlVkZBg6eLInk0jgQzQQ0cCT 34FIXyQh1lh2DpDAhIrfUGpt3jUZSNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Rtwsu7oWLC1dqyxqdUjnmInHU7eAz SwRFB5SsV++01g=; b=oIONxqs5mSi2vlUKENfniH/z9g7ZgbYmGBiiDosucw7TZ EBPMrNTHS4/n7TWPVSHjYno3HDWUugHMsSioHEP65M7NgUr8rOBWMpeCvF8Sz/ub IBtnabkmjEaoLFsnzZjlQC5364jHoCCZbKRekLBJFAmqySfqAsp4pmhQn1Not6v3 +ancv2ePneiaAcIDLC61ZeHfYfz/eIgZkId0xQBENZpQoj9lGsY8edJvQQ9nE46A TiSoIhYAVI8QXDESFr2Pxm+jhdpTNjL2h7YqMLbo+ndGuAHg5XxyaOj7oZ2y9c4P rLkei4ci8WW76SSeYeeJz4gXtGwFVE9Ke4vyN15Fg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleelgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihfegie dtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE6FA3605A0; Tue, 2 Mar 2021 01:22:35 -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: <5e3748e4-03c5-43c8-be53-f3f6db072d05@beta.fastmail.com> Date: Tue, 02 Mar 2021 17:22:15 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=d1776a576feb433bbbf42a05e21a612a Archived-At: Subject: [Jmap] Agenda for 110 posted X-BeenThere: jmap@ietf.org 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: Tue, 02 Mar 2021 06:22:39 -0000 --d1776a576feb433bbbf42a05e21a612a Content-Type: text/plain Hi All, I've put up an agenda for our meeting next week. I split it into three main categories. Calendar and related, Contacts and related, Sieve and related. Happy to take any suggestions or alterations to this plan! Cheers, Bron. JMAP session agenda - IETF110 (Prague virtual) === Thursday 2021-03-11 17:00-19:00 Intro and Note Well: 5 min Calendars and related topics: 40 min * draft-ietf-jmap-calendars - 20 min * draft-baum-jmap-tasks - 10 min * draft-jenkins-jmap-sharing - 10 min Contacts and related topics * draft-ietf-jmap-jscontact (+vcard) - 30 min Sieve and related topics * draft-gondwana-jmap-blob - 10 min * draft-ietf-jmap-sieve - 10 min Any other business: 20 min Milestone review: 5 min -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d1776a576feb433bbbf42a05e21a612a Content-Type: text/html
Hi All,

I've put up an agenda for our meeting next week.  I split it into three main categories.  Calendar and related, Contacts and related, Sieve and related.

Happy to take any suggestions or alterations to this plan!

Cheers,

Bron.


JMAP session agenda - IETF110 (Prague virtual)
===

Thursday 2021-03-11 17:00-19:00

Intro and Note Well: 5 min

Calendars and related topics: 40 min

* draft-ietf-jmap-calendars - 20 min
* draft-baum-jmap-tasks - 10 min
* draft-jenkins-jmap-sharing - 10 min

Contacts and related topics

* draft-ietf-jmap-jscontact (+vcard) - 30 min

Sieve and related topics

* draft-gondwana-jmap-blob - 10 min
* draft-ietf-jmap-sieve - 10 min

Any other business: 20 min

Milestone review: 5 min

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--d1776a576feb433bbbf42a05e21a612a-- From nobody Tue Mar 9 21:02:24 2021 Return-Path: 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 188D03A1278 for ; Tue, 9 Mar 2021 21:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jniYXWfu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QVh/YJeN 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 7Kxw08cgm_24 for ; Tue, 9 Mar 2021 21:02:20 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFB13A1275 for ; Tue, 9 Mar 2021 21:02:20 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3AF675C00AB for ; Wed, 10 Mar 2021 00:02:19 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Wed, 10 Mar 2021 00:02:19 -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=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= 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=4VVj3Q 05QQJI1jKymP6cDmUzvNURwYVX4wK/v/niL78=; b=QVh/YJeNpKJlcgeT4jquKb UElKnKFzJEeicf0TVEpdBiC/MEHhDdP0nZnuChiTjg8/naxb97tA+4TO33DAB3Mv fNxc7278P6zptDvv1zfURPePQHky4tyOm0Gzzs+4Zkg6viJYtkwlBAXtJs5Hk5z3 A2dCgqP6qIoQyzpUHFHcVcKA3+m7VuRjPr5RoiqZrFOBpb50UPmUy4nwGDbwVRaC EY0ONgDJNgOpkAhxD1JV2tH0h1wORYRZgUvKCpbBDnQXlrssUJrX9vRUGAf3mutd VY8adMqtBla04S6BLVVUbGSXrai+IgdpvO+5z66jSXMHg3dL1pHw+3Os/KbqUXJA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddujedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeevvdetvdduleekhfeghfetfeettdelhfehfeevffevleek uddtudffieevjeevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67D78260005C; Wed, 10 Mar 2021 00:02:18 -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: In-Reply-To: <161375338059.1324.4641187246320270178@ietfa.amsl.com> References: <161375338059.1324.4641187246320270178@ietfa.amsl.com> 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-BeenThere: jmap@ietf.org 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 --2bf282877639480aae1d375add98c8d8 Content-Type: text/plain 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`. Cheers, Neil. --2bf282877639480aae1d375add98c8d8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I've read throu= gh this draft and I have a few comments:
  • The metadata s= ection is missing a created timestamp. Also the= type of this and updated should be UTCDate, no= t 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 wha= t its purpose is. Is it always the same as name= joined together by spaces? (Presumably not, as that wouldn't be very us= eful.) Or is it to provide alternative versions of the name in different= character sets for internationalisation? (It's a LocalizedString t= ype so can have multiple variants, so maybe.) Or is to provide the prefe= rred name to call someone? (Not at all what the description says, but pe= rhaps useful.)
  • The idea of the name= field is its an array of tagged components, so you can accurately repre= sent names in locales where, for example, the family name comes first wh= en written out. That's great, however I think nickname= is not the same as one of these components and should be a separ= ate field in JSContact; a nickname is not a subpart of a name, it's an a= lternate one.
  • I found the description of the roles property hard to understand; I don't really get it.
    <= /li>
  • 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 t= o 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 d= o 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 o= r the phone number.
  • The taxonomy of type doesn't feel quite right for phones: if I have a mobile (cell) pho= ne 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 su= pposed 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/re= gion properties are not sufficient to accurately express many global add= resses. An array of tagged components like in name is probably a better approach, allowing many more options for accura= tely 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 ne= eded at all).
  • I think the notes fie= ld should be single-valued rather than an array, for the same reason as = with labels.
Cheers,
Neil.
--2bf282877639480aae1d375add98c8d8-- From nobody Wed Mar 10 19:37:17 2021 Return-Path: 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 C55563A0ADD for ; Wed, 10 Mar 2021 19:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BgQEOkES; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cr/ObCX3 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 zjStMOV-ABvE for ; Wed, 10 Mar 2021 19:37:13 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C46A3A0ADB for ; Wed, 10 Mar 2021 19:37:13 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1E76E5C00CC for ; Wed, 10 Mar 2021 22:37:11 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute6.internal (MEProxy); Wed, 10 Mar 2021 22:37:11 -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=9wTK3tK CLL9vlUsppwTVSb0magrHR/BZygNvto1SwDE=; b=BgQEOkESt82MVnsdHGnWJir QyfUW2WNQsIs1w14HSixHKEvSGl79abmCs9uJe3nBJT4nyUfymYLbE+73k8bUU95 Ht26RuuVjg+HEpzSFbsltaaQZInCmybo0vfV63BOZgEKcSZJOQneDbgr9sT+JtPp iGmar3bZkXyndECcu9SeJW0SgeQS+bt54DkXkRIu2VIjONP1qkp+bQYbAIUjw/5O ejuOCf+O7Lgu27NvuLiI0jsef8Hq2fjWEOR4AVx5Z7N7UttO3uTqjL9y9XfWPQat chngNiXmb49Lyqo/H2LJCdQ62wR/KYqN2PKC4vN7pBv7ucEiTt3ipoDM8iDNH+Q= = 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=9wTK3t KCLL9vlUsppwTVSb0magrHR/BZygNvto1SwDE=; b=cr/ObCX3BlXPfO5+ieKVrq imGO2wXTSin1JXbStwQqATmKIgg3w4Wy7Nqo4UwCBjzbsyomr77Y3lHxy6Wma0bE Z5TgtNhhJ+wIHzJs4PBpDYo/Yc2lNi1FwP6cPTAdgvnxHEwC0EFSZdUC/e7GPqjG pJ8ZOGu6G7A1Q4MA9MXlNSB9nuaPOUrmL/FZTZRzwNDyVEvH0mDCiKMm9grXoDHd YE8CWxdWIqdd6xSL2QLuDUP0E9C2rC9ISoSV/QQdfx/a6qZyCoPMoRoW49y5FL7+ Zv/s+JFNzwX6cyr5wXnBPv6Irvqq8nn8E4k3+Lmga4ynNFNO/0WS+DLXK1WKNiug == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudduledgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehuefhudejtdeiveekvdfhfffgleeflefhfeekhefhkeel kefhfeeufeevffejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjodhmvghsmhhtphhouhhtghhoihhnghdqnhgvihhljheppehf rghsthhmrghilhhtvggrmhdrtghomhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8C80A260005D; Wed, 10 Mar 2021 22:37:10 -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: In-Reply-To: References: <161191089978.17240.10563196389228010167@ietfa.amsl.com> <3dc39912-c432-1c4e-df09-b50da0ee738d@audriga.com> Date: Thu, 11 Mar 2021 14:37:09 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=06d4a60b49ba4eae9493e66435f11883 Archived-At: Subject: Re: [Jmap] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-baum-?= =?utf-8?q?jmap-tasks-00=2Etxt?= X-BeenThere: jmap@ietf.org 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: Thu, 11 Mar 2021 03:37:16 -0000 --06d4a60b49ba4eae9493e66435f11883 Content-Type: text/plain Thanks Joris! This is a great start, and reading through it I have a few thoughts for discussion at the imminent IETF 110 JMAP session and on the mailing list. The biggest question is definitely whether we should merge this into the JMAP Calendars spec; copy pasting so much stuff is generally pretty unwieldy. I think it's still important that servers can choose to support one and no the other, but we can easily define multiple capabilities in the same spec. On the other hand, now sharing is split out we might be able to do most things by reference and not be too duplicative, in which case I still think separate specs is slightly cleaner. Some other thoughts: * Many todo lists are a (manually) ordered series of tasks. I think supporting this is important; the way we generally do it in JMAP is to add a `sortOrder` property to the `Task` object (like we already have on the `TaskList` object). * Does it make sense for a `Task` to belong to multiple `TaskList`s? This interacts with the previous point; we would probably need to store a different sort order for each list it's in, which starts to get very unwieldy. Are there any existing task managers that do this, or is a task always in one list? * I'm not sure the `isVisible` property (copied over from Calendar) makes sense for TaskList. * The computed UTC properties for a Task need to be updated to map to task rather than event properties (e.g. `utcDue` for the due date). Cheers, Neil. --06d4a60b49ba4eae9493e66435f11883 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Joris! T= his is a great start, and reading through it I have a few thoughts for d= iscussion at the imminent IETF 110 JMAP session and on the mailing list.=

The biggest question is definitely whether= we should merge this into the JMAP Calendars spec; copy pasting so much= stuff is generally pretty unwieldy. I think it's still important that s= ervers can choose to support one and no the other, but we can easily def= ine multiple capabilities in the same spec. On the other hand, now shari= ng is split out we might be able to do most things by reference and not = be too duplicative, in which case I still think separate specs is slight= ly cleaner.

Some other thoughts:
<= ul>
  • Many todo lists are a (manually) ordered series of tasks. I think= supporting this is important; the way we generally do it in JMAP is to = add a sortOrder property to the Task object (like we already have on the Tas= kList object).
  • Does it make sense for a Task to belong to multiple TaskLists= ? This interacts with the previous point; we would probably need to stor= e a different sort order for each list it's in, which starts to get very= unwieldy. Are there any existing task managers that do this, or is a ta= sk always in one list?
  • I'm not sure the is= Visible property (copied over from Calendar) makes sense for Task= List.
  • The computed UTC properties for a Task need to be upda= ted to map to task rather than event properties (e.g. = utcDue for the due date).
    • Cheers,
    Neil.


    --06d4a60b49ba4eae9493e66435f11883-- From nobody Thu Mar 11 01:58:37 2021 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvtddguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepieeiffehle euiefhheefveegjefgkeelleefgefhgeehfffhieetvefgheduvdejnecuffhomhgrihhn pehivghtfhdrohhrghdpfihikhhiphgvughirgdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgv rghmrdgtohhm X-ME-Proxy: 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: References: <161375338059.1324.4641187246320270178@ietfa.amsl.com> Date: Thu, 11 Mar 2021 10:57:51 +0100 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=516ae2b4ecb745b9a2342944d1ff2b86 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 09:58:35 -0000 --516ae2b4ecb745b9a2342944d1ff2b86 Content-Type: text/plain 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 --516ae2b4ecb745b9a2342944d1ff2b86 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    Hi Neil,

    thanks for the feedback.

    <= /div>
    On Wed, Mar 10, 2021, at 6:02 AM, Neil Jenkins wrote:
    I've read through t= his draft and I have a few comments:
    • The metadata secti= on is missing a created timestamp. Also the typ= e of this and updated should be UTCDate, not ju= st String (this is more a notational comment, but I would recommend usin= g exactly the same type system as JSCalendar).

    Agreed.

    • The fullName description doesn't make it clear to me what its purpose is. Is it alw= ays 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 interna= tionalisation? (It's a LocalizedString type so can have multiple va= riants, 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 internati= onalisation 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 na= mes in locales where, for example, the family name comes first when writ= ten out. That's great, however I think nickname= is not the same as one of these components and should be a separate fie= ld in JSContact; a nickname is not a subpart of a name, it's an alternat= e one.

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

    • I found the description of the roles property hard to understand; I don't really ge= t it.

    We defined this prop= erty 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 th= e ROLE property isn't that clear to me (https://tools.ietf.org/html/rfc6350#sectio= n-6.6.2). It would interesting to understand how widely used this pr= operty is, and how people decide if to use TITLE or ROLE.
    =
    On a side-note it also bugs me that a jobTitle has no (op= tional) 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 emai= l 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 dat= a and the escaping/unescaping of characters to transform to/from a mailt= o URI is a pain to get right and likely to lead to incompatibilities.

    Just be clear, you mean we s= hould get rid of the mailto: URI, right? This makes sense to me as we wa= nt to keep any email addressee name in addition to the address itself. R= ather than using a String, we could reuse the EmailAddress type as defin= ed in the JMAP Mail spec.

    • For phones the= re's a kind of similar thing, although I do see the idea behind URIs her= e 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 a= n URI is the better choice. In contrast to emails, we don't lose any inf= ormation 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. B= ut type is single valued, so what type should it be?

    Agreed, it makes sense for phones to have mul= tiple types (or however one might call it). Both this and the idea to ha= ve an EmailAddress typed value for emails suggests that the generic Reso= urce object is too simplistic. We might better use a specific type for e= ach of the "phones", "email", .. properties.

    • I don't think the labels property of a Resource should be multi-val= ued (it should just be label, like it is in the= Address data type). While there's always a ten= sion 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 tex= t, a single one should be sufficient.
    Works for me.

    • I think the Address type needs thinking about more. The street/locality/region propert= ies are not sufficient to accurately express many global addresses. An a= rray of tagged components like in name is proba= bly a better approach, allowing many more options for accurately describ= ing the parts of the address without making it too unwieldy to use.
      <= /li>

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

    <= /div>
    The Wikipedia article on address formats suggests that the cur= rent scheme covers the majority of addresses in use globally (https://en.wikipe= dia.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 format= s (except that we'll need to separate out the street number from the str= eet field).

    That being said, the current sc= heme 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 ne= w address standard, but their approach seems to add considerably more co= mplexity. It might be too much for a Contacts API. I think they will pre= sent 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 pur= pose it to allow for localized addresses.