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

[Alexey Melnikov <[e-mail]>]

Hi Éric,

Thank you for your review. Comments below.

On 01/02/2021 15:23, Éric Vyncke via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. Collecting and aggregating all
> the previous updates is really useful. The numerous examples are really helpful.
>
> I must admit though that "unpublished IMAP2bis protocols" makes me wonder why
> it is mentioned if not public...
It was popular at the time and I believe there was a draft at some 
point. This actually predates my participation in IETF.
>   Also, "network connection" is kind of weird
> for an Internet based on connectionless IP layer... ;-)
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated), and some nits.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> -- Section 2.3.2 --
> Why two flags associated to "junk" but only one for "phishing" ?
> -- Section 8 --
> This example uses LOGIN method that is not recommended on plain text connection
> (see 6.2.3). Perhaps worth saying that this example works over implicit TLS or
> better use a AUTH method?
Yes, good idea. Apparently nobody looks at this except for IESG ;-).
> == NITS ==
>
> -- Section 4.3 --
> "synchonizing literal" ?
Fixed, thank you :-).
> -- Section 6.3.12 --
> The example contains "Content-Type: TEXT/PLAIN; CHARSET=US-ASCII" while in most
> email headers that I have seen, the value is in lowercase... May I assume that
> case is *not* relevant (because not part of the email message but part of IMAP)
> ? If so, this value reads lie SHOUTING to me ;-)

This is defined in RFC 2045, which defines Content-Type header field 
syntax. Basically, all three: the media type ("TEXT/PLAIN"), parameter 
name ("CHARSET") and charset parameter value ("US-ASCII") are all 
defined to be case insensitive.

So no, this has nothing to do with IMAP.

As an editor, I do like to pick some examples demonstrating 
case-insensitivity and other unusual conditions.

> -- Section 6.4.4 --
> The example dates are in 1994... perhaps worth updating ?  ;-) Other examples
> are in 2006

This is a revision of RFC 3501, which is a revision of RFC 2060, etc.

We could update examples, but they are still valid. Changes would most 
likely affect day-of-the-week, which might in turn change literal 
sizes... So changes can introduce new bugs.

Best Regards,

Alexey