From nobody Fri Jun 5 23:42:15 2020 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 245793A0A7B for ; Fri, 5 Jun 2020 23:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=kIgcyZjU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ny7cA5ct 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 e9-hypkZ8li0 for ; Fri, 5 Jun 2020 23:42:11 -0700 (PDT) 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 DBEBB3A0B48 for ; Fri, 5 Jun 2020 23:42:09 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 364AA5C0179 for ; Sat, 6 Jun 2020 02:42:09 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sat, 06 Jun 2020 02:42:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=Z3q20AwtESr7HYuy8EVdiQpmi2dcgVPiafg+f98 UDJc=; b=kIgcyZjUjYSuLKnckpr8HEGK9tsKU8uFEjd0hXKlMhZ7VRSLVB1v2Jf Fe0SyvsHF7tL73+jg8ABQrVSgAWVUYXM/W2vKHphcK28TJ0PGscJcAhd1A6WsAcH zZLlkYfCFgY3Rn/5W5ewOBP3AMdc+gWfU9I2Beg/Kd4LSNtqywEwhjTS95NAH97u eRQQaoHRedXWpnnBikHnTF+y+SKvpxaWpVn/9zlbXBN8d2F5Sko/Sr9T0lKuA6VK uDzWQXTuJ3HdClaepo36ko9HJ+q23SgPRqg9emJtxXI6KJYKO2Z++1ds+AdG7njc yQoJNl1zGe08bjIaIcg+Uz1BNoygo4Q== 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=fm3; bh=Z3q20AwtESr7HYuy8EVdiQpmi2dcg VPiafg+f98UDJc=; b=ny7cA5ctDrkM/WiVNdiOf6a3H17Vhvel9Btcf4/5E27aU nxWhRov5p709YxeLl8KpuckgHDxquiot0WP+7CWzRotKXDShm1ubPPp96iPpfYeX PjYTwvxqrmpFcSpVO0gakSYOfSKwCHdvMagEXQpaiYWyYaLJEMgMMFDTugWZ8TG5 GUsKfi5t8deYDzgRKruj6a8b+G1fV7PyP+jAZFrDn9FPVzA/eStGN27tnXflGmyu e2KHZ2VRatF1oohE1RrlHJLHREXu2O3gOZOHfJTiK++iVmQA4kYkYlFreQvFIc2Y alaVSFXzQd+HqHbxKfZSdkFMj3R3bfyvx+Jpebxlg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeggedguddtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihf egiedtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E26DA180091; Sat, 6 Jun 2020 02:42:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <9d20f8a5-9441-47ba-b2f3-c2ee87f97a81@dogfood.fastmail.com> Date: Sat, 06 Jun 2020 16:41:48 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=bfd380c7fe794cc69648e44f78650f92 Archived-At: Subject: [Extra] Do we need a session at IETF108? 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: Sat, 06 Jun 2020 06:42:13 -0000 --bfd380c7fe794cc69648e44f78650f92 Content-Type: text/plain Hi Extra-ordinary people, We have an interim meeting scheduled in a couple of weeks, where we'll be mostly talking about IMAP4rev2 I'm sure. We need to decide BEFORE then whether we will also be meeting at the IETF108 virtual meeting in not-Madrid. Does anybody have a strong opinion on this? I'm inclined not to take up a time slot unless people thing there's valuable work which is better done during the official IETF108 times. I'll be attending anyway because I plan to run a JMAP session, but I feel that EXTRA has less need to meet during a virtual IETF. Let me know, pretty much if anyone thinks it's going to be worth having the session I'll ask for it - they're always a pleasant way to spend some time. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --bfd380c7fe794cc69648e44f78650f92 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Extra-ordinary people,

We have an interi= m meeting scheduled in a couple of weeks, where we'll be mostly talking = about IMAP4rev2 I'm sure.  We need to decide BEFORE then whether we= will also be meeting at the IETF108 virtual meeting in not-Madrid.
<= /div>

Does anybody have a strong opinion on this?  I'm incline= d not to take up a time slot unless people thing there's valuable work w= hich is better done during the official IETF108 times.  I'll be att= ending anyway because I plan to run a JMAP session, but I feel that EXTR= A has less need to meet during a virtual IETF.

Let me kno= w, pretty much if anyone thinks it's going to be worth having the sessio= n I'll ask for it - they're always a pleasant way to spend some time.

Cheers,

Bron.

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


--bfd380c7fe794cc69648e44f78650f92-- From nobody Wed Jun 10 05:50:46 2020 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 798673A07B6 for ; Wed, 10 Jun 2020 05:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 ZLiBs2J5LJcP for ; Wed, 10 Jun 2020 05:50:44 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2D75F3A07B1 for ; Wed, 10 Jun 2020 05:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591793443; d=isode.com; s=june2016; i=@isode.com; bh=siNH89lAKnjtQxVhPoBz68GOhfszrU3/SEcQwLUhC68=; 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=vYwBKIkcm5X+QhprluC37FmloSSvuYmmxfNCD/6JohXytMj/ltUKmoHVETC2TERlICzQiY Hizzf9pcMwJgBtjaqruZNRJZh6AI8QRec0fKn13aaCwI9vV+dxlE9dmTRsEYqa+QKJIC2Y ELnSblyZUhzJLA39Y9T4ditJ+Y5GcEg=; Received: from [172.27.248.7] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 10 Jun 2020 13:50:41 +0100 To: Bron Gondwana , extra@ietf.org References: <9d20f8a5-9441-47ba-b2f3-c2ee87f97a81@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: <345bfd7c-f16e-c9b2-1697-da66929086d0@isode.com> Date: Wed, 10 Jun 2020 13:50:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <9d20f8a5-9441-47ba-b2f3-c2ee87f97a81@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7066F2A2899E4EC2E35D291B" Content-Language: en-GB Archived-At: Subject: Re: [Extra] Do we need a session at IETF108? 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, 10 Jun 2020 12:50:46 -0000 --------------7066F2A2899E4EC2E35D291B Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bron, On 06/06/2020 07:41, Bron Gondwana wrote: > Hi Extra-ordinary people, > > We have an interim meeting scheduled in a couple of weeks, where we'll=20 > be mostly talking about IMAP4rev2 I'm sure.=C2=A0 We need to decide BEFORE= =20 > then whether we will also be meeting at the IETF108 virtual meeting in=20 > not-Madrid. > > Does anybody have a strong opinion on this?=C2=A0 I'm inclined not to take= =20 > up a time slot unless people thing there's valuable work which is=20 > better done during the official IETF108 times.=C2=A0 I'll be attending=20 > anyway because I plan to run a JMAP session, but I feel that EXTRA has=20 > less need to meet during a virtual IETF. > > Let me know, pretty much if anyone thinks it's going to be worth=20 > having the session I'll ask for it - they're always a pleasant way to=20 > spend some time. I think it will really depend on what actions items we come up after the=20 EXTRA session next week and AD review of IMAP4rev2. Maybe ask for a shared slot between JMAP and EXTRA? Best Regards, Alexey --------------7066F2A2899E4EC2E35D291B Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bron,

On 06/06/2020 07:41, Bron Gondwana wrote:
Hi Extra-ordinary people,

We have an interim meeting scheduled in a couple of weeks, where we'll be mostly talking about IMAP4rev2 I'm sure.=C2=A0 We need to decide BEFORE then whethe= r we will also be meeting at the IETF108 virtual meeting in not-Madrid.

Does anybody have a strong opinion on this?=C2=A0 I'm inclined not to take up a time slot unless people thing there's valuable work which is better done during the official IETF108 times.=C2=A0 I'll be attending anyway because I pla= n to run a JMAP session, but I feel that EXTRA has less need to meet during a virtual IETF.

Let me know, pretty much if anyone thinks it's going to be worth having the session I'll ask for it - they're always a pleasant way to spend some time.

I think it will really depend on what actions items we come up after the EXTRA session next week and AD review of IMAP4rev2.

Maybe ask for a shared slot between JMAP and EXTRA?

Best Regards,

Alexey

--------------7066F2A2899E4EC2E35D291B-- From nobody Wed Jun 10 05:53:41 2020 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 5FDF13A07BF for ; Wed, 10 Jun 2020 05:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=cFTlRdeB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=btToUMvh 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 URfs-lAY5KLK for ; Wed, 10 Jun 2020 05:53:38 -0700 (PDT) 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 1B6693A07BE for ; Wed, 10 Jun 2020 05:53:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 515025C0095 for ; Wed, 10 Jun 2020 08:53:37 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 08:53:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=jCYcVBZ 8DvBUUpVOGu+98EudZLv6t04eF77U2edSCxI=; b=cFTlRdeBZYso8pt2O9NOBmX U7SXpy5rq/OXQEhAvH50thpxyhNgAhy4XTQVTZ4H9QkfzQrY8fFF33sfJsI6xEHv EJR163GdE4jxZbdbM507WV9zHpYYmPM3wRiXU0fDSLxy6IRpSSNNBB39ydTwsIVy +ULlzlVyllB98rFSXod4n/M31e8ELGsAZn7GDOczVUZBAs33GWfIjulOuvobb5Cv otdP/c7Fgy4eTt5BzlMDa84Qepf2iAEdmC1zTKRd5aTG7kLemJwBepnynvYMNwQQ P0IIHdcpvvrhBTVyhzsLowIsK2oQCSonkMkdERwtcvCRBPcxZ1SnFwNpMopP2mA= = 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=fm3; bh=jCYcVB Z8DvBUUpVOGu+98EudZLv6t04eF77U2edSCxI=; b=btToUMvhGhwNlraBHx6QJX tIVCHGu5WNZ2q/uRjq46bhKkjxeBz8tCewjlRhMkJheHQfPsKA/gUPmUNIi9o2vN a0k7+qoAZ3YtcuDRNYLeREnrbwPHtvhb5x2q/rQmthJux8Nr7awWzinzUs+rpDIG KTJy4vME0qAUp9FWMEviDFGn7pDvzWwQRr+rPvwEm/7OQbd+LEUK5zRYj/mCpATl T70rm/MlAx6/B//5loN8XPmsbF419wj+nbriCVag/445HxXxdTuvrtn1aSsKKMNl ji/g18to1mOSnMmqEftjGTkk2VXD8WH3b15IjHMOfQZRTzcsiz7C8VWLdReCDXPA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 05AEB180091; Wed, 10 Jun 2020 08:53:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: In-Reply-To: <345bfd7c-f16e-c9b2-1697-da66929086d0@isode.com> References: <9d20f8a5-9441-47ba-b2f3-c2ee87f97a81@dogfood.fastmail.com> <345bfd7c-f16e-c9b2-1697-da66929086d0@isode.com> Date: Wed, 10 Jun 2020 22:53:15 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=2a940c5cb3e6400bbf229a4a0d88a20c Archived-At: Subject: Re: [Extra] Do we need a session at IETF108? 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, 10 Jun 2020 12:53:39 -0000 --2a940c5cb3e6400bbf229a4a0d88a20c Content-Type: text/plain On Wed, Jun 10, 2020, at 22:50, Alexey Melnikov wrote: > Hi Bron, > On 06/06/2020 07:41, Bron Gondwana wrote: >> Hi Extra-ordinary people, >> >> We have an interim meeting scheduled in a couple of weeks, where we'll be mostly talking about IMAP4rev2 I'm sure. We need to decide BEFORE then whether we will also be meeting at the IETF108 virtual meeting in not-Madrid. >> >> Does anybody have a strong opinion on this? I'm inclined not to take up a time slot unless people thing there's valuable work which is better done during the official IETF108 times. I'll be attending anyway because I plan to run a JMAP session, but I feel that EXTRA has less need to meet during a virtual IETF. >> >> Let me know, pretty much if anyone thinks it's going to be worth having the session I'll ask for it - they're always a pleasant way to spend some time. > I think it will really depend on what actions items we come up after the EXTRA session next week and AD review of IMAP4rev2. > Maybe ask for a shared slot between JMAP and EXTRA? > Best Regards, > Alexey I currently have a 50 min slot for JMAP - I could extend that to ask for a 140 min slot instead for both! Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --2a940c5cb3e6400bbf229a4a0d88a20c Content-Type: text/html
On Wed, Jun 10, 2020, at 22:50, Alexey Melnikov wrote:

Hi Bron,

On 06/06/2020 07:41, Bron Gondwana wrote:
Hi Extra-ordinary people,

We have an interim meeting scheduled in a couple of weeks, where we'll be mostly talking about IMAP4rev2 I'm sure.  We need to decide BEFORE then whether we will also be meeting at the IETF108 virtual meeting in not-Madrid.

Does anybody have a strong opinion on this?  I'm inclined not to take up a time slot unless people thing there's valuable work which is better done during the official IETF108 times.  I'll be attending anyway because I plan to run a JMAP session, but I feel that EXTRA has less need to meet during a virtual IETF.

Let me know, pretty much if anyone thinks it's going to be worth having the session I'll ask for it - they're always a pleasant way to spend some time.

I think it will really depend on what actions items we come up after the EXTRA session next week and AD review of IMAP4rev2.

Maybe ask for a shared slot between JMAP and EXTRA?

Best Regards,

Alexey


I currently have a 50 min slot for JMAP - I could extend that to ask for a 140 min slot instead for both!

Bron.

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


--2a940c5cb3e6400bbf229a4a0d88a20c-- From nobody Wed Jun 10 05:54:32 2020 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 A4F073A0823 for ; Wed, 10 Jun 2020 05:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=X0CYRuTm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vDb5Nnt6 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 HB1cCm0B8lpr for ; Wed, 10 Jun 2020 05:54:29 -0700 (PDT) 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 1D6DA3A081D for ; Wed, 10 Jun 2020 05:54:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BD2095C0095 for ; Wed, 10 Jun 2020 08:54:27 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 08:54:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=rmViSV0 stGhecAfK+ohe9exQn7ldr1XXr6iyJvvnhj8=; b=X0CYRuTmxa8+1k8zL6TL9Pi Phg705CFrMuVNkDE/FyRWIGwm0fF+kJKNPxI7r6MLNeJQM93DUxwBoAZrUtny1TT RNaqRpA/220aIRzZKwSM1IjLT2uqNtu4ppZjhxrmkpcL8zJN99A7jI3ILHa++ExQ mJ/oml8482U/IbDF/K27rzylW62ebpFsABHXnEOq1HCMWmefIU4r+CVFb3GKqLA9 dcRZlvERBvbUqAP91zWDQ66Zv4Y4UKqZ9P43LC862j6wwHWxcNpSK8TFrDWVqsvV +4wmOjF5wfvqDjDha12J88wEM75zub9z28ETpbOo6kY6WUzpTNePzGw8v5NnJ4A= = 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=fm3; bh=rmViSV 0stGhecAfK+ohe9exQn7ldr1XXr6iyJvvnhj8=; b=vDb5Nnt6wb/ltJY+erZpUg jqDw92Ssmjbp/cNubczqVLaSZ9skIc960tMP10h+oDnNGfSNQH33d1aSJnzq1Qxa L+8GL0vc7oStgtZc5sKrd56F/zHlLhNo00O7M0TTb/kCw8izhDKjJ15LdKWsm0Cp fUGAT/jwwWe47lDIoN/gxDCFiZgrduC+6BY0SzucSTvkbeIp+49F1YPPKbFAM/V8 U5PlUcefxSiAsTDpBlkZbeqCtrWq9YISA4ifRtnpS7vtfkR99RsH5ZWfMsQtXt4p E188uDTOLIDS7Plk5liQRs/h03Itzxh4oiUDiL8V23N1F/hkjBDTJ5+43uBAVqeQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffveefiefgje evteehheelgeetleetveeguedthfehgffhtdejhfdvhefhtdekgfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 31B9F180091; Wed, 10 Jun 2020 08:54:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9d20f8a5-9441-47ba-b2f3-c2ee87f97a81@dogfood.fastmail.com> <345bfd7c-f16e-c9b2-1697-da66929086d0@isode.com> Date: Wed, 10 Jun 2020 22:54:07 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=eefb305272094ca8adc2611302fdffe4 Archived-At: Subject: Re: [Extra] Do we need a session at IETF108? 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, 10 Jun 2020 12:54:31 -0000 --eefb305272094ca8adc2611302fdffe4 Content-Type: text/plain Er, 100 minute. I can't maths. Bron. On Wed, Jun 10, 2020, at 22:53, Bron Gondwana wrote: > On Wed, Jun 10, 2020, at 22:50, Alexey Melnikov wrote: >> Hi Bron, >> On 06/06/2020 07:41, Bron Gondwana wrote: >>> Hi Extra-ordinary people, >>> >>> We have an interim meeting scheduled in a couple of weeks, where we'll be mostly talking about IMAP4rev2 I'm sure. We need to decide BEFORE then whether we will also be meeting at the IETF108 virtual meeting in not-Madrid. >>> >>> Does anybody have a strong opinion on this? I'm inclined not to take up a time slot unless people thing there's valuable work which is better done during the official IETF108 times. I'll be attending anyway because I plan to run a JMAP session, but I feel that EXTRA has less need to meet during a virtual IETF. >>> >>> Let me know, pretty much if anyone thinks it's going to be worth having the session I'll ask for it - they're always a pleasant way to spend some time. >> I think it will really depend on what actions items we come up after the EXTRA session next week and AD review of IMAP4rev2. >> Maybe ask for a shared slot between JMAP and EXTRA? >> Best Regards, >> Alexey > > I currently have a 50 min slot for JMAP - I could extend that to ask for a 140 min slot instead for both! > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --eefb305272094ca8adc2611302fdffe4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Er, 100 minute.  I can't maths.

