Re: [Extra] Review: draft-ietf-extra-imap4rev2-11

"Bron Gondwana" <> Fri, 07 February 2020 04:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B542120132 for <>; Thu, 6 Feb 2020 20:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=3FDI0Pa6; dkim=pass (2048-bit key) header.b=iEx2JEiA
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gM4fb-cg2C4B for <>; Thu, 6 Feb 2020 20:04:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05D7D12001B for <>; Thu, 6 Feb 2020 20:04:20 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2000721C4E for <>; Thu, 6 Feb 2020 23:04:19 -0500 (EST)
Received: from imap28 ([]) by compute6.internal (MEProxy); Thu, 06 Feb 2020 23:04:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=qOlghsy P78QdUrwc+XBKAeym8B6GwVhoYODqzyRt7No=; b=3FDI0Pa6ZXYojo+xxi/c64A YK3egV3cKyosC9qoGqb8Yq+wMbECNhOnVlYOCGkJaYW2Js/SJr92FMrekR6vLaKX LGLYpmZ/Tj7gp1U5GwEVDv8DeVvjt4Gl06fIg4tA/Kt92rLvUWoofO48BChHqR0h CjcP98pm17ibn1U8b32rd+kUjQ6VtY8SMJcz0+m4qQmNhGfNhezXFIl1tVoVBFqP 5pJgOaxAz9n5dZQqZ3tWkZ1ux64Kk9APrvT5JqDd9LGjO9L3eaSCnDgXHUQL0rxn 2tL2DzHEsm1LFlSMhRnIZC8GZO3dtu2tMP5fsbsu5+8OVAWNAl3dVYhKNtwd6YQ= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qOlghs yP78QdUrwc+XBKAeym8B6GwVhoYODqzyRt7No=; b=iEx2JEiA4ovC6hz/Sk6Pk9 1SWzqjMkmTOoLtQrIJtzxK+5CYsqx61spC/pKk9wIVZr3iU65IaB53t6NHSeAIR7 L+YU66mBklAiSQ33CXumelET8mFnwiIHzN5cmmJ9K/+kgiDkXdR85Q+ZE4GtPB0e Dz3x3lzyOfkYeFYIUm6N3DG6fkPwycBrcg00elpsLu1EyQarnqpHOS9FgDLmdaRs OD/LWGg8VcE0JvVsuiRibuzahrQ9pqYd6X13yN+CyVElfOUn4F8ZPLFpxBdytCbI yMVUme8ahmtq1o4v1w5WnVBL/yltSe6uEZaviYbN7PfKkiM7GpDF7WVavvAG/YvA ==
X-ME-Sender: <xms:wuE8Xnh33JTyyyHGJYuIi3RaptUajD7_-fCc1X47i-5xc68nLSuGRw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheeggdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:wuE8XqX2PTvSZAUAwepaBCbkew3LSBJA2ROK-M1LKN09KA5ILdpxHA> <xmx:wuE8XtG3okz7cHvu5e8yTEr43lVMyI76p0lSCggqQHKz_w2AYTlvAA> <xmx:wuE8XhmrFuTa-Pvf-5izb79vsIfnuTsh2KB7UNIUnNpDIV3pvzHSEg> <xmx:w-E8Xt9OVskyBlsm7LrEV9WO2Fy-BJHYOYWexvRxmukmtcfaG9UabQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B20524009E; Thu, 6 Feb 2020 23:04:18 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-871-gf1112c6-fmnext-20200202v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Date: Fri, 07 Feb 2020 15:03:51 +1100
From: "Bron Gondwana" <>
Content-Type: multipart/alternative; boundary=56e8d93d035d4e0791983b97c3d9a487
Archived-At: <>
Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11
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, 07 Feb 2020 04:04:23 -0000

Hi Alexey,

I agree with all the things Timo said. I've added a couple more comments below.

Do you want me to create github issues to track each thing, or are you happy that you know what changes are needed?

Again - sorry for the late final review and hence pushing the timeline back on this.



On Sun, Feb 2, 2020, at 06:00, Alexey Melnikov wrote:
> On 29 Jan 2020, at 14:20, Timo Sirainen < <>> wrote:
>> Is it too late to add a new response code? Something like:
>> * OK [CREATED] TAG "a123" NAME "Denormalized name"
> Response codes are cheap and don’t break older clients, so I am happy to add one.

Along with the instruction to add MAILBOXID if RFC8474 is supported, I'm good with this.

>> 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.
> Let me think about this.

We still need a decision on this. I'm going to keep dropping connections regardless in this rare case, because there's a horrible long tail of clients, and debugging their broken caches if we ever confuse them is very difficult.

>> 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.
> I am happy to disallow this, or at least say that servers can either disallow delete of a mailbox with children or add \NoSelect to it.

Sounds good to me. Allowing the disallow is enough :)

>>> *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.
> From the client prospective I am disagreeing with this, renaming INBOX is useful for archiving.
> I am happy to say that some servers might disallow this though. Would that be Ok with people?

Works for me.

>>> 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).
> I think I would rather weaken this to SHOULD and I would rather not require change in behaviour for servers that already comply with the MUST NOT.

Yeah, totally. I'm fine with SHOULD, and I don't care about 

>>> *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/*
> Exactly.
>> 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?
> I kept the text because non empty reference is still allowed. I think I would rather allow it and mark the text as recommended server behaviour if non empty reference parameter is supplied. Maybe move it to a separate section for clarity?

I don't think any change is needed here, sorry for adding confusion.

 Bron Gondwana, CEO, Fastmail Pty Ltd