From nobody Mon Nov 4 03:35:00 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDE61200DF; Mon, 4 Nov 2019 03:34:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <157286729905.16516.7287275095067883873@ietfa.amsl.com> Date: Mon, 04 Nov 2019 03:34:59 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-07.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 11:34:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-07.txt Pages : 146 Date : 2019-11-04 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-07 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 06:54:18 2019 Return-Path: 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 B328A1208F6 for ; Mon, 4 Nov 2019 06:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 9q29Yp9COs5z for ; Mon, 4 Nov 2019 06:54:03 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 35CC31200F4 for ; Mon, 4 Nov 2019 06:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1572879242; d=isode.com; s=june2016; i=@isode.com; bh=YnYHcpUiTLf3YaWzqB1gl5DH7kKiZa/WnFjbBmL4CeE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pWtmIhkpOR9gIaEL8HQWsjxEUW9iGmVTo5Awd8dlGPQI7UoYRnPQ9iLL4SNYoTYC9jphMa fig2nxdCz0yq9Bs+vEETUdIrwhaylDNKw3gU57iNaiNtTxX6KXziHS3pyOqylupQzbwlLH Hz6pXPm1uZwzaFdaGpDuOrDfvJGZXdU=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Nov 2019 14:54:02 +0000 To: extra@ietf.org References: <157286729905.16516.7287275095067883873@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <938bac19-5071-ed2c-7172-392c9ff377bc@isode.com> Date: Mon, 4 Nov 2019 14:52:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <157286729905.16516.7287275095067883873@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-07.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 14:54:12 -0000 Hi, On 04/11/2019 11:34, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-07 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-07 This version completes integration of extended LIST (including adding missing ABNF) and removes LSUB. There aare probably still some minor inconsistencies in the text, so please have a read. I haven't fully addressed Arnt's comments on SEARCH NEW/\Recent removal. There are also a few comments from Timo's review still outstanding. (Version -06 addressed most of Timo's comments.) These will be completed in the next revision. I think with this revision all bigger changes are complete. This is nearly ready for WGLC. Best Regards, Alexey From nobody Thu Nov 7 02:39:12 2019 Return-Path: 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 4053E120106 for ; Thu, 7 Nov 2019 02:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 vyqsqpur6DBu for ; Thu, 7 Nov 2019 02:39:08 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B944120103 for ; Thu, 7 Nov 2019 02:39:08 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 4E9EEC001E; Thu, 7 Nov 2019 10:42:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1573123370; bh=PHExspEeGtGlFIMoRFlPt5KXxSdPJyg5SNaTHxDNtqk=; h=From:To:Subject:Date:From; b=FfvaJWlx+m43mvRiUVzcVhwUqMCEpdLsVSaoI0La/z6+cif+qXYaNDwTIosx/3gM7 LBSh5xjV3IGqXGMCry/2oL6fVL462KAtBAlZyORSXE7yH9fEi1jvMIUlbRp3PPfThe zYDZRbpFka9zgyU2pW7MfrLgfUn7WJiBYgwpzNYE= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1573123369-28749-28747/9/3; Thu, 7 Nov 2019 10:42:49 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 7 Nov 2019 11:39:03 +0100 Mime-Version: 1.0 Message-Id: User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.1 (ascii) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: [Extra] IMAP4rev2, SEARCH CHARSET X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 10:39:10 -0000 Hi, SEARCH CHARSET is a bit ungood now. IMAP4rev1 used ASCII generally, and the CHARSET specification could be used to use something else in a search key. However, IMAP4rev2 now uses UTF-8 generally (see section 4.3.1), and so CHARSET becomes rather odd. I suggest obsoleting CHARSET and telling clients to use UTF-8 for searches. Suggested text (for 6.4.4): "In IMAP4rev1, the client could specify the character encoding of non-ASCII search keys using SEARCH CHARSET. In IMAP4rev2, the client uses UTF-8 for all search keys, and for this reason CHARSET is now obsolete." My question is: Obsolete CHARSET and say clients MUST NOT use it, or obsolete it and say that servers MUST support CHARSET UTF-8 and MAY support others? Arnt From nobody Thu Nov 7 02:49:06 2019 Return-Path: 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 94F051200B2 for ; Thu, 7 Nov 2019 02:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 GB3S4EPzWLch for ; Thu, 7 Nov 2019 02:49:04 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E7B120073 for ; Thu, 7 Nov 2019 02:49:04 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 5E471C001E; Thu, 7 Nov 2019 10:52:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1573123967; bh=1jzVaXsBXOOyfVkEtNEobQ2JX4NyaqVq6n2zy7jAJiY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aEY2W1ovV3CJ4Uw7KD1NkI4dv+jDDxRPYHZWQX1DLpq3OT3OQxS+I/vmSQzHMsKdO j5Csl8gyHeSMQq676v6qCheZCm8yaaK/dRHEsW9RXcZ7n8WLvETX/hn8n1i+lLiwwi /Ix10ChhC5OsdIRF8OvnjxU8zVuyMvBhSFvd7BAc= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1573123966-28749-28747/9/4; Thu, 7 Nov 2019 10:52:46 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 7 Nov 2019 11:49:00 +0100 Mime-Version: 1.0 Message-Id: <2b7ebdb2-7895-432f-8da9-8c6b95e315fb@gulbrandsen.priv.no> In-Reply-To: References: User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.1 (ascii) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] IMAP4rev2, SEARCH CHARSET X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 10:49:05 -0000 I wrote: > My question is: Obsolete CHARSET and say clients MUST NOT use > it, or obsolete it and say that servers MUST support CHARSET > UTF-8 and MAY support others? I had a coffee. My own preference is the latter. "Servers MUST support CHARSET UTF-8 and MAY support other encodings. Clients SHOULD NOT use other encodings. Note that UTF-8 is also the default, so selecting CHARSET UTF-8 is redundant. It is permitted for improved compatibility with existing IMAP4rev1 clients". Arnt From nobody Thu Nov 7 02:54:03 2019 Return-Path: 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 D77A3120103 for ; Thu, 7 Nov 2019 02:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 1UU6p0LqqElW for ; Thu, 7 Nov 2019 02:54:00 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id BA998120073 for ; Thu, 7 Nov 2019 02:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1573124040; d=isode.com; s=june2016; i=@isode.com; bh=4BhGKucVrzRtAMdsIj0UiwAvEzZr093WkNp+gaAmnjE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=LFBLqjVAG+ZuYQJPeyydGdjzAVgdhsDMqB6LZ/RrK/vmvGlSiOuVpj2oFJAvij0f2EShy3 uh25zOT0233s4/AnSaeMcyLaiCNoGM6iFJ41v2oZm/COreVLm8hmyBGanavHFlBFf5zofg ib7X6+WLwbv7yQHxZgezeL8SI2OG0eY=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 7 Nov 2019 10:53:59 +0000 To: Arnt Gulbrandsen , extra@ietf.org References: <2b7ebdb2-7895-432f-8da9-8c6b95e315fb@gulbrandsen.priv.no> From: Alexey Melnikov Message-ID: <5d75e63b-4393-2c70-a90e-ec082b80d63f@isode.com> Date: Thu, 7 Nov 2019 10:52:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <2b7ebdb2-7895-432f-8da9-8c6b95e315fb@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] IMAP4rev2, SEARCH CHARSET X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 10:54:02 -0000 On 07/11/2019 10:49, Arnt Gulbrandsen wrote: > I wrote: >> My question is: Obsolete CHARSET and say clients MUST NOT use it, or >> obsolete it and say that servers MUST support CHARSET UTF-8 and MAY >> support others? > > I had a coffee. My own preference is the latter. > > "Servers MUST support CHARSET UTF-8 and MAY support other encodings. > Clients SHOULD NOT use other encodings. Note that UTF-8 is also the > default, so selecting CHARSET UTF-8 is redundant. It is permitted for > improved compatibility with existing IMAP4rev1 clients". I like this too. From nobody Thu Nov 7 05:36:31 2019 Return-Path: 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 E420C120822 for ; Thu, 7 Nov 2019 05:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 I4SLr4J_vPBK for ; Thu, 7 Nov 2019 05:36:28 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDD3120219 for ; Thu, 7 Nov 2019 05:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1573133787; d=isode.com; s=june2016; i=@isode.com; bh=2w4Tmf8GEj01Ud8gG4gP5xm7SGxBjs6ObzsGuRzezaA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=OyJ+IZ4vufnU9TLFe1k4hMnpzBhW98wgff/kuOj/EMB+NiIqeMT5NmW6DXpxfRifdml/mj rVYm9QttYsgL+37CFRjw+0mACm03kxwLwejyGtvEtvmmUpmIH1H0wdIu7MYJfr58F4HuBp 5xKTrzqwDNJtyagd/whJ+yHPQhFnx7U=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 7 Nov 2019 13:36:27 +0000 To: Arnt Gulbrandsen , extra@ietf.org References: <2b7ebdb2-7895-432f-8da9-8c6b95e315fb@gulbrandsen.priv.no> From: Alexey Melnikov Message-ID: <9a25ae8f-7838-f69f-877f-99403ed15135@isode.com> Date: Thu, 7 Nov 2019 13:35:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <2b7ebdb2-7895-432f-8da9-8c6b95e315fb@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] IMAP4rev2, SEARCH CHARSET X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 13:36:30 -0000 Hi Arnt, On 07/11/2019 10:49, Arnt Gulbrandsen wrote: > I wrote: >> My question is: Obsolete CHARSET and say clients MUST NOT use it, or >> obsolete it and say that servers MUST support CHARSET UTF-8 and MAY >> support others? > > I had a coffee. My own preference is the latter. > > "Servers MUST support CHARSET UTF-8 and MAY support other encodings. > Clients SHOULD NOT use other encodings. Note that UTF-8 is also the > default, so selecting CHARSET UTF-8 is redundant. It is permitted for > improved compatibility with existing IMAP4rev1 clients". I used something very close to your text. Best Regards, Alexey From nobody Mon Nov 18 01:39:38 2019 Return-Path: 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 6FCEE120018 for ; Mon, 18 Nov 2019 01:39:36 -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=n5wuCPMg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C89fOplH 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 ba67g_xp_R9k for ; Mon, 18 Nov 2019 01:39:34 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5B11208A9 for ; Mon, 18 Nov 2019 01:39:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2442722451 for ; Mon, 18 Nov 2019 04:39:33 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Mon, 18 Nov 2019 04:39:33 -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=Js1cpsDRirBesFYwusPUesvhUFumZxQFMGFdAeg I14A=; b=n5wuCPMgy/k+BYkbQ3awhWLRlIky58368qceF8qSOuHV11QxJxtIiIR Vw+1AQhdAWFHVPIRVrUTiXxPDpDJHuZxetFRKiI1K1tB8JNiLNr06o21KguINZND 9iSlBd3v7je3AS8CBGkqn366MU0MVR2473iv62un3WmAlNwIGIp/3b7Y/mgkiHco njPlpv+rO/KjXQyoChwU9gASevuQaODl+nYNxzSWnxBRgGhJjnZoXRYdgdIsY6Rs 1rUihTZ+Y2ZiKFwxBMY6/OluwQEbudiFT8U1cNZzC7cnsCg1DDFyP9ASWYdZtjOq BOGtYxMSBItGfi+3RNfBs4o3WQ3azGA== 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=Js1cpsDRirBesFYwusPUesvhUFumZ xQFMGFdAegI14A=; b=C89fOplHGw0hwR8Js/x8N+QgrG8cjaHUkpptlmsTpHB9O RjPNKQ8wefQ1y8kGPPIBw9LaTbYoz/tOFRbvO/MgktzDdPpvqzpjriic2SlTe92v sdKiqqDxMcwHzO38Puv6fiTb3nngJeTQAUQiJ6BB1uzgEhccutbo8cYAtLjNzaN5 niy1c4LdtT6xF5Nw65kX5+Z5lhTqGrsI8YXjIyOC6arHKE8XxN4xQr09iHlHFcUa +8adAJvbTp68tI3GBPrn7Z9WOLSBftXy+al9ZXO9osqxapjA655IoVi4nAaZ6zX+ D2B/RMx9Y5reBoX2xAjWSjwVO4Pidmr6pcCp7VBFA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeghedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B978E324AAD; Mon, 18 Nov 2019 04:39:31 -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: Date: Mon, 18 Nov 2019 20:38:45 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=fc2801e192464f019ec3cdc05f3301d9 Archived-At: Subject: [Extra] Minutes for today's session uploaded X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 09:39:36 -0000 --fc2801e192464f019ec3cdc05f3301d9 Content-Type: text/plain Hi All, The minutes for today's session have been uploaded to the datatracker, and are included in this email for your convenience. Please check the ACTIONS section in particular for anything you need to do. Cheers, Bron. IETF106 EXTRA WORKING GROUP - Singapore 2019-11-18, 14:30-15:30 = AGENDA Welcome, Notewell, Bluesheets, Agenda bashing: 5m Current Drafts: * fetch-preview: 10m * imap4rev2: 20m * quota: 15m Milestone review: 5m Any other business: 5m = ACTIONS *Alexey:** * ** work with Barry to update IMAP4REV2** * ** consider both **https://datatracker.ietf.org/doc/minutes-104-extra/** notes and this set of minutes to see decisions made (and updated)** * * * *Barry:** * ** work with Alexey to update IMAP4REV2** * * * *Bron:** * ** send argument in favour of OBJECTID to the list** * ** consider ANNOTATION-STORAGE with quota** * ** update milestones** * * * *Michael:** * ** update wording of PREVIEW to have client request mediatypes** * * * *Stephan:** * ** upload EAI Sieve draft* = DETAILED NOTES == preview Barry: * Contention: client can't have any idea what algorithm is best, so server should choose the algorithm Michael: * From Dovecot perspective - have clients who want to be able to fetch image previews and show them * Particularly valuable on something like a dashboard where just a couple of emails are showed. * Also valuable where payload is encrypted and includes a fuzzy image showing enough to be useful to client "click on this to decrypt and see the actual content". Barry: * Ahh, now I see your use case! * Sounds like what you want is media types (e.g. Accept) rather than algorithms. Alexey: * Do you want RFC5259 CONVERT? Michael: * That doesn't do what we actually need * Don't want every client asking for a different format - server will produce ONE preview of text or image type and cache that Neil: * Appears that the consensus of the room is to change the mechanism to be content types instead of algorithms, but have text/plain be the initial supported option. * Behaviour will be same as now, just a different format. Bron: * do we need to define a different text/? format for this so we don't block other use of text/plain? * also: do we need a way to discover what formats a server supports, since it won't be in capabilities Pete: * clients will just send a query regardless of server support probably, easier to just leave it unspecified and see what the server will spit back Barry: * Should just have PREVIEW in the capabilities, no need to have a discovery mechanism, just specify the types you're willing to accept and server will spit out what it wants. Alexey: * This is a major change which will require IESG review again * But we can do it quickly. Back to the working group, quick WGLC, done. ACTION: Michael to get new draft done with updated wording == imap4rev2 Alexey: * should we deprecate or just remove FETCH RFC822.*? Bron: * Let's just delete it, likewise "SEARCH NEW". If your client requests IMAP4REV2 it's opting in to the removals, and should strip them from its code. Alexey: * Good - goal is to make all the bits that are in both rev1 and rev2 work the same, but the compatability path is servers supporting both, not that clients should be able to keep crappy old stuff once opting up. Barry: * Extended LIST still needs wordsmithing, will meet with Alexey on Friday morning and work on it Alexey: * BODYSTRUCTURE needs more examples, it's a common cause of bugs * LIST multiple patterns is OUT * LIST RETURN STATUS is IN * Binary fetch only leaf nodes has issues with message/global, more research required Long discussion on search - I didn't capture all the names of people who spoke on this, but the final proposal is: * SEARCH without modifier works like in rev1 (heuristic) * SEARCH FUZZY always does fuzzy matching * add a new SEARCH SUBSTRING modifier which forces the server to use substring matching. * The server MAY reply "NO" to a SUBSTRING search. * We need to define an extended response code for that [SUBSTRING-SEARCH-NOT-AVAILABLE] or whatever. Can do same for FUZZY if that's not supported on a field. Bron: * could also have SEARCH REGEX modifier. Room expressed suitable disgust. Alexey: * SEARCHRES is IN * STATUS DELETED - yes, easy for everyone to add * Want to do last call before Christmas! Bron: * I'd really like to see OBJECTID included, it's very valuable. * There's a degenerate algorithm which can be used which doesn't give you all the benefits, it's: - MAILBOXID: digest(mboxname,uidvalidity) - EMAILID: digest(mboxname,uidvalidity,uid) - THREADID: EMAILID * This is RFC compliant, but doesn't give any benefits. There's no hard requirement that same data has same ID after a rename/copy, only that same ID is never reused for different data. Neil: * OBJECTID is needed for JMAP too Alexey: * Not entirely opposed, despite own server not supporting it * make your case on the mailing list and make it quick! ACTION: Bron to make case for OBJECTID on the list ACTION: Alexey and Barry to update doc this week and send for WGLC == quotabis Bron: * do we want to add ANNOTATION-STORAGE as a separate type? * is 32 bits enough for each field? * should we redefine STORAGE in octets instead of koctets? Alexey: * feel free to make a case, but these all seem sensible from the numbers we have * need to make a good case to break backwards compat * more reviews please! * plan to address this after imap4rev2 is done Bron: * yeah, I accept all the above - I'll think about ANNOTATION-STORAGE ACTION: people to review the draft ACTION: Bron to consider ANNOTATION-STORAGE and whether it makes sense == Milestones Bron: * imap4rev2 - Dec 2019 * quota - Feb 2020 * charter review - Apr 2020 * eai sieve - May 2020 Alexey: * will have more time for EAI after quota Michael: * I think Stephan Bosch was going to do EAI Sieve Alexey: * Bonus! ACTION: Stephan to propose EAI Sieve document ACTION: Bron to update milestones == Other business Out of time! Take it to the list. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --fc2801e192464f019ec3cdc05f3301d9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