Bron.

On Wed, Jun 10, 2020, at 22:53, Bron Gondwana wro= te:
On Wed, Jun 10, 2020, at 22:50, Alexey Melnikov wro= te:

Hi Bro= n,

On 06/06/2020 07:41, Bron= Gondwana wrote:
Hi Extra-ordinary people,

We have an interim mee= ting scheduled in a couple of weeks, where we'll be mostly talking about IMAP4rev2 I'm sure.  We need to decide BEFORE then wh= ether we will also be meeting at the IETF108 virtual meeting in not-Madrid.

Does anybody have a strong opinion on this?  I'm inclined not to take up a time slot unless pe= ople thing there's valuable work which is better done during the official IETF108 times.  I'll be attending anyway because I= plan to run a JMAP session, but I feel that EXTRA has less need to meet during a virtual IETF.

Let me know, pretty m= uch if anyone thinks it's going to be worth having the session I'll ask for it= - they're always a pleasant way to spend some time.

I think it will really depend on what actions items we come= up after the EXTRA session next week and AD review of IMAP4rev2.
<= /p>

Maybe ask for a shared slot between JMAP and EXTRA?

Best= Regards,

Alexey


I currently have a 50= min slot for JMAP - I could extend that to ask for a 140 min slot inste= ad for both!

Bron.

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


_______________________________________________
Extra mailing list

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


--eefb305272094ca8adc2611302fdffe4-- From nobody Wed Jun 10 06:03:32 2020 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 D41A53A083B; Wed, 10 Jun 2020 06:03:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: barryleiba@computer.org, brong@fastmailteam.com, extra-chairs@ietf.org, extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159179421077.7266.14427418559596569877@ietfa.amsl.com> Date: Wed, 10 Jun 2020 06:03:30 -0700 Archived-At: Subject: [Extra] extra - Not having a session at IETF 108 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, 10 Jun 2020 13:03:31 -0000 Bron Gondwana, a chair of the extra working group, indicated that the extra working group does not plan to hold a session at IETF 108. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Jun 10 06:05:43 2020 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 0B4FE3A083F; Wed, 10 Jun 2020 06:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=gW58iXoC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mrnRvntL 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 sflvazM771ii; Wed, 10 Jun 2020 06:05:39 -0700 (PDT) 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 922683A083E; Wed, 10 Jun 2020 06:05:36 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E6DBC5C010D; Wed, 10 Jun 2020 09:05:35 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 09:05:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=pP/hp0p EwaVLYz+orC+MtwTkhv6lnU91miUeAyqVc7A=; b=gW58iXoCxQ5h7JPEjnVgWnx 31bOo8widaAFI05PilddxIJPnPNa+zbK1fuLLONjp1aGLp7yirqGBbsxcSjzNWt1 50ERqXSHFdVtbeP46IhnRso33Gqhe1O2x+UbMPqD2JaehGzznpk8eIbG3/mHWtsk cC4GkHV3FoFcODDZkX6ZN4gAbq3iMoANM/N7IW5mf9mDmxwyWLWTkGK+FxJqm0uf BRyVjc2JudPdsGIcUBY7wWZpkGIJRF8wMO/v5CNnhFlT8ylaW9d6tZhLn37SqWXC MHtMkDecLOy8KgLSU2n6wqmyXIND67PLGvI9dsrORY7ptN37ebKhLC/6q5vI3vQ= = 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=fm3; bh=pP/hp0 pEwaVLYz+orC+MtwTkhv6lnU91miUeAyqVc7A=; b=mrnRvntLMWmZBHPsFH2UjN E+LFBo+rsGvgSQBU1mjQ/09xyVmqUTTGEruYxg3RM6ShdVNVGJYjCGjwRfS0gcA2 w9BlxLNlw1vMRYYZegP6NeFyiTncC/35cjSwOTi/k13HB1RwN6Kx69qNmBTGKpr5 ll6QE6P2dlnoDK5FELQBSoy4qc2R4H1y0qzGppYXqxXvcLgDEkLiVL5KKrRIRgW3 yUuqLIDF29oc70er3RBbpTkMBHTDhetcjf5HsiNVp6jtnPjGdcxuw4q0tPJthKNP l5FNZib6RW9PTyebsu6L1W+hiTAc3EkQC1aosPwjuyU8Oht2jCwmEwaki6hJaomQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepvdduueeihefgvdehueeujeejuedugfeigfevteefleet feffgfdtjeejgfeuuddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8FF73180091; Wed, 10 Jun 2020 09:05:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: In-Reply-To: <159179421077.7266.14427418559596569877@ietfa.amsl.com> References: <159179421077.7266.14427418559596569877@ietfa.amsl.com> Date: Wed, 10 Jun 2020 23:05:15 +1000 From: "Bron Gondwana" To: "Barry Leiba" , extra-chairs@ietf.org, extra@ietf.org Content-Type: multipart/alternative; boundary=620316aab9f748a7ad3f13176c49fbf7 Archived-At: Subject: Re: [Extra] extra - Not having a session at IETF 108 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, 10 Jun 2020 13:05:42 -0000 --620316aab9f748a7ad3f13176c49fbf7 Content-Type: text/plain More strictly: we plan to share time with the JMAP working group session request if we have a need for it. On Wed, Jun 10, 2020, at 23:03, IETF Meeting Session Request Tool wrote: > > > Bron Gondwana, a chair of the extra working group, indicated that the extra working group does not plan to hold a session at IETF 108. > > This message was generated and sent by the IETF Meeting Session Request Tool. > > > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --620316aab9f748a7ad3f13176c49fbf7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
More strictly: we plan to share time with the JMAP working= group session request if we have a need for it.

On Wed, Jun 10, 2020, at 23:03, IETF = Meeting Session Request Tool wrote:


Br= on Gondwana, a chair of the extra working group, indicated that the extr= a working group does not plan to hold a session at IETF 108.

This message was generated and sent by the IETF Meeting Session Requ= est Tool.




--
<= /div>
  Bron Gondwana, CEO, Fastmail Pty Ltd
&nbs= p; brong@fastmailteam.com


--620316aab9f748a7ad3f13176c49fbf7-- From nobody Wed Jun 10 07:35:48 2020 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 37AC73A08F6; Wed, 10 Jun 2020 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 8Fi74w8gkZak; Wed, 10 Jun 2020 07:35:45 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1713A08ED; Wed, 10 Jun 2020 07:35:45 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id p5so2114398ile.6; Wed, 10 Jun 2020 07:35:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TgGQgZWwntRjY9rjRzN+d9/WxGxUZum01KmMu4mHWVE=; b=Q9lf1aFldhX0hA+c3fHt7+S1CxRMGrlpdg8zFXBkdiORKwuuE3DFeHSW6GTEc9hWkj 1EWVHdB09ScQb40cOnAVJ3LENP3mFHFJismr0wCJ0vGeJjlGbG9r7BWAzdFm1XB9XMTW 35u1WseAwL41DRTSi9mwm+sZ0c2vKD1QvdhtUQGi2x+5ukFKZjDjXb5QiTHUxi/X5Mpt l6M63AckjU53SsmFnVOg1sbJ9T+AndCEdiAd+Ewtcq7hkZ1aMLYQfC6tmKOIFA6EtrfR MNeY9d2F7qS0AuZXEioIt3QePh+VcQ61eVqfkMlfVpbDNo26iS6g6PoMkshCu7ifFaOm rAUQ== X-Gm-Message-State: AOAM531o564zfpJvmTO4dQZy9OGhDcdw+Tm7+hN0yJRZ1xr3cUM4IAwi M1cEE2FOtakWzNe+2zzMdDMdufYJ4cUthLuXlRDII4Ff X-Google-Smtp-Source: ABdhPJyJE6lf2Sv0GEFqlTI25sc+2EnrNWEElYAIN0hVr/ydhftXUzOVfUcmLvgos1czwDIafg7K9RlU37mpwCtbaMQ= X-Received: by 2002:a92:506:: with SMTP id q6mr3357279ile.107.1591799744463; Wed, 10 Jun 2020 07:35:44 -0700 (PDT) MIME-Version: 1.0 References: <159179421077.7266.14427418559596569877@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Wed, 10 Jun 2020 10:35:33 -0400 Message-ID: To: Bron Gondwana Cc: extra-chairs@ietf.org, extra@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] extra - Not having a session at IETF 108 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, 10 Jun 2020 14:35:46 -0000 > More strictly: we plan to share time with the JMAP working group session request if we have a need for it. But "extra" will not be on the agenda this way. It's better to make a session request and say in the request that you want to share the slot with jmap, so that both are shown on the agenda. Barry From nobody Wed Jun 10 15:27:58 2020 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 DB5943A155B; Wed, 10 Jun 2020 15:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=EundhDKa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f3jch4Uu 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 w--FUpdYw-8r; Wed, 10 Jun 2020 15:27:55 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15103A0943; Wed, 10 Jun 2020 15:27:55 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2A1445C8; Wed, 10 Jun 2020 18:27:55 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 18:27:55 -0400 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=fm2; bh=Pfu4 pS3wVhQQbhZCByZ5sPf6uFqLYbZJ5FU4WgCC9WU=; b=EundhDKawrpHaJH4Ze48 AhCnDxbpOKZqiQUo9VdLDWUz4VJNGE+RK97gwaber0oh2eUSDZXeznOXnlN1BQl0 odpP8K5UFuRhoiUh/t/Pq3G48nMaoFfEfgAYPpv2xuPhNkCrYozoFktHNVo629Jk 0aAug/nUbRDlEtr6Hp0B0XE39HmAgP/TF0dqo+ZxD0Kdlzo1NUkfnLUFEQnOsbwq Zf30fcZgHipY7G1e23DXlJU5KKo8k3rcNqxassKBMbVJWfstVn+4rvGw+lgna55S Fuoku2+I5IADGKlHY1Mn0LVTuGnl6+EjiN284lHH0yDwAUSmmPYpvxXsfv3T8Ctw NQ== 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=fm3; bh=Pfu4pS 3wVhQQbhZCByZ5sPf6uFqLYbZJ5FU4WgCC9WU=; b=f3jch4UuRXD20zj2zXSmFy tNca3cLt9XluzdQbQmeF59gEbF+u6xDvhaLV3ZOXX3Edr8CIDsBHl/OND6tiZqaH DVqxkLTiZm6g7VelecfD5ygEi9ITst7eOOR2bbKKNDhdrtKlPsD35inYDKYnpFYt DD9N6gyKQjW/3iQeseDDuQR6t2wXpt/ysAwhkZCBfwaGH0aFSgjou5NNkEe25og/ IBcl6JScXxDgE1bVb3p4YV5S/PdwsLAUKHI37yviidQI7csgc0KFdk7iiDZj7HCF QeKD0u5aCBxT9SeUto8YjkWJFF713fM6q+EBxms2Oat0wur0cfyzOoO5GcRruCtg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehjedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepvdduueeihefgvdehueeujeejuedugfeigfevteefleet feffgfdtjeejgfeuuddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 19007180091; Wed, 10 Jun 2020 18:27:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: <84dfbabc-3ae1-42b3-b92e-327cd1207935@dogfood.fastmail.com> In-Reply-To: References: <159179421077.7266.14427418559596569877@ietfa.amsl.com> Date: Thu, 11 Jun 2020 08:27:33 +1000 From: "Bron Gondwana" To: "Barry Leiba" Cc: extra-chairs@ietf.org, extra@ietf.org Content-Type: multipart/alternative; boundary=85ef6058c81847819ea0d0c302e9c2c2 Archived-At: Subject: Re: [Extra] extra - Not having a session at IETF 108 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, 10 Jun 2020 22:27:57 -0000 --85ef6058c81847819ea0d0c302e9c2c2 Content-Type: text/plain Alright - I'll do that! Thanks. Bron. On Thu, Jun 11, 2020, at 00:35, Barry Leiba wrote: > > More strictly: we plan to share time with the JMAP working group session request if we have a need for it. > > But "extra" will not be on the agenda this way. It's better to make a > session request and say in the request that you want to share the slot > with jmap, so that both are shown on the agenda. > > Barry > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --85ef6058c81847819ea0d0c302e9c2c2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Alright - I'll do that!  Thanks.

Bron.

On Thu, Jun 11,= 2020, at 00:35, Barry Leiba wrote:
> More strictly= : we plan to share time with the JMAP working group session request if w= e have a need for it.

But "extra" will not be on the agen= da this way.  It's better to make a
session request and say in the request that you want to shar= e the slot
with jmap, so that= both are shown on the agenda.

Barry


--
  Bro= n Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailtea= m.com

