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

[Roman Danyliw <[e-mail]>]

Hi Alexey!

Thanks for the quick turn around with all of the edits and the few places where you explained that a changed isn't appropriate.  A bit more inline ...

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Alexey Melnikov
> Sent: Tuesday, February 2, 2021 12:08 PM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-extra-
> [e-mail]; [e-mail]
> Subject: Re: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-
> imap4rev2-26: (with COMMENT)
> 
> 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.

Thanks.

> > ** 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?

I hadn't actually checked RFC3503.  If that's in there, no need to repeat here.

> > ** 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".

Ok.

> > ** 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.

Ok.

>   [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.

Thanks for all of the above changes.

Regards,
Roman

> Best Regards,
> 
> Alexey
>