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

Bron Gondwana <brong@fastmailteam.com> Wed, 08 July 2020 12:59 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 511E33A0AF8 for <extra@ietfa.amsl.com>; Wed, 8 Jul 2020 05:59:05 -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_H4=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=2KZHx74A; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QP03GcqX
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 F_YqKsYRZpoK for <extra@ietfa.amsl.com>; Wed, 8 Jul 2020 05:59:00 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B7D3A0A85 for <extra@ietf.org>; Wed, 8 Jul 2020 05:59:00 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8226AC41 for <extra@ietf.org>; Wed, 8 Jul 2020 08:58:59 -0400 (EDT)
Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Wed, 08 Jul 2020 08:58:59 -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=fm3; bh=5HPUwTH gTVh+P34WqXWkJqIr9ErgZdSR0R6Ip2kECT4=; b=2KZHx74AQZ1B+dFMDOnp7dd yhWWc7AOCMx5Cq2Q5uDTqWItLSh/HKreYjuYOWckaIc4RPoEwKjCwsZBVRxdaMPg COeZ7d1wmlNKpaRpgmco2Q7Je79n9xeKH1O53VdXE7C7OgVhKowKW3GlOjb1i5gM QpblwRFN5VzMseutznhOAq2J/C84vgnH6l1hSz8Eg3Ax6d+3iduFshoXHoOQov4N OZGV/LQefwSkG6xbEgyuIzTEoL781WmRE8In8P7Nbc5iAFnJpj52596xZtpbNAzp CznYoouMTm3sOi5Im5jk8Ky/+seLdumTTbT8OtvPg3+2ITIQWBlZOHzIkVd/v6A= =
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=fm3; bh=5HPUwT HgTVh+P34WqXWkJqIr9ErgZdSR0R6Ip2kECT4=; b=QP03GcqXczdXnOiicVTr18 vjy+VpIcBtQY9Qt0nkhRSk7I6RC1PT4CR6DTn/Y5YdAUWEnmbsREjZzCfkGsGg7m AT/2mmz/CltJnkSsc7ZIcFA5x2mv1QESia97O3Qwk7prqHoYENccDRAbI+ujDKiX 4umV4MYjQqMIfEydze+j+BwD6+1Xyn7HBfrrSZiK4f74P6RvtFLWP3A21YlBJftL HvUTdjrPAUgtT3EQgBIFjEHSVIG8qToWpOa8iHNX7jUPfR+nPo31germTiLyfva0 JPlf1yK9SeyZSM18tuCRHXGbKMumJnD40dKgBlO698sY1tKi9TxFK4HB5DO0vGJw ==
X-ME-Sender: <xms:E8MFX1XKjp4nluwlv6AP3eqXR-NlDj9vQS0LqAGggPMTfe3vIOlduw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdehlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepffevfeeigfejve etheehleegteelteevgeeutdfhhefghfdtjefhvdehhfdtkefgnecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:E8MFX1mg5lCZtBo8HDAQO05Zjn6GfQoXLToh_K0fQj5p5XNuJagzCg> <xmx:E8MFXxaUrp2SkTa34NF_lb6hQMwlIqSaogPhkPZoRqJ8XQCQi4G4Eg> <xmx:E8MFX4U9jNmzlRT6A1PAbChp17IAds7lPZ4TrmKBa0MfgkG8dnECXw> <xmx:E8MFX5kbLe4XEGl2f9LhRtSiK9ze3WgMzGi8fTXjcVCX-SdKxR4Cug>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D6F854AA005D; Wed, 8 Jul 2020 08:58:58 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-623-g16e0e99-fm-idx2020-20200708.001-g16e0e99e
Mime-Version: 1.0
Message-Id: <3da1a65d-4825-426a-8b6d-70f0e923310e@dogfood.fastmail.com>
In-Reply-To: <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com>
References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <cf5e3b1d-29fd-2b58-a2a8-6ade6d7ac307@isode.com> <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com>
Date: Wed, 08 Jul 2020 22:58:38 +1000
From: "Bron Gondwana" <brong@fastmailteam.com>
To: extra@ietf.org
Content-Type: multipart/alternative; boundary=5bcae40328e94799b81f2a007e0916fe
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/eavBHf5dc4a129-Md_aHlBgq4iw>
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: Wed, 08 Jul 2020 12:59:12 -0000

I have reviewed all the changes from -12 to -15 and am still mostly happy :) I haven't reviewed -15 in full because it's a big job!

Regarding the changes in -13, I have a couple of small things:

*Regarding unsolicited fetch:**
*

If the server chooses to send unsolicited FETCH responses, they MUST include UID FETCH item. Note that this is a new requirement when compared to RFC 3501.

This could do with a clarification that this only applies after "ENABLED IMAP4REV2".

*Regarding SELECT allowing non-canonical names:**
*

We've already discussed the list response to CREATE. Should SELECT also return the canonical representation of the mailbox name as part of the reply?

*Next steps:**
*

Alexey - are there any other changes still waiting before we do a working group last call?

Thanks,

Bron.

On Fri, Feb 14, 2020, at 10:47, Bron Gondwana wrote:
> Thanks Alexey, I see there's a -12 there now, and I'm happy with all the edits in it :)
> 
> There are still some outstanding points from this thread - are you expecting to issue a -13 for those?
> 
> Thanks,
> 
> Bron.
> 
> On Sat, Feb 8, 2020, at 04:04, Alexey Melnikov wrote:
>> Hi Bron, 

>> Replying to issues raised not covered by my reply to Timo:

