From nobody Thu Jan 16 20:47: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 23C2D1200D6 for ; Thu, 16 Jan 2020 20:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=PcIP+1yl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QqRkKYo3 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 O0cFAIwxsSao for ; Thu, 16 Jan 2020 20:47:45 -0800 (PST) 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 68F54120099 for ; Thu, 16 Jan 2020 20:47:45 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D4E9D475 for ; Thu, 16 Jan 2020 23:47:44 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Thu, 16 Jan 2020 23:47:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=nRur7Ys cE6X6iQdYkJseF3t7b6RrnlUMoUOpUJnv3Fs=; b=PcIP+1yl6R/prHcfMcRqf0k Y86gglBnoKu6s52IhVq9VECSboNW/fADOXr70PLhdaXT1tUjt8GSQDwxGCSyg1Lh voARUDoG/AxA7PAYeIZOxb+NrgkFui0n8hiMiXmFTcy7ySb1j6bEoFPAuNP35GQM DDISSFiTUgLCkiqMFRgnY7mOfw2qXCHT1u9XjM26rixDaiHwAddPGD0YnDaGn0/4 yvZD2jhy9W6xMRXz09IRm9KUTuM0K+GZoVZOi+IpY9Qd2PNsk3ac2mQQcNhr8O0i 2KCIcbC4NfPduryqtgiUML/K+p4N4aFSx8ionlxNovWaIotO9cf8OZ70X89v4Vw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nRur7Y scE6X6iQdYkJseF3t7b6RrnlUMoUOpUJnv3Fs=; b=QqRkKYo3uWykb9d0CmSl9i zMI62oJqc9vYdEgcew3n6g1LPF2em8eq53H3yi3CLjNjCdjIFtbOkESgBI6t9tYy 6YKvClXv+45miCyDzmDn3ANoPmt9J+kfS5/Oq4AEV9bmkV1OZF4p0YDzaVulhaEW WcNXptyGfuxnqqfRxaCcvkmBa5lOD+TvoXfi5qJ6MIw+UQ37BFwfOpmyiRJKbaux WInvJoacRZDc9foghuLGA+HTwOVL+sSKk9EdxSvPdCfw3tYzVRoFaxi6dqSyDfXl hntsXyVmD42j18XeLMZhTUruclfuHGclRfSxA/F9sXd04DNsAso5eWZUwnuwXgfg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdeigdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4693524009E; Thu, 16 Jan 2020 23:47:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: <95364fbe-5c65-4c7a-9059-e9cfacfeac12@beta.fastmail.com> In-Reply-To: <06d02f09-2565-40be-b131-114a095b2777@dogfood.fastmail.com> References: <06d02f09-2565-40be-b131-114a095b2777@dogfood.fastmail.com> Date: Fri, 17 Jan 2020 15:47:18 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=cd2190a7620c4b4b95072678c134644a Archived-At: Subject: Re: [Extra] Working Group Last Call draft-ietf-extra-imap4rev2-11 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 04:47:47 -0000 --cd2190a7620c4b4b95072678c134644a Content-Type: text/plain Happy Birthday (to my little brother in fact) - it's January 17th, and that means that the WGLC is expiring. I'll put together the shepherding document over the weekend, so you've got another day or so to give your feedback if you have any! Cheers, Bron. On Fri, Dec 20, 2019, at 00:40, Bron Gondwana wrote: > This is the big one! This email starts the working group last call for: > > https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ > > Due to the holiday season as well as the size of this document, I'm giving an extended last call period of 4 weeks, making this last call expire on January 17, 2020. > > Hopefully you've all been following along the multiple discussions and decisions we've made in the working group over the past few years, but we'd definitely all appreciate a thorough read of the document because it's a big spec with lots to cover! > > Have a great next couple of weeks, whatever you celebrate during this time, and I'll see you in the new year. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --cd2190a7620c4b4b95072678c134644a Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Happy Birthday (to my little brother in fact) - it's = January 17th, and that means that the WGLC is expiring.  I'll put t= ogether the shepherding document over the weekend, so you've got another= day or so to give your feedback if you have any!

Cheers,
=
Bron.

On F= ri, Dec 20, 2019, at 00:40, Bron Gondwana wrote:
This is the big = one!  This email starts the working group last call for:
<= div style=3D"font-family:Arial;">

Due to the holiday season as well as the size of this docu= ment, I'm giving an extended last call period of 4 weeks, making this la= st call expire on January 17, 2020.

Hopefully you've all = been following along the multiple discussions and decisions we've made i= n the working group over the past few years, but we'd definitely all app= reciate a thorough read of the document because it's a big spec with lot= s to cover!

Have a great next couple of weeks, whatever y= ou celebrate during this time, and I'll see you in the new year.
Cheers,

<= div style=3D"font-family:Arial;">Bron.

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



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


--cd2190a7620c4b4b95072678c134644a-- From nobody Thu Jan 16 20:51: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 8C31A1200D6 for ; Thu, 16 Jan 2020 20:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=GOD1lbh9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uxD2HRbA 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 gcQslcMMB6tW for ; Thu, 16 Jan 2020 20:51:40 -0800 (PST) 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 2F19C120099 for ; Thu, 16 Jan 2020 20:51:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 8A54048D; Thu, 16 Jan 2020 23:51:39 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Thu, 16 Jan 2020 23:51:39 -0500 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=fm1; bh=WAA5OGer5DeZFf7Y0HR8nDaX/S7PJI1 zeYsW15Jkhds=; b=GOD1lbh9RCu2ZDcXjVj8F2YkYyxucPARSzgTCLC+Pc6cOb6 4AA7uQF+11WWod0j2ExhLimmOMe9NO0/ygbU69VdtbL0kZIp23X4FH274Gj3D2YK wROJ05JRPDgcINpYypbeOzd9xzCLOwCcSpThFa5TZB5Xeu9hKv9ncSo3qTMZMNXt jNULIavMmXPoAFJQ3aVGbhAC+2KIi+bVXeOu2zK34NPzu10SpgxV0c0deHHtgA0v Ws2iB7EE94Eb40jBpbDhf+VWFRZIj/tsnX69uUwOkdaz1CYBLu9Y/rBbI+fPsZ2s 73ApTI9iooQA9RunbwwOPTF6SNjsep48vqgz7ZA== 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=fm1; bh=WAA5OGer5DeZFf7Y0HR8nDaX/S7PJ I1zeYsW15Jkhds=; b=uxD2HRbA2DIe0hIRrwB9SOl09OurQziUhXinJOWQch+Md UdHPUeNn3I7aTubgy0M61i+/05mU2AXirs1OHzKLWKQteUdCCxAqbMJaJcio2sZK gXORBAOb7Q3B7l24UVmp17igZ0Rfz9Rsp/LBs7a3Y4tt3VaBeVGWL0ssViVBaMn0 wDxf2wIJQD28FtEkQ7+d+/j99U+MKHADh22ci7NTvsAEcZHwCDUMOj+8tQPmhhPn SvhYopzeDuhEGr0Q7uENDI6GGzMfpWWt9gd8QM5x73M8VLmzRVCZ1vwT5k+6A1Uc zEQ1MR28RaI9tTI5nzMEJgZAAGV+yaFWtGDTvwXBQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdeigdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhnucfi ohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc frrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BA3B024009E; Thu, 16 Jan 2020 23:51:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: <67511f7a-b273-4b0b-a874-9be5542c5eaa@beta.fastmail.com> Date: Fri, 17 Jan 2020 15:51:18 +1100 From: "Bron Gondwana" To: "Stephan Bosch" Cc: extra@ietf.org Content-Type: multipart/alternative; boundary=2e74aff9632c4866b7e4357ac492bf0c Archived-At: Subject: [Extra] EAI Sieve X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 04:51:42 -0000 --2e74aff9632c4866b7e4357ac492bf0c Content-Type: text/plain Hi Stephan, According to the minutes from the EXTRA session in Singapore, you have been volunteered to write a Sieve EAI spec. Can you please upload it if you have one, or write one, or let us know not to expect it if you've changed your mind. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --2e74aff9632c4866b7e4357ac492bf0c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Stephan,
According to the minutes from t= he EXTRA session in Singapore, you have been volunteered to write a Siev= e EAI spec.  Can you please upload it if you have one, or write one= , or let us know not to expect it if you've changed your mind.
=

Thanks,

Bron.

--
<= /div>
  Bron Gondwana, CEO, Fastmail Pty Lt= d
  brong@fastmailteam.com


--2e74aff9632c4866b7e4357ac492bf0c-- From nobody Fri Jan 17 06:56:19 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 EBD49120077 for ; Fri, 17 Jan 2020 06:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfQ-hdN5xYOB for ; Fri, 17 Jan 2020 06:56:10 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CC4120074 for ; Fri, 17 Jan 2020 06:56:10 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 377DFC0074; Fri, 17 Jan 2020 15:00:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1579273225; bh=2BqufpiBVr8Yr1sHizA3cxOUFJVM8kTXmMojq39vQUU=; h=From:To:Subject:Date:From; b=VsXh+4RfedRB0sXQUZxtD3KXrc811DGeRk4Sy9j7ghRSg9IxONsfnpG+HFsaTqzdt Yf36xxoUIDT7e7xshD7K5GVlhNRERkSSG4vA9JX2brMG8is+/miag7LUbwSYkC9m6s eF0l1mbBHKElMG8CuWvGH6qwlKLyCkWx11lfwULA= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1579273224-27478-27476/9/59; Fri, 17 Jan 2020 15:00:24 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Fri, 17 Jan 2020 15:56:06 +0100 Mime-Version: 1.0 Message-Id: <9d918580-70be-4e9b-90ef-372523afe359@gulbrandsen.priv.no> 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 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Extra] IMAP4rev2 body search X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 14:56:18 -0000 Hi, a discussion the other day^Wweek jars in my mind. I think we should underspecify the BODY search key more clearly. All it = now=20 says is "matches if contains", which is IMO correct (it matches the = running=20 code) but underspecified and vague. I think we ought to eliminate the=20 vagueness, and propose the following explicit underspecification: =2D-- Messages that contain the specified string in the body of the message. The server SHOULD decdode the content-transfer-encoding, so that a = message=20 matches independent of its content-transfer-encoding. Apart from that = rule,=20 this specification explicitly allows much server behaviour that has been=20 common in IMAP4rev1 servers, including: Most servers interpret "contains" on a character level, ie. "BODY range"=20 matches a message that contains the word "orange", but some servers=20 interpret it on a token or word level, ie. "BODY range" does not match a=20 message that contains "orange", because "orange" is one token. It may=20 however match a message that contains "ranges", if the server uses = stemming=20 (and perhaps language detection). Some servers search only in text/plain. Others also search in other = types,=20 for example Microsoft Word and PDF attachments. Some servers search HTML on a source level ("BODY range" does not match=20 ra­nge), others search HTML as normally displayed ("BODY range" = matches=20 ra­nge). Most servers interpret the messages and search terms independent of=20 encoding, such that a message that uses charset=3Diso-8859-8 may match a=20 search term that uses UTF-8. However, not even this is required. Rationale: IMAP4rev1 servers vary in the kind and quality of their = search=20 implementation. This document chooses to avoid adding requirements on = the=20 business logic in such servers. =2D-- (I'm open to changing any of this. IMO any variant is good, and good is=20 better than best. I'd prefer that quarrelsome people can't beat each = other=20 over the head with the RFC, that's all.) Arnt From nobody Wed Jan 22 11:01: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 3F139120802 for ; Wed, 22 Jan 2020 11:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 AlYtsVnp7YZP for ; Wed, 22 Jan 2020 11:01:30 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 6CC1D120804 for ; Wed, 22 Jan 2020 11:01:30 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id j26so188000ljc.12 for ; Wed, 22 Jan 2020 11:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RV/dipOV1vLn7INKmrh+FpZUm8ldIhHpAqZaZZKELeo=; b=XBElU+AbiOHdMdgscjlDm0/+4I5/1GjVP4zBFgvQsNYjIQKmpeMTccunZKI04WN0Ke ZQ3IsyIQsGpOSR1toibjuYMUmG3D8SXMRD4aoauDbJOAuGaLH/ZejcWX6zzw+qQc7vEj 6PyHfjCqSqNhFf5oahOqbVgZizs/8gVt8qFpEl1HU6X+uvrzOXJCTy5wQSajrRtqUQXi Udejq9dWgcleZdVW7S2c9HWk6/VPUtBybsxaMUqD8hECP60Eusuqizx2jawbfz2lEoU2 LVA+IqREVZYnocK8Hs4rD8ovJrf3QoovwPbIUpAXGBZi4tMoyfReYDWgmpjlhB6fmB0B /sDg== 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=RV/dipOV1vLn7INKmrh+FpZUm8ldIhHpAqZaZZKELeo=; b=F51d45LGu6enH504z/eEMeqXcMEJh0KBbfe4a7fwpC9vD6SoblPKBciaurr3AcVUN8 2nSz/kc1UOZFGjZfIR+1W4vL2l7C0oNSjsmQllO7aDzabk+scU5wU78Slt5sYQu9qTG2 wnEion/LV1jTxglVyNvjbWVuzV0xU0Ph9ed4tCaTwAzHvrQItc1k5MHBTJSQ8XAomLIP SdwWkrJPvTga4qDrLjXRPI5o7pZ1mQnvxHVUvZSQcSlHUxCO1DtmmwVmlA8V+3R9+tTW TrGru3bKOluuMz6mbULg89Wm+Vk1rDqQUjzarnRuOPzNVVIoQS9Khno4dQiUe6brFjBv vylg== X-Gm-Message-State: APjAAAW8y57E6UILz9put6gX0XAFih+/TY7paQEN5XJDV0+6LYNGJBGo ceXlUnkle+um577T1IBF0odRtwNUg0dt2jvYvyghkEk= X-Google-Smtp-Source: APXvYqyLSkkuxtb45d4wHQJvFfNe1RJdnaKcBEAwtRj0Scwldc+vBg9mznJBkXocsIMDqZkkeMHEXtSSwgLumtxs60c= X-Received: by 2002:a05:651c:327:: with SMTP id b7mr6698186ljp.22.1579719688331; Wed, 22 Jan 2020 11:01:28 -0800 (PST) MIME-Version: 1.0 References: <9d918580-70be-4e9b-90ef-372523afe359@gulbrandsen.priv.no> In-Reply-To: <9d918580-70be-4e9b-90ef-372523afe359@gulbrandsen.priv.no> From: Brandon Long Date: Wed, 22 Jan 2020 11:01:14 -0800 Message-ID: To: Arnt Gulbrandsen Cc: extra@ietf.org Content-Type: multipart/alternative; boundary="000000000000de869f059cbf26c8" Archived-At: Subject: Re: [Extra] IMAP4rev2 body search 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, 22 Jan 2020 19:01:32 -0000 --000000000000de869f059cbf26c8 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 17, 2020 at 6:56 AM Arnt Gulbrandsen wrote: > Hi, > > a discussion the other day^Wweek jars in my mind. > > I think we should underspecify the BODY search key more clearly. All it > now > says is "matches if contains", which is IMO correct (it matches the > running > code) but underspecified and vague. I think we ought to eliminate the > vagueness, and propose the following explicit underspecification: > > --- > > Messages that contain the specified string in the body of the message. > > The server SHOULD decdode the content-transfer-encoding, so that a message > matches independent of its content-transfer-encoding. Apart from that > rule, > this specification explicitly allows much server behaviour that has been > common in IMAP4rev1 servers, including: > > Most servers interpret "contains" on a character level, ie. "BODY range" > matches a message that contains the word "orange", but some servers > interpret it on a token or word level, ie. "BODY range" does not match a > message that contains "orange", because "orange" is one token. It may > however match a message that contains "ranges", if the server uses > stemming > (and perhaps language detection). > > Some servers search only in text/plain. Others also search in other types, > for example Microsoft Word and PDF attachments. > > Some servers search HTML on a source level ("BODY range" does not match > ra­nge), others search HTML as normally displayed ("BODY range" > matches > ra­nge). > > Most servers interpret the messages and search terms independent of > encoding, such that a message that uses charset=iso-8859-8 may match a > search term that uses UTF-8. However, not even this is required. > > Rationale: IMAP4rev1 servers vary in the kind and quality of their search > implementation. This document chooses to avoid adding requirements on the > business logic in such servers. > > --- > > (I'm open to changing any of this. IMO any variant is good, and good is > better than best. I'd prefer that quarrelsome people can't beat each other > over the head with the RFC, that's all.) > This seems overly wordy, almost more like a bcp or something instead of the spec itself. I'm not opposed to it, but I wouldn't call myself an expert on the fine craft of spec writing either. Can we give intent itself? Ie, that there's several ways to implement search (substring, word based) and to interpret body (raw text, extracted from formatting, or even ocr) Brandon Brandon --000000000000de869f059cbf26c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 17, 2020 at 6:56 AM Arnt = Gulbrandsen <arnt@gulbrandse= n.priv.no> wrote:
Hi,

