Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 13 July 2020 15:29 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 60F063A135F for <extra@ietfa.amsl.com>; Mon, 13 Jul 2020 08:29:42 -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, MIME_QP_LONG_LINE=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 r_S8CCZDF2UY for <extra@ietfa.amsl.com>; Mon, 13 Jul 2020 08:29:40 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8A3A135C for <extra@ietf.org>; Mon, 13 Jul 2020 08:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594654179; d=isode.com; s=june2016; i=@isode.com; bh=OYd7g+7iN3/kld55HfTilrBRkh5TG0uxknNUJD94wr0=; 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=OIRAhFy2A85YCqmGDhnBiUSCCcpMxPKZ9cyk0/r4dPU/b1fQ1xOFfHU7F8cpcy8S1SKi99 GmM2aCMjjU8CJJWGvXcUZyTj2bJZkpjHnjrzwUq7CCR7lnWxAUBBV4NwbBLuCa5EGjtQ3A rwQ5qD6rj2+RClR8SdP+U2nJ6z4kM68=;
Received: from [192.168.0.2] (0546cbcb.skybroadband.com [5.70.203.203]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <Xwx94wAFT1EI@statler.isode.com>; Mon, 13 Jul 2020 16:29:39 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (16G102)
In-Reply-To: <A95B9D95-D935-4AB6-A11B-9F4C5A850B60@sirainen.com>
Date: Mon, 13 Jul 2020 16:29:38 +0100
Cc: extra@ietf.org, Bron Gondwana <brong@fastmailteam.com>
Message-Id: <DF6A43CD-2441-4BDD-A686-A0C389B230C7@isode.com>
References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com> <872422BE-C8FA-4AA0-8EF1-2ECA79F64926@sirainen.com> <96BAB7A5-420A-49AF-977F-1F722746E5DD@isode.com> <5FAA4D04-F1A8-4E23-B9F2-817EBAFF8021@sirainen.com> <5fe122d9-5313-8be1-199e-075a61d1bb2a@isode.com> <0fd3e8e2-1865-4021-b80c-11c4987b7d64@dogfood.fastmail.com> <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com> <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com> <2fe5352f-f2c5-4e50-b9c4-6da38fbcc4d0@dogfood.fastmail.com> <93c5effc-bf6c-b36b-282f-c334883c2966@isode.com> <178ba905-36d9-493e-a02f-ac1a91f3ae68@dogfood.fastmail.com> <c2e87d73-6a19-9c20-de75-81a98a2e7b2a@isode.com> <A95B9D95-D935-4AB6-A11B-9F4C5A850B60@sirainen.com>
To: Timo Sirainen <timo@sirainen.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=Apple-Mail-1D4EB44A-A898-4188-9DD2-D432CEF21E86
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/4-QXTCLLNMYR8OAu88C6gi8m7xA>
Subject: Re: [Extra] IMAP4rev2: how to signal canonical mailbox name after CREATE
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, 13 Jul 2020 15:29:42 -0000

Hi Timo,

> On 11 Jul 2020, at 09:26, Timo Sirainen <timo@sirainen.com> wrote:
> 
>> On 10. Jul 2020, at 13.47, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
>> 
>>> On 07/07/2020 00:30, Bron Gondwana wrote:
>>>> On Tue, Jul 7, 2020, at 03:38, Alexey Melnikov wrote:
>>>>> On 17/06/2020 13:27, Bron Gondwana wrote:
>>>>> On Wed, Jun 17, 2020, at 22:15, Timo Sirainen wrote:
>>>>>>> 1) abandon use of this response code (and use a new response instead), e.g.
>>>>>>> 
>>>>>>> * CREATED "a123" "Denormalized name" MAILBOXID "123456"
>>>>>>> 
>>>>>>>  This would require clients to ignore an extra response, if they don't recognize it.
>>>>>>> 
>>>>>> 
>>>>>> Somehow I've a feeling that there are going to be clients that will break if they see these kind of unknown untagged replies. But that's just a guess, so maybe not. We could of course send it only when client has used ENABLE IMAP4REV2 and then there wouldn't be any problems.
>>>>> 
>>>>> I like this.  Only send if IMAP4REV2 is enabled and all[tm] your problems go away.
>>>> Following on the suggestion to use LIST extended data items for this
>>>> 
>>>> 
>>>> 
>>>>       C: C04 create NonCannonicalName
>>>>       S: * LIST () "/" "CannonicalName" ("TAG" ("C04"))
>>>>       S: C04 OK done
>>>> 
>>>> 
>>>> In the example above imagine that "CannonicalName" is the canonical (normalized) version of "NonCannonicalName"
>>>> 
>>>> 
>>>> 
>>>> And the corresponding ABNF:
>>>> 
>>>> tag-extended-item = "TAG" SP "(" tag-string ")"
>>>>    ; Complies with &lt;mbox-list-extended-item&gt;
>>>>    ; The value complies with &lt;tagged-ext-val&gt;
>>>>    ; The value is the tag of the corresponding
>>>>    ; CREATE command.
>>>> 
>>>> 
>>>> And a similar extended data item can be used to return MAILBOXID (when supported).
>>>> 
>>> 
>>> Yes, this works for me.
>> After thinking a bit more about this, I remembered that we already registered OLDNAME extended data item in Section 5.4 of RFC 5465. (We can think of canonical mailbox name as the server "renaming" the mailbox.)
>> 
>> Matching to oldname is easier than matching to the tag of the command that generated the change.
>> 
>> 
>> 
>> So unless there are objections, I would go with that instead.
>> 
> 
> Hmm. I guess that could work.. What's the behavior if the mailbox name doesn't change? First I was thinking:
> 
>  * MAILBOXID supported: Send LIST () "/" "name" (MAILBOXID "12345")
>  * No MAILBOXID supported: Don't send LIST reply at all
> 
> But since CREATE already should return MAILBOXID in the tagged reply, it's not very useful to send MAILBOXID in the LIST reply, right?
Indeed.

> So the LIST reply should be only if the mailbox name changes? If it happens rarely enough, it could be that clients won't actually implement that.
> 
> Also, should we require that this name changing only is allowed for normalizing UTF8, or could it be used for "mailbox alias names"? That's been kind of an issue previously where two different folder names (both in LIST reply) point to the same physical folder, but there's no way to tell this to cilents so they cache the mails twice. Although in theory the client could realize this already by seeing that two folders have the same MAILBOXID.

I am thinking that mailbox alias names can be supported by exact the same mechanism. I had a similar thought about aliases. But I was not sure what, if anything the document should say about them.

Best Regards,
Alexey