>> On 29/01/2020 12:08, Bron Gondwana wrote:
>>> Sorry about the delay in doing this! I was supposed to be doing the shepherding write-up, and so I figured I should read it properly.
>>> 
>>> I've had a full read through over some very many days (I admit, I skimmed through the ABNF) and I have comments. It's long, and hopefully comprehensive - though I'm sure I missed things.
>>> 
>>> 
>>> *2.1 Link level*
>>> 
>>> Is it appropriate to mention TLS on 993 here? It's mentioned deep within the document, but not here.
>> Done.
>> 
>>> *2.3.2 Flags Message Attribute*
>>> 
>>> formatting issue: $Forwarded is duplicated 3 times and $MDNSent is duplicated twice in the plain-text format.
>> This is actually a bug in TXT rendering from XML.

>>  [snip]

>>> *6.3.1 ENABLE command*
>>> 
>>> The example shows a conversation with an imap4rev1 only server.
>> Fixed.
>> 
>>> The examples don't clearly show that only the newly enabled responses are correct, e.g. the sequence:
>>> 
>>> C1 ENABLE CONDSTORE
>>> * ENABLED CONDSTORE
>>> C1 OK foo
>>> C2 ENABLE CONDSTORE QRESYNC
>>> * ENABLED QRESYNC
>>> C2 OK foo
>>> 
>>> The second doesn't say "ENABLED CONDSTORE" because it was already enabled earlier on this connection.
>> Actually, it is perfectly Ok for the server to return in response to C2:

>> * ENABLED QRESYNC CONDSTORE
>> 
>> The text in the document wasn't entirely clear. It was trying to say that the preferred server behaviour is:
>> 
>> L1 ENABLE A B
>> * ENABLED A B
>> L1 OK foo
>> 
>> L2 ENABLE C
>> * ENABLED C
>> L2 OK foo
>> 
>> and not 
>> 
>> L2 ENABLE C
>> * ENABLED A B C
>> L2 OK foo
>> 
>> I clarified this.
>>> 
>>> (AKA: clients MUST remember what they have enabled)
>>> 
>>> *6.3.2 SELECT command*
>>> 
>>> The [UIDNEXT <n>] response is duplicated with two different pieces of text.
>> Again, this is a tool issue.
>> 
>>> *When deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox *is closed (see Paragraph 10). ***- I'm not sure where "Paragraph 10" is.*
>> I will check. I think the section reference for response codes is missing.
>> 
>>> The last paragraph of this section has the word "deprecated" spelled as "depractated".
>> Fixed.
>> 
>>> 
>>> *6.3.7 SUBSCRIBE*
>>> 
>>> Speak of the devil. Lots of sites violate the MUST NOT unilaterally remove rule. Should we weaken it to SHOULD?
>> Done.
>> 
>>>  The justification for the MUST is "the server site might choose to do X" - well, if the server site is doing that, then maybe they SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a better user experience and what people want.
>>> 
>>> (also: by enabling a non-default break the rules config, it's what our server does!)
>>> 
>>> *6.3.8 UNSUBSCRIBE*
>>> 
>>> *This command returns a tagged OK response only if the unsubscription is successful. *- this is not clear on what happens if the mailbox is not currently subscribed - does it silently succeed, or is there an expected error?
>>> 
>>> For what it's worth, our server just says "OK Completed" even if it's already been unsubscrbed - and likewise for subscribe if it's already subscribed it just say "yep, all good".
>> I agree that your server behaviour is sensible. Updated description of both SUBSCRIBE and UNSUBSCRIBE.
>> 
>>> 
>>> . create INBOX.foo
>>> . OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed
>>> . subscribe INBOX.foo
>>> . OK Completed
>>> . unsubscribe INBOX.foo
>>> . OK Completed
>>> . unsubscribe INBOX.foo
>>> . OK Completed
>>> . subscribe INBOX.foo
>>> . OK Completed
>>> . subscribe INBOX.foo
>>> . OK Completed
>>> 
>>> 
>>> *6.3.9 LIST*
>>> 
>>> There's a weird line wrapping near the top of page 44 where a paragraph is split in half:
>>> 
>>>    The reference and mailbox name arguments are interpreted into a
   canonical form that represents an unambiguous left-to-right
   hierarchy.  The returned mailbox names will be in the interpreted
   form,

   that we call "canonical LIST pattern" later in this document.  To
   define the term "canonical LIST pattern" formally: it refers to the
   canonical pattern constructed internally by the server from the
   reference and mailbox name arguments.
>>> 
>> I will double check, but I think it is another rendering issue to TXT format (there is a comment in bettween 2 parts of the sentence.
>> 
>>> 
>>> *6.3.9.2 LIST Return Options*
>>> 
>>> The CHILDREN item is duplicated with two different pieces of text.
>> Again, a rendering issue. These are actually 2 separate paragraphs under the same item.

>> 
>>> *6.4.4 SEARCH*
>>> 
>>>    For example,
   the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
   deleted messages from Smith that were placed in the mailbox since
   February 1, 1994.
>>> 
>>> 
>>> That's not strictly true - SAVEDATE would be "placed in the mailbox". The wording should say "with INTERNALDATE greater than February 1, 1994" or so.
>> Good point. Fixed.

>> 
>>> *6.4.4.1 SAVE Result*
>>> 
>>> I'm not sure I understand the interaction here with closing and re-opening a mailbox. I would expect that closing a mailbox would wipe the SAVED result, and that trying to use a SAVED result when there isn't one should return an error.
>> I think Timo explained this well in his response.
>> 
>> 
>>  [snip]

>>> 
>>> *7.1 Status Responses*
>>> 
>>> Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks like an attempt to do dot points!
>> Changed :-).
>> 
>>  [snip]

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

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