a discussion the other day^Wweek jars in my mind.

I think we should underspecify the BODY search key more clearly. All it now=
says is "matches if contains", which is IMO correct (it matches t= he running
code) but underspecified and vague. I think we ought to eliminate the
vagueness, and propose the following explicit underspecification:

---

Messages that contain the specified string in the body of the message.

The server SHOULD decdode the content-transfer-encoding, so that a message =
matches independent of its content-transfer-encoding. Apart from that rule,=
this specification explicitly allows much server behaviour that has been common in IMAP4rev1 servers, including:

Most servers interpret "contains" on a character level, ie. "= ;BODY range"
matches a message that contains the word "orange", but some serve= rs
interpret it on a token or word level, ie. "BODY range" does not = match a
message that contains "orange", because "orange" is one= token. It may
however match a message that contains "ranges", if the server use= s stemming
(and perhaps language detection).

Some servers search only in text/plain. Others also search in other types, =
for example Microsoft Word and PDF attachments.

Some servers search HTML on a source level ("BODY range" does not= match
ra&shy;nge), others search HTML as normally displayed ("BODY range= " matches
ra&shy;nge).

Most servers interpret the messages and search terms independent of
encoding, such that a message that uses charset=3Diso-8859-8 may match a search term that uses UTF-8. However, not even this is required.

Rationale: IMAP4rev1 servers vary in the kind and quality of their search <= br> implementation. This document chooses to avoid adding requirements on the <= br> business logic in such servers.

---

(I'm open to changing any of this. IMO any variant is good, and good is=
better than best. I'd prefer that quarrelsome people can't beat eac= h other
over the head with the RFC, that's all.)

This seems overly wordy, almost more like a bcp or something instead = of the spec itself.

I'm not opposed to it, but= I wouldn't call myself an expert on the fine craft of spec writing eit= her.

Can we give intent itself?=C2=A0 Ie, that the= re's several ways to implement search (substring, word based)
and to interpret body (raw text, extracted from formatting, or even ocr)

Brandon

Brandon=C2=A0
--000000000000de869f059cbf26c8-- From nobody Wed Jan 22 19:38:50 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 D9566120108; Wed, 22 Jan 2020 19:38:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: extra@ietf.org, brong@fastmailteam.com, barryleiba@computer.org, extra-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157975072888.12262.9217490871445837849.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2020 19:38:48 -0800 Archived-At: Subject: [Extra] extra - Not having a session at IETF 107 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: Thu, 23 Jan 2020 03:38:49 -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 107. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Jan 23 09:41:54 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 4F7EB1200FE for ; Thu, 23 Jan 2020 09:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwlhFo5ml5hn for ; Thu, 23 Jan 2020 09:41:51 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018A612011B for ; Thu, 23 Jan 2020 09:41:51 -0800 (PST) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 04952C001B; Thu, 23 Jan 2020 17:46:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1579801569; bh=8GbQjC6xwVhTFxJ7+YPOc00HQ9D02ezLMuuhhaLmcc8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cDlH3X5HyW5XqlbJgPRaTnDr+Fca17Y8/pJN2+ZGLIH4JbnfTmb1z3DUbXMyR61lB RE1NlZCbR3OQeS/gnxor8046pfj0rGvr+5MXDkqpnGuiSXUvAIi5dXG0fEG10h2HYI 7iTl99lkBNAzuc3ejrfVhFy/Ph3KDpRe8/4nPAOY= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1579801568-27478-27476/9/66; Thu, 23 Jan 2020 17:46:08 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Thu, 23 Jan 2020 18:41:48 +0100 Mime-Version: 1.0 Message-Id: <151d3e0b-e649-4e80-8a36-411afcf44d6c@gulbrandsen.priv.no> In-Reply-To: References: <9d918580-70be-4e9b-90ef-372523afe359@gulbrandsen.priv.no> User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.1 (ascii) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] IMAP4rev2 body search 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, 23 Jan 2020 17:41:52 -0000 I think the key question is: Underspecifed and vague about it, or underspecified and defiant about it. God knows that what I suggested isn't well-written. It's a first draft, written in one go while I was waiting impatiently for a slow, slow program to finish. First drafts are too wordy 99% of the time and the circumstances weren't favourable either. But that doesn't matter. Any good text should IMO have the traits a) explicit about what it doesn't standardise and b) explicit that we want existing servers to remain compliant, warts and all. The key question is whether you all agree with me about a+b. If you do agree with me I can refine the prose. Or Alexey does. Arnt From nobody Thu Jan 23 14:37: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 9E6AE12001B for ; Thu, 23 Jan 2020 14:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 q_YJsTwTAGzx for ; Thu, 23 Jan 2020 14:37:09 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 3B6EB120047 for ; Thu, 23 Jan 2020 14:37:09 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id i4so91636vkc.3 for ; Thu, 23 Jan 2020 14:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2m5uLPVCiFHLFjHDmsm+0j5Tc3KgPLSaScvpfq5+SWw=; b=sIa2cF1Zrhde7GmjXJPopVuaRlSBT2dez0HCRYkmDugatCPiFMnO34SzQGuauSbP3H RG7lvAJwiGkPAZoJl7Omh2Z3SbNuo4aIBVabhcrOy11QwthikfKZ2Mq5gb4zkM0jsGXA TjLjiEGighgTLhYDvahYiDS0c0AsMPWm8gt7vnH/DrQHlNjHchptozorviGtHsGfUfaq hU5jcZk0KgS8r78Ck/Lag7qoedhkLdMhZeRM50qGHD+MCeiIAgQYbBlyHaEuJnKl5PKo NyD+8scIyg+TSRKpvLl/Hk5T7ruX6GpbybDMFTMmvHMkJayVbZ5L3PjjHgXuY3ggAeZD F80w== 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=2m5uLPVCiFHLFjHDmsm+0j5Tc3KgPLSaScvpfq5+SWw=; b=ZNn0x2ey8rnzvGDHwCMpcq3Z8wPpmoohrFDKopyhb2AlPds6ywvC4VyiLN/9XEY14E lyvnpH4dXfGk+NsHwULZrBz0PQXn2OA70XCKcH3GoBBc5iKGFi5jNk94QVOVDOaMIUlS dlnVjFnnk2VgBiHCs/5b150IlJvfjcyDcM4MopWSiM72WKk9gP4qqVmq2gj6qVSQjW2F GuOdFze8Ex47NJOqb8iia/xplTjFXQwcVd/uf5nx3KobYu5pov46oePhioOSLBa+R3hR GMqj2GiTzZXRILzFP8NNY6QKolV/Ajj1fHgu7d/Q2668s/g8PtbYZ1TNYb9e0bLf7tWJ 6irA== X-Gm-Message-State: APjAAAWNM2iwDMCuEoZApf1/K1dNKKHt3SrUOf9u4391bNiN7KLaH/gR fxCVqk3GW5ZoWHCwy1VQ4UOwoKRpQ4QtvuM9DLchgWE= X-Google-Smtp-Source: APXvYqynI8KUy9/zX/r1ki9+QmvoWiQcTyhKJsojmCiSuhb1y/yqHKk0F3pZ+UhE+CuTqaWSCAAtdIcDOgkazucTrxI= X-Received: by 2002:a1f:9b0f:: with SMTP id d15mr251880vke.47.1579819027746; Thu, 23 Jan 2020 14:37:07 -0800 (PST) MIME-Version: 1.0 References: <9d918580-70be-4e9b-90ef-372523afe359@gulbrandsen.priv.no> <151d3e0b-e649-4e80-8a36-411afcf44d6c@gulbrandsen.priv.no> In-Reply-To: <151d3e0b-e649-4e80-8a36-411afcf44d6c@gulbrandsen.priv.no> From: Brandon Long Date: Thu, 23 Jan 2020 14:36:56 -0800 Message-ID: To: Arnt Gulbrandsen Cc: extra@ietf.org Content-Type: multipart/alternative; boundary="000000000000f6038f059cd647a6" Archived-At: Subject: Re: [Extra] IMAP4rev2 body search 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, 23 Jan 2020 22:37:12 -0000 --000000000000f6038f059cd647a6 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 23, 2020 at 9:41 AM Arnt Gulbrandsen wrote: > I think the key question is: Underspecifed and vague about it, or > underspecified and defiant about it. > > God knows that what I suggested isn't well-written. It's a first draft, > written in one go while I was waiting impatiently for a slow, slow program > to finish. First drafts are too wordy 99% of the time and the > circumstances > weren't favourable either. But that doesn't matter. Any good text should > IMO have the traits a) explicit about what it doesn't standardise and b) > explicit that we want existing servers to remain compliant, warts and all. > > The key question is whether you all agree with me about a+b. If you do > agree with me I can refine the prose. Or Alexey does. > as an author of one of the servers which definitely took liberties, I do agree with a+b Brandon --000000000000f6038f059cd647a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 23, 2020 at 9:41 AM Arnt Gulbrandsen = <arnt@gulbrandsen.priv.no> wrote:
I t= hink the key question is: Underspecifed and vague about it, or
underspecified and defiant about it.