The minutes for today's session hav= e been uploaded to the datatracker, and are included in this email for y= our convenience.

Please check the ACTIONS section in part= icular for anything you need to do.

Cheers,

Bron.

IETF106 EXTRA WORKING= GROUP - Singapore 2019-11-18, 14:30-15:30

=3D AGENDA
=

Welcome, Notewell, Bluesheets, Agenda bashing: 5m
<= div style=3D"font-family:Arial;">Current Drafts:
* fetch-preview: 10m
* imap4rev2: 20m
= * quota: 15m
Milestone review= : 5m
Any other business: 5m

=3D ACTIONS
Alexey:
=
* work with Barry to update IMAP4RE= V2
* consider b= oth = https://datatracker.ietf.org/doc/minutes-104-extra/ notes = and this set of minutes to see decisions made (and updated)

Barry:
* work with Alexey to update IMAP4REV2

Bron:
* send argument in favour of OBJECTID to the list
* consider ANNOTATION-STORA= GE with quota
*= update milestones

Michael:
* update wording of PRE= VIEW to have client request mediatypes

= Stephan:
* u= pload EAI Sieve draft
=3D DETAILED NOTES

=3D=3D preview

<= div style=3D"font-family:Arial;">Barry:
* Contention: client can't have any idea what algorithm is be= st, so server should choose the algorithm

