Re: [Extra] Alissa Cooper's No Objection on draft-ietf-extra-imap4rev2-26: (with COMMENT)
Alexey Melnikov <alexey.melnikov@isode.com> Tue, 02 February 2021 18:33 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 6991B3A0D76;
Tue, 2 Feb 2021 10:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fw0EayVRAWOY; Tue, 2 Feb 2021 10:33:12 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188])
by ietfa.amsl.com (Postfix) with ESMTP id 1C13E3A0D82;
Tue, 2 Feb 2021 10:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1612290790;
d=isode.com; s=june2016; i=@isode.com;
bh=q1siqX+xaO7O3ST5DwfBpvoWPP6NnmvR7rEDgHobTLI=;
h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:
In-Reply-To:References:Content-Type:Content-Transfer-Encoding:
Content-ID:Content-Description;
b=fFpK4CTLl+BhMBlXj/GFjBzPXggddIpWW/Z2eROsMrlawh+qlpBzXNd7hcecqr1vWX8zTD
6K1LqlkS3gtW8OD0K6YDlEF8pD+3W2Nveu1W5utkkTb03GrQDT2J86ULuBhVGpjwUppSl+
FAdxoFFgr8Ml1YnN//Kat41/WxgDOaE=;
Received: from [192.168.1.222] (host5-81-100-50.range5-81.btcentralplus.com
[5.81.100.50])
by waldorf.isode.com (submission channel) via TCP with ESMTPSA
id <YBma5gAuQRm1@waldorf.isode.com>; Tue, 2 Feb 2021 18:33:10 +0000
To: Barry Leiba <barryleiba@computer.org>, Alissa Cooper <alissa@cooperw.in>
Cc: The IESG <iesg@ietf.org>, draft-ietf-extra-imap4rev2@ietf.org,
extra-chairs@ietf.org, extra@ietf.org,
Bron Gondwana <brong@fastmailteam.com>
References: <161228843386.9750.10522178607825201429@ietfa.amsl.com>
<CALaySJJqMMR4er0Qz+pccOEKe0+F+ABiBSijifOyc3dK7ZqvhA@mail.gmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <7735f3bc-48d8-dddb-2f97-da889b5f1a9a@isode.com>
Date: Tue, 2 Feb 2021 18:33:09 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0)
Gecko/20100101 Thunderbird/78.7.0
In-Reply-To: <CALaySJJqMMR4er0Qz+pccOEKe0+F+ABiBSijifOyc3dK7ZqvhA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/_JH2PMlkXykfl2J6piulEr2lw5A>
Subject: Re: [Extra] Alissa Cooper's No Objection on
draft-ietf-extra-imap4rev2-26: (with COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>,
<mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>,
<mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2021 18:33:14 -0000
On 02/02/2021 18:12, Barry Leiba wrote: >> (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 > Indeed; this slipped through from the original. I agree that we don't > need the same BCP 14 statement twice. Right. I will fix. >> (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. > 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. Yes, I thought of #2 as well. Happy to go with IESG consensus on this. > Alexey, thoughts? > > Barry
- [Extra] Alissa Cooper's No Objection on draft-iet… Alissa Cooper via Datatracker
- Re: [Extra] Alissa Cooper's No Objection on draft… Barry Leiba
- Re: [Extra] Alissa Cooper's No Objection on draft… Alexey Melnikov
- Re: [Extra] Alissa Cooper's No Objection on draft… Alissa Cooper
- Re: [Extra] Alissa Cooper's No Objection on draft… Barry Leiba
- Re: [Extra] Alissa Cooper's No Objection on draft… Alissa Cooper
- Re: [Extra] Alissa Cooper's No Objection on draft… Barry Leiba
- Re: [Extra] Alissa Cooper's No Objection on draft… Alexey Melnikov