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

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 13 July 2020 15:23 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 970E63A126A for <extra@ietfa.amsl.com>; Mon, 13 Jul 2020 08:23:36 -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 n_uFLD9pA2wq for <extra@ietfa.amsl.com>; Mon, 13 Jul 2020 08:23:35 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id D7D623A0B3B for <extra@ietf.org>; Mon, 13 Jul 2020 08:23:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1594653813; d=isode.com; s=june2016; i=@isode.com; bh=QYZsKnRs7J2c0y/pR3DvCh3zdyShIHuSHWwDdmxqKYw=; 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=dLEONHIYl+eIVCuQzlShY7sbFv1WJqYEROmAjL2oOQNuMvJBJD66Cx6F2ReMYIXccuQQ0u 6N6SeTlVjGT/9roswXmsqPKscFD0bnCHCbGfnmvroVkueykTGmSkDnWS3SDe6fDW83lbco Bm4N0M45ETODk+Enu8aa1vAMoyYtAnw=;
Received: from [192.168.0.2] (0546cbcb.skybroadband.com [5.70.203.203]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <Xwx8dQAFTyQC@statler.isode.com>; Mon, 13 Jul 2020 16:23:33 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (16G102)
In-Reply-To: <94C68CF3-1B2C-425B-8EE3-D31AEB2AE1C8@sirainen.com>
Date: Mon, 13 Jul 2020 16:23:32 +0100
Cc: Bron Gondwana <brong@fastmailteam.com>, extra@ietf.org
Message-Id: <DD5A3CDF-8052-4C09-92F3-BA25A3F3B57D@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> <94C68CF3-1B2C-425B-8EE3-D31AEB2AE1C8@sirainen.com>
To: Timo Sirainen <timo@sirainen.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=Apple-Mail-FA1FD059-E426-4522-965E-E0C347A42CFC
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/DH5Sgg7I-xp3tgO8YytMtANz1RY>
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:23:37 -0000

Hi Timo,

> On 10 Jul 2020, at 07:44, Timo Sirainen <timo@sirainen.com> wrote:
> 
>> On 6. Jul 2020, at 20.38, Alexey Melnikov <alexey.melnikov@isode.com> 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).
>> 
>> Does this work for people?
>> 
> 
> OK. But should we return this always or only when canonical name changes? With MAILBOXID at least always. I guess it could be nice to do it always in any case so clients don't forget to support it.

(The same answer applies to both TAG and OLDNAME)
I think when it changes (or MAILBOXID is returned), but this doesn’t break if the server returns it always.

> But in SELECT case perhaps only return it on name change?

Yes, save these extra bytes :-).

Best Regards,
Alexey