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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 09 July 2020 10:34 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 528DA3A0829 for <extra@ietfa.amsl.com>; Thu, 9 Jul 2020 03:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 VxMByFSdKhyh for <extra@ietfa.amsl.com>; Thu, 9 Jul 2020 03:34:09 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 827B13A082B for <extra@ietf.org>; Thu, 9 Jul 2020 03:34:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594290848; d=isode.com; s=june2016; i=@isode.com; bh=8uPEN+mZ5lax+kFyHEG5kk4TDQYnX/MvMgf7OOsSoqY=; 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=Jn2sa9qWO8JEUCx5oecNpCPnsCG6+2kUdmhmXcbskqSq7colRFQPPYFOnFChTPplv6d1nD pSP4lxk4UgVgVWZd3o6/MeeM+OvkK/fHoTXzHUDFGf25uwmXGuzwn1kLQGFHSjJvMdTSFM lwUu+adnMSFacuY/1GBodnyJT1foNt8=;
Received: from [172.27.254.202] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <XwbynwAFT8JV@statler.isode.com>; Thu, 9 Jul 2020 11:34:08 +0100
To: Bron Gondwana <brong@fastmailteam.com>, extra@ietf.org
References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <cf5e3b1d-29fd-2b58-a2a8-6ade6d7ac307@isode.com> <345e934f-e540-4b42-bd5e-8c1e1f6965f8@www.fastmail.com> <3da1a65d-4825-426a-8b6d-70f0e923310e@dogfood.fastmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <bff6bdb1-2a36-ec54-602a-41f7206b34dc@isode.com>
Date: Thu, 9 Jul 2020 11:33:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
In-Reply-To: <3da1a65d-4825-426a-8b6d-70f0e923310e@dogfood.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------453512003D9B53847427F364"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/fNM6DXBk8-4nMB07t_UfPRRonkg>
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: Thu, 09 Jul 2020 10:34:12 -0000

Hi Bron,

On 08/07/2020 13:58, Bron Gondwana wrote:
> 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".

Actually, in this one case: I don't think so. It shouldn't break any old 
(IMAP4rev1 only) clients to return this.

But this made me think: Maybe the document needs a new section that list 
everything that the server should do 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?

This will be again returning an untagged LIST response on SELECT.

I will add it to my to do list.

>
> *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
>
>
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra