Re: [Extra] [EXT] Re: I-D Action: draft-ietf-extra-imap4rev2-15.txt

Stephan Bosch <> Wed, 02 September 2020 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BFEF3A0DEF for <>; Wed, 2 Sep 2020 13:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TL6WWHIL0Peu for <>; Wed, 2 Sep 2020 13:06:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 335343A0E05 for <>; Wed, 2 Sep 2020 13:06:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 018CE6A303; Wed, 2 Sep 2020 22:06:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1599077185; bh=Yc7J1xzKlUjDLM3T17f5ctOSSAhCCMPZI+uPgEZDde4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=V1flxSHP8i9pjZvlOzsKOlG0a7f5Ga/VV8UkY0Lt+oYwz9POje+8/5j2KeAzDz5h1 Kxvf9BrtCSyXcj0NkxOsaNi/kCJqT9/u/EYRu0zF85kjaGbSQD0zCnKP4BafiDSABc iY+XyojBZGcdCuwx8fWxJegTxcsXvi2RGiXBc7uczlf9DRwkFPvI0Xu1uurDl6qvsu 9sbkF7X6x8PW5hNGfoMOjmtGzcP03NUw7buzU9Jbu+7ck/GdFj6b+m81ediL3bsjKG FGDl1VDG5O37EEpFV+2kPQpuv25rJxsgXe1cZOxuGoBaGJLV/PXgtxh1M1M+UfsDVY erGi8tCarwJUQ==
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B55723C0431; Wed, 2 Sep 2020 22:06:24 +0200 (CEST)
To: Alexey Melnikov <>,
References: <> <> <> <> <>
From: Stephan Bosch <>
Message-ID: <>
Date: Wed, 2 Sep 2020 22:06:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Extra] [EXT] Re: I-D Action: draft-ietf-extra-imap4rev2-15.txt
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, 02 Sep 2020 20:06:33 -0000

Hi Alexey,

On 29/07/2020 17:55, Alexey Melnikov wrote:
> Hi Stephan,
> Thank you very much for your detailed review. Replying to most of your 
> comments below. Your remaining issues I will address in a later 
> revision/reply to later.

>>> section-6.3.9:
>>> -> This section mentions several examples of specific selection and 
>>> return options without introduction. It should maybe refer to 
>>> subsequent sections at the first instance of this.
> The document already says:
>     Initial selection options and return options are defined in the
>     following subsections, and new ones will also be defined in
>     extensions.
> Do you think this is not sufficient?

Right. I seem to have overlooked that sentence.

>>>    Future extensions to this
>>>    specification should keep parallelism in mind and define a pair of
>>>    corresponding options.
>>> -> So, what exactly is meant by "parallelism" here? Do you mean 
>>> "dualism" or something like that (which I actually find equally 
>>> confusing)?
> I think I clarified this a bit, but expanding the description:
>        In general, each selection option except RECURSIVEMATCH will have
>        a corresponding return option with the same name.  The REMOTE 
> selection option is an anomaly
>        in this regard, and does not have a corresponding return option.
>        That is because it expands, rather than restricts, the set of 
> mailboxes
>        that are returned.  Future extensions to this specification 
> should keep
>        this parallelism in mind and define a pair of corresponding
>        selection and return options.

Yeah, better.

>>>    It is an error for the server to return both a \HasChildren and a
>>>    \HasNoChildren attribute in the same LIST response.
>>> -> Any recommendation for what clients should do if this does happen? 
>>> Provisionally treat it as \HasChildren?

No word on this? Do we want to avoid recommending error mitigation 
strategies in the document?

>>> section-7.4.1:
>>> -> Isn't this sub-section supposed to be in the section before? It is 
>>> about the mailbox size, not message data.
> Arguably EXPUNGE is about message status (the message is no longer 
> there). But I can go either way on this.

I don't have an opinion really. I was just worried this was wrong 
somehow. Maybe others can weigh in.

>>> section-12.1:
>>>    As this specification revises the AUTH= prefix, STARTTLS and
>>>    LOGINDISABLED extensions previously defined in [IMAP-TLS], IANA is
>>>    requested to update registry entries for these 3 extensions to point
>>>    to this document.
>>> -> This is not noted in the document header.
> Can you explain what is the issue with this text? Are you talking about 
> documents listed as Updated/Obsolete?