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

[Stephan Bosch <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra

-- 
Stephan Bosch
Senior Developer

Phone: [phone]  Fax: [phone]
Email: [e-mail]
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)

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