--85ef6058c81847819ea0d0c302e9c2c2-- From nobody Wed Jun 10 15:33:06 2020 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 741543A1566; Wed, 10 Jun 2020 15:33:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: barryleiba@computer.org, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159182838439.29399.9861807050436651328@ietfa.amsl.com> Date: Wed, 10 Jun 2020 15:33:04 -0700 Archived-At: Subject: [Extra] extra - New Meeting Session Request for IETF 108 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, 10 Jun 2020 22:33:05 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the extra working group. --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: jmap calext dispatch People who must be present: Barry Leiba Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Special Requests: Per the notes on the JMAP session - we'd like to do a combined session for both. Barry suggested putting this request in so "extra" is listed on the agenda. --------------------------------------------------------- From nobody Mon Jun 15 04:40:45 2020 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 4177E3A0CA2; Mon, 15 Jun 2020 04:40:38 -0700 (PDT) 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: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159222123810.25764.6197709935009067530@ietfa.amsl.com> Date: Mon, 15 Jun 2020 04:40:38 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-quota-01.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, 15 Jun 2020 11:40:38 -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 : IMAP QUOTA Extension Author : Alexey Melnikov Filename : draft-ietf-extra-quota-01.txt Pages : 17 Date : 2020-06-15 Abstract: The QUOTA extension of the Internet Message Access Protocol (RFC 3501) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-quota/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-quota-01 https://datatracker.ietf.org/doc/html/draft-ietf-extra-quota-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-quota-01 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 Jun 16 21:01:29 2020 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 A66C53A0E3C for ; Tue, 16 Jun 2020 21:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=pTnCsBCV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D05U4CUE 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 d2cfaUlXDrBV for ; Tue, 16 Jun 2020 21:01:26 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46EE43A0E3D for ; Tue, 16 Jun 2020 21:01:26 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 92669422 for ; Wed, 17 Jun 2020 00:01:25 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 17 Jun 2020 00:01:25 -0400 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=fm3; bh=qVobRqI rwz3qON/1tGYsKNQ0V0xwwEk3Z9fTPOJPBIs=; b=pTnCsBCVRehZ72ayncULMr8 OiNvPzPxID8W/cFRz8uC0uIkIAiGaHVWYceS2j9v4zXVy9ofiOH2Bix+whmu6g9o AabY9qhSsyt26aaghiSUp+J69ZThNVRqTKh6FEZ8jxDj4FMGVNPdbMupu93G1bBz 7CUyxuH/1N9VBwc/Rwakxg4cgJKGDHgKBD4dUvmsJQSS1Iq6hZFwbnvxcaCc9equ Ajuk72frIP/PiYBNrF9yjVLkgaJEpym1Sz3QPWuiqwYUiQt1yoEZ2oH5ZILaV7oZ uvJFcyODdll59LD8ZYAdCl222pcNVvxkgp+12YrmLWRZETaJF2xayoQTPaDYSnQ= = 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=fm3; bh=qVobRq Irwz3qON/1tGYsKNQ0V0xwwEk3Z9fTPOJPBIs=; b=D05U4CUEV6t7s5iuJGt77K WG6uLYhcf0NbZ4NCN3ruDIPKqx3Vsc8bfIfVCApzKbfU1Zn/7vDlSfJuwQ2gzTP5 1GDHIEFhTb7TNxEKjKLJfhgO9qi3StvD5dwh/9ZzcatN3iCPrB8UxZ2kDH7tIK8u e1J+e+jpV/4LMqF4sqfvX56e4eiroUwRpdJtpixosI5rpen+vuM1LW2yfXYxG8DI umxkzL2K/ns6kfwXuOUeF7660WIgc23PFeokHuppt9k4U8LCK4m5xWaSUhCRN/Ed mCPOAixYuf0gedLN0oXU2mpI8yzVgeeRCL0MfnMms3xamfc1H2i7rcnHRHH0efZQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejuddgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffveefiefgje evteehheelgeetleetveeguedthfehgffhtdejhfdvhefhtdekgfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DCCE5180091; Wed, 17 Jun 2020 00:01:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-534-g18b7ee1-fm-20200616.002-g18b7ee12 Mime-Version: 1.0 Message-Id: <5d000f09-95a9-458a-865a-244e275221b8@www.fastmail.com> In-Reply-To: <1534074123.325963.1471428976.69051499@webmail.messagingengine.com> References: <1533965215.3244415.1470608496.2420C769@webmail.messagingengine.com> <3b91e44b-88ec-4665-fb1e-666ffc87f03e@fastmail.com> <01QVY4QRCYRI00004T@mauve.mrochek.com> <92650f94-50da-88be-466a-02fbab806c92@fastmail.com> <01QVYD4HLYU800004T@mauve.mrochek.com> <1534033942.194082.1471158928.7878DA2E@webmail.messagingengine.com> <1534074123.325963.1471428976.69051499@webmail.messagingengine.com> Date: Wed, 17 Jun 2020 14:01:04 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=fc72ce7fb6ff4e858f9773e69f2f4a64 Archived-At: Subject: Re: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid 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, 17 Jun 2020 04:01:28 -0000 --fc72ce7fb6ff4e858f9773e69f2f4a64 Content-Type: text/plain I submitted this with a call for adoption and never came back to it - and the draft expired! I went back and looked at the draft and it still looks right. I've uploaded v2: https://www.ietf.org/id/draft-gondwana-sieve-mailboxid-02.txt I'll talk about it in the upcoming call :) Unless there's any complaints there or kinda straight away here, I'll go ahead and do what I should have done a year ago and submit it as a working group document! We're using this in production on our systems, so it "works" for some value of. Bron. On Sun, Aug 12, 2018, at 21:42, Bron Gondwana wrote: > OK - I've posted version -01 which I believe addresses all the concerns :) > > * Switch to :mailboxid tagged parameter value with fallback mailbox name. > * Document interation with special-use. > * Document security considerations around :mailboxid and :create. > > I've also updated our implementation, which was very easy. > > (and I forgot to mention - I also documented interaction with :fcc. I'll add that to my .mdown file now) > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --fc72ce7fb6ff4e858f9773e69f2f4a64 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I submitted this with a call for adoption and never c= ame back to it - and the draft expired!  I went back and looked at = the draft and it still looks right.  I've uploaded v2:


I'll talk about it in the upcoming call :)  Unless th= ere's any complaints there or kinda straight away here, I'll go ahead an= d do what I should have done a year ago and submit it as a working group= document!

We're using this in production on our systems,= so it "works" for some value of.

Bron.

On Sun, Aug 12, 2018, at 21:42,= Bron Gondwana wrote:
OK - I've posted version -01 whi= ch I believe addresses all the concerns :)

* Switch to :m= ailboxid tagged parameter value with fallback mailbox name.
* Document interation with special-use.
* Document security considerat= ions around :mailboxid and :create.

I've also updated our= implementation, which was very easy.

(and I forgot to me= ntion - I also documented interaction with :fcc.  I'll add that to = my .mdown file now)

Bron.

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

<= div style=3D"font-family:Arial;">
________________________= _______________________
Extra mailing list
<= a href=3D"mailto:Extra@ietf.org">Extra@ietf.org


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


--fc72ce7fb6ff4e858f9773e69f2f4a64-- From nobody Wed Jun 17 02:53:57 2020 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 0F8443A08AD; Wed, 17 Jun 2020 02:53:56 -0700 (PDT) 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: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <159238763595.1803.574245566610096074@ietfa.amsl.com> Date: Wed, 17 Jun 2020 02:53:56 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-15.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, 17 Jun 2020 09:53:56 -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 (IMAP) - Version 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-15.txt Pages : 158 Date : 2020-06-17 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-15 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 Wed Jun 17 04:00:37 2020 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 0E01C3A095C for ; Wed, 17 Jun 2020 04:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 pBpyO54VymtI for ; Wed, 17 Jun 2020 04:00:33 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE783A0942 for ; Wed, 17 Jun 2020 04:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592391632; d=isode.com; s=june2016; i=@isode.com; bh=OajWwuEQg2cDr7RYEi//sMqkjoXaCeUJV8ZgYvPmF/4=; 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=WL79BvSnZaLCWO6cRSrY4iIg/V0xy1HEVRiF6uAklnG1yt6wZaV2KOcLS0sMCu/sfy2dQW EwcU3B2YQdGYbm1cvFj5dW/qv3fmLR8CRnto9TLk6wvoqjQE5AOTf8oFm/qk+4xx56tJRP BmHbM6W4F5l5T1e6NEnTuShEPRpXkYY=; Received: from [192.168.1.222] (host31-49-142-105.range31-49.btcentralplus.com [31.49.142.105]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 17 Jun 2020 12:00:31 +0100 From: Alexey Melnikov To: Timo Sirainen , Bron Gondwana Cc: extra@ietf.org References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> Message-ID: <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> Date: Wed, 17 Jun 2020 12:00:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FAE60FDE16F508AA2FC794E0" Content-Language: en-GB Archived-At: Subject: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE 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, 17 Jun 2020 11:00:35 -0000 --------------FAE60FDE16F508AA2FC794E0 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Timo/Bron, On 02/02/2020 15:16, Timo Sirainen wrote: > On 1. Feb 2020, at 21.00, Alexey Melnikov > wrote: > >>>> It still doesn't mean that you can reliably tell the correct octets=20 >>>> for the matching mailbox from the LIST response though :( >>> >>> Is it too late to add a new response code? Something like: >>> >>> * OK [CREATED] TAG "a123" NAME "Denormalized name" >> >> Response codes are cheap and don=E2=80=99t break older clients, so I am h= appy=20 >> to add one. I agreed to this in principle, but now is the time to see if we can make=20 this work ;-). > I guess an optional reply which can send both the changed name and/or=20 > mailboxid. Maybe something like: > > * OK [CREATED] TAG "a123" NAME "Denormalized name" MAILBOXID "123456" In IMAP, the part after the response code "[CREATED]" is human readable=20 and has no structure. Making it structured in general or making it=20 structured for some responses and not others is going to be a major=20 change in IMAP handling, so I don't think we should go there. > Although I'm not sure if some part of it would be nicer inside=20 > parenthesis. Yes, that is my point above: it has to be inside []. This would makes it something like: * OK [CREATED TAG "a123" NAME "Denormalized name" MAILBOXID "123456"] We can even drop some labels that provide no value, because the=20 corresponding value is required: * OK [CREATED=C2=A0 "a123" "Denormalized name" MAILBOXID "123456"] So ABNF for the latter is going to be something like this: =C2=A0 created =3D "CREATED" SP tag SP mailbox-quoted ["MAILBOXID" SP aquot= ed] =C2=A0 aquoted =3D 1*ATOM-CHAR / quoted =C2=A0 mailbox-quoted =3D "INBOX" / aquoted =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ; Same as "mailbox", but without =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ; allowing for "literal" string And also add "created" as one of "resp-text-code" choices. To elaborate on why I excluded "literal" string is because response=20 codes are defines as: =C2=A0 atom [SP 1] and TEXT-CHAR excludes CR and LF. Best Regards, Alexey --------------FAE60FDE16F508AA2FC794E0 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Timo/Bron,

On 02/02/2020 15:16, Timo Sirainen wrote:

On 1. Feb 2020, at 21.00, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :(

Is it too late to add a new response code? Something like:

* OK [CREATED] TAG "a123" NAME "Denormalized name"

Response codes are cheap and don=E2=80=99t break older clien= ts, so I am happy to add one.
I agreed to this in principle, but now is the time to see if we can make this work ;-).
I guess an optional reply which can send both the changed name and/or mailboxid. Maybe something like:

* OK [CREATED] TAG "a123" NAME "Denormalized name" MAILBOXID "123456"

In IMAP, the part after the response code "[CREATED]" is human readable and has no structure. Making it structured in general or making it structured for some responses and not others is going to be a major change in IMAP handling, so I don't think we should go there.

Although I'm not sure if some part of it would be nicer inside parenthesis.

Yes, that is my point above: it has to be inside [].

This would makes it something like:

* OK [CREATED TAG "a123" NAME "Denormalized name" MAILBOXID "123456"]

We can even drop some labels that provide no value, because the corresponding value is required:

* OK [CREATED=C2=A0 "a123" "Denormalized name" MAILBOXID "123456"]

So ABNF for the latter is going to be something like this:

=C2=A0 created =3D "CREATED" SP tag SP mailbox-quoted ["MAILBOXID" SP aquoted]

=C2=A0 aquoted =3D 1*ATOM-CHAR / quoted

=C2=A0 mailbox-quoted =3D "INBOX" / aquoted
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ; Same as "mailbox", but without
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 ; allowing for "literal" string

And also add "created" as one of "resp-text-code" choices.


To elaborate on why I excluded "literal" string is because response codes are defines as:

=C2=A0 atom [SP 1<any TEXT-CHAR except "]">]

and TEXT-CHAR excludes CR and LF.


Best Regards,

Alexey

--------------FAE60FDE16F508AA2FC794E0-- From nobody Wed Jun 17 04:07:58 2020 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 91A083A0967 for ; Wed, 17 Jun 2020 04:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=ptFFazPY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J+hjhnLz 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 T5-CR3SR_x-k for ; Wed, 17 Jun 2020 04:07:55 -0700 (PDT) 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 7D2183A0966 for ; Wed, 17 Jun 2020 04:07:55 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D2091572; Wed, 17 Jun 2020 07:07:53 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 17 Jun 2020 07:07:54 -0400 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=fm3; bh=Yszc ljgzqGWkxkEC6ZC2x8vVuNZ0G/ok6UC37XHWZPg=; b=ptFFazPYkzoj0X3CqefV k8vF8g+UfSG9SMHAvRQmPofGxWd1lSsmlPrqL7zXVLRcY6phI4Vy7crXhNER8tkO +HWBfSmcv2UlWaJR+zAxvAzxtVHkrkQyDBjA0nIRK56yPl9rqdl1kO9qtMblZzTD 0R9dWapPs99rWxtwR5pvETCRW6acdA/X3YkVwJEpLgbBsY5aVWWQ5xOxHLxDJAiv VBUmXJjXslMSjkaf3uFCcS4w3RDiCnIiaXIlu2qUbPVTz6XY9tb8yvOEaQrYWwZr 5a1lauuyvbpWD0G80VtoaEaVjtszqjO5e8/jQjMgYCAezkYeAVBCJb/F+2IVenuV dQ== 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=fm3; bh=Yszclj gzqGWkxkEC6ZC2x8vVuNZ0G/ok6UC37XHWZPg=; b=J+hjhnLzXWQIaTM0Zv1CKs I8bOUrost5CZntDbFXVbHIK1gT9qWL0EYR1kKiUiVwuxchDvKzomzMNxK1IVx1yx /DHFhvRSCv3lxw1XxYVQ3bQK7PqvqgHJaGctYaKHIsIq9hX0rU2bwUUQJ9siCObO 4KymSp+IgS9j0qWGjp/wJ7aef6HuybNZJX/6hP/oY49YJrZl0kEX9a7sbX/h11kw /Fx6+p6E/wVLgbvnfhRxd6lWGt9UakR35/huJ/+wHQJNpXrqm6JsiajPo7tBblY3 5mxUF4vKCNzn/jdB3v6aTrgyriebTTNbaHcLMfay43gJffHO0CPimP1tYd5BgkYQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejvddgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnheptdehteegfeevteduffevteehfffghefhvdevkeeuhfeh ueetudehgfegieekjeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F00B8180091; Wed, 17 Jun 2020 07:07:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-534-g18b7ee1-fm-20200616.002-g18b7ee12 Mime-Version: 1.0 Message-Id: <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> In-Reply-To: <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> Date: Wed, 17 Jun 2020 21:07:32 +1000 From: "Bron Gondwana" To: "Alexey Melnikov" , "Timo Sirainen" Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=ed355309bf53405cbdfffce6817d9f36 Archived-At: Subject: Re: [Extra] =?utf-8?q?IMAP4rev2=3A_how_to_signal_canonical_mailbox_n?= =?utf-8?q?ame_after_CREATE?= 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, 17 Jun 2020 11:07:57 -0000 --ed355309bf53405cbdfffce6817d9f36 Content-Type: text/plain On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote: > To elaborate on why I excluded "literal" string is because response codes are defines as: > atom [SP 1] > and TEXT-CHAR excludes CR and LF. Here's another problem: . CREATE INBOX.HELLO[] . OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed * LIST (\HasNoChildren) "." INBOX.HELLO[] Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --ed355309bf53405cbdfffce6817d9f36 Content-Type: text/html
On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote:

To elaborate on why I excluded "literal" string is because response codes are defines as:

  atom [SP 1<any TEXT-CHAR except "]">]

and TEXT-CHAR excludes CR and LF.


Here's another problem:

. CREATE INBOX.HELLO[]
. OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed

* LIST (\HasNoChildren) "." INBOX.HELLO[]

Bron.

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


--ed355309bf53405cbdfffce6817d9f36-- From nobody Wed Jun 17 04:51:57 2020 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 9D8DE3A0A03 for ; Wed, 17 Jun 2020 04:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 RieNeWMjejUW for ; Wed, 17 Jun 2020 04:51:54 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 752983A0A02 for ; Wed, 17 Jun 2020 04:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592394713; d=isode.com; s=june2016; i=@isode.com; bh=Jexp+Euj9jSzjI8tGWmVYvyUKTNizb9A+LDbyHLMGw4=; 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=cV5LAG9K4odRLmjvjnKPV6KJPIiP1M95HJOqL15DONEKvQtWka7hS1M+DqSBHf8ipfUiUo j0nUYS5wtK7AOGPMzchc+M7zoH/78kP72bZS8kSA1zyQVbEjVDjWLOY9m8p+BK/Y3WC96/ VoUHzrJyD9mqgF08TfyB3MMpdlLXVeE=; Received: from [192.168.1.222] (host31-49-142-105.range31-49.btcentralplus.com [31.49.142.105]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 17 Jun 2020 12:51:53 +0100 To: Bron Gondwana , Timo Sirainen Cc: extra@ietf.org References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> Date: Wed, 17 Jun 2020 12:51:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A3D376111D71ADDC04788626" Content-Language: en-GB Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE 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, 17 Jun 2020 11:51:56 -0000 --------------A3D376111D71ADDC04788626 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 17/06/2020 12:07, Bron Gondwana wrote: > On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote: >> >> To elaborate on why I excluded "literal" string is because response=20 >> codes are defines as: >> >> =C2=A0 atom [SP 1] >> >> and TEXT-CHAR excludes CR and LF. >> > > Here's another problem: > > . CREATE INBOX.HELLO[] > . OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed > > * LIST (\HasNoChildren) "." INBOX.HELLO[] Right, I was just about to mention that. I think we have a choice: 1) abandon use of this response code (and use a new response instead), e.g. * CREATED "a123" "Denormalized name" MAILBOXID "123456" =C2=A0This would require clients to ignore an extra response, if they don't= =20 recognize it. or 2) just describe limitations (e.g. no mailbox with "]" in it can have=20 this response code) and make them a special case. Hopefully will discuss this later today at the interim meeting. --------------A3D376111D71ADDC04788626 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 17/06/2020 12:07, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote:

To elaborate on why I excluded "literal" string is because response codes are defines as:

=C2=A0 atom [SP 1<any TEXT-CHAR except "]">]

and TEXT-CHAR excludes CR and LF.


Here's another problem:

. CREATE INBOX.HELLO[]
. OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed

* LIST (\HasNoChildren) "." INBOX.HELLO[]

Right, I was just about to mention that. I think we have a choice:

1) abandon use of this response code (and use a new response instead), e.g.

