Subject: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap4rev2-26: (with COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Tue, 02 Feb 2021 09:53:54 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-extra-imap4rev2-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for taking this on.

(1) Section 6.3.9 says:

"The LIST command SHOULD return its data quickly, without undue delay.
   For example, it SHOULD NOT go to excess trouble to calculate the
   \Marked or \Unmarked status or perform other processing"

The second sentence seems like it does not warrant normative language given
that it is giving an example (and what does it mean for a command to measure
whether trouble is excessive anyway?).

(2) There are some recurring example names -- owatagusiam, blurdybloop, etc. --
that could probably be replaced with names that are a little more
accessible/obvious to new readers. Also, there are a lot of examples with user
names from the same cultural/linguistic context -- smith, fred, eric, etc.
Neutralizing or diversifying those names would improve the document.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Feb 2021 13:12:51 -0500

> that it is giving an example

Indeed; this slipped through from the original.  I agree that we don't
need the same BCP 14 statement twice.

> Neutralizing or diversifying those names would improve the document.

This harks back to older times and to the late Mark Crispin, who liked
those sorts of things.

I agree with you.

That said, there are two things:

1. As Alexey has pointed out with other comments, changing these often
involves carefully checking literal lengths, RFC822-SIZE values, and
other such, and has a high potential to introduce errors.

2. I have some thought toward keeping Mark's voice in here, and that
mostly shows up in the examples.  Part of me would rather not scrub it
out.

Alexey, thoughts?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 2 Feb 2021 18:33:09 +0000

> need the same BCP 14 statement twice.
Right. I will fix.
> mostly shows up in the examples.  Part of me would rather not scrub it

Yes, I thought of #2 as well.

Happy to go with IESG consensus on this.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Feb 2021 10:21:16 -0500

Hi Barry,

> On Feb 2, 2021, at 1:12 PM, Barry Leiba <[email-masked]> wrote:
> 
>> (1) Section 6.3.9 says:
>> 

The point of raising it in the first place was about perpetuating the biases of the earlier documents/authors. The base RFCs will remain in the archive for people to read.

Alissa

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Feb 2021 10:32:03 -0500

> The point of raising it in the first place was about perpetuating the biases of the earlier documents/authors.
> The base RFCs will remain in the archive for people to read.

Yes, true, and that takes care of point 2.  You're right.

Do you think it's worth the risk of introducing errors (point 1)?

Barry

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Feb 2021 12:02:23 -0500

> On Feb 4, 2021, at 10:32 AM, Barry Leiba <[email-masked]> wrote:
> 

I’m not sure I understand it well enough. If you substitute values that are the same length in characters as the old values, is this still a problem? I.e., if you padded examples with numbers ("example123456”) or something along those lines, does that help?

Thanks,
Alissa

---

From: Barry Leiba <[email-masked]>
Date: Thu, 4 Feb 2021 12:38:06 -0500

> I’m not sure I understand it well enough. If you substitute values that are the same length in
> characters as the old values, is this still a problem? I.e., if you padded examples with numbers
> ("example123456”) or something along those lines, does that help?

That sounds workable; I don't think we have any digital signatures,
which would still break, but I don't think we need to worry about
that.  Let me talk it over with Alexey.

Thanks, Alissa.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Feb 2021 18:19:03 +0000

Hi all,

> that.  Let me talk it over with Alexey.

I changed example domains to end with .example. I think this both 
preserves Mark's original intent and also uses example domains. It 
turned out that there was only one example that needed recalculating 
literal length.

Best Regards,

Alexey