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

Alexey Melnikov <> Wed, 29 July 2020 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 535E83A0BDF for <>; Wed, 29 Jul 2020 08:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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.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 56V6Oov-RlnZ for <>; Wed, 29 Jul 2020 08:55:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 33CDD3A0BD8 for <>; Wed, 29 Jul 2020 08:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1596038129;; s=june2016;; bh=vbqCgpjj2k5d7eTTAX/3GecZtAkm8APS10UuH3hITJc=; 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=nqz7Hk9x7nViLDhiG8MdPfIH1XficaWv2P+D1QDcUrIoPVK6stvJ/naCo91Af3qxrdRLgU 7411aZYXm1icz5cvPcQgfai30mVA4Asu8Ls4/hMXi15V2DI7gmIb5bcakpNTS20RAnAPZs vzMw8S3iG5J3celUTfIv9o5APEa3e9s=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Wed, 29 Jul 2020 16:55:29 +0100
From: Alexey Melnikov <>
To: Stephan Bosch <>,
References: <> <> <> <>
Message-ID: <>
Date: Wed, 29 Jul 2020 16:55:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [Extra] 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, 29 Jul 2020 15:55:32 -0000

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.

On 16/07/2020 13:21, Stephan Bosch wrote:
> Hi Alexey,
> Did you see my review (below) ?
> Regards,
> Stephan.
> Op 22-6-2020 om 19:56 schreef Stephan Bosch:
>> Hi,
>> On 17/06/2020 13:53, Alexey Melnikov wrote:
>>> Hi all,
>>> On 17/06/2020 10:53, wrote:
>>>> The IETF datatracker status page for this draft is:
>>>> There are also htmlized versions available at:
>>>> A diff from the previous version is available at:
>>> In this version I finally removed multiple list patterns and also 
>>> clarified a few things based on earlier comments.
>> I gave this document a quick review. Below are my comments so far. 
>> Quoted text from the document is copied directly, while my comments 
>> are prefixed with "-> ".
>> Regards,
>> Stephan
>> section-2.3.2:
>> $Phishing  The $Phishing keyword can be used by a delivery agent to
>>       mark a message as highly likely to be a phishing email. An email
>>       that's determined to be a phishing email by the delivery agent
>>       should also be considered a junk email and have the appropriate
>>       junk filtering applied, including setting the $Junk flag and
>>       placing in the \Junk special-use mailbox if available.
>> -> Special-use is not mentioned up to this point. It needs to be 
>> explained briefly or referred elsewhere.
Added a reference.
>> section-5.1:
>>    5.  Two characters, "#" and "&", have meanings by convention, and
>>        should be avoided except when used in that convention.
>> -> Maybe remove the mystery and mention briefly what these are used 
>> for conventionally (or provide some citation). Section does 
>> part of this, so that could at least be referred from here.
>> 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

Do you think this is not sufficient?

>>    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 
       that are returned.  Future extensions to this specification 
should keep
       this parallelism in mind and define a pair of corresponding
       selection and return options.


>> section-
>>                                                            For each
>>          selectable mailbox matching the list pattern and selection
>>          options, the server MUST return an untagged LIST response
>>          followed by an untagged STATUS response containing the
>>          information requested in the STATUS return option.
>> -> This sentence describes a hard requirement, but subsequent 
>> paragraphs describe what amounts to exceptions. Maybe this sentence 
>> should already announce this to the reader; e.g. ", except for the 
>> following cases." or something like that. This should also avoid 
>> confusion about the contraction that seems to exist between the 
>> paragraphs.
Done, thanks.
>> section-
>>    The CHILDREN return option implements the Child Mailbox Extension,
>>    originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
>>    Corporation. Most of the information in this section is taken
>>    directly from their original specification [RFC3348].
>> -> Is it conventional to have acknowledgements like this in the 
>> normative text? Also, text borrowed from other RFCs is only 
>> acknowledged in Appendix E.
You are right, this is unusual. I moved this text to the Appendix E.
>>    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?
>> section-6.3.10:
>>    Namespace-Response-Extensions ABNF non
>>    terminal is defined for extensibility and MAY be included in the
>>    response.
>> -> What is this? And this sentence is incomplete (no article at the 
>> beginning).
There was a language extension to NAMESPACE response, but it is not 
specified in this document. I clarified.


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


>> section-10:
>> -> What about RFC 3501?
Good point. Added.
>> section-11.4:
>>    Additional security considerations are discussed in the section
>>    discussing the AUTHENTICATE and LOGIN commands.
>> -> Explicit references
>> 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?

Thank you,