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

From: Stephan Bosch <[email-masked]>
Date: Thu, 16 Jul 2020 14:21:00 +0200

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

-- 
Stephan Bosch
Senior Developer

Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: [email-masked]
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)

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Jul 2020 13:52:39 +0100

Hi Stephan,

> Did you see my review (below) ?

My apologies for missing your review. I will incorporate in -17.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jul 2020 16:55:27 +0100

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.

>> explained briefly or referred elsewhere.
Added a reference.
>> part of this, so that could at least be referred from here.
Done
>> 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?

>> "dualism" or something like that (which I actually find equally 

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]

>> confusion about the contraction that seems to exist between the 
Done, thanks.
>> acknowledged in Appendix E.
You are right, this is unusual. I moved this text to the Appendix E.
>> -> What is this? And this sentence is incomplete (no article at the 
There was a language extension to NAMESPACE response, but it is not 
specified in this document. I clarified.

  [snip]

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

>> -> What about RFC 3501?
Good point. Added.
>>    discussing the AUTHENTICATE and LOGIN commands.
Added
>> -> 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