Re: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-imap4rev2-26: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Roman,

Thank you for your comments. Replying to most of your comments (I will 
reply to the rest separately):

On 02/02/2021 15:15, Roman Danyliw via Datatracker wrote:
> ** Section 1.3.  What are the “unpublished IMAP2bis protocols”?  Even if there
> were unpublished, is there any pointer/reference that can be provided, say like
> https://tools.ietf.org/html/draft-ietf-imap-imap2bis-02?
Yes, this looks like a reasonable informative reference.
> ** Section 2.3.1.1.  Step #4.  Should “In particular, the internal date,
> [RFC-5322] size, envelope, body structure, and message texts (all BODY[...]
> fetch data items) must never change)”, use the normative “MUST never change”?
Sure.
> ** Section 2.3.3.  The text for $Forwarded notes that “Once set, the flag
> SHOULD NOT be cleared.”  Should the same guidance apply to $MDNSent?
$MDNSet description points to RFC 3503, which states "MUST NOT be 
cleared". I would rather not copy the text into this draft, if that is 
Ok with you?
> ** Section 5.1.2.  Editorial.  s/manager to grant to their secretary access
> rights/manager to grant to their administrative support staff access rights/
Ok.
> ** Section 6.3.1.  Per “However, servers cannot send those unsolicited
> responses (with the exception of response codes (see Section 7.1) included in
> tagged or untagged OK/NO/BAD responses, which can always be sent) until they
> know that the clients support such extensions and thus won't choke on the
> extension response data”, what is the more precise definition of “choke” here.
> Is it that the client doesn’t understand the extension or that it won’t be able
> to process it?
The former. I think it was intended as a shortcut for "crash and 
misbehave in other surprising ways".
> ** Section 6.3.9.3.  Step 3.  Per “Attributes returned in the same LIST
> response must be treated additively”, should this be a normative “MUST”?
I think MUST is going to be a bit silly here, as the whole set is 
specified in a single LIST response. I will change this to "are treated 
additively".
> ** Section 6.3.12 and Section 8.  The examples here have a few “non example”
> domains (e.g., @Blurdybloop.com, @owatagu.siam.edu, @cac.washington.edu)
Yes, this comes from RFC 3501. I can change these if this is a big deal 
to people, but this will cause literal size changes in various places, 
so this is more work than just search & replace everywhere in the document.
> ** Section 6.4.4.4.  Editorial.  In this section the inline annotation of the
> C: and S: examples are with a “//”.  In Section 6.3.10, these annotations are
> made via “< … >”.  I’d recommend consistency.

Ok. Murray has pointed out the same thing. I will discuss with RFC 
Editor about the best way of representing comments.

  [snip]

> ** Section 7.1.4.  Per “For this reason PREAUTH response SHOULD only be
> returned by servers on connections that are protected by TLS (such as on
> implicit TLS port [RFC8314]) or protected through other means such as IPSec”,
> what is the corner case in mind that motives a SHOULD (instead of a MUST)?
I was thinking about loopback interface or something like Unix domain 
socket (the latter is technically out of scope for this document).
> ** Section 11.  There are both confidentiality and integrity issues with
> sending of IMAP in the clear.
>
> OLD
> IMAP4rev2 protocol transactions, including electronic mail data, are
> sent in the clear over the network unless protection from snooping is
> negotiated.
>
> NEW
> IMAP4rev2 protocol transactions, including electronic mail data, are sent in
> the clear over the network exposing them to possible eavesdropping and
> manipulation unless protections are negotiated.
I used your text, thank you.
> ** Section 11.1.  Per “Other TLS cipher suites recommended in RFC 7525 are
> RECOMMENDED …”, seems as if RFC7525 needs to be an explicit reference.

Good point. Added.

  [snip]

> ** In the spirit of inclusive language, consider something like the following:
>
> -- Section 6.2.1.  s/to protect against man-in-the-middle attackers which
> alter/to protect against an on-path attacker which could alter/
>
> -- Section 11.1
> OLD
> … as presented in the server Certificate message, in order to prevent
> man-in-the-middle attacks.
>
> NEW
> … as presented in the server Certificate message, in order to prevent on-path
> attackers attempting to masquerade as the server.
Changed, thank you.
> -- Section 11.3.  s/(or a man-in-the-middle attacker)/ (or an on-path attacker)/
Changed.
> ** Typos:
> -- Section 11.2. s/overriden/overridden/
Fixed, thanks.
> ** From idnits:
>    -- The draft header indicates that this document obsoletes RFC3501, but the
>       abstract doesn't seem to mention this, which it should.
>
>    -- There are a number of reference warnings which should be confirmed as not
>    being problematic (not mentioned in the shepherd write-up)

Will do. I think all of them were covered by the IETF LC announcement, 
but I will double check.

Best Regards,

Alexey