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

Alexey Melnikov <> Mon, 09 March 2020 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4116D3A1239 for <>; Mon, 9 Mar 2020 08:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LFdLVDmyNV7x for <>; Mon, 9 Mar 2020 08:39:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B33D73A1238 for <>; Mon, 9 Mar 2020 08:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1583768357;; s=june2016;; bh=+yT3SmSXBazRvxAzN2Be0CdtMz+6rzju3N6gLeV4ixg=; 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=aqdAbYNOtzQRmuFgjKJEOy4+1dA+qoe4tLR77yDRu7wwCIYoaghdwW7yVz/ma62A1MVM50 dS0/AnNVswJaazhRazzT9aWWfK6eh6BG4ge+yioDq8Ldy+Mk9lMl8BR0d6faOwmZ7JiKAj oKFoPg8s1Nm1Lw+4hUOjg+VSnXFDUSU=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Mon, 9 Mar 2020 15:39:17 +0000
From: Alexey Melnikov <>
To: Bron Gondwana <>,
Cc: Barry Leiba <>
References: <>
Message-ID: <>
Date: Mon, 9 Mar 2020 15:39:14 +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="------------338EE19ED86927065B8790FE"
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: Mon, 09 Mar 2020 15:39:24 -0000

Hi Bron,

I addressed several more comments from you in -13:

On 29/01/2020 12: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 added:

    (More formally: the client SHOULD generate a unique tag for every 
    but a server MUST accept tag reuse.)

> * UID Attribute
> *
> /
> /
> 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
> *
> Should this section also reference 
> ?
> *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 
> It still doesn't mean that you can reliably tell the correct octets 
> for the matching mailbox from the LIST response though :(
I believe I clarified this with the following text:

    However, servers MAY accept a de-normalized UTF-8
    mailbox name and convert it to Unicode normalization form "NFC"
    (as per Net-Unicode requirements) prior to mailbox creation.
    Servers that choose to accept such de-normalized UTF-8 mailbox
    names MUST accept them in all IMAP commands that have a mailbox name 
    In particular SELECT &lt;name&gt; must open the same mailbox that
    was successfully created with CREATE &lt;name&gt;, even if &lt;name&gt;
    is a de-normalized UTF-8 mailbox name.

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

I've added the IANA registry reference.


> __
> __
> *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)?

I am border line on this, but I don't think so. This should be common 
enough that even IMAP4rev1 clients should be able to handle this.

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

I cleaned this up and there are only 2 smaller items remaining, that we 
might want to discuss in the WG.

Best Regards,