Michael:
* From Dovecot perspective - have c= lients who want to be able to fetch image previews and show them
* Particularly valuable on something= like a dashboard where just a couple of emails are showed.
* Also valuable where payload is encrypte= d and includes a fuzzy image showing enough to be useful to client "clic= k on this to decrypt and see the actual content".

Barry:<= br>
* Ahh, now I see your use cas= e!
* Sounds like what you wan= t is media types (e.g. Accept) rather than algorithms.

Al= exey:
* Do you want RFC5259 C= ONVERT?

Michael:
* That doesn't do what we actually need
* Don't want every client asking for a different format - se= rver will produce ONE preview of text or image type and cache that

Neil:
* Appears tha= t the consensus of the room is to change the mechanism to be content typ= es instead of algorithms, but have text/plain be the initial supported o= ption.
* Behaviour will be sa= me as now, just a different format.

Bron:
* do we need to define a different text/? fo= rmat for this so we don't block other use of text/plain?
* also: do we need a way to discover what fo= rmats a server supports, since it won't be in capabilities

Pete:
* clients will just s= end a query regardless of server support probably, easier to just leave = it unspecified and see what the server will spit back

Bar= ry:
* Should just have PREVIE= W in the capabilities, no need to have a discovery mechanism, just speci= fy the types you're willing to accept and server will spit out what it w= ants.

Alexey:
= * This is a major change which will require IESG review again
<= div style=3D"font-family:Arial;">* But we can do it quickly.  Back = to the working group, quick WGLC, done.

ACTION: Michael t= o get new draft done with updated wording

=3D=3D imap4rev= 2

Alexey:
* sh= ould we deprecate or just remove FETCH RFC822.*?

Bron:
* Let's just delete it, likewis= e "SEARCH NEW".  If your client requests IMAP4REV2 it's opting in t= o the removals, and should strip them from its code.

Alex= ey:
* Good - goal is to make = all the bits that are in both rev1 and rev2 work the same, but the compa= tability path is servers supporting both, not that clients should be abl= e to keep crappy old stuff once opting up.

Barry:
* Extended LIST still needs wordsmit= hing, will meet with Alexey on Friday morning and work on it

Alexey:
* BODYSTRUCTURE n= eeds more examples, it's a common cause of bugs
* LIST multiple patterns is OUT
* LIST RETURN STATUS is IN
* Binary fetch only leaf nodes has issues with messag= e/global, more research required

Long discussion on searc= h - I didn't capture all the names of people who spoke on this, but the = final proposal is:

=
* SEARCH without modifier works like i= n rev1 (heuristic)
* SEARCH F= UZZY always does fuzzy matching
* add a new SEARCH SUBSTRING modifier which forces the server to use = substring matching.
* The ser= ver MAY reply "NO" to a SUBSTRING search.
* We need to define an extended response code for that [SUB= STRING-SEARCH-NOT-AVAILABLE] or whatever.  Can do same for FUZZY if= that's not supported on a field.

Bron:
* could also have SEARCH REGEX modifier. = Room expressed suitable disgust.

Alexey:
* SEARCHRES is IN
* STATUS DELETED - yes, easy for everyone to add
* Want to do last call before Chris= tmas!

Bron:
* = I'd really like to see OBJECTID included, it's very valuable.
<= div style=3D"font-family:Arial;">* There's a degenerate algorithm which = can be used which doesn't give you all the benefits, it's:
- MAILBOXID: digest(mboxname,uidvalidity)<= br>
- EMAILID: digest(mboxname,ui= dvalidity,uid)
- THREADID: EM= AILID
* This is RFC compliant= , but doesn't give any benefits.  There's no hard requirement that = same data has same ID after a rename/copy, only that same ID is never re= used for different data.

=
Neil:
* OBJECTID is needed for JMAP too

Alexey:=
* Not entirely opposed, desp= ite own server not supporting it
* make your case on the mailing list and make it quick!

ACTION: Bron to make case for OBJECTID on the list
ACTION: Alexey and Barry to update doc this wee= k and send for WGLC

=3D=3D quotabis

Bron:
* do we want to add ANNOTATION= -STORAGE as a separate type?
= * is 32 bits enough for each field?
* should we redefine STORAGE in octets instead of koctets?

Alexey:
* feel free = to make a case, but these all seem sensible from the numbers we have
=
* need to make a good case to br= eak backwards compat
* more r= eviews please!
* plan to addr= ess this after imap4rev2 is done

Bron:
* yeah, I accept all the above - I'll think abo= ut ANNOTATION-STORAGE

ACTION: people to review the draft<= br>
ACTION: Bron to consider ANNO= TATION-STORAGE and whether it makes sense

=3D=3D Mileston= es

Bron:
* ima= p4rev2 - Dec 2019
* quota - F= eb 2020
* charter review - Ap= r 2020
* eai sieve - May 2020=

Alexey:
* wil= l have more time for EAI after quota

Michael:
* I think Stephan Bosch was going to do = EAI Sieve

Alexey:
* Bonus!

ACTION: Stephan to propose EAI Sieve documen= t
ACTION: Bron to update mile= stones

=3D=3D Other business

Out of time!&n= bsp; Take it to the list.

--
  = Bron Gondwana, CEO, Fastmail Pty Ltd
&= nbsp; brong@fastmailteam.com


--fc2801e192464f019ec3cdc05f3301d9-- From nobody Mon Nov 18 01:50:58 2019 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeghedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghroh hnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: 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" To: extra@ietf.org Content-Type: multipart/alternative; boundary=86d59d065f134a03b2ed29133912c70d Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 09:50:57 -0000 --86d59d065f134a03b2ed29133912c70d Content-Type: text/plain 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 --86d59d065f134a03b2ed29133912c70d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
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 Sing= apore time then the guidance will be in place before Alexey and Barr= y have their editing session.

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

<= div style=3D"font-family:Arial;">Also - if your server doesn't store a v= alue and doesn't have anywhere to cache it, it can fall back to this alg= orithm:

 - MAI=
LBOXID: digest(mboxname,uidvalidity)
 - EMAILID: digest(mboxname,uidvalidity,uid)
 - THREADID: NIL

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

In the minutes I suggested THREADID =3D=3D EMAILID, so every e= mail 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 c= lients better over time.  (and as Neil pointed out, you already nee= d it for JMAP).

Cheers,

Bron.

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


