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

[Stephan Bosch <[e-mail]>]

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