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

Timo Sirainen <> Sun, 02 February 2020 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF19E12003F for <>; Sun, 2 Feb 2020 07:16:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6jqzA5CoJIxM for <>; Sun, 2 Feb 2020 07:16:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A53381200DF for <>; Sun, 2 Feb 2020 07:16:37 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 340222B3C8B; Sun, 2 Feb 2020 15:16:36 +0000 (UTC)
From: Timo Sirainen <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1831F738-855A-4ABC-BF6B-66FF611EE8B6"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Sun, 2 Feb 2020 17:16:34 +0200
In-Reply-To: <>
To: Alexey Melnikov <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
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: Sun, 02 Feb 2020 15:16:42 -0000

On 1. Feb 2020, at 21.00, Alexey Melnikov <> wrote:
> Hi,
> On 29 Jan 2020, at 14: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 see this as a problem and I don’t want to make the server check for reuse.
> I am Ok with adding informative suggestion for clients to generate unique tags to ease in debugging issues. Would this work for people?

Fine with me.

>>> It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :(
>> Is it too late to add a new response code? Something like:
>> * OK [CREATED] TAG "a123" NAME "Denormalized name"
> Response codes are cheap and don’t break older clients, so I am happy to add one.

I guess an optional reply which can send both the changed name and/or mailboxid. Maybe something like:

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

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

>>> 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?

Fine with me.

>>> 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.

But is the MUST NOT or SHOULD NOT behavior wanted nowadays anymore? Especially subscriptions not following RENAME is annoying for clients because they have to explicitly transfer the subscription as well. So my suggestion would be that if ENABLE IMAP4rev2 is used then subscriptions would follow RENAME/DELETE.

>>> 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 think a separate section would be clearer.

>>> 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.
> I think we agreed to this. I think I mention this for IDLE, but didn’t say it in this section. What is the best place for this text?

Maybe near the beginning of the 7.4.2 section?