= --86d59d065f134a03b2ed29133912c70d-- From nobody Mon Nov 18 02:15:21 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D1E120909 for ; Mon, 18 Nov 2019 02:15:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157407211842.14188.5491011937157825056.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2019 02:15:18 -0800 From: IETF Secretariat Archived-At: Subject: [Extra] Milestones changed for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 10:15:18 -0000 Changed milestone "Adopt a QUOTA-BIS document", resolved as "Done". Changed milestone "Adopt a document for EAI with Sieve", set due date to December 2019 from March 2019. Changed milestone "Submit "IMAP4rev2" to IESG as a Proposed Standard", set due date to December 2019 from March 2019, added draft-ietf-extra-imap4rev2 to milestone. Changed milestone "Update charter to reflect current and planned work", set due date to April 2020 from April 2019. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Mon Nov 18 02:34:44 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEE412086E for ; Mon, 18 Nov 2019 02:34:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157407328263.14135.15774172274241993572.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2019 02:34:42 -0800 From: IETF Secretariat Archived-At: Subject: [Extra] Milestones changed for extra WG X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 10:34:43 -0000 Changed milestone "Submit "Quota BIS" to IESG as a Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Tue Nov 19 18:43:22 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35731120A8E; Tue, 19 Nov 2019 18:43:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <157421778511.5379.340076662534945028@ietfa.amsl.com> Date: Tue, 19 Nov 2019 18:43:05 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-08.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 02:43:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-08.txt Pages : 147 Date : 2019-11-19 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-08 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 19 23:49:47 2019 Return-Path: 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 C28761209DE for ; Tue, 19 Nov 2019 23:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=1tt4budn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ne+Mw12W 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 pOI295FlyTgW for ; Tue, 19 Nov 2019 23:49:42 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403BC120939 for ; Tue, 19 Nov 2019 23:49:42 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 90D5158C for ; Wed, 20 Nov 2019 02:49:40 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 02:49:40 -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=fm1; bh=AmGa1A0 w36RbQ516c0VAoXHjSw+Dthh+gQAP1UYjJfI=; b=1tt4budnWkEI2xMlorlje7K ldX4wPy5kxR6H5237f1JpvYJza9l7ZMZYG2iuynTXd8JoUeX8/8IT4pAvXFdKhW2 c9NGWkrpoUoJOomE5xGomp1pXdJsEyYZ22fhZQp/dRvaSrXnD5jcP+qr/4GccAx8 kil0HV7mA7TBHXWCZIUkDb0pVOZAeeiwRrGnYEOMveHfUQ7zoR8chkaN1q6Of9og hfZIsJnRgB8BbsKho5OzEI6OYcpJTlniywfHK7EYB65LH8NXlCL1c6didymboYE4 Emp9/0axCQBOrbXwVmYJdZuUQ+UrdsfSNics4zKqjbc9a5pinlGFEazxJMEjTHw= = 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=fm1; bh=AmGa1A 0w36RbQ516c0VAoXHjSw+Dthh+gQAP1UYjJfI=; b=Ne+Mw12WmO8v1piT+ERReW ba3VY/Ob0TvmNmyqfu2FFkoMO9WqwZUX7u6+jAjLAByIL0sssdGPAmmLj3wyK2X9 aZmSlHTadH6NKB72WcApYaf9BkGJKGRmKh0dF93Xf53kQfl26ru0bpZP4I7eOJLx uAbspig6VILHvPHLp6e31WgOzsoBxqTp9wgBHayUu2z39fEnHDT85fRjVyeqllKL Ye5BRoELeDkoiSoR9ibHmyfxVU0vp0fD/3I8Q9sbZl8KJSuMVBvPry/zBkdUxHqk 2dcYtg7jC0P3hJLfonNE13w+Ie6BaS50uX9+BdaOqPEqik+8pEGcYvZb80C4M6Ig == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegledgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhg sehfrghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigv pedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BF3E830006F; Wed, 20 Nov 2019 02:49:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <9583d392-d699-486a-9111-b8a0288d2cda@dogfood.fastmail.com> In-Reply-To: <51568edb-792c-46b7-a2b2-3f0a1ac91997@dogfood.fastmail.com> References: <51568edb-792c-46b7-a2b2-3f0a1ac91997@dogfood.fastmail.com> Date: Wed, 20 Nov 2019 18:49:34 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=b5e4c79cb6874658999ca4cc6cba77f1 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 07:49:45 -0000 --b5e4c79cb6874658999ca4cc6cba77f1 Content-Type: text/plain On Mon, Nov 18, 2019, at 20:50, Bron Gondwana wrote: > 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 I was reminded off list that the final text in RFC8474 made it MUST be the same value, so it's not as easy as all that to have the objectid change on MOVE or RENAME and be totally compliant. Some options: 1) insist on remaining exactly compliant. 2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken the MUSTs around keeping IDs the same. 3) OK, leave OBJECTID as optional and don't include it in IMAP4REV2. Opinions? Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --b5e4c79cb6874658999ca4cc6cba77f1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Nov 18, 2019, at 20:50, Bron Gondwana wrote:<= br>
Also - if your server doesn't store a value and doesn't have anyw= here to cache it, it can fall back to this algorithm:

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

I was reminded off list tha= t the final text in RFC8474 made it MUST be the same value, so it's not = as easy as all that to have the objectid change on MOVE or RENAME and be= totally compliant.

Some options:
1) insist on remaining exactly compliant.
<= div style=3D"font-family:Arial;">2) include RFC8474 naming and behaviour= in IMAP4REV2 but weaken the MUSTs around keeping IDs the same.
3) OK, leave OBJECTID as optional and= don't include it in IMAP4REV2.

Opinions?

Bron.

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


--b5e4c79cb6874658999ca4cc6cba77f1-- From nobody Tue Nov 19 23:55:54 2019 Return-Path: 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 7B0F0120A15 for ; Tue, 19 Nov 2019 23:55:52 -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=J/FmxtsB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K+F63VPU 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 pjVKHg-Fd6bh for ; Tue, 19 Nov 2019 23:55:50 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5EC12082F for ; Tue, 19 Nov 2019 23:55:50 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9ADB8524 for ; Wed, 20 Nov 2019 02:55:49 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 02:55:49 -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=fm1; bh=xhw735w SVP8AD3wgcMEiKUtjJeyZKn1BH9kKx4e/iXw=; b=J/FmxtsBzZ68EGW4Vr8Y+Ds StCEYZThFxtZDLbU60jGWxn0lLVTvz8rjtvNBb7e402tVGstkUaUqpEQOE6+yclu WwdxaKhq1S9qV8R+poLwF7SmHza5zezLfFamPYCWEzdUCFNAFi5VcWi1hv/a7kEY Ryb+LdJHqcUzwIsRjUSOh+x+YOJQHsZhJP/ZNdkuoWCtjLVnzcq9+11TdWeKj8ah C8UdQRJm5kXQlfnfF2hBcePQGNk/oFPXjbrQ6pSaqTMstNopECxTcTTZ59Kp3sio s79rUz4g23gl7I9lGzxIT+SNARWUsJZ2tSxekhUKbMM2uSETkQmuzMam7s19Dtw= = 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=fm1; bh=xhw735 wSVP8AD3wgcMEiKUtjJeyZKn1BH9kKx4e/iXw=; b=K+F63VPUvFbThVbF/fTG/t AyIEEk1lWJNWPkj8BtCldXKEGxfTuJDWVA2a9dJhpIfTuKw+5kMPlGE/6xX3DXZM GYNBOyxevBxd6h0gxr/GYVJOX8jqZVwBE64mA+CvQAEXPO36yb8rRWRTn6VI8VdP JY4KbVmJVk9imVpTuG0607sgbI14joE5xEQs3YCHzw+Bq0vRjpbW+fvQT8QBN/U+ LWH9ZFdHET8NqhR2GFNwssAbLE4TCFE8Np6mZlkCLMiw1qykPmV+YeO+w4Vm4H25 nsL94dtl71Zmfwi0uy29VJnVngX0sNI9ZhgsaDO8wsFL7uLaOeXAZIF1Mhi9eTGg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegledguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepnh gvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F023B30006F; Wed, 20 Nov 2019 02:55:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <9583d392-d699-486a-9111-b8a0288d2cda@dogfood.fastmail.com> References: <51568edb-792c-46b7-a2b2-3f0a1ac91997@dogfood.fastmail.com> <9583d392-d699-486a-9111-b8a0288d2cda@dogfood.fastmail.com> Date: Wed, 20 Nov 2019 15:55:26 +0800 From: "Neil Jenkins" To: extra@ietf.org Content-Type: multipart/alternative; boundary=1821655d5e12402fbf0a4901f8893f18 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 07:55:53 -0000 --1821655d5e12402fbf0a4901f8893f18 Content-Type: text/plain On Wed, 20 Nov 2019, at 15:49, Bron Gondwana wrote: > 2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken the MUSTs around keeping IDs the same. I am not in favour of this. It basically removes the whole point of OBJECTID. If it's mandatory, you need to implement it properly. Either mandatory or not is fine (I'd prefer it in, but worth consulting implementors), but let's not change its semantics. Neil. --1821655d5e12402fbf0a4901f8893f18 Content-Type: text/html
On Wed, 20 Nov 2019, at 15:49, Bron Gondwana wrote:
2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken the MUSTs around keeping IDs the same.

I am not in favour of this. It basically removes the whole point of OBJECTID. If it's mandatory, you need to implement it properly. Either mandatory or not is fine (I'd prefer it in, but worth consulting implementors), but let's not change its semantics.

