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

Stephan Bosch <stephan.bosch@open-xchange.com> Thu, 16 July 2020 12:23 UTC

Return-Path: <stephan.bosch@open-xchange.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 60E183A07D4 for <extra@ietfa.amsl.com>; Thu, 16 Jul 2020 05:23:37 -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 (2048-bit key) header.d=open-xchange.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 sFFt8YuL1jEg for <extra@ietfa.amsl.com>; Thu, 16 Jul 2020 05:23:35 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC1F3A07D7 for <extra@ietf.org>; Thu, 16 Jul 2020 05:23:34 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id D27F96A311; Thu, 16 Jul 2020 14:23:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1594902211; bh=HgL0eOE0gc+FFCbDaET/OdHRhsLy29Q358r7hIm1utw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=24++Nvo4NvpAdaE4fta5+UggGNEO/BHSKGA6RthJMgRX/Z3EspXmU6X01HBVd7Z17 ijIGzecAreipPwGoaEz/wkbmumHuZ471Opec0XQuoEa6zZ0lLr6wpxznNyf48FoK2i SR/F6/h0Hhm0h4bLmrclweoCGswH865suMP1RLI8RcSgAP4E4ZKASjeme/YSqbyqWg rc8oVQJrEYBxkDxg/Srdz9CN0lBTui25gu62DPXjU4v0KU6YByo7eckAFIu3GnGOtw Kpl/5YMt7iCU8KD4Jj1yWmXmDfaz+MEdXf/0xmnXXGhlqXmDSrjdBZj1T6SZAvX1oz dqFyKRwsscr8w==
Received: from [192.168.1.112] (lab.inertia-technology.com [217.119.239.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id B83753C0379; Thu, 16 Jul 2020 14:23:31 +0200 (CEST)
To: Alexey Melnikov <alexey.melnikov@isode.com>, 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>
From: Stephan Bosch <stephan.bosch@open-xchange.com>
Message-ID: <b908d009-5ee4-9caa-63ea-23788a270188@open-xchange.com>
Date: Thu, 16 Jul 2020 14:21:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <a7304716-b160-4731-e145-934cb127d28e@open-xchange.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/ASS5QgvVTTA188QSaMvIbygQhig>
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: Thu, 16 Jul 2020 12:23:37 -0000

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.
>
> 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.
>
> 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.
>
>    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)?
>
> -> The SPECIAL-USE extension, which adds selection and return options, 
> is not mentioned here, while the specification envelops it.
>
> 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.
>
> 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.
>
>    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).
>
> section-6.3.12:
>
>    On successful completion of an APPEND, the server SHOULD return an
>    APPENDUID response code.
> -> This response code is not explained at this port. Provide brief 
> purpose or reference to where it is explained.
>
>    In the case of a mailbox that has UIDNOTSTICKY status (see
>    UIDNOTSTICKY response code definition)
> -> See where? Needs reference.
>
> section-6.4.5:
>
> -> Now that the BINARY fetch items are also part of the specification, 
> the "<section>" bit should probably be described separately before the 
> enumeration of fetch data items. Stuffing it in the description of 
> BODY is confusing, as it applies to several fetch items now.
>
>    BODYSTRUCTURE  The [MIME-IMB] body structure of the message. This is
>       computed by the server by parsing the [MIME-IMB] header fields in
>       the [RFC-5322] header and [MIME-IMB] headers.
>
>    ENVELOPE  The envelope structure of the message.  This is computed by
>       the server by parsing the [RFC-5322] header into the component
>       parts, defaulting various fields as necessary.
> -> At least these two could use a forward reference to the FETCH 
> response section, where the semantics of these are described in more 
> detail. Could also put a single reference in the sentence announcing 
> the list of data items.
>
> section-6.4.7:
>
>    On successful completion of a COPY, the server SHOULD return a
>    COPYUID response code.
> -> This response code is not explained at this point. Provide brief 
> purpose or reference to where it is explained (weirdly, section on 
> MOVE does this correctly).
>
>    In the case of a mailbox that has UIDNOTSTICKY status (see the
>    UIDNOTSTICKY response code), the server MAY omit the COPYUID response
>    code as it is not meaningful.
> -> See where? Needs reference.
>
> 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.
>
> section-7.4.2:
>
>             Note: [RFC-5322] requires that all messages have a valid
>             Date header.  Therefore, the date member in the envelope can
>             not be NIL or the empty string.
> -> We all like to live in a perfect world, but what should the server 
> do if the sender is naughty and the message has no Date header? Return 
> the internal date instead?
>
>         Note: [RFC-5322] requires that the In-Reply-To and Message-
>             ID headers, if present, have non-empty content. Therefore,
>             the in-reply-to and message-id members in the envelope can
>             not be the empty string.
> -> Same...
>
>             Note: [RFC-5322] requires that all messages have a valid
>             From header.  Therefore, the from, sender, and reply-to
>             members in the envelope can not be NIL.
> -> Same...
>
> section-10:
>
> -> What about RFC 3501?
>
> 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.
>
> General comments:
>
> -> This document should probably mention at the appropriate locations 
> pre-existing and often-implemented extensions that significantly 
> improve upon the base IMAP4rev1/2 protocol. So, for example, the 
> section describing IDLE could mention the NOTIFY capability.
> -> Enumerations of options/flags/items/identifiers are often strangely 
> formatted. Compare e.g. the search key descriptions in 
> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-15#section-6.4.4 
> to the old  https://tools.ietf.org/html/rfc3501#section-6.4.4
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra

-- 
Stephan Bosch
Senior Developer

Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: stephan.bosch@open-xchange.com
Direct Chat: https://chat.open-xchange.com/direct/stephan.bosch

-------------------------------------------------------------------------------------
Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court Cologne HRB 95366
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin
Chairman of the Board: Richard Seibt
    
Open-Xchange Oy, Lars Sonckin Kaari 12, 02600 Espoo, Finland
Managing Director: Carsten Dirks
Board: Michael Knapstein (Chairman) and Timo Sirainen (board member)

    
-------------------------------------------------------------------------------------