Re: [Extra] Review: draft-ietf-extra-imap4rev2-11

Bron Gondwana <brong@fastmailteam.com> Mon, 09 March 2020 15:44 UTC

Return-Path: <brong@fastmailteam.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 0AD253A1337 for <extra@ietfa.amsl.com>; Mon, 9 Mar 2020 08:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=LvLGZfXh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yIZpUYLp
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 dU17VOKHuujy for <extra@ietfa.amsl.com>; Mon, 9 Mar 2020 08:44:53 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8873A1336 for <extra@ietf.org>; Mon, 9 Mar 2020 08:44:53 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 94EC2220D5 for <extra@ietf.org>; Mon, 9 Mar 2020 11:44:52 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 09 Mar 2020 11:44:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=x0VEQF6 lQC6qfvFVGmhpj9i1m1PsrcNni/LZB/Bw11I=; b=LvLGZfXhkeLtnANMi1Ie9nr 7f3GA7gt2JGM8G0Lxro8Gk2YKV23f8LSpvElZUjc7rJPaXr4yE4iUfTqGbVE0Ct/ 5ZKEBHd5W2blW2R9D1rzGG5xnUZMHhxIld/K93sKTCDHQlqqfoXGm9PVHQZG4Br5 bqNzvVqSyq6MLB5TBoCRuKd7l57HQrpwkQbQKC+TzfjZg2m+wq9nrCV4b7ZeLBVS m0B6+/xLzBaPMC4J2Jqte9uzMJA4q/fCZ3etIeCuua6SbG2mNCU/02mno2rFJbO8 FeYxbYRrj5i+QBKf9JzezZB4l6gHpRa+Opopg8YTGOxiHWJztHGajL19xNQ7E8Q= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=x0VEQF 6lQC6qfvFVGmhpj9i1m1PsrcNni/LZB/Bw11I=; b=yIZpUYLpcUx6SIu/ObnQOK +dZgcl6j5OUsN3LBf6BaZMjCUWKSstaXNH1ewIEtLfCG8m56iFWUvBfQwzujZWfq +oE/ZHFP0L+6xN2qSdQKNaBW+3J4RFq2M/1m3aALdWi4wNs1851ZnWue3nNUTTOz Dt4bN+EQU6p8XrS7cijIZQhBvBP/OTueCnftp+DF2mx4RSNwchaXfwlvTJlwGhgv UjqktV9H9a1w/qPv7fkbkWNBl/TVRF3a2zNgYx7pyJKzqPZUWNt7FvRYtIF4AbU4 qkRjgguTK6S+uvEuSW7PrZwTHajZpTOYlel7HtBfR9udhyV0E3J2qXhep9OS5MuQ ==
X-ME-Sender: <xms:dGRmXn7vgYE9dr1mxR1-MxJUvdHT2O4UGIJqxxFipGI3fk_I47LK6g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddukedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgrnhgrrdhorhhgpd hivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:dGRmXqi3WwrJu0zg5EZlQIyK47Db3N7H-O_7KlnCK5PAdWa1tZEzzA> <xmx:dGRmXkDoZCZYiQm6A-fb4wfEPCfZ4aikpvWKB6hAI2HN3klixV20bw> <xmx:dGRmXrx2fVMfQuLQ8PHR4Kot5PgfwTi65hUH-Vz8zqtciyGvgh_rrA> <xmx:dGRmXssQ39lnRXUhIgGvnPVKLa-g1mKo0ill2-SKSkVvlhQNjrN-Pw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 27AC2180091; Mon, 9 Mar 2020 11:44:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3
Mime-Version: 1.0
Message-Id: <af62ac76-db5d-40ef-80bf-7d6d39a77bb6@www.fastmail.com>
In-Reply-To: <d1aed0d2-eb18-bd85-26c9-444c91fb130a@isode.com>
References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <d1aed0d2-eb18-bd85-26c9-444c91fb130a@isode.com>
Date: Mon, 09 Mar 2020 08:44:29 -0700
From: "Bron Gondwana" <brong@fastmailteam.com>
To: extra@ietf.org
Content-Type: multipart/alternative; boundary=19852b6f2db9466ca830f42c84b884be
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/-o0KYl4DZ9aDZ-08tIJesFv-F30>
Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11
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: Mon, 09 Mar 2020 15:45:01 -0000

Thanks Alexey. Am traveling this week but will try to make time to review.

Extra isn't meeting in Vancouver, so we will have to discuss things on the list! Probably good with the number of people not coming anyway.

I'm not so sure that unsolicited UID is common, but then I haven't looked at what other servers do for 10 years or so...

Cheers,

Bron.



On Mon, Mar 9, 2020, at 08:39, Alexey Melnikov wrote:
> Hi Bron,

> I addressed several more comments from you in -13:

> On 29/01/2020 12:08, Bron Gondwana wrote:
>> *2.2.1 Client protocol*
>> **
>> *"A different tag is generated by the client for each command".* There's no "MUST" on this, and certainly I've seen clients which don't. Do we want to make that more strict in rev2? It would be a bit of a pain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness.
>> 
>> Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned")
> I added:


>  (More formally: the client SHOULD generate a unique tag for every command,
>  but a server MUST accept tag reuse.)
> ****

>> 
>> 
>> *2.3.1.1 UID Attribute*
>> **
>> Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly (as seen later in the ABNF) they aren't allowed to be zero. It would be good to say "non-zero" when each is first mentioned, but I don't care strongly about this one.
> Clarified.

>> 
>> 
>> *2.3.2 Flags Message Attribute*
>> 
>> Should this section also reference https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml ?
> Added
> 
>> 
>> 
>> *5.1 Mailbox Naming*
>> 
>> This doesn't solve one of my naming bugbears. The spec says things like *"servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." -*** **there is no clear way to know what the SELECTable name will be after creating a mailbox.
>> 
>> If I was designing this myself from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect. Since we're messing with how mailbox naming works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop.
>> 
>> It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :(
>> 
> I believe I clarified this with the following text:


>  However, servers MAY accept a de-normalized UTF-8
>  mailbox name and convert it to Unicode normalization form "NFC"
>  (as per Net-Unicode requirements) prior to mailbox creation.
>  Servers that choose to accept such de-normalized UTF-8 mailbox
>  names MUST accept them in all IMAP commands that have a mailbox name parameter.
>  In particular SELECT &lt;name&gt; must open the same mailbox that
>  was successfully created with CREATE &lt;name&gt;, even if &lt;name&gt;
>  is a de-normalized UTF-8 mailbox name.

> 
>> 
>> *7.2.3 LIST Response*
>> 
>> This is the interesting bit for SPECIAL-USE - it should reference that here - as well as referencing the registry since it reproduces some of it inline.
>> 
>> https://www.iana.org/assignments/imap-mailbox-name-attributes/imap-mailbox-name-attributes.xhtml
> I've added the IANA registry reference.

> __

>> __
>> __
>> *7.4.2 FETCH Response*
>> 
>> I remember past bugs with UID in "unsolicited" FLAGS responses. Do we need to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)?
> I am border line on this, but I don't think so. This should be common enough that even IMAP4rev1 clients should be able to handle this.

> 

>> 
>> *Appendix C: Changes*
>> 
>> Right now it's still stated as "the planned changes" and there's still some TODO in there (some of which I think could be well handled by referencing the registries rather than replicating them inline).
> I cleaned this up and there are only 2 smaller items remaining, that we might want to discuss in the WG.

> Best Regards,

> Alexey

> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
> 

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 brong@fastmailteam.com