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

Alexey Melnikov <> Fri, 07 February 2020 13:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B07D12086A for <>; Fri, 7 Feb 2020 05:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m7BJX-n3nkTB for <>; Fri, 7 Feb 2020 05:32:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C4CF3120869 for <>; Fri, 7 Feb 2020 05:32:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1581082333;; s=june2016;; bh=WyDAM/nhb0Y7BlXo3cTjUCpX/i3WH3KOU4iFfWYYSss=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=EKuO9YnxQLe0wG37XCmbJG6m0zzY82tKmkntKCHKqqQk5dzuoeua/lBQe1laqcMa2gep1S 1iL0fjJJ13K+2zRgDudUqA6c15elfB7bz130W5m6vBCPfZJl5BThwras+rKwyQIUM4590R 32QflmZAtu4XhpLO3plboqKRA94eUOo=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 7 Feb 2020 13:32:12 +0000
To: Bron Gondwana <>,
References: <> <> <> <>
From: Alexey Melnikov <>
Message-ID: <>
Date: Fri, 7 Feb 2020 13:31:53 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------6EC6D6D1427D7F983C6AEB8C"
Content-Language: en-US
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 13:32:17 -0000

Hi Bron,

On 07/02/2020 04:03, Bron Gondwana wrote:
> Hi Alexey,
> I agree with all the things Timo said. I've added a couple more 
> comments below.
I started replying to your emails and applied some changes, but I 
haven't done all of them. I will send an email on this.
> Do you want me to create github issues to track each thing, or are you 
> happy that you know what changes are needed?
I think I am Ok for now without tracking issues in github.
> Again - sorry for the late final review and hence pushing the timeline 
> back on this.

No worries.

Best Regards,


> Cheers,
> Bron.
> 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 
> 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
> _______________________________________________
> Extra mailing list