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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 29 July 2020 15:55 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E83A0BDF for <extra@ietfa.amsl.com>; Wed, 29 Jul 2020 08:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56V6Oov-RlnZ for <extra@ietfa.amsl.com>; Wed, 29 Jul 2020 08:55:30 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 33CDD3A0BD8 for <extra@ietf.org>; Wed, 29 Jul 2020 08:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1596038129; d=isode.com; s=june2016; i=@isode.com; 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 [192.168.1.216] (host31-49-142-53.range31-49.btcentralplus.com [31.49.142.53]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <XyGb8AAFT2Tv@statler.isode.com>; Wed, 29 Jul 2020 16:55:29 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Stephan Bosch <stephan.bosch=40open-xchange.com@dmarc.ietf.org>, extra@ietf.org
References: <159238763595.1803.574245566610096074@ietfa.amsl.com> <b4390473-241f-6860-2ebb-fdf4dad06ec8@isode.com> <a7304716-b160-4731-e145-934cb127d28e@open-xchange.com> <b908d009-5ee4-9caa-63ea-23788a270188@open-xchange.com>
Message-ID: <de1f23c9-5516-91d7-039e-9354ce73ffea@isode.com>
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: <b908d009-5ee4-9caa-63ea-23788a270188@open-xchange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/1rQRZZ8ldLo37RypeVr83DO_K7k>
Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-15.txt
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=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, internet-drafts@ietf.org wrote:
>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-15
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-15
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-15
>>>
>>> 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 5.1.2.1 does 
>> part of this, so that could at least be referred from here.
Done
>> 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?

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

  [snip]

>> section-6.3.9.2:
>>
>>                                                            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-6.3.9.5:
>>
>>    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.


  [snip]

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


  [snip]

>> 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
Added
>>
>> 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,

Alexey