* CREATED "a123" "Denormalized name" MAILBOXID "123456"

=C2=A0This would require clients to ignore an extra response, if they don't recognize it.

or

2) just describe limitations (e.g. no mailbox with "]" in it can have this response code) and make them a special case.

Hopefully will discuss this later today at the interim meeting.


--------------A3D376111D71ADDC04788626-- From nobody Wed Jun 17 04:53:31 2020 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 A1EF33A0A09 for ; Wed, 17 Jun 2020 04:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 HK9mgEeC_CrU for ; Wed, 17 Jun 2020 04:53:28 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9BF3A0A06 for ; Wed, 17 Jun 2020 04:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592394807; d=isode.com; s=june2016; i=@isode.com; bh=T4av36w/nP4jvyQpvViYxBxhNV9OKFwRCQUGCs9f/+I=; 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=je9G2KJ5sjX4vflH7e4tAM75v1ZKibFpksDrEK5Ui0Yi4nvrsmyvq2BCwjz+NdUwIiFIoJ 2TfgpN9y913DJuaf4H9RKizHLF+X/lEIdEcSnq5NMrw4VoirAQqEy289zGBrYeNjPvEwuA AB4hHfNrlnB9XyJi1aHO+oYlnnS7gHs=; Received: from [192.168.1.222] (host31-49-142-105.range31-49.btcentralplus.com [31.49.142.105]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 17 Jun 2020 12:53:27 +0100 To: extra@ietf.org References: <159238763595.1803.574245566610096074@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Wed, 17 Jun 2020 12:53:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <159238763595.1803.574245566610096074@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-15.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, 17 Jun 2020 11:53:30 -0000 Hi all, On 17/06/2020 10:53, 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-15 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-15 In this version I finally removed multiple list patterns and also clarified a few things based on earlier comments. Best Regards, Alexey From nobody Wed Jun 17 05:15:37 2020 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 F03D73A0A3E for ; Wed, 17 Jun 2020 05:15:35 -0700 (PDT) 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 OQVuGvqeXkUJ for ; Wed, 17 Jun 2020 05:15:31 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 86BCB3A0A3D for ; Wed, 17 Jun 2020 05:15:31 -0700 (PDT) Received: from [192.168.10.110] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 24ED72B3C8B; Wed, 17 Jun 2020 12:15:30 +0000 (UTC) From: Timo Sirainen Message-Id: <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B00B4247-AF1A-4103-913D-72F1551607EF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 17 Jun 2020 15:15:29 +0300 In-Reply-To: <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> Cc: Bron Gondwana , extra@ietf.org To: Alexey Melnikov References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE 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, 17 Jun 2020 12:15:36 -0000 --Apple-Mail=_B00B4247-AF1A-4103-913D-72F1551607EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17. Jun 2020, at 14.51, Alexey Melnikov = wrote: >=20 > On 17/06/2020 12:07, Bron Gondwana wrote: >=20 >> On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote: >>> To elaborate on why I excluded "literal" string is because response = codes are defines as: >>>=20 >>> atom [SP 1] >>>=20 >>> and TEXT-CHAR excludes CR and LF. >>>=20 >>=20 >> Here's another problem: >>=20 >> . CREATE INBOX.HELLO[] >> . OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed >>=20 >> * LIST (\HasNoChildren) "." INBOX.HELLO[] > Right, I was just about to mention that. I think we have a choice: >=20 > 1) abandon use of this response code (and use a new response instead), = e.g. >=20 > * CREATED "a123" "Denormalized name" MAILBOXID "123456" >=20 > This would require clients to ignore an extra response, if they don't = recognize it. >=20 Somehow I've a feeling that there are going to be clients that will = break if they see these kind of unknown untagged replies. But that's = just a guess, so maybe not. We could of course send it only when client = has used ENABLE IMAP4REV2 and then there wouldn't be any problems. > 2) just describe limitations (e.g. no mailbox with "]" in it can have = this response code) and make them a special case. >=20 > Hopefully will discuss this later today at the interim meeting. >=20 I'd rather avoid these kind of ugly special cases. It's just going to = cause bugs in both clients and servers. --Apple-Mail=_B00B4247-AF1A-4103-913D-72F1551607EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 17. Jun 2020, at 14.51, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On = 17/06/2020 12:07, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote:

To elaborate on why I excluded "literal" string is because = response codes are defines as:

  atom [SP 1<any = TEXT-CHAR except "]">]

and TEXT-CHAR = excludes CR and LF.


Here's another problem:

. CREATE = INBOX.HELLO[]
. OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] = Completed

* LIST (\HasNoChildren) "." INBOX.HELLO[]

Right, I was just about to mention = that. I think we have a choice:

1) abandon use of this response code = (and use a new response instead), e.g.

* = CREATED "a123" "Denormalized name" MAILBOXID "123456"

 This would require clients to ignore an extra response, = if they don't recognize it.


Somehow I've a feeling that there are going to be = clients that will break if they see these kind of unknown untagged = replies. But that's just a guess, so maybe not. We could of course send = it only when client has used ENABLE IMAP4REV2 and then there wouldn't be = any problems.

2) = just describe limitations (e.g. no mailbox with "]" in it can have this = response code) and make them a special case.

Hopefully will discuss this later = today at the interim meeting.


I'd rather avoid these kind of ugly special cases. = It's just going to cause bugs in both clients and servers.

= --Apple-Mail=_B00B4247-AF1A-4103-913D-72F1551607EF-- From nobody Wed Jun 17 05:27:33 2020 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 0A5B23A0365 for ; Wed, 17 Jun 2020 05:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=h/pcewfI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ePyDQKmi 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 oANGHkhRF9lA for ; Wed, 17 Jun 2020 05:27:30 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B331D3A0112 for ; Wed, 17 Jun 2020 05:27:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0C0BE5C0185; Wed, 17 Jun 2020 08:27:30 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 17 Jun 2020 08:27:30 -0400 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=fm3; bh=FWGm kkwC+Df2oSN1TT/4wmPTNwej3wJ1C3nV5GbYcPw=; b=h/pcewfIuu/9LvTC9GCP Zv2T0jBotaDzzKShIcN+tM2vhh20IB4JhQC/cMvoYFn3/l5slyGTxqOzn1Xjy905 YbXtzVaZIUnfEBoEv6l+23DdsWA5UTGxL2BRX142BqHtUPp7wGg5ARqs9L8tv54W 3VDWQi7ywfAQqMNZjnj8Kpzo3MTSHInwHbYVvoJMh+7gFT6A6Ng/Gl9QaQxQp2Ag LnMXOQ+zmYA9LY5sBMbJo3sIMGu8xqMGFNwEqI3jeF1nvaXAAFvGAeMGV1R5X3jh uz+eCUaujfJb1gqvQWw9CphUK7Rjv3sHzmutZ68e1kvjgwsfqwdEWT81eEKZwnIq tQ== 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=fm3; bh=FWGmkk wC+Df2oSN1TT/4wmPTNwej3wJ1C3nV5GbYcPw=; b=ePyDQKmilvD7HEy+ISSfl2 sSWjgq2F3A7BlCOOqITkDqLqP9Co+mn46vyiqWlTSFODhwONQ8Z+Rc5ck/NQYf1f ZuQBOitj2kdkoVkpwOCC+BkHeIFtajSkgncPP2Tr8FQfnl6l1B1kR87jl7obuN1t ySyb9w9I9d3kDczdgjzSgUT6fxA/dqi+Djs8qJf2FdZ08PaWjaK2IxiadMS54ciz DM2VSBg4+sGVv8Pib0TGbQHZT8WTDUZYwUrBXUvORS+JUCpCMcJJ3Dk3TAypxKyE VihobBs231tTo7AS9WrpF0nwVgkU5ksxS8vQJ+g3llFxr+DF6v8+SJLcVuClt7hQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejvddghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnheptdehteegfeevteduffevteehfffghefhvdevkeeuhfeh ueetudehgfegieekjeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 975DC180091; Wed, 17 Jun 2020 08:27:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-534-g18b7ee1-fm-20200616.002-g18b7ee12 Mime-Version: 1.0 Message-Id: <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> In-Reply-To: <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> Date: Wed, 17 Jun 2020 22:27:09 +1000 From: "Bron Gondwana" To: "Timo Sirainen" , "Alexey Melnikov" Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=99a0b2c05ce94b8b9dedec5f3cb5df36 Archived-At: Subject: Re: [Extra] =?utf-8?q?IMAP4rev2=3A_how_to_signal_canonical_mailbox_n?= =?utf-8?q?ame_after_CREATE?= 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, 17 Jun 2020 12:27:32 -0000 --99a0b2c05ce94b8b9dedec5f3cb5df36 Content-Type: text/plain On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote: >> 1) abandon use of this response code (and use a new response instead), e.g. >> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >> This would require clients to ignore an extra response, if they don't recognize it. > > Somehow I've a feeling that there are going to be clients that will break if they see these kind of unknown untagged replies. But that's just a guess, so maybe not. We could of course send it only when client has used ENABLE IMAP4REV2 and then there wouldn't be any problems. I like this. Only send if IMAP4REV2 is enabled and all[tm] your problems go away. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --99a0b2c05ce94b8b9dedec5f3cb5df36 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote:

1) abandon use of this response code (and use a = new response instead), e.g.

* CREATED= "a123" "Denormalized name" MAILBOXID "123456"

 This would require clients to ignore an extra response, = if they don't recognize it.


Somehow I've a feeling that there are going to be clients that will br= eak if they see these kind of unknown untagged replies. But that's just = a guess, so maybe not. We could of course send it only when client has u= sed ENABLE IMAP4REV2 and then there wouldn't be any problems.
<= /div>

I like this.  Only send if IMAP4REV2 is ena= bled and all[tm] your problems go away.

Bron.

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


--99a0b2c05ce94b8b9dedec5f3cb5df36-- From nobody Wed Jun 17 05:32:46 2020 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 DCA5A3A040F for ; Wed, 17 Jun 2020 05:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 2YD7DIPObtnD for ; Wed, 17 Jun 2020 05:32:43 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 73FB23A0366 for ; Wed, 17 Jun 2020 05:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592397162; d=isode.com; s=june2016; i=@isode.com; bh=X11+h+FttKS1fSKC5qxZIxKEz1UYyF7i7QDLJK2u6v4=; 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=j3Mv65Gq7DPlCfEi478jPWQ79TihYONjw0u+q3kJFfAT5a8tBk60Q8lhMUufT3hyGSZzyy Kls4nHmo4QdF+pQG7PRbjtXY6HRs3CbHKBh6DP/y51WUs7ynNbh4e2V7eUj0sMd1QuX1Yw nBFHGXsiuaYKuG6O5qo2E5oL5q4I+wc=; Received: from [192.168.1.222] (host31-49-142-105.range31-49.btcentralplus.com [31.49.142.105]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 17 Jun 2020 13:32:42 +0100 To: Timo Sirainen Cc: Bron Gondwana , extra@ietf.org References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> From: Alexey Melnikov Message-ID: <0e65342e-abc4-cb65-b600-7f195f0bd2c2@isode.com> Date: Wed, 17 Jun 2020 13:32:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F6D6EB6A8C63E51FAE1CC618" Content-Language: en-GB Archived-At: Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE 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, 17 Jun 2020 12:32:45 -0000 --------------F6D6EB6A8C63E51FAE1CC618 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable On 17/06/2020 13:15, Timo Sirainen wrote: > On 17. Jun 2020, at 14.51, Alexey Melnikov > wrote: >> >> On 17/06/2020 12:07, Bron Gondwana wrote: >> >>> On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote: >>>> >>>> To elaborate on why I excluded "literal" string is because response=20 >>>> codes are defines as: >>>> >>>> atom [SP 1] >>>> >>>> and TEXT-CHAR excludes CR and LF. >>>> >>> >>> Here's another problem: >>> >>> . CREATE INBOX.HELLO[] >>> . OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed >>> >>> * LIST (\HasNoChildren) "." INBOX.HELLO[] >> >> Right, I was just about to mention that. I think we have a choice: >> >> 1) abandon use of this response code (and use a new response=20 >> instead), e.g. >> >> * CREATED "a123" "Denormalized name" MAILBOXID "123456" >> >> =A0This would require clients to ignore an extra response, if they=20 >> don't recognize it. >> > > Somehow I've a feeling that there are going to be clients that will=20 > break if they see these kind of unknown untagged replies. But that's=20 > just a guess, so maybe not. Yes, I have some discomfort about this as well. > We could of course send it only when client has used ENABLE IMAP4REV2=20 > and then there wouldn't be any problems. Right, this seems to be sufficient. >> >> 2) just describe limitations (e.g. no mailbox with "]" in it can have=20 >> this response code) and make them a special case. >> >> Hopefully will discuss this later today at the interim meeting. >> > > I'd rather avoid these kind of ugly special cases. It's just going to=20 > cause bugs in both clients and servers. I would rather avoid special cases as well. I also noticed that tags also allow for "]". --------------F6D6EB6A8C63E51FAE1CC618 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

On 17/06/2020 13:15, Timo Sirainen wrote:

On 17. Jun 2020, at 14.51, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

On 17/06/2020 12:07, Bron Gondwana wrote:

On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote:

To elaborate on why I excluded "literal" string is because response codes are defines as:

=A0=A0atom [SP 1<any TEXT-CHAR except "]">]

and TEXT-CHAR excludes CR and LF.


Here's another problem:

. CREATE INBOX.HELLO[]
. OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed

* LIST (\HasNoChildren) "." INBOX.HELLO[]

Right, I was just about to mention that. I think we have a choice:

1) abandon use of this response code (and use a new response instead), e.g.

* CREATED "a123" "Denormalized name" MAILBOXID "123456"

=A0This would require clients to ignore an extra response, if they don't recognize it.


Somehow I've a feeling that there are going to be clients that will break if they see these kind of unknown untagged replies. But that's just a guess, so maybe not.
Yes, I have some discomfort about this as well.
We could of course send it only when client has used ENABLE IMAP4REV2 and then there wouldn't be any problems.
Right, this seems to be sufficient.

2) just describe limitations (e.g. no mailbox with "]" in it can have this response code) and make them a special case.

Hopefully will discuss this later today at the interim meeting.


I'd rather avoid these kind of ugly special cases. It's just going to cause bugs in both clients and servers.

