[Extra] In favour of OBJECTID being inculded in IMAP4REV2 - please reply by Friday!

"Bron Gondwana" <brong@fastmailteam.com> Mon, 18 November 2019 09:50 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8511A120923 for <extra@ietfa.amsl.com>; Mon, 18 Nov 2019 01:50:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=hosP6cld; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nXzVR/7O
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 yjKZOxvfOYCi for <extra@ietfa.amsl.com>; Mon, 18 Nov 2019 01:50:48 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F33120914 for <extra@ietf.org>; Mon, 18 Nov 2019 01:50:48 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A49F722489 for <extra@ietf.org>; Mon, 18 Nov 2019 04:50:47 -0500 (EST)
Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Mon, 18 Nov 2019 04:50:47 -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=fm1; bh=YA828bDKoV7lm3xfaVPDy3xYCNe9WEJ5+O6YZBI VTvM=; b=hosP6cldTnAMTgU6x6+AfsBUXLM6IvxAOAv15NB6p8Jbk4FFVTGEZwI d/Lz6IqS1xEPlzsClK4oO/K7DnHQH7p+BOUe3Z6GkWddMqvdUNMV9CBhr/GD949G eFvKEdPB15MBL4Kf7TBGW0A5mbJu6dw86uxBQInB+VCu4DyDlkwYpo+19Kw0T0am jDUkgJZ3Bc3vYgpoHxfye+g6ZkIOZ94LONN+iVJ4JXzqqtcvr8g0lrH9XmTAl4E5 7UZ7OnPiqpqfs9BPl6I4PIHN/WrYVNhAREOw47JWSSJkBY7wkvpi2jbGjI5DvQwD mAoZqSpWEz+v6XQ7qa3Yal40A9k0mzg==
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=fm1; bh=YA828bDKoV7lm3xfaVPDy3xYCNe9W EJ5+O6YZBIVTvM=; b=nXzVR/7OWGOWiR4KGB4yoYrVG5c1wW9cAIUDNWbzpFx3e tLZg7SwbO3wgW6j78cSCn7m4tV51uUtMBI0YXl57TxVQVVRKHxK0s1klBwrQq7RQ ZmhSsjs/lGhyw679eHrvBiWEhKkF9NyvX00b3REFJkr2HggYKIcAiXoH7qZVS1LJ NQSAL27+c3TxwWuCdFs4Pzw3OO3/DO/q2ba7vvKELbZL8O87HA1kvziTMgBVslM7 iYqDzf5WnwvSAqAton/LXl0eSkTaDKOUlnMX2Z7pxSkSKw3ePjxZb0IB9egbQphz /6U8OsxVaTatGGIUeZJ7nO9gNvOK/okcLibazbVnQ==
X-ME-Sender: <xms:d2nSXYI5tc_eJgivkuxDy6TCfOkYTWsYE15rkgpiJGJuysbE6D6HTA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeghedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghroh hnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:d2nSXcY90aLvlFTz5HrgS6VtcRoCG-7RMzTB918jL1UFD_4OolYPKQ> <xmx:d2nSXTseyrjOHAjN6HakSlxUPseDAUPbD23sIzo-AGf2AhwR1WeoxQ> <xmx:d2nSXZvqmlz10t5W3kFKM3_OsOLrX6kFIyoeqlv8X2-50jEKuvlFIQ> <xmx:d2nSXciJQwhHLh2d3OhmgSHLOdegsmmUjsSz9DhzgIOR2b6hIeYSqQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 30FEF324B6F; Mon, 18 Nov 2019 04:50:47 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1
Mime-Version: 1.0
Message-Id: <51568edb-792c-46b7-a2b2-3f0a1ac91997@dogfood.fastmail.com>
Date: Mon, 18 Nov 2019 20:50:41 +1100
From: "Bron Gondwana" <brong@fastmailteam.com>
To: extra@ietf.org
Content-Type: multipart/alternative; boundary=86d59d065f134a03b2ed29133912c70d
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/3PkKsB7jHhZuthAohrsDoYJqeK0>
Subject: [Extra] =?utf-8?q?In_favour_of_OBJECTID_being_inculded_in_IMAP4R?= =?utf-8?q?EV2_-_please_reply_by_Friday!?=
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 09:50:57 -0000

In today's EXTRA meeting at IETF106, I argued in favour of including OBJECTID into IMAP4REV2. I'm arguing again here.

Please comment on this thread - both in favour and particularly if you're against this.

Ideally, if you could reply to this email by *8am Friday Nov 22 Singapore time* then the guidance will be in place before Alexey and Barry have their editing session.

I think having OBJECTID required is valuable because:
* it allows much better caching on clients
* many servers already have a unique ID stored internally for each item

Also - if your server doesn't store a value and doesn't have anywhere to cache it, it can fall back to this algorithm:

 - MAILBOXID: digest(mboxname,uidvalidity)
 - EMAILID: digest(mboxname,uidvalidity,uid)
 - THREADID: NIL

Or if it does have a way to cache, it can do that, and then keep the first value on copy/rename - since that value can never be used again. And if you lose the cache, you lose the cache - and it's not the end of the world, because the new value calculated from the new mboxname/uidvalidity[/uid] will also be unique.

In the minutes I suggested THREADID == EMAILID, so every email is its own thread (which is legal) but RFC8474 does allow for NIL, and that's probably better (client knows that the server isn't threading).

I'd like to see this included in imap4rev2 and I think it won't disadvantage implementation significantly, but will make new clients better over time. (and as Neil pointed out, you already need it for JMAP).

Cheers,

Bron.

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