Neil.
--1821655d5e12402fbf0a4901f8893f18-- From nobody Wed Nov 20 00:03:17 2019 Return-Path: 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 8D2A9120A71 for ; Wed, 20 Nov 2019 00:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=EvCIAAn3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vpmbvzVQ 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 L71SI1dgsUHI for ; Wed, 20 Nov 2019 00:03:15 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EED120A65 for ; Wed, 20 Nov 2019 00:03:15 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id CD5E9214 for ; Wed, 20 Nov 2019 03:03:13 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 03:03:13 -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=IOSde/vU5RC8L0BJWjomRe2c6N+lHBNV+kTvMoy 6qe0=; b=EvCIAAn3tUaRpMVdmhLUp0nL+i7lm9HCV4cJwgmvNwpuDABWRkyigr4 QD2n1Lk8CACPwDhLLuAbm44qwOYbvOpjMKmNnx9CBU3hfgGzN6zIsOJDIWyiukd0 2jHqKsisgw+zJSvi1AOE3jJvM2TLKGgyE/KtxaIMXr2+khN0b/wGRjEDxnoHsEJY kWQtaMdsnPOBk3LTXdqsgtEmwg/IUDGUbkLVjzoYbxsW4/mkQ5U/aZQ9uAuWXbF7 /fZxcQ6Dyiw7V6lecWN/z1lUKI337yoGnrh0j0DFHiL81+P3RvZwS/z2azL+Je0o TJtdGSQRjW6XFUETTbQtNtAcQUDuLBw== 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=IOSde/vU5RC8L0BJWjomRe2c6N+lH BNV+kTvMoy6qe0=; b=vpmbvzVQot+Z1cZvwiytuiJ1a2+wKRbmoq5gH/JTMWs7U cV3atNv5Msub+f9yjxi1Ysj75va2IUvFh3SDqSczIur0ZdlF9tsVMZQZkEqzgKRW s1KDiV1vjlTQW2q6UufaH1f2RTF3AJdV4+yTop8H8caB6T/C3NNKvFHtOzxP+pRo 7ZgR1xHdvWRYH69lBYq2/88IOQB6NirdejECFXDLoRIT5sn+bTGayevMAhRB3lwm S/HIleB+60LHbQmmXgsshRudDejm1haFxHxKH3Q0ko+YzlIbhDcPVCyiyEbl7Fy1 inIZdiL7PKz9KgrGMDB59qLBHYq/kbz0Sdj236fbQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegledgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 355F630006F; Wed, 20 Nov 2019 03:03:13 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <4e0b4598-8d6e-480c-bcdb-8948ee46992d@dogfood.fastmail.com> Date: Wed, 20 Nov 2019 19:02:49 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=30835181944c4115a385ae0fe10c53d3 Archived-At: Subject: [Extra] =?utf-8?q?QUOTA=3A_is_there_any_value_in_a_separate_ANNO?= =?utf-8?q?TATION-STORAGE_quota_field=3F?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 08:03:17 -0000 --30835181944c4115a385ae0fe10c53d3 Content-Type: text/plain Right now Cyrus IMAP stores 4 things: "STORAGE", /* QUOTA_STORAGE -- RFC2087 */ "MESSAGE", /* QUOTA_MESSAGE -- RFC2087 */ "X-ANNOTATION-STORAGE", /* QUOTA_ANNOTSTORAGE */ "X-NUM-FOLDERS" /* QUOTA_NUMFOLDERS */ Three of these are covered by the new QUOTA-BIS, because X-NUM-FOLDERS becomes the "MAILBOX" quota, which is the number of mailboxes inside the quota root. My question - does anybody see any value in ANNOTATION-STORAGE as a separate quota? We could of course just merge the two values to create a total "STORAGE USED" and we'd still get a limit. To some extent this matters to Cyrus because annotations are all stored in a separate (and in Fastmail's case, more expensive SSD based) location than the emails. It would cause us grief if somebody decided to use their entire 100Gb quota on shoving large things into annotations. But I can certainly see that most users don't care - they just want to see "how much of my email quota am I using" and get a single number! So - I'm interested to hear from others - do you think it's worth asking for a separate item to be defined? Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --30835181944c4115a385ae0fe10c53d3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Right now Cyrus IMAP stores 4 things:

 &= nbsp;  "STORAGE",        &n= bsp;         /* QUOTA_STORAGE --= RFC2087 */
   = ; "MESSAGE",          =         /* QUOTA_MESSAGE -- RFC2087 *= /
    "X-ANNOT= ATION-STORAGE",     /* QUOTA_ANNOTSTORAGE */
    "X-NUM-FOLDERS"&n= bsp;            /= * QUOTA_NUMFOLDERS */

Three of these are covered by the n= ew QUOTA-BIS, because X-NUM-FOLDERS becomes the "MAILBOX" quota, which i= s the number of mailboxes inside the quota root.

My quest= ion - does anybody see any value in ANNOTATION-STORAGE as a separate quo= ta?  We could of course just merge the two values to create a total= "STORAGE USED" and we'd still get a limit.