I would rather avoid special cases as well.

I also noticed that tags also allow for "]".

--------------F6D6EB6A8C63E51FAE1CC618-- From nobody Wed Jun 17 14:31:10 2020 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 E19433A00D2 for ; Wed, 17 Jun 2020 14:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 aPiw33KZh2rW for ; Wed, 17 Jun 2020 14:31:05 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7BF3A00C4 for ; Wed, 17 Jun 2020 14:31:05 -0700 (PDT) Received: from [172.16.37.20] (unknown [37.120.152.50]) by sirainen.com (Postfix) with ESMTPSA id 859DD2B3C8B for ; Wed, 17 Jun 2020 21:31:03 +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.4 \(3608.80.23.2.2\)) Message-Id: Date: Thu, 18 Jun 2020 00:30:58 +0300 To: extra@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Extra] draft-ietf-extra-quota: 64 bit numbers 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, 17 Jun 2020 21:31:08 -0000 > The usage of a resource MUST be represented as a 32 bit unsigned > integer. I think we should go for 64 bit numbers already. RES-STORAGE is now = limited to 4 terabytes, which is rather high value for a single user's = limit for now, but I could imagine it being a possibility in some more = years. Maybe even already in email systems that use only a few users. = Also there's already an example: C: G0001 GETQUOTA "!partition/sda4" S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) S: G0001 OK Getquota complete The 4 TB limit can already be easily reached if describing a filesystem = size. From nobody Mon Jun 22 05:11:45 2020 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 B7D863A0C7C for ; Mon, 22 Jun 2020 05:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 2tp9RrfDDul0 for ; Mon, 22 Jun 2020 05:11:42 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A56C73A0C7B for ; Mon, 22 Jun 2020 05:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592827901; d=isode.com; s=june2016; i=@isode.com; bh=KqDd0ZyMZfUS3D3UE2wihrecoHQlLCevmNX52Gt2T2A=; 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=M5Ux82XqiDe1CCs/mpNxy2nRHpm7/yZzvFtgHQjQ6KATwx09qIh3RTH8MPSXmkK2l/Oj9h 7SV5Q+s83KquxldmZhB+RFqMO+VW7SNwdx6fGKFloRCt8T+EDEDW1asn0dykVggAFOT93p 3m/MlY8NYkQlfplmYFv8F3T4u7Lm+Bo=; Received: from [172.27.251.173] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 22 Jun 2020 13:11:41 +0100 To: Timo Sirainen References: From: Alexey Melnikov Cc: extra Message-ID: Date: Mon, 22 Jun 2020 13:11:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: 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] draft-ietf-extra-quota: 64 bit numbers 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, 22 Jun 2020 12:11:44 -0000 On 17/06/2020 22:30, Timo Sirainen wrote: >> The usage of a resource MUST be represented as a 32 bit unsigned >> integer. > I think we should go for 64 bit numbers already. RES-STORAGE is now limited to 4 terabytes, which is rather high value for a single user's limit for now, but I could imagine it being a possibility in some more years. Maybe even already in email systems that use only a few users. Also there's already an example: > > C: G0001 GETQUOTA "!partition/sda4" > S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) > S: G0001 OK Getquota complete > > The 4 TB limit can already be easily reached if describing a filesystem size. Sounds good. Shall we make it 63 bits to make it easier to implement for Java based implementations? From nobody Mon Jun 22 05:23:31 2020 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 676A73A0CA4 for ; Mon, 22 Jun 2020 05:23:29 -0700 (PDT) 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 s0zZGOZK29kH for ; Mon, 22 Jun 2020 05:23:27 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id C70FF3A0CA3 for ; Mon, 22 Jun 2020 05:23:27 -0700 (PDT) Received: from [172.20.10.2] (unknown [85.76.109.0]) by sirainen.com (Postfix) with ESMTPSA id 0C1E52B3C8B; Mon, 22 Jun 2020 12:23:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Timo Sirainen In-Reply-To: Date: Mon, 22 Jun 2020 15:23:25 +0300 Cc: extra Content-Transfer-Encoding: quoted-printable Message-Id: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> References: To: Alexey Melnikov X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] draft-ietf-extra-quota: 64 bit numbers 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, 22 Jun 2020 12:23:29 -0000 On 22. Jun 2020, at 15.11, Alexey Melnikov = wrote: >=20 > On 17/06/2020 22:30, Timo Sirainen wrote: >=20 >>> The usage of a resource MUST be represented as a 32 bit unsigned >>> integer. >> I think we should go for 64 bit numbers already. RES-STORAGE is now = limited to 4 terabytes, which is rather high value for a single user's = limit for now, but I could imagine it being a possibility in some more = years. Maybe even already in email systems that use only a few users. = Also there's already an example: >>=20 >> C: G0001 GETQUOTA "!partition/sda4" >> S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) >> S: G0001 OK Getquota complete >>=20 >> The 4 TB limit can already be easily reached if describing a = filesystem size. >=20 > Sounds good. Shall we make it 63 bits to make it easier to implement = for Java based implementations? Yes. I think this 63/64bit issue was discussed some time ago already. = Maybe related to some other extension. From nobody Mon Jun 22 06:40:42 2020 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 C4FE93A0D1F for ; Mon, 22 Jun 2020 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 P2OO1-uUJLjT for ; Mon, 22 Jun 2020 06:40:39 -0700 (PDT) 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 6280A3A0D1E for ; Mon, 22 Jun 2020 06:40:39 -0700 (PDT) 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 6379BC0050; Mon, 22 Jun 2020 14:46:04 +0100 (IST) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1592833564; bh=fCLY44GBjKkoAqqmlWgNSlHDnuHMh9tqYLjO6WGtOY4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ffqio9DJ6PscReBdKZgBWt4xX4JrIrW2OEQd0CjXedjwGDLlejLQAngw0faj0iGKR fXWaSZ07MqAZloEW7C4yuKNVkd+QMYCnUkcM+jkOt0iAmQjzpCdblLpT7QYGyQed5E agJECOQSMFTqCsL7W2cFL2bSqmkEdJaJud7MEsWA= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1592833563-9695-9692/9/68; Mon, 22 Jun 2020 13:46:03 +0000 From: Arnt Gulbrandsen To: Timo Sirainen Cc: Alexey Melnikov , extra@ietf.org Date: Mon, 22 Jun 2020 15:40:36 +0200 Mime-Version: 1.0 Message-Id: <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> In-Reply-To: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> References: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.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] draft-ietf-extra-quota: 64 bit numbers 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, 22 Jun 2020 13:40:41 -0000 On Monday 22 June 2020 14:23:25 CEST, Timo Sirainen wrote: > On 22. Jun 2020, at 15.11, Alexey Melnikov > wrote: >> On 17/06/2020 22:30, Timo Sirainen wrote: >> ... > > Yes. I think this 63/64bit issue was discussed some time ago > already. Maybe related to some other extension. How about making ALL 32-bit numbers 63-bit in 4rev2? This may require nothing more than an entry in Appendix D. Arnt From nobody Mon Jun 22 06:41:51 2020 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 E07803A0D20 for ; Mon, 22 Jun 2020 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 8z6vnr2BMr90 for ; Mon, 22 Jun 2020 06:41:48 -0700 (PDT) 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 CF02A3A0D1E for ; Mon, 22 Jun 2020 06:41:31 -0700 (PDT) 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 56CEBC0050; Mon, 22 Jun 2020 14:46:57 +0100 (IST) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1592833617; bh=J6akbfm3/ynfJ2zOTYI1gAZVGmGrWDm3+C36D8fiGAo=; h=From:To:Subject:Date:From; b=PnTBfnv2LMRaRjbbC8aIJvP0nuxg6SyYKl4aHg5fDFGuRVcT7kkJKiru3qiztbndr nyXWM1jZGFc5FBAHYrQm7y/Nc/HyrLwYVN3VQ7TzQH9q0h2VmO9ryxNOSQzyRalB9N T3ATkBTTdcIuloZiQVA6EY+fJkYnDGycH3nd9zhY= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1592833616-9695-9692/9/69; Mon, 22 Jun 2020 13:46:56 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Mon, 22 Jun 2020 15:41:29 +0200 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] 4rev2, PREAUTH 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, 22 Jun 2020 13:41:50 -0000 Hi, how about dropping that? It seems to be little used and is presumably poorly tested. Arnt From nobody Mon Jun 22 06:45:35 2020 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 218A23A0D23 for ; Mon, 22 Jun 2020 06:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 CoTmIQrAz-7X for ; Mon, 22 Jun 2020 06:45:32 -0700 (PDT) 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 F1F0F3A0D22 for ; Mon, 22 Jun 2020 06:45:31 -0700 (PDT) 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 421ECC0050; Mon, 22 Jun 2020 14:50:57 +0100 (IST) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1592833857; bh=R7QUFcQWEROuNBd3C5j3CBUvowxVIaQAQFZXVIfMeRY=; h=From:To:Subject:Date:From; b=mG8a6/4YAX7XG7eWOSaxE+84k/gnN2p3iryzR9g5W1OWgbozzTAOqb5ULOMNyTuEC r9b6BGvp1H2XzO5kFynvQvkGEu5zugemZETVynNFSYZ9jgE6RnnD2fz68Bp1ArYj9L U5JGt4lMxIQhnrd1tQNZ8N5/wQVngeVTuaubCRwc= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1592833856-9695-9692/9/70; Mon, 22 Jun 2020 13:50:56 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Mon, 22 Jun 2020 15:45:29 +0200 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] 4rev2. implementation notes for 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, 22 Jun 2020 13:45:33 -0000 Hi, 4rev2 should contain two lists. One list titled roughly "as server authors, check all of these when you update 4rev1 code", the other for client authors, and this second would IMO arguably the most important part of this document. Appendix D isn't far from this in substance, but quite different in wording. Agreed? I can suggest wording. Arnt From nobody Mon Jun 22 07:08:33 2020 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 3ED263A0D48 for ; Mon, 22 Jun 2020 07:08:31 -0700 (PDT) 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 51rghmJqzlEu for ; Mon, 22 Jun 2020 07:08:30 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id CE84E3A0D47 for ; Mon, 22 Jun 2020 07:08:29 -0700 (PDT) Received: from [172.20.10.2] (unknown [85.76.109.0]) by sirainen.com (Postfix) with ESMTPSA id 64B662B3C8B; Mon, 22 Jun 2020 14:08:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Timo Sirainen In-Reply-To: <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> Date: Mon, 22 Jun 2020 17:08:25 +0300 Cc: extra@ietf.org, Alexey Melnikov Content-Transfer-Encoding: quoted-printable Message-Id: References: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] draft-ietf-extra-quota: 64 bit numbers 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, 22 Jun 2020 14:08:31 -0000 On 22. Jun 2020, at 16.40, Arnt Gulbrandsen = wrote: >=20 > On Monday 22 June 2020 14:23:25 CEST, Timo Sirainen wrote: >> On 22. Jun 2020, at 15.11, Alexey Melnikov = wrote: >>> On 17/06/2020 22:30, Timo Sirainen wrote: >>> ... >>=20 >> Yes. I think this 63/64bit issue was discussed some time ago already. = Maybe related to some other extension. >=20 > How about making ALL 32-bit numbers 63-bit in 4rev2? This may require = nothing more than an entry in Appendix D. I wouldn't make sequences or UIDs more than 32bit. I don't see much = benefits, only a lot of extra complexity and waste of memory/disk space. I wouldn't mind making message sizes (literals, RFC822.SIZE) 63bit = though. Dovecot has actually internally done that already since the = beginning. From nobody Mon Jun 22 07:12:42 2020 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 37CF33A0D4A for ; Mon, 22 Jun 2020 07:12:41 -0700 (PDT) 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 3XmDgdjPuhVu for ; Mon, 22 Jun 2020 07:12:40 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id E2ADD3A0D47 for ; Mon, 22 Jun 2020 07:12:39 -0700 (PDT) Received: from [172.20.10.2] (unknown [85.76.109.0]) by sirainen.com (Postfix) with ESMTPSA id 093782B3C8B; Mon, 22 Jun 2020 14:12:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Timo Sirainen In-Reply-To: Date: Mon, 22 Jun 2020 17:12:38 +0300 Cc: extra@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] 4rev2, PREAUTH 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, 22 Jun 2020 14:12:41 -0000 On 22. Jun 2020, at 16.41, Arnt Gulbrandsen = wrote: >=20 > Hi, >=20 > how about dropping that? It seems to be little used and is presumably = poorly tested. It's not used much, but I know there are a bunch of people using that = with Dovecot. Mutt, Pine and Evolution at least supports it (not sure = about Evolution nowadays). I'm also very commonly using it while = developing Dovecot, so I think it's pretty well tested in Dovecot at = least. I'm not necessarily against removing it, but I wouldn't say it's = entirely useless. From nobody Mon Jun 22 10:51:53 2020 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 866883A1038 for ; Mon, 22 Jun 2020 10:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 aSMaBvnNkD09 for ; Mon, 22 Jun 2020 10:51:49 -0700 (PDT) Received: from mx3.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 ADC053A1037 for ; Mon, 22 Jun 2020 10:51:49 -0700 (PDT) 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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 930326A230; Mon, 22 Jun 2020 19:51:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1592848303; bh=eoa/qFUt1CAHjSkOQzEx2FzwVA/FSWA5zfWIkpSYy2k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=s4N0rsy9pZNfcwDY/ud4tczzZuV4qhI/Svf8CxPOZ6ju5XrHWZxNYxDh1yvxECQ72 +NbML62hStQCJxBnJRZ52/QtRPLIhTxjsBSY4rOvnblXtHfKmyfXbOfi8lajNDNaGL W+8HGKnfG3711AYNHVRaZ5gc/lnmet/gWBn5haPkzCXZ/Pjvg4y1aoRlomvGaBW5EC 5+EsfkVrYlE4cYLb2TVmI1AHYX/XBLlZ9OL4zuoEEobYnA6jASppkfNOfcp9CJEf+Y Vb9I6FlHUSzohFXKrWMs0rZ6k8h4/ajacJTBe7B/uSzMfxTytWF+tjElVEZUGFpaWZ ARJ76PyJsCYgA== Received: from [10.168.3.2] (unknown [10.217.131.10]) (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 456273C004B; Mon, 22 Jun 2020 19:51:43 +0200 (CEST) To: Timo Sirainen , Alexey Melnikov Cc: extra References: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> From: Stephan Bosch Message-ID: Date: Mon, 22 Jun 2020 19:51:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] draft-ietf-extra-quota: 64 bit numbers 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, 22 Jun 2020 17:51:52 -0000 On 22/06/2020 14:23, Timo Sirainen wrote: > On 22. Jun 2020, at 15.11, Alexey Melnikov wrote: >> >> On 17/06/2020 22:30, Timo Sirainen wrote: >> >>>> The usage of a resource MUST be represented as a 32 bit unsigned >>>> integer. >>> I think we should go for 64 bit numbers already. RES-STORAGE is now limited to 4 terabytes, which is rather high value for a single user's limit for now, but I could imagine it being a possibility in some more years. Maybe even already in email systems that use only a few users. Also there's already an example: >>> >>> C: G0001 GETQUOTA "!partition/sda4" >>> S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) >>> S: G0001 OK Getquota complete >>> >>> The 4 TB limit can already be easily reached if describing a filesystem size. >> >> Sounds good. Shall we make it 63 bits to make it easier to implement for Java based implementations? > > Yes. I think this 63/64bit issue was discussed some time ago already. Maybe related to some other extension. This is mentioned in STATUS=SIZE, and in draft IMAP4rev2 by inference. Regards, Stephan. > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra > From nobody Mon Jun 22 10:56:08 2020 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 978213A1038 for ; Mon, 22 Jun 2020 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 pcRJxp7-yXZe for ; Mon, 22 Jun 2020 10:56:04 -0700 (PDT) Received: from mx3.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 4AE693A0DBE for ; Mon, 22 Jun 2020 10:56:04 -0700 (PDT) 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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id C81096A230; Mon, 22 Jun 2020 19:56:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1592848562; bh=IlHc91RlzD5b01s4US7Z1bEMdgcHzQsIODOwnnhk2p8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=KxzoEP4+QAXdCC6ywK7o95f+T1PTZMAnRyx6+TYWueExhVM6VSYZF25N9KikuiCrH noGL2qLj/dteJg3KTRAj+NcS7pcxBOj62waZCSEKPDaDlo0Segg+YCkBWJxoLs1Vgt MIbIYj3uAEIwgp/uHc7hze3EdFbP0wZxWQQTFKeOZK+WE1QqJCXUTBlUqFsjQnHg56 fYCnti0xaQ+2qbADDosHVg7A655BYy7tSLBSQX+Y8EbdM2iDuCaq4hPXNs7bOCtpxP q2eS4wwPyENS7FLbPAHIODWr0N2AS55XoypwEoZZp5ezK29zvLcjJb+tiLoVL+kgPK +V5s04q9p4Yxg== Received: from [10.168.3.2] (unknown [10.217.131.10]) (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 8A5593C004B; Mon, 22 Jun 2020 19:56:02 +0200 (CEST) To: Alexey Melnikov , extra@ietf.org References: <159238763595.1803.574245566610096074@ietfa.amsl.com> From: Stephan Bosch Message-ID: Date: Mon, 22 Jun 2020 19:56:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-15.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, 22 Jun 2020 17:56:07 -0000 Hi, On 17/06/2020 13:53, Alexey Melnikov wrote: > Hi all, > > On 17/06/2020 10:53, 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-15 >> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-15 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-15 > > In this version I finally removed multiple list patterns and also > clarified a few things based on earlier comments. I gave this document a quick review. Below are my comments so far. Quoted text from the document is copied directly, while my comments are prefixed with "-> ". Regards, Stephan section-2.3.2: $Phishing The $Phishing keyword can be used by a delivery agent to mark a message as highly likely to be a phishing email. An email that's determined to be a phishing email by the delivery agent should also be considered a junk email and have the appropriate junk filtering applied, including setting the $Junk flag and placing in the \Junk special-use mailbox if available. -> Special-use is not mentioned up to this point. It needs to be explained briefly or referred elsewhere. section-5.1: 5. Two characters, "#" and "&", have meanings by convention, and should be avoided except when used in that convention. -> Maybe remove the mystery and mention briefly what these are used for conventionally (or provide some citation). Section 5.1.2.1 does part of this, so that could at least be referred from here. section-6.3.9: -> This section mentions several examples of specific selection and return options without introduction. It should maybe refer to subsequent sections at the first instance of this. Future extensions to this specification should keep parallelism in mind and define a pair of corresponding options. -> So, what exactly is meant by "parallelism" here? Do you mean "dualism" or something like that (which I actually find equally confusing)? -> The SPECIAL-USE extension, which adds selection and return options, is not mentioned here, while the specification envelops it. section-6.3.9.2: For each selectable mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response followed by an untagged STATUS response containing the information requested in the STATUS return option. -> This sentence describes a hard requirement, but subsequent paragraphs describe what amounts to exceptions. Maybe this sentence should already announce this to the reader; e.g. ", except for the following cases." or something like that. This should also avoid confusion about the contraction that seems to exist between the paragraphs. section-6.3.9.5: The CHILDREN return option implements the Child Mailbox Extension, originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft Corporation. Most of the information in this section is taken directly from their original specification [RFC3348]. -> Is it conventional to have acknowledgements like this in the normative text? Also, text borrowed from other RFCs is only acknowledged in Appendix E. It is an error for the server to return both a \HasChildren and a \HasNoChildren attribute in the same LIST response. -> Any recommendation for what clients should do if this does happen? Provisionally treat it as \HasChildren? section-6.3.10: Namespace-Response-Extensions ABNF non terminal is defined for extensibility and MAY be included in the response. -> What is this? And this sentence is incomplete (no article at the beginning). section-6.3.12: On successful completion of an APPEND, the server SHOULD return an APPENDUID response code. -> This response code is not explained at this port. Provide brief purpose or reference to where it is explained. In the case of a mailbox that has UIDNOTSTICKY status (see UIDNOTSTICKY response code definition) -> See where? Needs reference. section-6.4.5: -> Now that the BINARY fetch items are also part of the specification, the "
" bit should probably be described separately before the enumeration of fetch data items. Stuffing it in the description of BODY is confusing, as it applies to several fetch items now. BODYSTRUCTURE The [MIME-IMB] body structure of the message. This is computed by the server by parsing the [MIME-IMB] header fields in the [RFC-5322] header and [MIME-IMB] headers. ENVELOPE The envelope structure of the message. This is computed by the server by parsing the [RFC-5322] header into the component parts, defaulting various fields as necessary. -> At least these two could use a forward reference to the FETCH response section, where the semantics of these are described in more detail. Could also put a single reference in the sentence announcing the list of data items. section-6.4.7: On successful completion of a COPY, the server SHOULD return a COPYUID response code. -> This response code is not explained at this point. Provide brief purpose or reference to where it is explained (weirdly, section on MOVE does this correctly). In the case of a mailbox that has UIDNOTSTICKY status (see the UIDNOTSTICKY response code), the server MAY omit the COPYUID response code as it is not meaningful. -> See where? Needs reference. section-7.4.1: -> Isn't this sub-section supposed to be in the section before? It is about the mailbox size, not message data. section-7.4.2: Note: [RFC-5322] requires that all messages have a valid Date header. Therefore, the date member in the envelope can not be NIL or the empty string. -> We all like to live in a perfect world, but what should the server do if the sender is naughty and the message has no Date header? Return the internal date instead? Note: [RFC-5322] requires that the In-Reply-To and Message- ID headers, if present, have non-empty content. Therefore, the in-reply-to and message-id members in the envelope can not be the empty string. -> Same... Note: [RFC-5322] requires that all messages have a valid From header. Therefore, the from, sender, and reply-to members in the envelope can not be NIL. -> Same... section-10: -> What about RFC 3501? section-11.4: Additional security considerations are discussed in the section discussing the AUTHENTICATE and LOGIN commands. -> Explicit references section-12.1: As this specification revises the AUTH= prefix, STARTTLS and LOGINDISABLED extensions previously defined in [IMAP-TLS], IANA is requested to update registry entries for these 3 extensions to point to this document. -> This is not noted in the document header. General comments: -> This document should probably mention at the appropriate locations pre-existing and often-implemented extensions that significantly improve upon the base IMAP4rev1/2 protocol. So, for example, the section describing IDLE could mention the NOTIFY capability. -> Enumerations of options/flags/items/identifiers are often strangely formatted. Compare e.g. the search key descriptions in https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-15#section-6.4.4 to the old https://tools.ietf.org/html/rfc3501#section-6.4.4 From nobody Tue Jun 23 00:46:21 2020 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 E163C3A09B8 for ; Tue, 23 Jun 2020 00:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 ZC6Pv1LQIEbl for ; Tue, 23 Jun 2020 00:46:18 -0700 (PDT) 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 5DFC63A10B1 for ; Tue, 23 Jun 2020 00:46:18 -0700 (PDT) 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 48816C00EF; Tue, 23 Jun 2020 08:51:43 +0100 (IST) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1592898703; bh=JxpUv7UD5hmrOLJWkuHLYVybTBc6H9ZSAqweVqZcBgw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ryUZpfwDWj07+OtoAgW8gr6ojChYBzIXN76TUjnUA1IQNUFaInowGlYe2mdzHQoF0 fGj4wvLXBLPaFho2RCichQYtWBzl7RGU+gIFyYfI3r/rl298aFlcBdYmIXXvGjp+pS sFLrKy1/WD0Ic46tysavyHTHulifyYQwuhCXWe9Q= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1592898702-9694-9692/9/75; Tue, 23 Jun 2020 07:51:42 +0000 From: Arnt Gulbrandsen To: Timo Sirainen Cc: extra@ietf.org Date: Tue, 23 Jun 2020 09:46:14 +0200 Mime-Version: 1.0 Message-Id: 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] 4rev2, PREAUTH 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: Tue, 23 Jun 2020 07:46:20 -0000 On second reflection, I don't think PREAUTH can be removed. IMAP4rev2 can easily deprecate things from the point where the client enables imap4rev2, but PREAUTH is before that point. Deprecation before that point would require very good justification. Arnt From nobody Tue Jun 23 03:21:13 2020 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 93BEA3A183A for ; Tue, 23 Jun 2020 03:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 xPhrlHj6S0aV for ; Tue, 23 Jun 2020 03:21:07 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE213A1836 for ; Tue, 23 Jun 2020 03:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592907666; d=isode.com; s=june2016; i=@isode.com; bh=jjjg4R2lX5fATA/eakyMizNYJNayeLxcN5vvcMe5b2Y=; 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=X89zrTpZRDttw2DlAHY3hT+0pYU21C4hWSjQUVZZr9uyTNbNqjZT/xpKMcdWHXavhy11Fw a/Iet22eqhWFQ0J8g9GW6ujD0gxnu9VIOv5ylZJvBtIBjTK8QURgTPDc5N5YMA7i1RLYdZ FXqFkKGmZUlXyBJjyL+QwtgMtudNpzo=; Received: from [172.27.251.32] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 23 Jun 2020 11:21:05 +0100 To: Arnt Gulbrandsen , Timo Sirainen Cc: extra@ietf.org References: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> From: Alexey Melnikov Message-ID: <99e0d0aa-cc3e-daed-9251-1ffba481b7d2@isode.com> Date: Tue, 23 Jun 2020 11:20:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] draft-ietf-extra-quota: 64 bit numbers 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: Tue, 23 Jun 2020 10:21:12 -0000 Hi Arnt, On 22/06/2020 14:40, Arnt Gulbrandsen wrote: > On Monday 22 June 2020 14:23:25 CEST, Timo Sirainen wrote: >> On 22. Jun 2020, at 15.11, Alexey Melnikov=20 >> wrote: >>> On 17/06/2020 22:30, Timo Sirainen wrote: >>> =C2=A0... >> >> Yes. I think this 63/64bit issue was discussed some time ago already.=20 >> Maybe related to some other extension. > > How about making ALL 32-bit numbers 63-bit in 4rev2? This may require=20 > nothing more than an entry in Appendix D. My proposal for 64bit sizes everywhere=20 (https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/) got=20 rejected a few years back, partially due to reasons of backward=20 compatibility with IMAP4rev1. I don't think we are yet at the point=20 where we can just do this. If we want to incorporate this now, I would like to see rather strong=20 support for this from this WG. Best Regards, Alexey From nobody Tue Jun 23 04:34:53 2020 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 03EE73A0D83 for ; Tue, 23 Jun 2020 04:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=arpSU7Ra; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LVUNMM8/ 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 ZWEyOYxbOPdy for ; Tue, 23 Jun 2020 04:34:49 -0700 (PDT) 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 C1B593A0D86 for ; Tue, 23 Jun 2020 04:34:49 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DBDACA3C for ; Tue, 23 Jun 2020 07:34:48 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 23 Jun 2020 07:34:48 -0400 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=fm3; bh=KaWOY7x hznhHX/4+vuEABej/XqmptXRS9z7GhnhjDdU=; b=arpSU7RaWzUusdbHNza5WVz 5MtbDm7jswcel/Dpcu33YjLV8MC/C5yPtBkkVNZdGU4//nuW3PakXsahoqcBXGEm tckIn9OntvlbJ/NjwWSPUkHpwajEYCwZuRDi6/E4Wsq5mwBz8LgPWhsWBUttmCvp UHePzq3rNhL8ukQ/s8IgxoJz0Aylek8RAijDusY/snPG1wjOa3DzKedb3WYqlLVB 1dQZ4e1IggDZbgo5pXJAjwsZrJKOh4suhUXulsDrInfdy2UUnKS7lQU6aj8Hz89R J6yvNfsIstybrTcTW2CZ3DBw9a6oC8q8NtU1LV4CnxPaTTawbh24OuKR6ERRDLQ= = 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=fm3; bh=KaWOY7 xhznhHX/4+vuEABej/XqmptXRS9z7GhnhjDdU=; b=LVUNMM8/X9REBT1P/Twv87 iOK5bLZUjpkNSNYEj2EeM83H3FY2Pe26Uv9MC6WKxqQMgCdbGkt95AK4F7FD4q86 KUERN8kcHMewunU0KyvdUwnYOv7KHd3UpOCh+gwfOwLxHh/+LUb3iGwb5pzkmKSq 4E3+mOEmrHsBkMj7ckWUBz1FiW2fU8cORORUZyXHQEDOsmYxyrwT8Is44vq6MvaV TTnD3gg2FynQqPSYEzToIGbTyTln5dAvfdxtvYkH9Qrlw2p3plOAPO8K0/H/bsLb H0qh9y1mEKO6ptedzgNWN0lExdui2FGTl++kXsOi973mCFnZkxHjhDSk755dE0xg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekhedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2D3C6180091; Tue, 23 Jun 2020 07:34:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: <91984c14-505a-4e2c-a626-ca96549b7f4f@dogfood.fastmail.com> In-Reply-To: References: Date: Tue, 23 Jun 2020 21:34:27 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=6e84d69468de42eea9a582b88e53a3b3 Archived-At: Subject: Re: [Extra] 4rev2. implementation notes for 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: Tue, 23 Jun 2020 11:34:51 -0000 --6e84d69468de42eea9a582b88e53a3b3 Content-Type: text/plain On Mon, Jun 22, 2020, at 23:45, Arnt Gulbrandsen wrote: > Hi, > > 4rev2 should contain two lists. One list titled roughly "as server authors, > check all of these when you update 4rev1 code", the other for client > authors, and this second would IMO arguably the most important part of this > document. > > Appendix D isn't far from this in substance, but quite different in > wording. > > Agreed? I can suggest wording. I had a similar thought about a third list which would be titled something like "interactions with RFC3501 extensions" which lists each of the documents that extend RFC3501 and says things like: * "is merged in and part of THISRFC" * "is partially required by THISRFC" * "works exactly the same as before" * "works slightly differently in these ways" * "is not compatible at all, you can't do them together" I'm happy to help with wording, though it will probably require some workshopping! Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --6e84d69468de42eea9a582b88e53a3b3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, Jun 22, 2020, at 23:45, Arnt Gulbrandsen wrote:
Hi,

4rev2 should contain two lists. One l= ist titled roughly "as server authors, 
check all of these when you update 4rev1 code", the othe= r for client 
authors, a= nd this second would IMO arguably the most important part of this <= br>
document.

Appe= ndix D isn't far from this in substance, but quite different in 
wording.

Agreed?= I can suggest wording.

I had a similar thou= ght about a third list which would be titled something like "interaction= s with RFC3501 extensions" which lists each of the documents that extend= RFC3501 and says things like:

* "is merged in and part = of THISRFC"
* "is partially r= equired by THISRFC"
* "works = exactly the same as before"
*= "works slightly differently in these ways"
* "is not compatible at all, you can't do them together"<= br>

I'm happy to help with wording, though it will probably r= equire some workshopping!
Cheers,

Bron.

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

<= div style=3D"font-family:Arial;">
--6e84d69468de42eea9a582b88e53a3b3-- From nobody Tue Jun 23 04:37:44 2020 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 20CD53A184E for ; Tue, 23 Jun 2020 04:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=RQtnPQhR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qrvtsGwN 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 wWmxQMxh_drb for ; Tue, 23 Jun 2020 04:37:40 -0700 (PDT) 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 A238F3A1864 for ; Tue, 23 Jun 2020 04:37:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 26841A45 for ; Tue, 23 Jun 2020 07:37:40 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 23 Jun 2020 07:37:40 -0400 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=fm3; bh=I1Mkhrz Lu8TFtVmO+aEoeeAo68xU41O811vUD8LUxzA=; b=RQtnPQhRVy5o344otgqMAxP yMA8XU2mRaot+/ZuFhHjLtyK/Hr65DbMd4mnwnzFQGpiDqaqlY8PfU+a74y1lzIM uuzRuUIzApWOIlsMwsJsMt0vDfTXf0D5E5Wsxeki+DLMQpqjue8tRcq8yam1yV+F KchaISXZNTzDY1z2tBLmtpthclDa0yfu58t15AitT8ndPoDAZrUH9iyNefCxzLID KEw87GcdgBj1j6gEewCTEuVvZ5nR6JN3h+zwW8wiwEgCSlRCYMiqdgVhk1zuALMB 2ffncdKZS8yXhQaJy/6Bv8eAxRQR3YZkqD4tnqovRdIYQaEnW030JFwiBXDyKHg= = 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=fm3; bh=I1Mkhr zLu8TFtVmO+aEoeeAo68xU41O811vUD8LUxzA=; b=qrvtsGwNvnESrAKaeOLGfu 8ORsvxwESW3/MkW+pC4q+PLuq42gzgpot0ymTXxl/+5D5s/il7WeHbVp9rjVRzGP OG9sKXKGhershOQ17gFtqcWktoDg+kvvnn4DtLq5F8bfm1D3z5uIETEiKNGuO8w4 438DjBhUoTv17oLFpDoBLv415vpPit7A/BG3CPe1S99jgcYTcNGT4TreuNAQiMvY 9H4aYva2MmoM3XUunrkUU4eilCs+JKeiByAsAdlJotivMl69weydRveUpFxDRRgn cNBo9l3DqBhkz0ujIGHN4Mul+/sZ+ZKnwuCb/ieC9zXrVbKdxgoiLBZgW+wCdhfA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekhedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffveefiefgje evteehheelgeetleetveeguedthfehgffhtdejhfdvhefhtdekgfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 66C0D180091; Tue, 23 Jun 2020 07:37:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: <29511fb8-f027-4081-8bda-1b459768e84f@dogfood.fastmail.com> In-Reply-To: <99e0d0aa-cc3e-daed-9251-1ffba481b7d2@isode.com> References: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> <99e0d0aa-cc3e-daed-9251-1ffba481b7d2@isode.com> Date: Tue, 23 Jun 2020 21:37:19 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=efa96bf1d0c6467d9292b282655aec2b Archived-At: Subject: Re: [Extra] draft-ietf-extra-quota: 64 bit numbers 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: Tue, 23 Jun 2020 11:37:42 -0000 --efa96bf1d0c6467d9292b282655aec2b Content-Type: text/plain On Tue, Jun 23, 2020, at 20:20, Alexey Melnikov wrote: > Hi Arnt, > > On 22/06/2020 14:40, Arnt Gulbrandsen wrote: > > > On Monday 22 June 2020 14:23:25 CEST, Timo Sirainen wrote: > >> On 22. Jun 2020, at 15.11, Alexey Melnikov > >> wrote: > >>> On 17/06/2020 22:30, Timo Sirainen wrote: > >>> ... > >> > >> Yes. I think this 63/64bit issue was discussed some time ago already. > >> Maybe related to some other extension. > > > > How about making ALL 32-bit numbers 63-bit in 4rev2? This may require > > nothing more than an entry in Appendix D. > > My proposal for 64bit sizes everywhere > (https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/) got > rejected a few years back, partially due to reasons of backward > compatibility with IMAP4rev1. I don't think we are yet at the point > where we can just do this. > > If we want to incorporate this now, I would like to see rather strong > support for this from this WG. Just to summarise the reason it got rejected, it was something like "suppose you get something created by a V2 client which is larger than 32 bits - what does the v1 client see? The bigger item?, nothing?, a truncated version at 2^32-1?". The can has worms in it :( Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --efa96bf1d0c6467d9292b282655aec2b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Jun 23, 2020, at 20:20, Alexey Melnikov wrote:
=
Hi Arnt,

<= /div>
On 22/06/2020 14:40, Arnt Gulbran= dsen wrote:

> On Monday 22 June 2020 14:23:25 CEST, Ti= mo Sirainen wrote:
>> O= n 22. Jun 2020, at 15.11, Alexey Melnikov 
>>> On 17/06/2020 22:30, Timo Sirainen wrote:<= br>
>>>  ...
>>
>> Yes. I think this 63/64bit issue was discussed= some time ago already. 
>> Maybe related to some other extension.
>
>= How about making ALL 32-bit numbers 63-bit in 4rev2? This may require&n= bsp;
> nothing more than a= n entry in Appendix D.

My proposal for 64bit sizes everyw= here 
<= div style=3D"font-family:Arial;">rejected a few years back, partially du= e to reasons of backward 
compatibility with IMAP4rev1. I don't think we are yet at the point&nb= sp;
where we can just do this= .

If we want to incorporate this now, I would like to see= rather strong 
support = for this from this WG.

Just to summarise the= reason it got rejected, it was something like "suppose you get somethin= g created by a V2 client which is larger than 32 bits - what does the v1= client see?  The bigger item?, nothing?, a truncated version at 2^= 32-1?".  The can has worms in it :(

Bron.
<= div style=3D"font-family:Arial;">
= --
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--efa96bf1d0c6467d9292b282655aec2b-- From nobody Tue Jun 23 04:49:08 2020 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 05F473A1876 for ; Tue, 23 Jun 2020 04:49:07 -0700 (PDT) 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 SFwiUYHLqDlk for ; Tue, 23 Jun 2020 04:49:05 -0700 (PDT) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id B9CD03A109F for ; Tue, 23 Jun 2020 04:49:04 -0700 (PDT) Received: from [172.20.10.2] (unknown [85.76.109.0]) by sirainen.com (Postfix) with ESMTPSA id 84D502B3C8B for ; Tue, 23 Jun 2020 11:49:00 +0000 (UTC) From: Timo Sirainen Content-Type: multipart/alternative; boundary="Apple-Mail=_AFBD451A-699E-4CB3-A295-B7B6CB62E5F2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 14:48:59 +0300 References: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> <99e0d0aa-cc3e-daed-9251-1ffba481b7d2@isode.com> <29511fb8-f027-4081-8bda-1b459768e84f@dogfood.fastmail.com> To: extra@ietf.org In-Reply-To: <29511fb8-f027-4081-8bda-1b459768e84f@dogfood.fastmail.com> Message-Id: <396060DA-BACB-4B42-A2EB-1CF4AE4E956C@sirainen.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Extra] draft-ietf-extra-quota: 64 bit numbers 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: Tue, 23 Jun 2020 11:49:07 -0000 --Apple-Mail=_AFBD451A-699E-4CB3-A295-B7B6CB62E5F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23. Jun 2020, at 14.37, Bron Gondwana wrote: >=20 > On Tue, Jun 23, 2020, at 20:20, Alexey Melnikov wrote: >> Hi Arnt, >>=20 >> On 22/06/2020 14:40, Arnt Gulbrandsen wrote: >>=20 >> > On Monday 22 June 2020 14:23:25 CEST, Timo Sirainen wrote: >> >> On 22. Jun 2020, at 15.11, Alexey Melnikov=20 >> >> > = wrote: >> >>> On 17/06/2020 22:30, Timo Sirainen wrote: >> >>> ... >> >> >> >> Yes. I think this 63/64bit issue was discussed some time ago = already.=20 >> >> Maybe related to some other extension. >> > >> > How about making ALL 32-bit numbers 63-bit in 4rev2? This may = require=20 >> > nothing more than an entry in Appendix D. >>=20 >> My proposal for 64bit sizes everywhere=20 >> (https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/ = ) got=20 >> rejected a few years back, partially due to reasons of backward=20 >> compatibility with IMAP4rev1. I don't think we are yet at the point=20= >> where we can just do this.. >>=20 >> If we want to incorporate this now, I would like to see rather strong=20= >> support for this from this WG. >=20 > Just to summarise the reason it got rejected, it was something like = "suppose you get something created by a V2 client which is larger than = 32 bits - what does the v1 client see? The bigger item?, nothing?, a = truncated version at 2^32-1?". The can has worms in it :( One possibility is that we could allow 63bit numbers for FETCH results, = but not for APPEND. So it would be future compatible with reading large = mails, even if IMAP couldn't be used to save them directly. --Apple-Mail=_AFBD451A-699E-4CB3-A295-B7B6CB62E5F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 23. Jun 2020, at 14.37, Bron Gondwana <brong@fastmailteam.com> wrote:

On Tue, Jun 23, = 2020, at 20:20, Alexey Melnikov wrote:
Hi Arnt,

On 22/06/2020 14:40, Arnt = Gulbrandsen wrote:

> On Monday 22 June 2020 14:23:25 CEST, Timo = Sirainen wrote:
>> On 22. Jun 2020, at 15.11, Alexey Melnikov 
>> = <alexey.melnikov@isode.com> wrote:
>>> On 17/06/2020 22:30, Timo Sirainen wrote:
>>>  ...
>>
>> Yes. I think this = 63/64bit issue was discussed some time ago already. 
>> = Maybe related to some other extension.
>
> How about making ALL = 32-bit numbers 63-bit in 4rev2? This may require 
> = nothing more than an entry in Appendix D.

My proposal for 64bit sizes = everywhere 

If we want to incorporate this = now, I would like to see rather strong 
support for this from this = WG.

Just to summarise = the reason it got rejected, it was something like "suppose you get = something created by a V2 client which is larger than 32 bits - what = does the v1 client see?  The bigger item?, nothing?, a truncated = version at 2^32-1?".  The can has worms in it :(

One = possibility is that we could allow 63bit numbers for FETCH results, but = not for APPEND. So it would be future compatible with reading large = mails, even if IMAP couldn't be used to save them = directly.

= --Apple-Mail=_AFBD451A-699E-4CB3-A295-B7B6CB62E5F2-- From nobody Tue Jun 23 05:59:13 2020 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 520883A0C63 for ; Tue, 23 Jun 2020 05:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 WlVAwCw4Emam for ; Tue, 23 Jun 2020 05:59:11 -0700 (PDT) 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 DCF7E3A0C45 for ; Tue, 23 Jun 2020 05:59:10 -0700 (PDT) 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 52046C00EF; Tue, 23 Jun 2020 14:04:35 +0100 (IST) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1592917475; bh=hfR0t1XXqmxFRIXab27myw3+J4MBRZxyrcQnVKVzw/U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tOQn7ALEoCjGTehXLk22G1dowhcUmAFfACaFhNV5PeOKJI7czUo+rkZ3ed1zMIJ1y lukL/OtsDxDcoLnjRkltvMFGGKlVCDyoIqA0O7RK6YSzGnJfHMNRjup6lwx3EPDlkp 98waTBOjDNQAE3ClTZAr4uOJFrDMgl5NtLeMyquc= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1592917474-9694-9692/9/77; Tue, 23 Jun 2020 13:04:34 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Tue, 23 Jun 2020 14:59:07 +0200 Mime-Version: 1.0 Message-Id: In-Reply-To: <396060DA-BACB-4B42-A2EB-1CF4AE4E956C@sirainen.com> References: <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> <99e0d0aa-cc3e-daed-9251-1ffba481b7d2@isode.com> <29511fb8-f027-4081-8bda-1b459768e84f@dogfood.fastmail.com> <396060DA-BACB-4B42-A2EB-1CF4AE4E956C@sirainen.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] draft-ietf-extra-quota: 64 bit numbers 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: Tue, 23 Jun 2020 12:59:12 -0000 On Tuesday 23 June 2020 13:48:59 CEST, Timo Sirainen wrote: > One possibility is that we could allow 63bit numbers for FETCH > results, but not for APPEND. So it would be future compatible > with reading large mails, even if IMAP couldn't be used to save > them directly. That's more or less what I had in mind. I think APPEND should be free to reject very large arguments, but the definition of "very large" should be an implementation matter, not a protocol matter. The protocol should allow the client to send {723894723489237} in the prelude to appending, and then the server can say NO [LIMIT], but cannot say BAD [CLIENTBUG]. Servers that also serve 4r1 (all, I suppose) would of course have appropriate limits. The practical effect of the change is to provide a simple, easily comprehensible change. "Make sure that your number parser can parse from 0 to 9223372036854775807." Simplicity is a feature. Arnt From nobody Tue Jun 23 22:42:03 2020 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 B57343A095C for ; Tue, 23 Jun 2020 22:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=Qoh9h4HG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SstHvLyM 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 35B0TWV-tjK9 for ; Tue, 23 Jun 2020 22:41:59 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B293A0B4A for ; Tue, 23 Jun 2020 22:41:59 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2BC827F4 for ; Wed, 24 Jun 2020 01:41:59 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 01:41:59 -0400 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=fm3; bh=IJ7AXq+Mm6oTpx6Mlio55Ii+bFQC71JJRqY9tqG bk2I=; b=Qoh9h4HGFWG4L+Oj+vz2P1dYTWNG/DYrxkXdo06EiDG6lellECsXTuA +06uYo6LMTaaGhY1Vnxtaoe7mm53K2HJ0Q7aFrGritCxafj68Mwi+ShnUUw45U88 dx894fIyI0baaLf5EugQS83r1tVoKZ7alh++PpXAC/+C6ux6pLA7GiP4Z/GrJs8n cRksABBRc5FkHL5jrYnRJ34+rFFSz+EpX8q0huBq1FAAM6iM7vV7evms/KeQ/xpx Z8aUJOISiUdDxAYirBqB24A1VD3sW3WwZEp5E+3xwMW6Xu4Oh+VK8wAjGOyUip5+ mvJUo6e2Rm8CAr4hsaR5Nh61i3Y6+NQ== 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=fm3; bh=IJ7AXq+Mm6oTpx6Mlio55Ii+bFQC7 1JJRqY9tqGbk2I=; b=SstHvLyMY8ta6CPZKQ/VqJZMW7DZeqN9+wu5Yv21+w1ky q5LVQnmP3Zte4QZPEKncH8Zf72MWVenoPOsy4DZznLjCGBTfrcVKn+eCOCxSZ9yL /0Nay9M1WwP8erfECFVFaIslo1pHELc9d4xMSs2QfXiBmrFUqbGvmQJCGtogKxn7 272e6nvrSRvRT3PmGKRXVCRA4jWahdMF+nkns6zOJUk/jz2KZYm36IIZyQoY0yDV qnMp2AE9JQ2J8o6WuGt9Y68WKGd/tTlH3gc/FLK2UG6fuZBg3/knKV6+e/njrdil tiiRGN7xpKvRjz3HeKzGafJD1rMQPc/5H8He6QpPg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9EA2E180091; Wed, 24 Jun 2020 01:41:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: <79c93cda-68aa-4078-b75e-2c5d6d1dfaa7@dogfood.fastmail.com> Date: Wed, 24 Jun 2020 15:41:37 +1000 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=a156ca7d09d3412e8ed5f0dd4ad86b8a Archived-At: Subject: [Extra] Action points from last week's interim meeting 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, 24 Jun 2020 05:42:02 -0000 --a156ca7d09d3412e8ed5f0dd4ad86b8a Content-Type: text/plain *The full minutes are available in the datatracker:** * https://datatracker.ietf.org/meeting/interim-2020-extra-01/materials/minutes-interim-2020-extra-01-202006171400 If you have any actions listed there, please make sure you do them! Thanks. In particular, ALL have been asked to review the quota draft. *_ This means you._* *Here's the full list of actions:** * ACTION: All please review the draft for quota. ACTION: Alexey to review notes and publish another draft of IMAP4rev2 before Madrid. ACTION: Alexey to make SETQUOTA a separate capability in the quota draft. ACTION: Bron to initiate discussion on the list about reverting to a simpler version of preview. ACTION: Bron will make changes from Alexey and upload into group for sieve-mailboxid ACTION: Bron, follow up with Stephan about EAI Sieve document. ACTION: Ken will put together a -00 draft for sieve-snooze. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --a156ca7d09d3412e8ed5f0dd4ad86b8a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
The full minutes are available in the datatracker:<= b>


If you have = any actions listed there, please make sure you do them!  Thanks.&nb= sp; In particular, ALL have been asked to review the quota draft. <= i> This means you.

Here's the full list of = actions:

ACT= ION: All please review the draft for quota.

AC= TION: Alexey to review notes and publish another draft of IMAP4rev2 befo= re Madrid.
ACTION: Alexey to = make SETQUOTA a separate capability in the quota draft.
ACTION: Bron to initiate= discussion on the list about reverting to a simpler version of preview.=
ACTION: Bron will make chang= es from Alexey and upload into group for sieve-mailboxid
ACTION: Bron, follow up with Stephan about E= AI Sieve document.

=
ACTI= ON: Ken will put together a -00 draft for sieve-snooze.

Cheers,

Bron.

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


--a156ca7d09d3412e8ed5f0dd4ad86b8a-- From nobody Tue Jun 23 23:09:23 2020 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 264F53A0B99 for ; Tue, 23 Jun 2020 23:09:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159297896114.4676.17327779156729128050@ietfa.amsl.com> Date: Tue, 23 Jun 2020 23:09:21 -0700 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: Wed, 24 Jun 2020 06:09:21 -0000 Changed milestone "Adopt a document for EAI with Sieve", set due date to June 2020 from December 2019, added draft-bosch-sieve-eai to milestone. Changed milestone "Submit "IMAP4rev2" to IESG as a Proposed Standard", set due date to September 2020 from December 2019. Changed milestone "Submit "Quota BIS" to IESG as a Proposed Standard", set due date to December 2020 from February 2020. Changed milestone "Update charter to reflect current and planned work", set due date to December 2020 from April 2020. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Tue Jun 23 23:17:21 2020 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 B75A53A0BA1 for ; Tue, 23 Jun 2020 23:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=CD5GsaH7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YS6+EfNA 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 GZ19coLZqwFy for ; Tue, 23 Jun 2020 23:17:14 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B343A3A0B9C for ; Tue, 23 Jun 2020 23:17:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C57018AC; Wed, 24 Jun 2020 02:17:13 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 02:17:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm3; bh=FteH7M33oznUi4ZVjznGto9KVCVRhLo 2oyqyYw+dHfE=; b=CD5GsaH7uHiD3IpCvVJNPnAlaCLtl9wBRD0KXMyCclJ/2F4 6VwfIsWUXDpSXAWKsll2/XQlmVOfIKKYqamvG2G9Fn0ZBev8wBncHaJRQJQGBQGQ 76fshixwUyMqpMYDeHwvCz3abZAJm+8zFFEPl8vk88Brvf7vd6tr19JWuOG7B9RB Hh8uskwgB7d4359STuM4ICxpuETmT6wZvMGq5yikphOc5BFab3DVxFNDQal2MuAu ALFY4b0d2b18HvYWUt/gzPHp8DN1zdRy6T4glbymnvTHS8/BzLXEa0gmyHv4ZGXs A/w7nh7xMhlJrdQY+GbkGzJ7jHmpkeXhA4pajtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=FteH7M33oznUi4ZVjznGto9KVCVRh Lo2oyqyYw+dHfE=; b=YS6+EfNAmCUd/EHBCto06P89cu5O1idHBxiyBIsZT6ahX 94YRqTZmheWRq3+aK9UDkBrj5/VrA9DAu8Spni4/7W8XUqQeDJLeVvJp/fora13E wIFhxMzRgArEuGNphvRewasSBDBOJ+MjpK1nUdwbsAJfUt46ZEnU/DYUGS7akNvH A/8rTHQupXlCiMRwlR9OnoX+TW1WWIupNyCzONXQ+MCywL4rWK9Jhx4Q5AhWk6GM f+YcEfMToJKA6T1h00WYrz4RL76eOfTd20O+j1eqbSEP+IsP9POYkZMeJY/lPxKg vUpLhPzJhZmUPb1FTZIK/UbHKvqViE+1gepobrQAA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpedvteetieeviefhgeeitdegiefgudevleehgfffleegleeu hefhiedtleegtdffgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D7448180091; Wed, 24 Jun 2020 02:17:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: Date: Wed, 24 Jun 2020 16:16:52 +1000 From: "Bron Gondwana" To: extra@ietf.org Cc: "Michael Slusarz" , "Barry Leiba" Content-Type: multipart/alternative; boundary=060b27245aef44eba8b32f6db5cabb72 Archived-At: Subject: [Extra] Reverting draft-ietf-extra-imap-fetch-preview to an earlier design 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, 24 Jun 2020 06:17:20 -0000 --060b27245aef44eba8b32f6db5cabb72 Content-Type: text/plain Hi All, I've been in contact with the authors of draft-ietf-extra-imap-fetch-preview, and they're not happy with the current state. We ended up with something over-complicated. The suggestion from the interim meeting last week was to pare it right back to a very basic thing - just a single fetch item called PREVIEW which is plain text of up to 255 characters or so, server defined, no fancy algorithms, no nothing else. If we want to add something more complex later, we can always do a separate extension for that. Value MAY change over time as server algorithms are updated, but it's fine to keep the previous version cached. *Michael* - do you agree with that characterisation? Everyone in the meeting last week was in favour of doing that. Are you happy to update the wording and submit a new draft? *Barry* - do we need to bring the document back from "submitted to the IESG" into the working group, or is it OK just to have a new draft submitted? I'm sure we'll review it here either way. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --060b27245aef44eba8b32f6db5cabb72 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

I've been in contact with the autho= rs of draft-ietf-extra-imap-fetch-preview, and they're not happy with th= e current state.  We ended up with something over-complicated.
<= /div>

The suggestion from the interim meeting last week was to pare= it right back to a very basic thing - just a single fetch item called P= REVIEW which is plain text of up to 255 characters or so, server defined= , no fancy algorithms, no nothing else.  If we want to add somethin= g more complex later, we can always do a separate extension for that.

Value MAY change over time as server algorithms are updated= , but it's fine to keep the previous version cached.

M= ichael - do you agree with that characterisation?  Everyone in = the meeting last week was in favour of doing that.  Are you happy t= o update the wording and submit a new draft?

Barry= - do we need to bring the document back from "submitted to the IESG" in= to the working group, or is it OK just to have a new draft submitted?&nb= sp; I'm sure we'll review it here either way.

Thanks,
=

Bron.

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


--060b27245aef44eba8b32f6db5cabb72-- From nobody Wed Jun 24 07:10:48 2020 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 2346A3A0DE8 for ; Wed, 24 Jun 2020 07:10:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159300784713.1780.12496939412244065423@ietfa.amsl.com> Date: Wed, 24 Jun 2020 07:10:47 -0700 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: Wed, 24 Jun 2020 14:10:47 -0000 Changed milestone "Adopt a sieve-snooze document", set state to active from review, accepting new milestone. Changed milestone "Submit sieve-mailboxid to the IESG as a proposed standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/extra/about/ From nobody Wed Jun 24 07:14:32 2020 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 458153A0DE8 for ; Wed, 24 Jun 2020 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Mmym3DuQhWU7 for ; Wed, 24 Jun 2020 07:14:30 -0700 (PDT) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323D53A0DE5 for ; Wed, 24 Jun 2020 07:14:30 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id y5so2249534iob.12 for ; Wed, 24 Jun 2020 07:14:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fwDnpUakN9afQAHE+HwgnsvFWvwhOa85FJsSGlWjfYU=; b=MpN6dw+D5nwBvT8xKwlU56PXB2zb8yGTk1VzeTuY4uSsqWiSTKiDGimlI42Fs25pKx fLLSXadhQz6AStOwCqWgynmeBAv64LW6+/3c8OZqpZoJ/jndGJ56PQJ3Ai6bNJJ6C1+s MfcpLz3RHdcBA5TmOGQWjX9FhG0CoG/VwFwQSe2ChSA46bwmV59Lws+AGwMcTSBlbGnw aZ0MJZX7NkgmSPKs6JlinSW5ymyLdyApKif7jgOWwxtti1YuccnH8lzD5Gl90eK/lSFw UWgqMXMW2uYWG+9JLWthtctHbHR/9YJ5RulBmPRb2fsnLripdoknl6mKfY74X4gantP1 KEig== X-Gm-Message-State: AOAM530S16Sph1KVznvVgUOG8yf+LFcVcwxVPOZGlihMbo4LvC7Pkb+w KKbi/smLmkECcEVcFlpFGrvYTXSWo4c/aVUJyZo= X-Google-Smtp-Source: ABdhPJypTqXqeKhK/RkQcKcGg3izrGeAvyk/iPyzAG8E0IW8pjThGsC66QDkJjDCmhS4BIfXu6JmBOX3Ax0an2mQ4IA= X-Received: by 2002:a05:6602:13c6:: with SMTP id o6mr30261028iov.84.1593008069301; Wed, 24 Jun 2020 07:14:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Wed, 24 Jun 2020 10:14:18 -0400 Message-ID: To: Bron Gondwana Cc: extra@ietf.org, Michael Slusarz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] Reverting draft-ietf-extra-imap-fetch-preview to an earlier design 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, 24 Jun 2020 14:14:31 -0000 I think it's best to bring it back to the working group, so I will do that. Because it wasn't in "Approved" state before March it will need more ballots from the new ADs anyway, and with the changes we're talking about it should get a new last call anyway. Barry On Wed, Jun 24, 2020 at 2:17 AM Bron Gondwana wrot= e: > > Hi All, > > I've been in contact with the authors of draft-ietf-extra-imap-fetch-prev= iew, and they're not happy with the current state. We ended up with someth= ing over-complicated. > > The suggestion from the interim meeting last week was to pare it right ba= ck to a very basic thing - just a single fetch item called PREVIEW which is= plain text of up to 255 characters or so, server defined, no fancy algorit= hms, no nothing else. If we want to add something more complex later, we c= an always do a separate extension for that. > > Value MAY change over time as server algorithms are updated, but it's fin= e to keep the previous version cached. > > Michael - do you agree with that characterisation? Everyone in the meeti= ng last week was in favour of doing that. Are you happy to update the word= ing and submit a new draft? > > Barry - do we need to bring the document back from "submitted to the IESG= " into the working group, or is it OK just to have a new draft submitted? = I'm sure we'll review it here either way. > > Thanks, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > From nobody Wed Jun 24 08:09:21 2020 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 72B263A0E72 for ; Wed, 24 Jun 2020 08:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 0rDRGLnb1it4 for ; Wed, 24 Jun 2020 08:09:19 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [208.79.93.154]) (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 970E03A0ECC for ; Wed, 24 Jun 2020 08:09:18 -0700 (PDT) Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id e9fc161b; Wed, 24 Jun 2020 08:09:18 -0700 (PDT) From: Lyndon Nerenberg To: Timo Sirainen cc: Arnt Gulbrandsen , extra@ietf.org In-reply-to: References: Comments: In-reply-to Timo Sirainen message dated "Mon, 22 Jun 2020 17:12:38 +0300." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99024.1593011358.1@orthanc.ca> Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2020 08:09:18 -0700 Message-ID: Archived-At: Subject: Re: [Extra] 4rev2, PREAUTH 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, 24 Jun 2020 15:09:20 -0000 Timo Sirainen writes: > It's not used much > I'm not necessarily against removing it, but I wouldn't say it's entirel= y use > less. I'll just note that I've used PREAUTH in the past on IMAP servers dedicate= d to serving up mailing list archives, and found it quite useful. Think of = it as the IMAP version of anonymous FTP. --lyndon From nobody Thu Jun 25 16:13:03 2020 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 E29573A105D for ; Thu, 25 Jun 2020 16:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 q3PUQ2OzknAS for ; Thu, 25 Jun 2020 16:12:59 -0700 (PDT) Received: from mx3.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 030FD3A1054 for ; Thu, 25 Jun 2020 16:12:58 -0700 (PDT) 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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 505156A30D; Fri, 26 Jun 2020 01:12:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1593126776; bh=xm82JA864GqD3Xr/Qrx5cyjAfUxw8FxeOxpWxBZwgm4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=caLyamuY1/u7Tf0sjGWknyPeoUrVQ6AXYfuoVo3lUGIR806etQwyRxOZSMNDMK3Sp v8wKVDhd9jaZs9ULx14nmRTvgGi032/7vG/nEVYmfMLFSmF3G5kcOqQBB91hMMSDLz DxwnOfpaVNLToTRlftBK20nOOsngKVXCZ8iEm2x8Ll89+ihL19fnGsS5g9cnS1cER0 nS4Aoykqy/KTP5C2g+gZfXsYUoMsdvPsfpbJvTI04qzVDODI2nfNU40Xmij7XywQrD swCumZ66ha4KrgbD7rZdF29h2RzMJRtnFBicj3mUa4ExCJfuh8fcNcOy77NgmEu9Zv WEjVUTqILb1PA== 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 1EBB03C0250; Fri, 26 Jun 2020 01:12:56 +0200 (CEST) Date: Thu, 25 Jun 2020 17:12:54 -0600 (MDT) From: Michael Slusarz To: Bron Gondwana , extra@ietf.org Cc: Barry Leiba Message-ID: <867062184.6798.1593126775956@appsuite.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6797_1482858832.1593126775950" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev13 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] [EXT] Reverting draft-ietf-extra-imap-fetch-preview to an earlier design 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, 25 Jun 2020 23:13:01 -0000 ------=_Part_6797_1482858832.1593126775950 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, Sorry I was unable to attend the call last week. > On 06/24/2020 12:16 AM Bron Gondwana wrote: > > > Hi All, > > I've been in contact with the authors of draft-ietf-extra-imap-fetch-preview, and they're not happy with the current state. We ended up with something over-complicated. > > The suggestion from the interim meeting last week was to pare it right back to a very basic thing - just a single fetch item called PREVIEW which is plain text of up to 255 characters or so, server defined, no fancy algorithms, no nothing else. If we want to add something more complex later, we can always do a separate extension for that. > > Value MAY change over time as server algorithms are updated, but it's fine to keep the previous version cached. > > Michael - do you agree with that characterisation? Everyone in the meeting last week was in favour of doing that. Are you happy to update the wording and submit a new draft? > Thanks Bron - you've accurately relayed my thoughts on the current draft (-07). For Dovecot we've now had something like 3 years of experience with some form of this draft. Users of this preview functionality care about 1 thing: what does the output look like? They don't care what that output is - there is no desire to control preview text generation with client-side parameters - just as long as they have a description of the boundaries of what the data will look like. So agreed that we shouldn't make this overly complicated. There is a confirmed need/desire for preview generation for FETCH that has a tightly defined data semantics. If we stick with that narrow scope for now, this is the correct goal. I'll submit a new draft - my guess is it will look VERY similar to -06 minus the extensibility stuff. michael ------=_Part_6797_1482858832.1593126775950 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hi all,

Sorry I was unable to attend the call last week.

On 06/24/2020 12:16 AM Bron Gondwana <brong@fastmailteam.com> wrote:


Hi All,

I've been in contact with the authors of draft-ietf-extra-imap-fetch-preview, and they're not happy with the current state.  We ended up with something over-complicated.

The suggestion from the interim meeting last week was to pare it right back to a very basic thing - just a single fetch item called PREVIEW which is plain text of up to 255 characters or so, server defined, no fancy algorithms, no nothing else.  If we want to add something more complex later, we can always do a separate extension for that.

Value MAY change over time as server algorithms are updated, but it's fine to keep the previous version cached.

Michael - do you agree with that characterisation?  Everyone in the meeting last week was in favour of doing that.  Are you happy to update the wording and submit a new draft?
Thanks Bron - you've accurately relayed my thoughts on the current draft (-07).

For Dovecot we've now had something like 3 years of experience with some form of this draft.  Users of this preview functionality care about 1 thing: what does the output look like?  They don't care what that output is - there is no desire to control preview text generation with client-side parameters - just as long as they have a description of the boundaries of what the data will look like.

So agreed that we shouldn't make this overly complicated.  There is a confirmed need/desire for preview generation for FETCH that has a tightly defined data semantics.  If we stick with that narrow scope for now, this is the correct goal.

I'll submit a new draft - my guess is it will look VERY similar to -06 minus the extensibility stuff.

michael
------=_Part_6797_1482858832.1593126775950--