God knows that what I suggested isn't well-written. It's a first dr= aft,
written in one go while I was waiting impatiently for a slow, slow program =
to finish. First drafts are too wordy 99% of the time and the circumstances=
weren't favourable either. But that doesn't matter. Any good text s= hould
IMO have the traits a) explicit about what it doesn't standardise and b= )
explicit that we want existing servers to remain compliant, warts and all.<= br>
The key question is whether you all agree with me about a+b. If you do
agree with me I can refine the prose. Or Alexey does.

--000000000000f6038f059cd647a6-- From nobody Wed Jan 29 04:09:14 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 232CB120113 for ; Wed, 29 Jan 2020 04:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=bpoptMAt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QOJJmf/z 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 9XtW2scNTEZS for ; Wed, 29 Jan 2020 04:09:09 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCBA1200F5 for ; Wed, 29 Jan 2020 04:09:09 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 511396DF; Wed, 29 Jan 2020 07:09:08 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute2.internal (MEProxy); Wed, 29 Jan 2020 07:09:08 -0500 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=fm1; bh=L0AtBic0iw2aK0WDAHr8yAcHZzBTFpR 40bZ6P8jEoV8=; b=bpoptMAtGmnK43lnJpdJcup6FlJmzyBt5AI0TMKHnMDMeMm FGao3bF3zdoHGj91GeVnUqkwXXE1e4QvbHTkLhSfuKuAP69Hr6BsaJyqYF6y9n3x 1DT93mvAdlugPRwYeUnGVn3v4q3bCFl3MsYtcseBstHLoXn1IimlPbHy2lBw0w1J oXhwW88t7TkX3rLXkYXpMeQvYdqKsenhlI5Go78yUNVeWzK4JC7GVNKIdxibbVVk PXyOZoltr/ZPGsJSzXt6qjydhY9GX0ZHX/91HrxcMdZSRVPaSJTZIukQzjcL4bOf Jkevsqou/7lU0SBYpnE6RVHylE/LPXEI+sE2xlA== 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=fm1; bh=L0AtBic0iw2aK0WDAHr8yAcHZzBTF pR40bZ6P8jEoV8=; b=QOJJmf/z8+4jGhPHNFagMhQxtElhxJIslOU6wGolKChQK 3yxNUjKyindU4AfvItRj2amw+Phlh3AK6SoGOGDoJ4eaIWxCK77uHoqVAn2mfxYn vtGmtBLSf/7HDc8Y7PzWezljJ/2PNuRjtKg3lMx5r94ifaEMfa394Gwf7NHQnjbt x7GlA0vMXP1xb5+ChQHwYE7ycsAPuGXqjNd3Gg3SPbS9XHNtehvqq/2Qj5OGp44L ovTFXU3hhJVSxJ60KuEkJ0dlXxXIVeW4YVliB4DEhslYBT5XPHgJw/iqOqNX3HCs elB+8KBcbkLt90c/qCOPG8xXJW9OnyT5MKUWhlkZQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeeigdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhnucfi ohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ffohhmrghinhepihgrnhgrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 885F924009E; Wed, 29 Jan 2020 07:09:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-850-ga703523-fmnext-20200128v1 Mime-Version: 1.0 Message-Id: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> Date: Wed, 29 Jan 2020 23:08:55 +1100 From: "Bron Gondwana" To: extra@ietf.org Cc: "Barry Leiba" , "Alexey Melnikov" Content-Type: multipart/alternative; boundary=fbdff0f53f704b33ac63771ed8444276 Archived-At: Subject: [Extra] Review: draft-ietf-extra-imap4rev2-11 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, 29 Jan 2020 12:09:13 -0000 --fbdff0f53f704b33ac63771ed8444276 Content-Type: text/plain Sorry about the delay in doing this! I was supposed to be doing the shepherding write-up, and so I figured I should read it properly. I've had a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments. It's long, and hopefully comprehensive - though I'm sure I missed things. *2.1 Link level * Is it appropriate to mention TLS on 993 here? It's mentioned deep within the document, but not here. *2.2.1 Client protocol* * * *"A different tag is generated by the client for each command".* There's no "MUST" on this, and certainly I've seen clients which don't. Do we want to make that more strict in rev2? It would be a bit of a pain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness. Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned") *2.3.1.1 UID Attribute * * * *"The next unique identifier value MUST NOT change unless new messages are added to the mailbox". * I would very much like that first MUST NOT to be weakened to "SHOULD NOT". My reasoning is that you could have a virtual mailbox which used a global sequence number per message. It would behave to clients as if a message had been delivered and then immediately expunged. I'm pretty sure clients don't care - they'll fetch the range, discover that nothing new has appeared, and stay happy. The second MUST is obviously correct, that the UIDNEXT must increase when messages are delivered. Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly (as seen later in the ABNF) they aren't allowed to be zero. It would be good to say "non-zero" when each is first mentioned, but I don't care strongly about this one. *2.3.2 Flags Message Attribute * formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format. Should this section also reference https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml ? *5.1 Mailbox Naming * This doesn't solve one of my naming bugbears. The spec says things like *"servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." -*** **there is no clear way to know what the SELECTable name will be after creating a mailbox. If I was designing this myself from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect. Since we're messing with how mailbox naming works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop. It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :( *6.3.1 ENABLE command * The example shows a conversation with an imap4rev1 only server. The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence: C1 ENABLE CONDSTORE * ENABLED CONDSTORE C1 OK foo C2 ENABLE CONDSTORE QRESYNC * ENABLED QRESYNC C2 OK foo The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection. (AKA: clients MUST remember what they have enabled) *6.3.2 SELECT command * The [UIDNEXT ] response is duplicated with two different pieces of text. *When deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox is closed (see Paragraph 10). *- I'm not sure where "Paragraph 10" is. The last paragraph of this section has the word "deprecated" spelled as "depractated". I also saw somewhere that the server can unilaterally send a "* [CLOSED]" response at any point if it's had to close the mailbox (e.g. it got deleted, or IO errors). I'm not sure if that requires opt-in to IMAP4REV2, since otherwise clients will not be aware to watch for it. This may need to be clarified. Current behaviour of our server right now is to drop the connection entirely, which is ugly - but it's rare and all clients already need to handle it cleanly, so it guarantees no messed up data model for the clients. *6.3.4 and 6.3.5 CREATE and DELETE * Can we make it illegal to "DELETE" a mailbox with children rather than make it a \NoSelect mailbox pretty pretty please? I'm just looking at some patches to deal with Outlook misbehaving with this precise situation, and it's all horrible. Because of mailboxId requirements for JMAP we've been forced to keep these things around as "intermediate" mailboxes anyway, and it's been the source of tons of bugs. *6.3.6 RENAME * I thought we had agreed to strongly recommend against clients using RENAME INBOX Other, but maybe I've forgotten. I don't see it in the minutes, so maybe it's just my wishful thinking. We definitely have an option in Cyrus IMAP to make subscriptions follow RENAME. It's one of the warts (largely due to Thunderbird showing greyed out folders and confusing people). *6.3.7 SUBSCRIBE * Speak of the devil. Lots of sites violate the MUST NOT unilaterally remove rule. Should we weaken it to SHOULD? The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want. (also: by enabling a non-default break the rules config, it's what our server does!) *6.3.8 UNSUBSCRIBE* *This command returns a tagged OK response only if the unsubscription is successful. *- this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error? For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good". . create INBOX.foo . OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed . subscribe INBOX.foo . OK Completed . unsubscribe INBOX.foo . OK Completed . unsubscribe INBOX.foo . OK Completed . subscribe INBOX.foo . OK Completed . subscribe INBOX.foo . OK Completed *6.3.9 LIST * There's a weird line wrapping near the top of page 44 where a paragraph is split in half: The reference and mailbox name arguments are interpreted into a canonical form that represents an unambiguous left-to-right hierarchy. The returned mailbox names will be in the interpreted form, that we call "canonical LIST pattern" later in this document. To define the term "canonical LIST pattern" formally: it refers to the canonical pattern constructed internally by the server from the reference and mailbox name arguments. *6.3.9.2 LIST Return Options * The CHILDREN item is duplicated with two different pieces of text. *6.3.9.7 LIST EXAMPLES * We've kinda half-added SPECIAL-USE, but we don't reference it, and it isn't shown in these examples. *6.3.10 NAMESPACE * We've created a conflict here. The NAMESPACE command contains prefix strings for the individual namespaces, and says: The prefix string allows a client to do things such as automatically creating personal mailboxes or LISTing all available mailboxes within a namespace. Which contradicts the advice we gave back in the LIST command not to use prefix. Perhaps we should change the LIST advice to be "only use the empty prefix or prefixes given in the NAMESPACE response"? *6.3.11 STATUS * Note: The STATUS command is intended to access the status of mailboxes other than the currently selected mailbox. Because the STATUS command can cause the mailbox to be opened internally, and because this information is available by other means on the selected mailbox, the STATUS command SHOULD NOT be used on the currently selected mailbox. This advice is all well and good, but it says nothing about what the server may or may not do when it gets one of these STATUS commands. This is particularly relevant in the context of LIST RETURN STATUS, where it's hard to construct list patterns which explicitly avoid the currently selected mailbox. Likewise with the: *MUST NOT be used as a "check for new messages in the selected mailbox" *assertion. Plenty of clients will do a STATUS run across folders and if they're doing LIST RETURN STATUS they're gonna find out about the new messages if the server returns it. Clients can not rely on it working is a more honest representation of what happens. I'd like to see that IMAP4REV2 servers MUST implement STATUS of the currently selected mailbox. Yes, it's a special codepath - but if you're already testing if it's the currently open mailbox then you're at exactly the right place to do the right thing: /* use the index status if we can so we get the 'alive' Recent count */ if (!strcmpsafe(mbentry->name, index_mboxname(imapd_index)) && imapd_index->mailbox) return index_status(imapd_index, sd); /* fall back to generic lookup */ return status_lookup_mbentry(mbentry, imapd_userid, statusitems, sd); *6.4.4 SEARCH * For example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all deleted messages from Smith that were placed in the mailbox since February 1, 1994. That's not strictly true - SAVEDATE would be "placed in the mailbox". The wording should say "with INTERNALDATE greater than February 1, 1994" or so. *6.4.4.1 SAVE Result * I'm not sure I understand the interaction here with closing and re-opening a mailbox. I would expect that closing a mailbox would wipe the SAVED result, and that trying to use a SAVED result when there isn't one should return an error. Speaking of which, Example 5 is wrong: It says that the second search command leads to the variable containing no messages, but the second search command did not contain the RETURN SAVE option, so it should not have altered the variable. *7.1 Status Responses * Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points! *7.2.3 LIST Response * This is the interesting bit for SPECIAL-USE - it should reference that here - as well as referencing the registry since it reproduces some of it inline. https://www.iana.org/assignments/imap-mailbox-name-attributes/imap-mailbox-name-attributes.xhtml *7.4.2 FETCH Response * I remember past bugs with UID in "unsolicited" FLAGS responses. Do we need to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)? *Appendix C: Changes * Right now it's still stated as "the planned changes" and there's still some TODO in there (some of which I think could be well handled by referencing the registries rather than replicating them inline). -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --fbdff0f53f704b33ac63771ed8444276 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Sorry about the delay in doing this!   I was sup= posed to be doing the shepherding write-up, and so I figured I should re= ad it properly.

I've had a full read through over some v= ery many days (I admit, I skimmed through the ABNF) and I have comments.=   It's long, and hopefully comprehensive - though I'm sure I missed= things.



<= div style=3D"font-family:Arial;">Is it appropriate to mention TLS on 993= here?  It's mentioned deep within the document, but not here.
<= /div>

2.2.1 Client protocol

"A diff= erent tag is generated by the client for each command".  There'= s no "MUST" on this, and certainly I've seen clients which don't.  = Do we want to make that more strict in rev2?  It would be a bit of = a pain on the commandline where I normally use ".", but it's also annoyi= ng as a server author that you can't rely on tag uniqueness.



<= /div>
"The next unique identifier va= lue MUST NOT change unless new messages are added to the mailbox". = I would very much like that first MUST NOT to be weakened to "SHOUL= D NOT".  My reasoning is that you could have a virtual mailbox whic= h used a global sequence number per message.  It would behave to cl= ients as if a message had been delivered and then immediately expunged.&= nbsp; I'm pretty sure clients don't care - they'll fetch the range, disc= over that nothing new has appeared, and stay happy.  The second MUS= T is obviously correct, that the UIDNEXT must increase when messages are= delivered.

Both UID and UIDVALIDITY say "unsigned 32-bit= value" - but strictly (as seen later in the ABNF) they aren't allowed t= o be zero.  It would be good to say "non-zero" when each is first m= entioned, but I don't care strongly about this one.

2.3.= 2 Flags Message Attribute

formatting issue: $Forwarde= d is duplicated 3 times and $MDNSent is duplicated twice in the plain-te= xt format.


5.1 Mailbox Naming

This doesn't solve one of my naming bugbears.  The spec says thing= s like "servers MAY accept a de-normalized UTF-8 mailbox name and con= ver it to Net-Unicode prior to mailbox creation." - th= ere is no clear way to know what the SELECTable name will be after creat= ing a mailbox.

If I was designing this myself from scratc= h I would say that "SELECT of the same octets that were passed to CREATE= MUST open that same mailbox" or something to that effect.  Since w= e're messing with how mailbox naming works somewhat for imap4rev2, I'd b= e keen to add this restriction on server behaviour so that clients don't= fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" = loop.

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

6.3.1 ENABLE command

The example= shows a conversation with an imap4rev1 only server.

The = examples don't clearly show that only the newly enabled responses are co= rrect, e.g. the sequence:
C1 ENABLE CONDSTORE
* ENABLED CONDSTORE
C1 OK foo
C2 ENABLE CONDSTORE QRESYNC
* ENABLED QRESYNC
C2 OK foo<= br>

The second doesn't say "ENABLED CONDSTORE" because i= t was already enabled earlier on this connection.

(AKA: c= lients MUST remember what they have enabled)

6.3.= 2 SELECT command

The [UIDNEXT <n>] response is = duplicated with two different pieces of text.

When des= electing a selected mailbox, the server MUST return an untagged OK respo= nse with the "[CLOSED]" response code when the currently selected mailbo= x is closed (see Paragraph 10). - I'm not sure where "Paragraph 10" = is.

The last paragraph of this section has the word "depr= ecated" spelled as "depractated".

I also saw somewhere th= at the server can unilaterally send a "* [CLOSED]" response at any point= if it's had to close the mailbox (e.g. it got deleted, or IO errors).&n= bsp; I'm not sure if that requires opt-in to IMAP4REV2, since otherwise = clients will not be aware to watch for it.  This may need to be cla= rified.  Current behaviour of our server right now is to drop the c= onnection entirely, which is ugly - but it's rare and all clients alread= y need to handle it cleanly, so it guarantees no messed up data model fo= r the clients.

6.3.4 and 6.3.5 CREATE and DELETE

Can we make it illegal to "DELETE" a mailbox with children= rather than make it a \NoSelect mailbox pretty pretty please?  I'm= just looking at some patches to deal with Outlook misbehaving with this= precise situation, and it's all horrible.  Because of mailboxId re= quirements for JMAP we've been forced to keep these things around as "in= termediate" mailboxes anyway, and it's been the source of tons of bugs.<= br>

6.3.6 RENAME

I thought we had agre= ed to strongly recommend against clients using RENAME INBOX Other, but m= aybe I've forgotten.  I don't see it in the minutes, so maybe it's = just my wishful thinking.
We definitely have an option in= Cyrus IMAP to make subscriptions follow RENAME.  It's one of the w= arts (largely due to Thunderbird showing greyed out folders and confusin= g people).

6.3.7 SUBSCRIBE

Speak of= the devil.  Lots of sites violate the MUST NOT unilaterally remove= rule.  Should we weaken it to SHOULD?  The justification for = the MUST is "the server site might choose to do X" - well, if the server= site is doing that, then maybe they SHOULDN'T unilaterally remove the s= ubscriptions, but otherwise it's a better user experience and what peopl= e want.

(also: by enabling a non-default break the rules co= nfig, it's what our server does!)

6.3.8 UNSUBSCRIBE

This command returns a tagged OK response only if the unsubscription is successful. - this is not clear on = what happens if the mailbox is not currently subscribed - does it silent= ly succeed, or is there an expected error?

For what it's = worth, our server just says "OK Completed" even if it's already been uns= ubscrbed - and likewise for subscribe if it's already subscribed it just= say "yep, all good".

. create INBOX.foo
. OK [MAILBOXID (7eca8f55-e233-4458-9d48-af85= 4fb4b279)] Completed
. subscr= ibe INBOX.foo
. OK Completed<= br>
. unsubscribe INBOX.foo
. OK Completed
. unsubscribe INBOX.foo
. OK Completed
. subscribe INBOX.foo
. = OK Completed
. subscribe INBO= X.foo
. OK Completed


6.3.9 LIST
=

There's a weird line wrapping near the top of page 44 where = a paragraph is split in half:

   The reference and mailbox name arguments are interpre=
ted into a
   canonical form that represents an unambiguous left-to-right
   hierarchy.  The returned mailbox names will be in the interpreted
   form,

   that we call "canonical LIST pattern" later in this document.  To
   define the term "canonical LIST pattern" formally: it refers to the
   canonical pattern constructed internally by the server from the
   reference and mailbox name arguments.

6.3.9.2 LIST = Return Options

=
The CHILDREN item is duplicated with t= wo different pieces of text.
=
6.3.9.7 LIST EXAMPLES
=

We've kinda half-added SPECIAL-USE, but we don't referen= ce it, and it isn't shown in these examples.

6.3.10 NA= MESPACE

We've created a conflict here.  The NAME= SPACE command contains prefix strings for the individual namespaces, and= says:

   The =
prefix string allows a client to do things such as automatically
   creating personal mailboxes or LISTing all available mailboxes within=

   a namespace.

Which contradicts the advice we gave back= in the LIST command not to use prefix.  Perhaps we should change t= he LIST advice to be "only use the empty prefix or prefixes given in the= NAMESPACE response"?

6.3.11 STATUS

      Note: The STATUS comma=
nd is intended to access the status of
      mailboxes other than the currently selected mailbox.  Because the
      STATUS command can cause the mailbox to be opened internally, and
      because this information is available by other means on the
      selected mailbox, the STATUS command SHOULD NOT be used on the
      currently selected mailbox.

This advice is all well= and good, but it says nothing about what the server may or may not do w= hen it gets one of these STATUS commands.  This is particularly rel= evant in the context of LIST RETURN STATUS, where it's hard to construct= list patterns which explicitly avoid the currently selected mailbox.

Likewise with the: MUST NOT be used as a "check for new = messages in the selected mailbox" assertion.  Plenty of clients= will do a STATUS run across folders and if they're doing LIST RETURN ST= ATUS they're gonna find out about the new messages if the server returns= it.  Clients can not rely on it working is a more honest represent= ation of what happens.

I'd like to see that IMAP4REV2 ser= vers MUST implement STATUS of the currently selected mailbox.  Yes,= it's a special codepath - but if you're already testing if it's the cur= rently open mailbox then you're at exactly the right place to do the rig= ht thing:

    /* use the index= status if we can so we get the 'alive' Recent count */
=
    if (!st= rcmpsafe(mbentry->name, index_mboxname(imapd_index)) && imapd= _index->mailbox)
        return index_status= (imapd_index, sd);

&n= bsp;   /* fall back to generic lookup */
    return statu= s_lookup_mbentry(mbentry, imapd_userid, statusitems, sd);

6.4.4 SEARCH
<= br>
   For example,
   the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
   deleted messages from Smith that were placed in the mailbox since
   February 1, 1994.

That's not strictly true - SAVEDATE = would be "placed in the mailbox".  The wording should say "with INT= ERNALDATE greater than February 1, 1994" or so.

6.4.4.= 1 SAVE Result

<= div style=3D"font-family:Arial;">I'm not sure I understand the interacti= on here with closing and re-opening a mailbox.  I would expect that= closing a mailbox would wipe the SAVED result, and that trying to use a= SAVED result when there isn't one should return an error.

Speaking of which, Example 5 is wrong: It says that the second search = command leads to the variable containing no messages, but the second sea= rch command did not contain the RETURN SAVE option, so it should not hav= e altered the variable.

<= /div>
7.1 Status Responses

Using 'o' as a tag in the ALREADYEXISTS item is confusing, it = looks like an attempt to do dot points!

7.2.3 LIST Res= ponse

This is the interesting bit for SPECIAL-USE - i= t should reference that here - as well as referencing the registry since= it reproduces some of it inline.


7.4.2 FETCH= Response

I remember past bugs with UID in "unsolicit= ed" FLAGS responses.  Do we need to require that including UID only= happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)?
<= div style=3D"font-family:Arial;">
Appendix C: Changes

Right now it's still stat= ed as "the planned changes" and there's still some TODO in there (some o= f which I think could be well handled by referencing the registries rath= er than replicating them inline).



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


--fbdff0f53f704b33ac63771ed8444276-- From nobody Wed Jan 29 06:21:14 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 60921120842 for ; Wed, 29 Jan 2020 06:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXNoGypG8UuX for ; Wed, 29 Jan 2020 06:21:04 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id B30F5120875 for ; Wed, 29 Jan 2020 06:21:03 -0800 (PST) Received: from [192.168.10.100] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 338982B3C8B; Wed, 29 Jan 2020 14:21:00 +0000 (UTC) From: Timo Sirainen Message-Id: <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7A094FED-0736-4660-85D1-89C686852378" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Wed, 29 Jan 2020 16:20:58 +0200 In-Reply-To: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> Cc: extra@ietf.org, Alexey Melnikov , Barry Leiba To: Bron Gondwana References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 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, 29 Jan 2020 14:21:13 -0000 --Apple-Mail=_7A094FED-0736-4660-85D1-89C686852378 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29. Jan 2020, at 14.08, Bron Gondwana wrote: >=20 > 2.2.1 Client protocol >=20 > "A different tag is generated by the client for each command". = There's no "MUST" on this, and certainly I've seen clients which don't. = Do we want to make that more strict in rev2? It would be a bit of a = pain on the commandline where I normally use ".", but it's also annoying = as a server author that you can't rely on tag uniqueness. >=20 > Maybe the client SHOULD generate a different tag for every command, = but a server MUST accept tag reuse (could restrict concurrency, a tag = can only be reused after it's been "returned") I haven't seen this as a problem, so I don't really care either way. > 2.3.1.1 UID Attribute >=20 > "The next unique identifier value MUST NOT change unless new messages = are added to the mailbox". I would very much like that first MUST NOT = to be weakened to "SHOULD NOT". My reasoning is that you could have a = virtual mailbox which used a global sequence number per message. It = would behave to clients as if a message had been delivered and then = immediately expunged. I'm pretty sure clients don't care - they'll = fetch the range, discover that nothing new has appeared, and stay happy. = The second MUST is obviously correct, that the UIDNEXT must increase = when messages are delivered. Agreed. > 5.1 Mailbox Naming >=20 > This doesn't solve one of my naming bugbears. The spec says things = like "servers MAY accept a de-normalized UTF-8 mailbox name and conver = it to Net-Unicode prior to mailbox creation." - there is no clear way to = know what the SELECTable name will be after creating a mailbox. >=20 > If I was designing this myself from scratch I would say that "SELECT = of the same octets that were passed to CREATE MUST open that same = mailbox" or something to that effect. Since we're messing with how = mailbox naming works somewhat for imap4rev2, I'd be keen to add this = restriction on server behaviour so that clients don't fall into a = "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop. >=20 > 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" > 6.3.2 SELECT command >=20 > I also saw somewhere that the server can unilaterally send a "* = [CLOSED]" response at any point if it's had to close the mailbox (e.g. = it got deleted, or IO errors). I'm not sure if that requires opt-in to = IMAP4REV2, since otherwise clients will not be aware to watch for it. = This may need to be clarified. Current behaviour of our server right = now is to drop the connection entirely, which is ugly - but it's rare = and all clients already need to handle it cleanly, so it guarantees no = messed up data model for the clients. Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't think = clients are going to implement it correctly since it almost never = happens, so nobody tests that code path. > 6.3.4 and 6.3.5 CREATE and DELETE >=20 > Can we make it illegal to "DELETE" a mailbox with children rather than = make it a \NoSelect mailbox pretty pretty please? I'm just looking at = some patches to deal with Outlook misbehaving with this precise = situation, and it's all horrible. Because of mailboxId requirements for = JMAP we've been forced to keep these things around as "intermediate" = mailboxes anyway, and it's been the source of tons of bugs. \NoSelect seems to be causing confusion in general, and Dovecot nowadays = has options that makes it try to avoid creating them. But I'm not sure = if it needs to be made illegal in the RFC itself. I think your server = implementation can just decide to reject DELETE if it has children. It sounds like your issues are with \NoSelect mailboxes in general, not = just this specific way of creating them with DELETE? For example CREATE = a/b could create "a" se \NoSelect also. > 6.3.6 RENAME=20 >=20 > I thought we had agreed to strongly recommend against clients using = RENAME INBOX Other, but maybe I've forgotten. I don't see it in the = minutes, so maybe it's just my wishful thinking. Dovecot doesn't allow RENAME INBOX in some configurations. I don't = remember people complaining. > We definitely have an option in Cyrus IMAP to make subscriptions = follow RENAME. It's one of the warts (largely due to Thunderbird = showing greyed out folders and confusing people). We haven't needed to do this yet. I think the \NoSelect folders have = been more of a reason for Thunderbird confusion. > 6.3.7 SUBSCRIBE >=20 > Speak of the devil. Lots of sites violate the MUST NOT unilaterally = remove rule. Should we weaken it to SHOULD? The justification for the = MUST is "the server site might choose to do X" - well, if the server = site is doing that, then maybe they SHOULDN'T unilaterally remove the = subscriptions, but otherwise it's a better user experience and what = people want. >=20 > (also: by enabling a non-default break the rules config, it's what our = server does!) The original use case for not auto-removing a subscription is rather = ancient already. I'd be fine with changing subscriptions to follow = deletes and renames in the rev2 mode (but better not change behavior in = rev1 mode). > 6.3.8 UNSUBSCRIBE >=20 > This command returns a tagged OK response only if the unsubscription = is successful. - this is not clear on what happens if the mailbox is not = currently subscribed - does it silently succeed, or is there an expected = error? >=20 > For what it's worth, our server just says "OK Completed" even if it's = already been unsubscrbed - and likewise for subscribe if it's already = subscribed it just say "yep, all good". Same with Dovecot. I think should keep the OK behavior, since that's = what is commonly been done. > 6.3.10 NAMESPACE >=20 > We've created a conflict here. The NAMESPACE command contains prefix = strings for the individual namespaces, and says: >=20 > The prefix string allows a client to do things such as = automatically > creating personal mailboxes or LISTing all available mailboxes = within > a namespace. >=20 > Which contradicts the advice we gave back in the LIST command not to = use prefix. Perhaps we should change the LIST advice to be "only use = the empty prefix or prefixes given in the NAMESPACE response"? I think you're mixing "namespace prefixes" with "list references"? I = don't think the above sentence advocates using LIST reference parameter, = just using the namespace prefix for listing e.g. LIST "" ns-prefix/* Anyway, I see lots and lots of text is still preserved for the LIST = reference parameter explanation, even though it shouldn't be used. = Couldn't we just decide to get rid of it entirely in rev2 and say the = reference MUST be empty? Or say only that is is implementation-defined = and refer to IMAP4rev1 if anyone wants to see how it used to be = implemented? > 6.3.11 STATUS >=20 > Note: The STATUS command is intended to access the status of > mailboxes other than the currently selected mailbox. Because = the > STATUS command can cause the mailbox to be opened internally, = and > because this information is available by other means on the > selected mailbox, the STATUS command SHOULD NOT be used on the > currently selected mailbox. >=20 > This advice is all well and good, but it says nothing about what the = server may or may not do when it gets one of these STATUS commands. = This is particularly relevant in the context of LIST RETURN STATUS, = where it's hard to construct list patterns which explicitly avoid the = currently selected mailbox. >=20 > Likewise with the: MUST NOT be used as a "check for new messages in = the selected mailbox" assertion. Plenty of clients will do a STATUS run = across folders and if they're doing LIST RETURN STATUS they're gonna = find out about the new messages if the server returns it. Clients can = not rely on it working is a more honest representation of what happens. >=20 > I'd like to see that IMAP4REV2 servers MUST implement STATUS of the = currently selected mailbox. Yes, it's a special codepath - but if = you're already testing if it's the currently open mailbox then you're at = exactly the right place to do the right thing: Also this is the only way to get the current UIDNEXT of the selected = mailbox (since it might be higher than last message's UID). The main ambiguity though is whether STATUS on the current mailbox is = expected to check for new changes. Dovecot implements it in a way that = it doesn't check for changes. I think there used to be even a good = reason for that. > 6.4.4.1 SAVE Result >=20 > I'm not sure I understand the interaction here with closing and = re-opening a mailbox. I would expect that closing a mailbox would wipe = the SAVED result, I think it practically says that, since it says that SELECT/EXAMINE = resets it to empty sequence. It's not really relevant whether it happens = when the mailbox is closed or when the next mailbox is opened, because = you can't use it in non-selected state anyway.. > and that trying to use a SAVED result when there isn't one should = return an error. It says that the default is an empty sequence. So it won't result in an = error, just a non-matching set. I'm fine with this behavior, especially = since it's easier to implement and I don't really see much of a = downside. > Speaking of which, Example 5 is wrong: It says that the second search = command leads to the variable containing no messages, but the second = search command did not contain the RETURN SAVE option, so it should not = have altered the variable. Right. And even if it did contain RETURN SAVE option it still shouldn't = have altered the variable, because: """ Any of the following SEARCH commands MUST NOT change the search result variable: a SEARCH command that caused the server to return the BAD tagged response, """ > 7.4.2 FETCH Response >=20 > I remember past bugs with UID in "unsolicited" FLAGS responses. Do we = need to require that including UID only happen after ENABLE IMAP4REV2 = (as it is for ENABLE QRESYNC)? Might be useful to require UID for any untagged FETCH reply. It can = simplify client behavior. --Apple-Mail=_7A094FED-0736-4660-85D1-89C686852378 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 29. Jan 2020, at 14.08, Bron Gondwana <brong@fastmailteam.com> wrote:

2.2.1= Client protocol

"A different tag is generated by the = client for each command".  There's no "MUST" on this, and = certainly I've seen clients which don't.  Do we want to make that = more strict in rev2?  It would be a bit of a pain on the = commandline where I normally use ".", but it's also annoying as a server = author that you can't rely on tag uniqueness.

Maybe the client SHOULD generate a different tag for = every command, but a server MUST accept tag reuse (could restrict = concurrency, a tag can only be reused after it's been "returned")

I = haven't seen this as a problem, so I don't really care either = way.

2.3.1.1 UID Attribute

"The = next unique identifier value MUST NOT change unless new messages are = added to the mailbox".  I would very much like that = first MUST NOT to be weakened to "SHOULD NOT".  My reasoning is = that you could have a virtual mailbox which used a global sequence = number per message.  It would behave to clients as if a message had = been delivered and then immediately expunged.  I'm pretty sure = clients don't care - they'll fetch the range, discover that nothing new = has appeared, and stay happy.  The second MUST is obviously = correct, that the UIDNEXT must increase when messages are delivered.

Agreed.

5.1 Mailbox = Naming

This doesn't solve one of my = naming bugbears.  The spec says things like "servers MAY = accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode = prior to mailbox creation." - there is no clear = way to know what the SELECTable name will be after creating a = mailbox.

If I was = designing this myself from scratch I would say that "SELECT of the same = octets that were passed to CREATE MUST open that same mailbox" or = something to that effect.  Since we're messing with how mailbox = naming works somewhat for imap4rev2, I'd be keen to add this restriction = on server behaviour so that clients don't fall into a "CREATE -> = ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop.

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"

6.3.2= SELECT command

I also saw = somewhere that the server can unilaterally send a "* [CLOSED]" response = at any point if it's had to close the mailbox (e.g. it got deleted, or = IO errors).  I'm not sure if that requires opt-in to IMAP4REV2, = since otherwise clients will not be aware to watch for it.  This = may need to be clarified.  Current behaviour of our server right = now is to drop the connection entirely, which is ugly - but it's rare = and all clients already need to handle it cleanly, so it guarantees no = messed up data model for the clients.

Yeah, I'd prefer just BYE instead of unilateral = CLOSED. I don't think clients are going to implement it correctly since = it almost never happens, so nobody tests that code path.

6.3.4= and 6.3.5 CREATE and DELETE

Can we make it illegal to "DELETE" a mailbox with = children rather than make it a \NoSelect mailbox pretty pretty = please?  I'm just looking at some patches to deal with Outlook = misbehaving with this precise situation, and it's all horrible.  = Because of mailboxId requirements for JMAP we've been forced to keep = these things around as "intermediate" mailboxes anyway, and it's been = the source of tons of bugs.

\NoSelect seems to be causing confusion in = general, and Dovecot nowadays has options that makes it try to avoid = creating them. But I'm not sure if it needs to be made illegal in the = RFC itself. I think your server implementation can just decide to reject = DELETE if it has children.

It sounds = like your issues are with \NoSelect mailboxes in general, not just this = specific way of creating them with DELETE? For example CREATE a/b could = create "a" se \NoSelect also.

6.3.6 RENAME 

I thought we had agreed to strongly recommend against = clients using RENAME INBOX Other, but maybe I've forgotten.  I = don't see it in the minutes, so maybe it's just my wishful thinking.

Dovecot= doesn't allow RENAME INBOX in some configurations. I don't remember = people complaining.

We definitely have an option in = Cyrus IMAP to make subscriptions follow RENAME.  It's one of the = warts (largely due to Thunderbird showing greyed out folders and = confusing people).

We haven't needed to do this yet. I think the = \NoSelect folders have been more of a reason for Thunderbird = confusion.

6.3.7 SUBSCRIBE

Speak of the devil.  Lots of = sites violate the MUST NOT unilaterally remove rule.  Should we = weaken it to SHOULD?  The justification for the MUST is "the server = site might choose to do X" - well, if the server site is doing that, = then maybe they SHOULDN'T unilaterally remove the subscriptions, but = otherwise it's a better user experience and what people want.

(also: by enabling a non-default = break the rules config, it's what our server does!)

The = original use case for not auto-removing a subscription is rather ancient = already. I'd be fine with changing subscriptions to follow deletes and = renames in the rev2 mode (but better not change behavior in rev1 = mode).

6.3.8 UNSUBSCRIBE

This command returns = a tagged OK response only if the unsubscription is successful. - this is not clear on = what happens if the mailbox is not currently subscribed - does it = silently succeed, or is there an expected error?

For what it's worth, our server just says "OK = Completed" even if it's already been unsubscrbed - and likewise for = subscribe if it's already subscribed it just say "yep, all good".

Same = with Dovecot. I think should keep the OK behavior, since that's what is = commonly been done.

6.3.10 = NAMESPACE

We've created a conflict = here.  The NAMESPACE command contains prefix strings for the = individual namespaces, and says:

   The prefix string allows a client =
to do things such as automatically
   creating personal mailboxes or LISTing all available mailboxes within
   a namespace.

Which contradicts = the advice we gave back in the LIST command not to use prefix.  = Perhaps we should change the LIST advice to be "only use the empty = prefix or prefixes given in the NAMESPACE response"?

I = think you're mixing "namespace prefixes" with "list references"? I don't = think the above sentence advocates using LIST reference parameter, just = using the namespace prefix for listing e.g. LIST "" = ns-prefix/*

Anyway, I see lots and = lots of text is still preserved for the LIST reference parameter = explanation, even though it shouldn't be used. Couldn't we just decide = to get rid of it entirely in rev2 and say the reference MUST be empty? = Or say only that is is implementation-defined and refer to IMAP4rev1 if = anyone wants to see how it used to be implemented?

6.3.11 STATUS

      Note: The STATUS command is =
intended to access the status of
      mailboxes other than the currently selected mailbox.  Because the
      STATUS command can cause the mailbox to be opened internally, and
      because this information is available by other means on the
      selected mailbox, the STATUS command SHOULD NOT be used on the
      currently selected mailbox.

This advice is all well and good, but it says nothing = about what the server may or may not do when it gets one of these STATUS = commands.  This is particularly relevant in the context of LIST = RETURN STATUS, where it's hard to construct list patterns which = explicitly avoid the currently selected mailbox.

Likewise with the: MUST NOT be = used as a "check for new messages in the selected mailbox" assertion.  Plenty = of clients will do a STATUS run across folders and if they're doing LIST = RETURN STATUS they're gonna find out about the new messages if the = server returns it.  Clients can not rely on it working is a more = honest representation of what happens.

I'd like to see that IMAP4REV2 servers MUST implement = STATUS of the currently selected mailbox.  Yes, it's a special = codepath - but if you're already testing if it's the currently open = mailbox then you're at exactly the right place to do the right thing:

Also = this is the only way to get the current UIDNEXT of the selected mailbox = (since it might be higher than last message's UID).

The main ambiguity though is whether STATUS on the = current mailbox is expected to check for new changes. Dovecot implements = it in a way that it doesn't check for changes. I think there used to be = even a good reason for that.

6.4.4.1 SAVE = Result

I'm not sure I understand the = interaction here with closing and re-opening a mailbox.  I would = expect that closing a mailbox would wipe the SAVED result, =

I think it = practically says that, since it says that SELECT/EXAMINE resets it to = empty sequence. It's not really relevant whether it happens when the = mailbox is closed or when the next mailbox is opened, because you can't = use it in non-selected state anyway..

and that trying to use a SAVED = result when there isn't one should return an error.

It = says that the default is an empty sequence. So it won't result in an = error, just a non-matching set. I'm fine with this behavior, especially = since it's easier to implement and I don't really see much of a = downside.

Speaking of which, Example 5 is wrong: It says that = the second search command leads to the variable containing no messages, = but the second search command did not contain the RETURN SAVE option, so = it should not have altered the variable.

Right. = And even if it did contain RETURN SAVE option it still shouldn't have = altered the variable, because:

"""
   Any of the following = SEARCH commands MUST NOT change the search
  =  result variable:

      a SEARCH command that caused the server = to return the BAD tagged
      = response,
"""


7.4.2 FETCH Response

I remember past bugs with UID in "unsolicited" FLAGS = responses.  Do we need to require that including UID only happen = after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)?

Might = be useful to require UID for any untagged FETCH reply. It can simplify = client behavior.

= --Apple-Mail=_7A094FED-0736-4660-85D1-89C686852378-- From nobody Wed Jan 29 13:52: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 CB932120026 for ; Wed, 29 Jan 2020 13:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=MGW7R1OX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PvGqEQQF 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 SdEXiQ9PnTHR for ; Wed, 29 Jan 2020 13:52:39 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689F7120047 for ; Wed, 29 Jan 2020 13:52:39 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8BB2E21AF1 for ; Wed, 29 Jan 2020 16:52:38 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute2.internal (MEProxy); Wed, 29 Jan 2020 16:52:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=usJ6rfV k8RBD9EV5KL7yXJ5NRapKlv0DWvBVIoCSBcA=; b=MGW7R1OXZ+PA0wz93knh27b u47NASU2Pnd9G5Hxi2E4MDY7iFqnJP0mX82UG66TQQq20hAHg+Yc0ZHsYKLeEkqT pxUTPMlLyiCdL8pN1o4PSw/zKGSBmWIEcHP8IzRRcjC4MZVqXlUSBoeNQ0CXWMW9 rSlrgpyUP3rAMsBVkG+NggWEVIoc1ZkteEYTXy7Tl6bi8qybh4ZdDP7uBGkJUqeC Xo1BSqsEaad5mq2yJYt07ZK4cUU36/7VujyF6dSK2/vrd07BDiQ7lyR5U4xhn7F5 35h0IzGJs18H+mHoYUf75tF1wKha4lyOcXY17PVNv+BCEJvKiOo8cd/VQxwMlUA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=usJ6rf Vk8RBD9EV5KL7yXJ5NRapKlv0DWvBVIoCSBcA=; b=PvGqEQQF8vP2u8CNAg1OK2 cou2hjUJjyCgQFQbw1UcplbnlkPAJPGpbbrYjDuikE1+YDO1sDYEUND1PUhebkeS wxPIrjCef7Xb0VE9KC77yo2k7b1wnIaCpMEj1jpidkRc3SJza39z/YLYGWvioeLR nK+fHlWv+LuKMirdNVqXneTSqmQbCZmcGHiGkk4AaUkOjJiSMXdGtdU/YkhaQw0D vwxgaz5DAQgGInBQBqcSQUajun4Ng8Qnc49nsRsD4rxnD3irc9HzQzPLDbZgZhNj YvrclBtY4AxpWaRHxLxrixHcJAhIf+Ox8keGyG/oHLFiveWYsGe63LjEI/mQC23g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeeigdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14A0C24009E; Wed, 29 Jan 2020 16:52:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-850-ga703523-fmnext-20200128v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> Date: Thu, 30 Jan 2020 08:52:25 +1100 From: "Bron Gondwana" To: extra@ietf.org Content-Type: multipart/alternative; boundary=1b11fc3d76f64b74907b1a8679deede5 Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 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, 29 Jan 2020 21:52:43 -0000 --1b11fc3d76f64b74907b1a8679deede5 Content-Type: text/plain On Thu, Jan 30, 2020, at 01:20, Timo Sirainen wrote: > On 29. Jan 2020, at 14.08, Bron Gondwana wrote: >> >> *2.2.1 Client protocol* >> ** >> *"A different tag is generated by the client for each command".* There's no "MUST" on this, and certainly I've seen clients which don't. Do we want to make that more strict in rev2? It would be a bit of a pain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness. >> >> Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned") > > I haven't seen this as a problem, so I don't really care either way. I don't care either way, it's more "if I was writing a server it wouldn't be clear to me that a client might just send . every time". > >> *2.3.1.1 UID Attribute* >> ** >> *"The next unique identifier value MUST NOT change unless new messages are added to the mailbox". * I would very much like that first MUST NOT to be weakened to "SHOULD NOT". My reasoning is that you could have a virtual mailbox which used a global sequence number per message. It would behave to clients as if a message had been delivered and then immediately expunged. I'm pretty sure clients don't care - they'll fetch the range, discover that nothing new has appeared, and stay happy. The second MUST is obviously correct, that the UIDNEXT must increase when messages are delivered. > > Agreed. > >> *5.1 Mailbox Naming* >> >> This doesn't solve one of my naming bugbears. The spec says things like *"servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." -*** **there is no clear way to know what the SELECTable name will be after creating a mailbox. >> >> If I was designing this myself from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect. Since we're messing with how mailbox naming works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop. >> >> 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" Presumable the name would be an astring. If we did this, I'd want to say "if OBJECTID is supported, MAILBOXID goes into this response as well". > >> *6.3.2 SELECT command* >> >> I also saw somewhere that the server can unilaterally send a "* [CLOSED]" response at any point if it's had to close the mailbox (e.g. it got deleted, or IO errors). I'm not sure if that requires opt-in to IMAP4REV2, since otherwise clients will not be aware to watch for it. This may need to be clarified. Current behaviour of our server right now is to drop the connection entirely, which is ugly - but it's rare and all clients already need to handle it cleanly, so it guarantees no messed up data model for the clients. > > Yeah, I'd prefer just BYE instead of unilateral CLOSED. I don't think clients are going to implement it correctly since it almost never happens, so nobody tests that code path. > >> *6.3.4 and 6.3.5 CREATE and DELETE* >> >> Can we make it illegal to "DELETE" a mailbox with children rather than make it a \NoSelect mailbox pretty pretty please? I'm just looking at some patches to deal with Outlook misbehaving with this precise situation, and it's all horrible. Because of mailboxId requirements for JMAP we've been forced to keep these things around as "intermediate" mailboxes anyway, and it's been the source of tons of bugs. > > \NoSelect seems to be causing confusion in general, and Dovecot nowadays has options that makes it try to avoid creating them. But I'm not sure if it needs to be made illegal in the RFC itself. I think your server implementation can just decide to reject DELETE if it has children. > > It sounds like your issues are with \NoSelect mailboxes in general, not just this specific way of creating them with DELETE? For example CREATE a/b could create "a" se \NoSelect also. That's indeed what happens now in our server: . list "" a* * LIST (\HasNoChildren) "/" a/b/c . OK Completed (0.001 secs 3 calls) . list "" a/% * LIST (\Noselect \HasChildren) "/" a/b . OK Completed (0.001 secs 3 calls) . list "" a * LIST (\Noselect \HasChildren) "/" a . OK Completed (0.000 secs 3 calls) >> *6.3.6 RENAME * >> >> I thought we had agreed to strongly recommend against clients using RENAME INBOX Other, but maybe I've forgotten. I don't see it in the minutes, so maybe it's just my wishful thinking. > > Dovecot doesn't allow RENAME INBOX in some configurations. I don't remember people complaining. Excellent. I'm keen to turn it off on our server. I should probably scan the logs and see how often it gets used! >> We definitely have an option in Cyrus IMAP to make subscriptions follow RENAME. It's one of the warts (largely due to Thunderbird showing greyed out folders and confusing people). > > We haven't needed to do this yet. I think the \NoSelect folders have been more of a reason for Thunderbird confusion. > >> *6.3.7 SUBSCRIBE* >> >> Speak of the devil. Lots of sites violate the MUST NOT unilaterally remove rule. Should we weaken it to SHOULD? The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want. >> >> (also: by enabling a non-default break the rules config, it's what our server does!) > > The original use case for not auto-removing a subscription is rather ancient already. I'd be fine with changing subscriptions to follow deletes and renames in the rev2 mode (but better not change behavior in rev1 mode). > >> *6.3.8 UNSUBSCRIBE* >> >> *This command returns a tagged OK response only if the unsubscription is successful. *- this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error? >> >> For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good". > > Same with Dovecot. I think should keep the OK behavior, since that's what is commonly been done. > >> *6.3.10 NAMESPACE* >> >> We've created a conflict here. The NAMESPACE command contains prefix strings for the individual namespaces, and says: >> >> The prefix string allows a client to do things such as automatically creating personal mailboxes or LISTing all available mailboxes within a namespace. >> >> Which contradicts the advice we gave back in the LIST command not to use prefix. Perhaps we should change the LIST advice to be "only use the empty prefix or prefixes given in the NAMESPACE response"? > > I think you're mixing "namespace prefixes" with "list references"? I don't think the above sentence advocates using LIST reference parameter, just using the namespace prefix for listing e.g. LIST "" ns-prefix/* > > Anyway, I see lots and lots of text is still preserved for the LIST reference parameter explanation, even though it shouldn't be used. Couldn't we just decide to get rid of it entirely in rev2 and say the reference MUST be empty? Or say only that is is implementation-defined and refer to IMAP4rev1 if anyone wants to see how it used to be implemented? There was some discussion about this - I'll leave it for Barry/Alexey to reply on this one, since they've thought about it more than I have. >> *6.3.11 STATUS* >> >> Note: The STATUS command is intended to access the status of mailboxes other than the currently selected mailbox. Because the STATUS command can cause the mailbox to be opened internally, and because this information is available by other means on the selected mailbox, the STATUS command SHOULD NOT be used on the currently selected mailbox. >> >> This advice is all well and good, but it says nothing about what the server may or may not do when it gets one of these STATUS commands. This is particularly relevant in the context of LIST RETURN STATUS, where it's hard to construct list patterns which explicitly avoid the currently selected mailbox. >> >> Likewise with the: *MUST NOT be used as a "check for new messages in the selected mailbox" *assertion. Plenty of clients will do a STATUS run across folders and if they're doing LIST RETURN STATUS they're gonna find out about the new messages if the server returns it. Clients can not rely on it working is a more honest representation of what happens. >> >> I'd like to see that IMAP4REV2 servers MUST implement STATUS of the currently selected mailbox. Yes, it's a special codepath - but if you're already testing if it's the currently open mailbox then you're at exactly the right place to do the right thing: > > Also this is the only way to get the current UIDNEXT of the selected mailbox (since it might be higher than last message's UID). > > The main ambiguity though is whether STATUS on the current mailbox is expected to check for new changes. Dovecot implements it in a way that it doesn't check for changes. I think there used to be even a good reason for that. Well.. if it doesn't check for changes presumably it can't tell you the correct UIDNEXT? Either that or it will have an inconsistent response for the selected folder. >> *6.4.4.1 SAVE Result* >> >> I'm not sure I understand the interaction here with closing and re-opening a mailbox. I would expect that closing a mailbox would wipe the SAVED result, > > I think it practically says that, since it says that SELECT/EXAMINE resets it to empty sequence. It's not really relevant whether it happens when the mailbox is closed or when the next mailbox is opened, because you can't use it in non-selected state anyway.. Right - so that whole section is pointless. This text: If the server decides to send a new UIDVALIDITY value while the mailbox is opened, this causes resetting of the search variable to the empty sequence. If any SELECT resets the variable. >> and that trying to use a SAVED result when there isn't one should return an error. > > It says that the default is an empty sequence. So it won't result in an error, just a non-matching set. I'm fine with this behavior, especially since it's easier to implement and I don't really see much of a downside. Yep, fair enough. I haven't implemented $ yet, but it will be easy. >> Speaking of which, Example 5 is wrong: It says that the second search command leads to the variable containing no messages, but the second search command did not contain the RETURN SAVE option, so it should not have altered the variable. > > Right. And even if it did contain RETURN SAVE option it still shouldn't have altered the variable, because: > > """ > Any of the following SEARCH commands MUST NOT change the search > result variable: > > a SEARCH command that caused the server to return the BAD tagged > response, > """ > > >> *7.4.2 FETCH Response* >> >> I remember past bugs with UID in "unsolicited" FLAGS responses. Do we need to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)? > > Might be useful to require UID for any untagged FETCH reply. It can simplify client behavior. We definitely changed from doing it always because some clients couldn't handle it - but that was 10 years ago, maybe those clients don't exist any more. Sadly I don't remember which clients it was. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --1b11fc3d76f64b74907b1a8679deede5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Thu, Jan 30, 2020, at 01:20, Timo Sirainen wrote:
On 29. Jan 2020, at 14.08, Bron Gondwana= <brong@fastm= ailteam.com> wrote:

2.2.1 Client protocol
<= b class=3D"qt-">
"A different tag is generated by the client for each command". = ; There's no "MUST" on this, and certainly I've seen clients which don't= .  Do we want to make that more strict in rev2?  It would be a= bit of a pain on the commandline where I normally use ".", but it's als= o annoying as a server author that you can't rely on tag uniqueness.
=

Mayb= e the client SHOULD generate a different tag for every command, but a se= rver MUST accept tag reuse (could restrict concurrency, a tag can only b= e reused after it's been "returned")
I haven't seen this as a problem, so I don't really care ei= ther way.
=
I don't care either way, it'= s more "if I was writing a server it wouldn't be clear to me that a clie= nt might just send . every time".


<= blockquote class=3D"qt-" type=3D"cite">
2.3.1.1 UID Attribute

"The next unique identifier value MUST NOT change un= less new messages are added to the mailbox".  I would very much like that first MU= ST NOT to be weakened to "SHOULD NOT".  My reasoning is that you co= uld have a virtual mailbox which used a global sequence number per messa= ge.  It would behave to clients as if a message had been delivered = and then immediately expunged.  I'm pretty sure clients don't care = - they'll fetch the range, discover that nothing new has appeared, and s= tay happy.  The second MUST is obviously correct, that the UIDNEXT = must increase when messages are delivered.
<= div>
Agreed.

5.1 Mailbox Naming

<= /div>
This doesn't solve one of my naming bugbe= ars.  The spec says things like "servers MAY accept a de-normalized U= TF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation= ." - there is no clear way to know what the S= ELECTable name will be after creating a mailbox.

If I was designing this = myself from scratch I would say that "SELECT of the same octets that wer= e passed to CREATE MUST open that same mailbox" or something to that eff= ect.  Since we're messing with how mailbox naming works somewhat fo= r imap4rev2, I'd be keen to add this restriction on server behaviour so = that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -&g= t; DOESN'T EXIST" loop.

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

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

* O= K [CREATED] TAG "a123" NAME "Denormalized name"

Presumable the name would be an astring.  If we did this,= I'd want to say "if OBJECTID is supported, MAILBOXID goes into this res= ponse as well".


6.3.2 SELECT command

I also saw somewhere th= at the server can unilaterally send a "* [CLOSED]" response at any point= if it's had to close the mailbox (e.g. it got deleted, or IO errors).&n= bsp; I'm not sure if that requires opt-in to IMAP4REV2, since otherwise = clients will not be aware to watch for it.  This may need to be cla= rified.  Current behaviour of our server right now is to drop the c= onnection entirely, which is ugly - but it's rare and all clients alread= y need to handle it cleanly, so it guarantees no messed up data model fo= r the clients.

Yeah, I'd= prefer just BYE instead of unilateral CLOSED. I don't think clients are= going to implement it correctly since it almost never happens, so nobod= y tests that code path.

6.3.4 and 6.3.5 CREATE and DELETE

Can we make it illegal to "DE= LETE" a mailbox with children rather than make it a \NoSelect mailbox pr= etty pretty please?  I'm just looking at some patches to deal with = Outlook misbehaving with this precise situation, and it's all horrible.&= nbsp; Because of mailboxId requirements for JMAP we've been forced to ke= ep these things around as "intermediate" mailboxes anyway, and it's been= the source of tons of bugs.

=
\NoSelect seems to be causing confusion in general, and Dovecot now= adays has options that makes it try to avoid creating them. But I'm not = sure if it needs to be made illegal in the RFC itself. I think your serv= er implementation can just decide to reject DELETE if it has children.

It sounds like your issues are with \NoSelec= t mailboxes in general, not just this specific way of creating them with= DELETE? For example CREATE a/b could create "a" se \NoSelect also.
<= /div>

That's indeed what happens now in our serv= er:

. list "" a*
* LIST (\HasNoChildren) "/" a/b/c
. OK Completed (0.001 secs 3 calls)
. list "" a/%
= * LIST (\Noselect \HasChildren) "/" a/b
. OK Completed (0.001 secs 3 calls)
. list "" a
* LIST (\Noselect \HasChildren) "/" a
. OK Completed (0.000 secs 3 calls)

6.3.6 RENAME 

I thought we had agreed to strongly recommend ag= ainst clients using RENAME INBOX Other, but maybe I've forgotten.  = I don't see it in the minutes, so maybe it's just my wishful thinking.

Dovecot doesn't allow REN= AME INBOX in some configurations. I don't remember people complaining.

<= div style=3D"font-family:Arial;">Excellent.  I'm keen to turn it of= f on our server.  I should probably scan the logs and see how often= it gets used!

We definitely have an = option in Cyrus IMAP to make subscriptions follow RENAME.  It's one= of the warts (largely due to Thunderbird showing greyed out folders and= confusing people).

We h= aven't needed to do this yet. I think the \NoSelect folders have been mo= re of a reason for Thunderbird confusion.

6.3.7 SUBSCRIBE

Speak of the devil.  Lot= s of sites violate the MUST NOT unilaterally remove rule.  Should w= e weaken it to SHOULD?  The justification for the MUST is "the serv= er site might choose to do X" - well, if the server site is doing that, = then maybe they SHOULDN'T unilaterally remove the subscriptions, but oth= erwise it's a better user experience and what people want.

(also: by enab= ling a non-default break the rules config, it's what our server does!)

The original use case for= not auto-removing a subscription is rather ancient already. I'd be fine= with changing subscriptions to follow deletes and renames in the rev2 m= ode (but better not change behavior in rev1 mode).

6.3.8 UNSUBSCRIBE

T= his command returns a tagged OK response only if the unsubscription is s= uccessful. - th= is is not clear on what happens if the mailbox is not currently subscrib= ed - does it silently succeed, or is there an expected error?
<= div class=3D"qt-" style=3D"font-size:12px;font-style:normal;font-variant= -caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;t= ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;-= webkit-text-stroke-width:0px;text-decoration-line:none;text-decoration-s= tyle:solid;text-decoration-color:currentcolor;text-decoration-thickness:= auto;font-family:Arial;">
For what it= 's worth, our server just says "OK Completed" even if it's already been = unsubscrbed - and likewise for subscribe if it's already subscribed it j= ust say "yep, all good".

Same with Dovecot. I think should keep the OK behavior, since that's wh= at is commonly been done.

6.3.10 NAMESPACE

=
We've created a conflict here.  The NAMES= PACE command contains prefix strings for the individual namespaces, and = says:

   The prefix string allows a cl=
ient to do things such as automatically
   creating personal mailboxes or LISTing all available mailboxes within=

   a namespace.

Which contradicts the advice we gave back in the LIST comma= nd not to use prefix.  Perhaps we should change the LIST advice to = be "only use the empty prefix or prefixes given in the NAMESPACE respons= e"?

I think you're mixin= g "namespace prefixes" with "list references"? I don't think the above s= entence advocates using LIST reference parameter, just using the namespa= ce prefix for listing e.g. LIST "" ns-prefix/*

<= div>Anyway, I see lots and lots of text is still preserved for the LIST = reference parameter explanation, even though it shouldn't be used. Could= n't we just decide to get rid of it entirely in rev2 and say the referen= ce MUST be empty? Or say only that is is implementation-defined and refe= r to IMAP4rev1 if anyone wants to see how it used to be implemented?
=

There was some discussion about this - I'= ll leave it for Barry/Alexey to reply on this one, since they've thought= about it more than I have.
<= br>
6.3.11 STATUS

Note: Th= e STATUS command is intended to access the status of mailboxes other than the currently selected mailbox. Because the STATUS command can cause the mailbox to be opened internally, and because this information is available by other means on the selected mailbox, the STATUS command SHOULD NOT be used on the currently selected mailbox.
This advice is all well and good, but i= t says nothing about what the server may or may not do when it gets one = of these STATUS commands.  This is particularly relevant in the con= text of LIST RETURN STATUS, where it's hard to construct list patterns w= hich explicitly avoid the currently selected mailbox.

Likewise with the:<= span class=3D"qt-Apple-converted-space"> MU= ST NOT be used as a "check for new messages in the selected mailbox" assertion.  P= lenty of clients will do a STATUS run across folders and if they're doin= g LIST RETURN STATUS they're gonna find out about the new messages if th= e server returns it.  Clients can not rely on it working is a more = honest representation of what happens.

I'd like to see that IMAP4REV2 ser= vers MUST implement STATUS of the currently selected mailbox.  Yes,= it's a special codepath - but if you're already testing if it's the cur= rently open mailbox then you're at exactly the right place to do the rig= ht thing:

Also this is t= he only way to get the current UIDNEXT of the selected mailbox (since it= might be higher than last message's UID).

= The main ambiguity though is whether STATUS on the current mailbox is ex= pected to check for new changes. Dovecot implements it in a way that it = doesn't check for changes. I think there used to be even a good reason f= or that.
<= br>
Well.. if it doesn't check fo= r changes presumably it can't tell you the correct UIDNEXT? Either that = or it will have an inconsistent response for the selected folder.

6.4.4.1 SAVE Result

I'm= not sure I understand the interaction here with closing and re-opening = a mailbox.  I would expect that closing a mailbox would wipe the SA= VED result,

I think it p= ractically says that, since it says that SELECT/EXAMINE resets it to emp= ty sequence. It's not really relevant whether it happens when the mailbo= x is closed or when the next mailbox is opened, because you can't use it= in non-selected state anyway..

Right -= so that whole section is pointless.  This text:

   If the server decides to send=
 a new UIDVALIDITY value while the
   mailbox is opened, this causes resetting of the search variable to
   the empty sequence.

If any SELECT resets the variable.=

and that trying to use a SAVED result= when there isn't one should return an error.

It says that the default is an empty sequence. So = it won't result in an error, just a non-matching set. I'm fine with this= behavior, especially since it's easier to implement and I don't really = see much of a downside.

Yep, fair enou= gh.  I haven't implemented $ yet, but it will be easy.

Speaking of which, Example 5 is wrong: It says th= at the second search command leads to the variable containing no message= s, but the second search command did not contain the RETURN SAVE option,= so it should not have altered the variable.

Right. And even if it did contain RETURN SAVE optio= n it still shouldn't have altered the variable, because:
<= br>
"""
  =  Any of the following SEARCH commands MUST NOT change the search
   result variable:
      a SEARCH comm= and that caused the server to return the BAD tagged
      response,
"""

7.4.2 FETCH Re= sponse

I remember past bugs with UID in "unsolicited" FLAGS responses= .  Do we need to require that including UID only happen after ENABL= E IMAP4REV2 (as it is for ENABLE QRESYNC)?
<= div>
Might be useful to require UID for any untagged FETCH= reply. It can simplify client behavior.

We definitely changed from doing it always because some clients could= n't handle it - but that was 10 years ago, maybe those clients don't exi= st any more.  Sadly I don't remember which clients it was.

Cheers,

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


<= /div> --1b11fc3d76f64b74907b1a8679deede5-- From nobody Thu Jan 30 00:26: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 024D3120112 for ; Thu, 30 Jan 2020 00:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Cnsr6OiPag3e for ; Thu, 30 Jan 2020 00:26:01 -0800 (PST) Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 243E512010F for ; Thu, 30 Jan 2020 00:26:00 -0800 (PST) Received: from [192.168.10.100] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 4927A2B3C8B; Thu, 30 Jan 2020 08:25:59 +0000 (UTC) From: Timo Sirainen Message-Id: <4056563A-AF4E-4B1D-9AD7-D079A8EAC971@sirainen.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_24C95EA1-7E3A-48E9-86C5-2EEB710DE94A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 30 Jan 2020 10:25:58 +0200 In-Reply-To: Cc: extra@ietf.org To: Bron Gondwana References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11 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, 30 Jan 2020 08:26:06 -0000 --Apple-Mail=_24C95EA1-7E3A-48E9-86C5-2EEB710DE94A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29. Jan 2020, at 23.52, Bron Gondwana wrote: >>> 5.1 Mailbox Naming >>>=20 >>> This doesn't solve one of my naming bugbears. The spec says things = like "servers MAY accept a de-normalized UTF-8 mailbox name and conver = it to Net-Unicode prior to mailbox creation.." - there is no clear way = to know what the SELECTable name will be after creating a mailbox. >>>=20 >>> If I was designing this myself from scratch I would say that "SELECT = of the same octets that were passed to CREATE MUST open that same = mailbox" or something to that effect. Since we're messing with how = mailbox naming works somewhat for imap4rev2, I'd be keen to add this = restriction on server behaviour so that clients don't fall into a = "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop. >>>=20 >>> It still doesn't mean that you can reliably tell the correct octets = for the matching mailbox from the LIST response though :( >>=20 >> Is it too late to add a new response code? Something like: >>=20 >> * OK [CREATED] TAG "a123" NAME "Denormalized name" >=20 > Presumable the name would be an astring. If we did this, I'd want to = say "if OBJECTID is supported, MAILBOXID goes into this response as = well". Yeah, would be nice. >>> 6.3.4 and 6.3.5 CREATE and DELETE >>>=20 >>> Can we make it illegal to "DELETE" a mailbox with children rather = than make it a \NoSelect mailbox pretty pretty please? I'm just looking = at some patches to deal with Outlook misbehaving with this precise = situation, and it's all horrible. Because of mailboxId requirements for = JMAP we've been forced to keep these things around as "intermediate" = mailboxes anyway, and it's been the source of tons of bugs. >>=20 >> \NoSelect seems to be causing confusion in general, and Dovecot = nowadays has options that makes it try to avoid creating them. But I'm = not sure if it needs to be made illegal in the RFC itself. I think your = server implementation can just decide to reject DELETE if it has = children. >>=20 >> It sounds like your issues are with \NoSelect mailboxes in general, = not just this specific way of creating them with DELETE? For example = CREATE a/b could create "a" se \NoSelect also. >=20 > That's indeed what happens now in our server: >=20 > . list "" a* > * LIST (\HasNoChildren) "/" a/b/c > . OK Completed (0.001 secs 3 calls) > . list "" a/% > * LIST (\Noselect \HasChildren) "/" a/b > . OK Completed (0.001 secs 3 calls) > . list "" a > * LIST (\Noselect \HasChildren) "/" a > . OK Completed (0.000 secs 3 calls) This is also server-specific whether the "a" would be listed as part of = "a*". Or in Dovecot case it's mailbox format specific - it happens with = some formats but not with others. >>> 6.3.11 STATUS >>>=20 >>> Note: The STATUS command is intended to access the status of >>> mailboxes other than the currently selected mailbox. Because = the >>> STATUS command can cause the mailbox to be opened internally, = and >>> because this information is available by other means on the >>> selected mailbox, the STATUS command SHOULD NOT be used on the >>> currently selected mailbox. >>>=20 >>> This advice is all well and good, but it says nothing about what the = server may or may not do when it gets one of these STATUS commands. = This is particularly relevant in the context of LIST RETURN STATUS, = where it's hard to construct list patterns which explicitly avoid the = currently selected mailbox. >>>=20 >>> Likewise with the: MUST NOT be used as a "check for new messages in = the selected mailbox" assertion. Plenty of clients will do a STATUS run = across folders and if they're doing LIST RETURN STATUS they're gonna = find out about the new messages if the server returns it. Clients can = not rely on it working is a more honest representation of what happens. >>>=20 >>> I'd like to see that IMAP4REV2 servers MUST implement STATUS of the = currently selected mailbox. Yes, it's a special codepath - but if = you're already testing if it's the currently open mailbox then you're at = exactly the right place to do the right thing: >>=20 >> Also this is the only way to get the current UIDNEXT of the selected = mailbox (since it might be higher than last message's UID). >>=20 >> The main ambiguity though is whether STATUS on the current mailbox is = expected to check for new changes. Dovecot implements it in a way that = it doesn't check for changes. I think there used to be even a good = reason for that. >=20 > Well.. if it doesn't check for changes presumably it can't tell you = the correct UIDNEXT? Either that or it will have an inconsistent = response for the selected folder. I think arguably it's even more correct that the UIDNEXT tells what it = is in the current IMAP session state rather than the refreshed state. = (Although I wouldn't want to require that in the RFC.) So for example: a status inbox (uidnext) * STATUS inbox (UIDNEXT 10) a OK [CLIENTBUG] Status on selected mailbox completed (0.001 + 0.000 = secs). ## deliver new mail b status inbox (uidnext) * STATUS inbox (UIDNEXT 10) b OK [CLIENTBUG] Status on selected mailbox completed (0.001 + 0.000 = secs). c noop * 2 EXISTS * 2 RECENT c OK NOOP completed (0.001 + 0.000 secs). d status inbox (uidnext) * STATUS inbox (UIDNEXT 11) d OK [CLIENTBUG] Status on selected mailbox completed (0.001 + 0.000 = secs). I'll probably remove that [CLIENTBUG].. >>> 6.4.4.1 SAVE Result >>>=20 >>> I'm not sure I understand the interaction here with closing and = re-opening a mailbox. I would expect that closing a mailbox would wipe = the SAVED result, >>=20 >> I think it practically says that, since it says that SELECT/EXAMINE = resets it to empty sequence. It's not really relevant whether it happens = when the mailbox is closed or when the next mailbox is opened, because = you can't use it in non-selected state anyway.. >=20 > Right - so that whole section is pointless. This text: >=20 > If the server decides to send a new UIDVALIDITY value while the > mailbox is opened, this causes resetting of the search variable to > the empty sequence. >=20 > If any SELECT resets the variable. I'm not sure I understand your point. This text is pointless? The first = paragraph discussing SELECT resetting the sequence is pointless? They = seem somewhat complementary to me. Actually I think it would most make = sense to not allow IMAP server to change UIDVALIDITY while a mailbox is = selected. I highly doubt there are many clients that can handle it = correctly. >>> 7.4.2 FETCH Response >>>=20 >>> I remember past bugs with UID in "unsolicited" FLAGS responses.. Do = we need to require that including UID only happen after ENABLE IMAP4REV2 = (as it is for ENABLE QRESYNC)? >>=20 >> Might be useful to require UID for any untagged FETCH reply. It can = simplify client behavior. >=20 > We definitely changed from doing it always because some clients = couldn't handle it - but that was 10 years ago, maybe those clients = don't exist any more. Sadly I don't remember which clients it was. This behavior can be enabled only after ENABLE IMAP4rev2 so it wouldn't = matter if some old clients couldn't handle it. --Apple-Mail=_24C95EA1-7E3A-48E9-86C5-2EEB710DE94A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 29. Jan 2020, at 23.52, Bron Gondwana <brong@fastmailteam.com> wrote:

5.1 Mailbox = Naming

This doesn't solve = one of my naming bugbears.  The spec says things like "servers = MAY accept a de-normalized UTF-8 mailbox name and conver it to = Net-Unicode prior to mailbox creation.." - there is no = clear way to know what the SELECTable name will be after creating a = mailbox.

If I was designing = this myself from scratch I would say that "SELECT of the same octets = that were passed to CREATE MUST open that same mailbox" or something to = that effect.  Since we're messing with how mailbox naming works = somewhat for imap4rev2, I'd be keen to add this restriction on server = behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS = / SELECT -> DOESN'T EXIST" loop.

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"

Presumable the name would be an astring.  If we = did this, I'd want to say "if OBJECTID is supported, MAILBOXID goes into = this response as well".

Yeah, would be nice.

6.3.4 and 6.3.5 CREATE and = DELETE

Can we make it = illegal to "DELETE" a mailbox with children rather than make it a = \NoSelect mailbox pretty pretty please?  I'm just looking at some = patches to deal with Outlook misbehaving with this precise situation, = and it's all horrible.  Because of mailboxId requirements for JMAP = we've been forced to keep these things around as "intermediate" = mailboxes anyway, and it's been the source of tons of bugs.

\NoSelect seems to be causing confusion = in general, and Dovecot nowadays has options that makes it try to avoid = creating them. But I'm not sure if it needs to be made illegal in the = RFC itself. I think your server implementation can just decide to reject = DELETE if it has children.

It sounds like your issues are with = \NoSelect mailboxes in general, not just this specific way of creating = them with DELETE? For example CREATE a/b could create "a" se \NoSelect = also.

That's indeed = what happens now in our server:

. list "" a*
* LIST = (\HasNoChildren) "/" a/b/c
. OK Completed (0.001 secs 3 = calls)
. list "" a/%
* LIST (\Noselect \HasChildren) "/" a/b
. OK Completed (0.001 secs 3 calls)
. list "" a
* LIST (\Noselect = \HasChildren) "/" a
. OK Completed (0.000 secs 3 = calls)

This is also server-specific whether the "a" would = be listed as part of "a*". Or in Dovecot case it's mailbox format = specific - it happens with some formats but not with others.

6.3.11 = STATUS

      Note: The STATUS command is =
intended to access the status of
      mailboxes other than the currently selected mailbox.  Because the
      STATUS command can cause the mailbox to be opened internally, and
      because this information is available by other means on the
      selected mailbox, the STATUS command SHOULD NOT be used on the
      currently selected mailbox.

This advice is all = well and good, but it says nothing about what the server may or may not = do when it gets one of these STATUS commands.  This is particularly = relevant in the context of LIST RETURN STATUS, where it's hard to = construct list patterns which explicitly avoid the currently selected = mailbox.

Likewise with = the: MUST NOT be used as a "check for new messages in the = selected mailbox" assertion.  = Plenty of clients will do a STATUS run across folders and if they're = doing LIST RETURN STATUS they're gonna find out about the new messages = if the server returns it.  Clients can not rely on it working is a = more honest representation of what happens.

I'd like to see = that IMAP4REV2 servers MUST implement STATUS of the currently selected = mailbox.  Yes, it's a special codepath - but if you're already = testing if it's the currently open mailbox then you're at exactly the = right place to do the right thing:

Also this is the only way to get the = current UIDNEXT of the selected mailbox (since it might be higher than = last message's UID).

The main ambiguity though is whether = STATUS on the current mailbox is expected to check for new changes. = Dovecot implements it in a way that it doesn't check for changes. I = think there used to be even a good reason for that.

Well.. if it = doesn't check for changes presumably it can't tell you the correct = UIDNEXT? Either that or it will have an inconsistent response for the = selected folder.

I think arguably it's even more correct that the = UIDNEXT tells what it is in the current IMAP session state rather than = the refreshed state. (Although I wouldn't want to require that in the = RFC.) So for example:

a status = inbox (uidnext)
* STATUS inbox (UIDNEXT 10)
a OK = [CLIENTBUG] Status on selected mailbox completed (0.001 + 0.000 = secs).

## deliver new = mail

b status inbox = (uidnext)
* STATUS inbox (UIDNEXT 10)
b OK = [CLIENTBUG] Status on selected mailbox completed (0.001 + 0.000 = secs).
c noop
* 2 EXISTS
* 2 = RECENT
c OK NOOP completed (0.001 + 0.000 secs).
d = status inbox (uidnext)
* STATUS inbox (UIDNEXT 11)
d = OK [CLIENTBUG] Status on selected mailbox completed (0.001 + 0.000 = secs).

I'll probably remove = that [CLIENTBUG]..

6.4.4.1 SAVE Result

I'm not sure I = understand the interaction here with closing and re-opening a = mailbox.  I would expect that closing a mailbox would wipe the = SAVED result,

I think it practically says that, since = it says that SELECT/EXAMINE resets it to empty sequence. It's not really = relevant whether it happens when the mailbox is closed or when the next = mailbox is opened, because you can't use it in non-selected state = anyway..

Right - so that = whole section is pointless.  This text:

   If the server decides to send a =
new UIDVALIDITY value while the
   mailbox is opened, this causes resetting of the search variable to
   the empty sequence.

If any SELECT = resets the variable.

I'm not sure I understand your point. This text is = pointless? The first paragraph discussing SELECT resetting the sequence = is pointless? They seem somewhat complementary to me. Actually I think = it would most make sense to not allow IMAP server to change UIDVALIDITY = while a mailbox is selected. I highly doubt there are many clients that = can handle it correctly.

7.4.2 FETCH = Response

I remember past = bugs with UID in "unsolicited" FLAGS responses..  Do we need to = require that including UID only happen after ENABLE IMAP4REV2 (as it is = for ENABLE QRESYNC)?

Might be useful to = require UID for any untagged FETCH reply. It can simplify client = behavior.

We definitely changed from doing it always because = some clients couldn't handle it - but that was 10 years ago, maybe those = clients don't exist any more.  Sadly I don't remember which clients = it was.

This behavior can be enabled only after ENABLE = IMAP4rev2 so it wouldn't matter if some old clients couldn't handle = it.

= --Apple-Mail=_24C95EA1-7E3A-48E9-86C5-2EEB710DE94A--