To some exten= t this matters to Cyrus because annotations are all stored in a separate= (and in Fastmail's case, more expensive SSD based) location than the em= ails.  It would cause us grief if somebody decided to use their ent= ire 100Gb quota on shoving large things into annotations.

But I can certainly see that most users don't care - they just want to = see "how much of my email quota am I using" and get a single number!
=

So - I'm interested to hear from others - do you think it's = worth asking for a separate item to be defined?

Cheers,

Bron.
--
  Bron Gondwana, CEO, Fa= stmail Pty Ltd
  brong@fastmailte= am.com


--30835181944c4115a385ae0fe10c53d3-- From nobody Wed Nov 20 00:06:20 2019 Return-Path: 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 B0F9D12083E for ; Wed, 20 Nov 2019 00:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=Mnox1fPV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ODcZg12B 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 1cAZ5xN8vSFv for ; Wed, 20 Nov 2019 00:06:16 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11A11201AA for ; Wed, 20 Nov 2019 00:06:16 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3244E590 for ; Wed, 20 Nov 2019 03:06:16 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 03:06:16 -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=eWkyRlJHNUstbiL5IJkz8QD/lD4EI4PCi1Mdkkz 2JL8=; b=Mnox1fPVW3VcxVI9FwvY6pJ83CFYAEhVOS6b+tgmRsI9+I2qQYVogvj 6LykwXU+reu7O2pTrd/uGef8UUVeR71JZqrGqC/1Mwyau46x9aCBATd7j6iBHuwu iHkYFpQg48L5TGwcqeLjLSjQWQhb7QHuAIRivA4SYic1cexCJAA7obQuniashA2j XVoDdgOpr49IgkDUF+Jza839vArFMmaHTbzPT7eVDDXBXkAGIIoTPPwY0kVYnZJm VjStbLSmm/0evQ49jLnyRARyUYl3Q3N2Uz54E74Rb6XNyx+4Em5MDRvzqgDVyoYx GWjoOMUb3GebjO9yeNKNHOmk+k8Dlmg== 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=eWkyRlJHNUstbiL5IJkz8QD/lD4EI 4PCi1Mdkkz2JL8=; b=ODcZg12BSakriNKiUSyCiiJefwXteWhB4LZlq4Mk+eAZ4 RG7X5LEHeXxEYeyon+uYYhRL6TLdutcqmYNOYGWj9xXGMoonLYd2cgPmweecAxYV bFeiM2N1t7H1GK89J6FsrPk1JJ6QudX1ja2jwwvH5zkjwPNTEkKGtYtNuvlAX1YL s01ksdfgVVVnVBNpyO1mwgJuVGpoqZ+6NrQJcHxd8lENGlb/R/ST3zbtSQsqYyEq MXVcPR8+slmqkklQk6eXAcN3J83MqhFgjZPK9kz1Lo20B08i+PmGFePoHhERBj+R 8K6i0K4uhhvMo3IbI/VjYnJzCg5ZAAfW0MA8Ll2KQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegledgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrh honhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 65C1B30006F; Wed, 20 Nov 2019 03:06:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <43c6b1ea-8d63-4bcf-9aed-36154481b4f6@dogfood.fastmail.com> Date: Wed, 20 Nov 2019 19:06:12 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=8d42bdd77b2a4bc78b19d7650d93a3fe Archived-At: Subject: [Extra] QUOTA: representing "no limit" while still giving counts X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 08:06:19 -0000 --8d42bdd77b2a4bc78b19d7650d93a3fe Content-Type: text/plain An issue I've had with QUOTA in the past is that I've set a limit on storage but not on "number of messages". Internally, our server is storing all the counts, but it has "-1" (aka: unlimited) as the limit. There's no way in the wire protocol to indicate this. I'm not sure if it's possible to do it in a backwards compatible way other than just say "use UINT32_MAX for unlimited", but it would be nice to define that in the spec and tell clients to treat UINT32_MAX in that field as "unlimited" for display purposes. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --8d42bdd77b2a4bc78b19d7650d93a3fe Content-Type: text/html Content-Transfer-Encoding: quoted-printable
An issue I've had with QUOTA in the past is that I've set = a limit on storage but not on "number of messages".  Internally, ou= r server is storing all the counts, but it has "-1" (aka: unlimited) as = the limit.

There's no way in the wire protocol to indicat= e this.  I'm not sure if it's possible to do it in a backwards comp= atible way other than just say "use UINT32_MAX for unlimited", but it wo= uld be nice to define that in the spec and tell clients to treat UINT32_= MAX in that field as "unlimited" for display purposes.

Ch= eers,

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

--8d42bdd77b2a4bc78b19d7650d93a3fe-- From nobody Wed Nov 20 01:38:15 2019 Return-Path: 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 7E68512026E for ; Wed, 20 Nov 2019 01:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=YxjVXiII; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZoZ/smI4 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 ndhK_yGLj5Hk for ; Wed, 20 Nov 2019 01:38:11 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1D812088B for ; Wed, 20 Nov 2019 01:38:11 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7793E597; Wed, 20 Nov 2019 04:38:10 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Wed, 20 Nov 2019 04:38:10 -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:cc:subject:content-type; s=fm1; bh=wGkg kHR5NwCdZTz7mKiKtFC+WBcpWZZrmaZkloR6/ZQ=; b=YxjVXiIItjiA4n+Vu6jQ p4Mcil2Ox9qm0RcolppBUzjDMAp9qtKByR7xuaU7r/jnH9I+DLDtpB/IU/236BQU 7+MWDEJdLgoiE2nCvdi9P/2bu8jzoukwQcFbPdh9L4AhDp3FGR7LyZvDizZx3UhM RDMQTWs877Txmj+qbsG7lfQ59y9xX6s0A7CZ1xncmyF2wdTGYeJTbZPUKuZFM4X4 L70Uo9V1K4glBU6rieMtMerYtRmMpDLzN5AgDEoJcsXpGzmUlnRV88gDqImLSbaH wDa67FA9ugASbz9VAIM0k07l09UxvQz3Ovpu8qhHMYNnvR/NsbJRGhc+ilu3pidY XQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=wGkgkH R5NwCdZTz7mKiKtFC+WBcpWZZrmaZkloR6/ZQ=; b=ZoZ/smI46VX8uLYPJIjTDc 7/UtwIkCOiPv/OHx1qgwtM+szVzCkQ0Yu3daV7KAPtwdciI/3jlm3nFyl9SQ7nxa QLRM3WEsm7hutLiIV3RS46wxbwkCB/dUEeRlOdeUhX+IqYhk/7qJBTKFAK+Wiu1L RsDjjYjbpToZXGkhDOVYbyKdbLuyWIHu9C4X5J6JD82TZgoaogE0cJQALnMn78qv c5XLOaLmTxV5KX1Nm4zeqzaB9uj7BUuwXxj4JvdTKt6Ovr1JDqn8jrUiJFR8f4BA GUBXTPPXSMokk7W5nRGEMQE0q5dCNa6zG3JyyhxzOI2twhDHwMXv/StUfAuw+ZDQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehtddgtdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggr mhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9654230006F; Wed, 20 Nov 2019 04:38:09 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <3ee0cfe0-4763-42e9-8446-518294382539@dogfood.fastmail.com> In-Reply-To: <77D3433C-4CF4-485A-A2FB-42D80E94889D@sirainen.com> References: <43c6b1ea-8d63-4bcf-9aed-36154481b4f6@dogfood.fastmail.com> <77D3433C-4CF4-485A-A2FB-42D80E94889D@sirainen.com> Date: Wed, 20 Nov 2019 20:38:07 +1100 From: "Bron Gondwana" To: "Timo Sirainen" Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=67fe222ee7c446c5b9ed99e74ca3834c Archived-At: Subject: Re: [Extra] QUOTA: representing "no limit" while still giving counts X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 09:38:13 -0000 --67fe222ee7c446c5b9ed99e74ca3834c Content-Type: text/plain On Wed, Nov 20, 2019, at 20:36, Timo Sirainen wrote: > On 20. Nov 2019, at 10.06, Bron Gondwana wrote: >> >> An issue I've had with QUOTA in the past is that I've set a limit on storage but not on "number of messages". Internally, our server is storing all the counts, but it has "-1" (aka: unlimited) as the limit. >> >> There's no way in the wire protocol to indicate this. I'm not sure if it's possible to do it in a backwards compatible way other than just say "use UINT32_MAX for unlimited", but it would be nice to define that in the spec and tell clients to treat UINT32_MAX in that field as "unlimited" for display purposes. > What's wrong with just not sending the MESSAGE reply when it's unlimited? Sometimes it's nice to know how much of something you have even when you don't have a limited bucket. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --67fe222ee7c446c5b9ed99e74ca3834c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2019, at 20:36, Timo Sirainen wrote:
On 20. Nov 2019, at 10.06, Bron Gondwana <brong@fastmailteam.com> wrote:
=

An i= ssue I've had with QUOTA in the past is that I've set a limit on storage= but not on "number of messages".  Internally, our server is storin= g all the counts, but it has "-1" (aka: unlimited) as the limit.

There's = no way in the wire protocol to indicate this.  I'm not sure if it's= possible to do it in a backwards compatible way other than just say "us= e UINT32_MAX for unlimited", but it would be nice to define that in the = spec and tell clients to treat UINT32_MAX in that field as "unlimited" f= or display purposes.
What's wrong= with just not sending the MESSAGE reply when it's unlimited?
<= /blockquote>

Sometimes it's nice to know how much of something you = have even when you don't have a limited bucket.

Bron.
=
--
<= div class=3D"signature">  Bron Gondwana, CEO, Fastmail Pty Ltd
<= /div>
  brong@fastmailteam.com

=
--67fe222ee7c446c5b9ed99e74ca3834c-- From timo@sirainen.com Wed Nov 20 01:36:25 2019 Return-Path: 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 BFAF4120AC6 for ; Wed, 20 Nov 2019 01:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FyCXqCaMRX_9 for ; Wed, 20 Nov 2019 01:36:24 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id DDD231208E6 for ; Wed, 20 Nov 2019 01:36:23 -0800 (PST) Received: from [192.168.10.100] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 664222B3C7E; Wed, 20 Nov 2019 09:36:22 +0000 (UTC) From: Timo Sirainen Message-Id: <77D3433C-4CF4-485A-A2FB-42D80E94889D@sirainen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B6FFA40-5FD8-4D92-A318-FA9FF6483E14" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 20 Nov 2019 11:36:21 +0200 In-Reply-To: <43c6b1ea-8d63-4bcf-9aed-36154481b4f6@dogfood.fastmail.com> Cc: extra@ietf.org To: Bron Gondwana References: <43c6b1ea-8d63-4bcf-9aed-36154481b4f6@dogfood.fastmail.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: X-Mailman-Approved-At: Wed, 20 Nov 2019 01:40:38 -0800 Subject: Re: [Extra] QUOTA: representing "no limit" while still giving counts X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 09:37:58 -0000 --Apple-Mail=_8B6FFA40-5FD8-4D92-A318-FA9FF6483E14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20. Nov 2019, at 10.06, Bron Gondwana wrote: >=20 > An issue I've had with QUOTA in the past is that I've set a limit on = storage but not on "number of messages". Internally, our server is = storing all the counts, but it has "-1" (aka: unlimited) as the limit. >=20 > There's no way in the wire protocol to indicate this. I'm not sure if = it's possible to do it in a backwards compatible way other than just say = "use UINT32_MAX for unlimited", but it would be nice to define that in = the spec and tell clients to treat UINT32_MAX in that field as = "unlimited" for display purposes. What's wrong with just not sending the MESSAGE reply when it's = unlimited? --Apple-Mail=_8B6FFA40-5FD8-4D92-A318-FA9FF6483E14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 20. Nov 2019, at 10.06, Bron Gondwana <brong@fastmailteam.com> wrote:

An issue I've had = with QUOTA in the past is that I've set a limit on storage but not on = "number of messages".  Internally, our server is storing all the = counts, but it has "-1" (aka: unlimited) as the limit.

There's no way in the wire = protocol to indicate this.  I'm not sure if it's possible to do it = in a backwards compatible way other than just say "use UINT32_MAX for = unlimited", but it would be nice to define that in the spec and tell = clients to treat UINT32_MAX in that field as "unlimited" for display = purposes.

What's wrong with just not sending the MESSAGE = reply when it's unlimited?

= --Apple-Mail=_8B6FFA40-5FD8-4D92-A318-FA9FF6483E14-- From nobody Wed Nov 20 01:51:59 2019 Return-Path: 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 0B203120803 for ; Wed, 20 Nov 2019 01:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XtNjXC44DFJZ for ; Wed, 20 Nov 2019 01:51:57 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id DB0F81200B2 for ; Wed, 20 Nov 2019 01:51:56 -0800 (PST) Received: from [192.168.10.100] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 30EC02B3C7E for ; Wed, 20 Nov 2019 09:51:56 +0000 (UTC) From: Timo Sirainen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 20 Nov 2019 11:51:55 +0200 References: <157421778511.5379.340076662534945028@ietfa.amsl.com> To: extra@ietf.org In-Reply-To: <157421778511.5379.340076662534945028@ietfa.amsl.com> Message-Id: <431A7507-03AF-4563-9027-C880CD81EEC3@sirainen.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-08.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 09:51:58 -0000 On 20. Nov 2019, at 4.43, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Email mailstore and eXtensions To = Revise or Amend WG of the IETF. >=20 > Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION = 4rev2 > Authors : Alexey Melnikov > Barry Leiba > Filename : draft-ietf-extra-imap4rev2-08.txt > Pages : 147 > Date : 2019-11-19 Something went wrong with this one. It adds some weirdly duplicate half = empty lines for e.g. $Forwarded, $MDNSent, SIZE, etc. There are also a = lot of new paragraph breaks, which I don't know if they're intentional = or not, but surely not this one: > The IDLE command is sent from the client to the server when the > client is ready to accept unsolicited mailbox >=20 > update messages. The server requests a response to the IDLE = command or: > Servers advertising both IMAP4rev1 and IMAP4rev2 SHOULD NOT >=20 > generate UTF-8 quoted strings unless the client has issued "ENABLE From nobody Wed Nov 20 03:47:20 2019 Return-Path: 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 B96A6120AC7 for ; Wed, 20 Nov 2019 03:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 yRjQ4cH6P1OX for ; Wed, 20 Nov 2019 03:47:18 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F52120AC6 for ; Wed, 20 Nov 2019 03:47:18 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 43A1EC0075; Wed, 20 Nov 2019 11:51:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1574250667; bh=7iAEOJYShKpyTqcMB8Pe2c8U+HaWaroCFHjcz5smpB4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KVNKVISOnuBJXVrTwx35Oa3HjQtJaeXehiHk08UBXcCnGDocZOniH/gmUSxYNwbrQ tYO9T14evSpxhjf9bC1PrAZ3wgQ3FGHJuSy9hBEQEshuFDJfY6OYVrzJypdG4L1b4A MWKmuHltOqdzSBuQ1KriHz/Rcg3IhRTCh3wDkJ/4= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1574250666-28749-28747/9/15; Wed, 20 Nov 2019 11:51:06 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Wed, 20 Nov 2019 12:47:14 +0100 Mime-Version: 1.0 Message-Id: <2cc95212-9c81-40d7-acbf-48e5f8873732@gulbrandsen.priv.no> In-Reply-To: References: <51568edb-792c-46b7-a2b2-3f0a1ac91997@dogfood.fastmail.com> <9583d392-d699-486a-9111-b8a0288d2cda@dogfood.fastmail.com> User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.1 (ascii) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] In favour of OBJECTID being inculded in IMAP4REV2 - 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 11:47:20 -0000 On Wednesday 20 November 2019 08:55:26 CET, Neil Jenkins wrote: > On Wed, 20 Nov 2019, at 15:49, Bron Gondwana wrote: > 2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken > the MUSTs around keeping IDs the same. > > I am not in favour of this. It basically removes the whole > point of OBJECTID. If it's mandatory, you need to implement it > properly. Either mandatory or not is fine (I'd prefer it in, but > worth consulting implementors), but let's not change its > semantics. Does it really remove the whole point? I see two kinds of MUSTs: Two equal IDs MUST refer to they same object Two different IDs MUST refer to different objects The former has to be a MUST, but the latter could be downgraded to SHOULD and still leave significant value.... unless I'm overlooking something? Arnt From nobody Wed Nov 20 09:58:47 2019 Return-Path: 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 56E2312013A for ; Wed, 20 Nov 2019 09:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 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, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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=open-xchange.com 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 3OBo9DdFD2Kc for ; Wed, 20 Nov 2019 09:58:44 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75CD1200E6 for ; Wed, 20 Nov 2019 09:58:43 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 880DC6A27D; Wed, 20 Nov 2019 18:58:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574272721; bh=0OO/ukI1Rx1rlc8zeEr7a15wvcb23Lc53FD183p6vlo=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=Qw9vUw12Zjn40kDOJdUFF6s47vtcKL7Yl4KW/0Ku0foolOJ8Rs7jd05ZTFnnwOofO azQYNVjkLvvtz1sda/ZpPkmEHJT4jgFOXzkadsk2phgk29roau/wnXrbtfxbXY/hVh qBKep3GijOEB0SJUqVYI5y0CA9Xg+n4GvOQAMWMLmgNdjq6WLmIfX94YNm0hBzP0Vo eOl8wSo2/iZlBwycJNXlP44Sld7fvJQKNKEFlRdyh97szRSseB4tjDE+ZI1eUZgeIr RfW6TSZCPNIyk2bBvxOYlrIwiLcHQlssvRXz9mPNNnIFwFYxYptcvj9tddO1Fi1xU4 gPA47viImTVAQ== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 7A92A3C0101; Wed, 20 Nov 2019 18:58:41 +0100 (CET) Date: Wed, 20 Nov 2019 10:58:41 -0700 (MST) From: Michael Slusarz Reply-To: Michael Slusarz To: Bron Gondwana , extra@ietf.org Message-ID: <779461021.18132.1574272721408@appsuite-gw2.open-xchange.com> In-Reply-To: <9583d392-d699-486a-9111-b8a0288d2cda@dogfood.fastmail.com> References: <51568edb-792c-46b7-a2b2-3f0a1ac91997@dogfood.fastmail.com> <9583d392-d699-486a-9111-b8a0288d2cda@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=michael.slusarz@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFdRf+ABCACjsnzeuEJqUrZHnmyTL0r8JwN0YF6ZS/hgHYx83/dhz2LRgq0bkl5FSYPc6ZY7j7G NqvvPxR4Ri6xfevym91IhdJbQaiJ2B0kWAz+p4H/iXhgZwsYdjFN/c3+MPEjSazCPwASWCDHv2ueCay 0YO2dmw9TnR6rA6GiReQPGumgCZJ4xX8AUBUQftdJOrq/fl1xpYWrsFrTIfBml1x3Q4Mf3+ocH7ZT/u SST2IJTx4a9szQcnrsVHn/Fc2wp4P4FkW87sQFpLND80E5VAwxEdCAtQrhoocUfmh3LyyIncAOIRdw0 aR/1PSgwuj8A2c1W0DRYuzCNaGveugCT6GmbF7qbABEBAAG5AQ0EV1F/4AEIAJ98e4BRvKeJSzSqybD ZzOcphkUy+PlMrhkQkc2m36U01+4E9AtUz3XGNIJE+in9yYKqXbtHJCavOPcFhktVGFvSADKT311ZXq Cx/ibvrWI/DmoBCCIY9iwrutJX08nOoj53wpiNVOuR6vGFJIHO7TNosPcWWsw16LiZIwo9GiU2KseU/ xW0h26ouPbVqVpFX1Tgv+xaCBF8rj4kgoghnvTVG5aEgF+QExOLqx6BmarePKboTFVnMk6NYAwC5TtJ DfpWqa/5vQa8oVAex09elUrN+IQM/tcbMG+tAe5mhjJCke96tdEno29KYjs3Ecl9t1GMcsVAM1k8D8J DJzPCB/cAEQEAAYkBMQQYAQIAGwUCV1F/4AIbDAQLCQgHBhUKCQgLAgUJEswDAAAKCRAH1y6/pl54M6 obB/9AbXRu5SYhYrmTMFGDNqq0BKeoeS1n6cA2rvYRPmmwKSd9/sZG6815X8worSUjPb4r0P/9UoUUy P99BIN0aKc/7baCCV2/00fITrW0sS5Es2xuDuwcRAwwMJX09yMDeCu6M0Y2kn8QjKr1Pu87isoxliQz QDdsYJd9b/iSPFAW+sV7xYlkVcw4XoXYolQTUjNBuWbl6tV6dQN66m6RnCnB1uolFtbZENRiVcHOAdI DmYMjX3UL8cMtqpMyAXe0HTkb1BK2I5m4Kz0thK+beBBLyd6M4bK45zI6L3f5oDOty9o2jAnxlSVdUi ZfBSBypOekOX0bw2w/4XtUoS9emDRk Archived-At: Subject: Re: [Extra] In favour of OBJECTID being inculded in IMAP4REV2 - 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 17:58:46 -0000
On November 20, 2019 12:49 AM Bron Gondwana <brong@fastmailteam.com> wrote:


On Mon, Nov 18, 2019, at 20:50, Bron Gondwana wrote:
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

I was reminded off list that the final text in RFC8474 made it MUST be the same value, so it's not as easy as all that to have the objectid change on MOVE or RENAME and be totally compliant.

Some options:
1) insist on remaining exactly compliant.
2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken the MUSTs around keeping IDs the same.
3) OK, leave OBJECTID as optional and don't include it in IMAP4REV2.
Dovecot response:
  • Our previous thoughts: https://mailarchive.ietf.org/arch/msg/extra/9-hEpNOrcJryfMgMYkhrgqSPs8Q
  • New thoughts: MAILBOXID/EMAILID is ok for rev2
  • Dovecot already tracks this internally, so we have work-in-progress code to expose this already
  • Agree that MAILBOXID/EMAILID should not be "fake", but should be persistent - a server should do this right, rather than trying to fake it with on-demand digest generation.  So I think this is a vote for #1 of Bron's options.  This requirement (assigning a non-ephemeral uniqueid per message/mailbox) doesn't seem any more onerous than keeping a UID associated with a specific message.
  • THREADID comment from Timo (so he can expand on this, if needed): "I wonder if it would be ok to have MAILBOXID and EMAILID in the base spec, while THREADID would exist only if OBJECTID capability exists. Slightly nicer than just returning NILs as THREADIDs."

michael
From nobody Thu Nov 21 19:10:40 2019 Return-Path: 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 E5668120836 for ; Thu, 21 Nov 2019 19:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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=Bp/4kv3e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i7A3+yJp 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 rv-6AJm9zBV6 for ; Thu, 21 Nov 2019 19:10:36 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E1312018B for ; Thu, 21 Nov 2019 19:10:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id F2091D92; Thu, 21 Nov 2019 22:10:35 -0500 (EST) Received: from imap99 ([10.202.2.99]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 22:10:36 -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=fm1; bh=l3V48O+ JN9KX3aEcGGU06pF7fphz8Q92SnzMsb5oa6o=; b=Bp/4kv3eOe+o9dbaIbtK1TA KJdhyq2JIfHrUMTj0FU6IYyj/hfx69yZyMJ/gKbsZ/sDa3oqhTsY3Ea5Zy59w+3m GirZF8T8CSnelKwY2zvgTuXEk4eVHoezFOBKaRqQ7gcIXHh1NpnMFNiq9Fx11kA1 kIXkk7sZNfEM4sR2ZyDR2PUKdoeuQETf/qTwF6OkiCNrPndhvgf1EieGhaPDf818 qrFAsaFKR8U+VHtwDFYFcUB/BXZE4ZcLKjx3tWiljRaCz/HTxaXQ7ubjvr7nNRPk LAM9IC5HSGMWSR4foKB/uouztyY5Hmi1jEvp1qFNEQSShAD7DLu2j/FI58yTydg= = 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=fm1; bh=l3V48O +JN9KX3aEcGGU06pF7fphz8Q92SnzMsb5oa6o=; b=i7A3+yJp2KWHoOKHq6pU3X 457JBwT8yRDjfgXFo+NxEQJhXf4uEeuRd8Y2PA61d7JaIuhubiYgYr5Hj5k5CTfO +4bgKqtF1qL16AyL5n6clqJDaKjP6YUH4nsDe38/0OwRP7gMO8U9Lsl86PYO0QOb LABi4tIaclrqIpTCL+m8T1mgOUdrezwDiY7a4qFJ28sGr7c+o40BXqTGOGYvWH3t rmvONkheua7FopDOJR5uxAoJ/8AWCiamH20FFW9sJlDP1fFJvawtgzEW1Tfi57MS D/OfYyn6SO6+VFu1LkDPs94smzv7FuLrj/mmqApyHLYiTeL+MXCEcp2jbiSr6FUA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehfedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhep sghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A28B300DAA; Thu, 21 Nov 2019 22:10:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <7397ac9a-b2cf-49a1-a620-9c2ae1b18d0a@dogfood.fastmail.com> In-Reply-To: <779461021.18132.1574272721408@appsuite-gw2.open-xchange.com> References: <51568edb-792c-46b7-a2b2-3f0a1ac91997@dogfood.fastmail.com> <9583d392-d699-486a-9111-b8a0288d2cda@dogfood.fastmail.com> <779461021.18132.1574272721408@appsuite-gw2.open-xchange.com> Date: Fri, 22 Nov 2019 14:10:32 +1100 From: "Bron Gondwana" To: "Michael Slusarz" , extra@ietf.org Content-Type: multipart/alternative; boundary=75206f3d15de432bb7df15bcdb77961d Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 03:10:39 -0000 --75206f3d15de432bb7df15bcdb77961d Content-Type: text/plain Thanks Michael, I've discussed this with Alexey and Barry today, and we've decided not to *require* OBJECTID in the base spec, but to add a section of "recommended other extensions" to the base spec which mentions the benefits of implementing OBJECTID. Bron. On Thu, Nov 21, 2019, at 04:58, Michael Slusarz wrote: >> On November 20, 2019 12:49 AM Bron Gondwana wrote: >> >> >> On Mon, Nov 18, 2019, at 20:50, Bron Gondwana wrote: >>> 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 >> >> I was reminded off list that the final text in RFC8474 made it MUST be the same value, so it's not as easy as all that to have the objectid change on MOVE or RENAME and be totally compliant. >> >> Some options: >> 1) insist on remaining exactly compliant. >> 2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken the MUSTs around keeping IDs the same. >> 3) OK, leave OBJECTID as optional and don't include it in IMAP4REV2. > Dovecot response: > * Our previous thoughts: https://mailarchive.ietf.org/arch/msg/extra/9-hEpNOrcJryfMgMYkhrgqSPs8Q > * New thoughts: MAILBOXID/EMAILID is ok for rev2 > * Dovecot already tracks this internally, so we have work-in-progress code to expose this already > * Agree that MAILBOXID/EMAILID should not be "fake", but should be persistent - a server should do this right, rather than trying to fake it with on-demand digest generation. So I think this is a vote for #1 of Bron's options. This requirement (assigning a non-ephemeral uniqueid per message/mailbox) doesn't seem any more onerous than keeping a UID associated with a specific message. > * THREADID comment from Timo (so he can expand on this, if needed): "I wonder if it would be ok to have MAILBOXID and EMAILID in the base spec, while THREADID would exist only if OBJECTID capability exists. Slightly nicer than just returning NILs as THREADIDs." > michael > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --75206f3d15de432bb7df15bcdb77961d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Michael,

I've discussed this with Al= exey and Barry today, and we've decided not to require OBJECTID i= n the base spec, but to add a section of "recommended other extensions" = to the base spec which mentions the benefits of implementing OBJECTID.

Bron.

On Thu, Nov 21, 2019, at 04:58, Michael Slusarz wrote:
On Nove= mber 20, 2019 12:49 AM Bron Gondwana <brong@fastmailteam.com> wrot= e:


On Mon, Nov 18, 2019, at 20:50, Bron Gondwana wrote:
Also - if your se= rver 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

I was reminded off list tha= t the final text in RFC8474 made it MUST be the same value, so it's not = as easy as all that to have the objectid change on MOVE or RENAME and be= totally compliant.

Some options:
1) insist on remaining exactly compliant.
2) include RFC8474 naming and behavio= ur in IMAP4REV2 but weaken the MUSTs around keeping IDs the same.
3) OK, leave OBJECTID as optional = and don't include it in IMAP4REV2.
Dovec= ot response:
  • Our previous thoughts: https:/= /mailarchive.ietf.org/arch/msg/extra/9-hEpNOrcJryfMgMYkhrgqSPs8Q
    =
  • New thoughts: MAILBOXID/EMAILID is ok for rev2
  • Dove= cot already tracks this internally, so we have work-in-progress code to = expose this already
  • Agree that MAILBOXID/EMAILID should not = be "fake", but should be persistent - a server should do this right, rat= her than trying to fake it with on-demand digest generation.  So I = think this is a vote for #1 of Bron's options.  This requirement (a= ssigning a non-ephemeral uniqueid per message/mailbox) doesn't seem any = more onerous than keeping a UID associated with a specific message.
    <= /li>
  • THREADID comment from Timo (so= he can expand on this, if needed): "I wonder if it would be ok to have = MAILBOXID and EMAILID in the base spec, while THREADID would exist only = if OBJECTID capability exists. Slightly nicer than just returning NILs a= s THREADIDs."
michael=
_______________________________________________
Extra mailing list
Extra@ietf.org
https://www.ietf.org/mailman/listinfo/extra


--
&nb= sp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

<= /div>

--75206f3d15de432bb7df15bcdb77961d-- From nobody Sun Nov 24 23:43:28 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B0D120824; Sun, 24 Nov 2019 23:43:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <157466780579.32643.12730934158758662608@ietfa.amsl.com> Date: Sun, 24 Nov 2019 23:43:25 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-09.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 07:43:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-09.txt Pages : 148 Date : 2019-11-24 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-09 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 26 00:09:19 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8A12083D; Tue, 26 Nov 2019 00:09:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <157475575695.13585.15518657468804932544@ietfa.amsl.com> Date: Tue, 26 Nov 2019 00:09:17 -0800 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-10.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 08:09:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-10.txt Pages : 150 Date : 2019-11-26 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-10 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/