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

Timo Sirainen <timo@sirainen.com> Wed, 17 June 2020 12:15 UTC

Return-Path: <timo@sirainen.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 F03D73A0A3E for <extra@ietfa.amsl.com>; Wed, 17 Jun 2020 05:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 OQVuGvqeXkUJ for <extra@ietfa.amsl.com>; Wed, 17 Jun 2020 05:15:31 -0700 (PDT)
Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id 86BCB3A0A3D for <extra@ietf.org>; Wed, 17 Jun 2020 05:15:31 -0700 (PDT)
Received: from [192.168.10.110] (unknown [91.155.205.240]) by sirainen.com (Postfix) with ESMTPSA id 24ED72B3C8B; Wed, 17 Jun 2020 12:15:30 +0000 (UTC)
From: Timo Sirainen <timo@sirainen.com>
Message-Id: <1BC59434-C16C-4A32-AB3C-D2783092CF9B@sirainen.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B00B4247-AF1A-4103-913D-72F1551607EF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 17 Jun 2020 15:15:29 +0300
In-Reply-To: <9c674fad-dabe-cc9d-649d-30cb40f5c506@isode.com>
Cc: Bron Gondwana <brong@fastmailteam.com>, extra@ietf.org
To: Alexey Melnikov <alexey.melnikov@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>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/Cz_DilDN0sk8IzcgnQFh90_qQ3U>
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: Wed, 17 Jun 2020 12:15:36 -0000

On 17. Jun 2020, at 14.51, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
> On 17/06/2020 12:07, Bron Gondwana wrote:
> 
>> On Wed, Jun 17, 2020, at 21:00, Alexey Melnikov wrote:
>>> To elaborate on why I excluded "literal" string is because response codes are defines as:
>>> 
>>>   atom [SP 1<any TEXT-CHAR except "]">]
>>> 
>>> and TEXT-CHAR excludes CR and LF.
>>> 
>> 
>> Here's another problem:
>> 
>> . CREATE INBOX.HELLO[]
>> . OK [MAILBOXID (f3633f0c-3a4d-4df2-9b2f-618464b97504)] Completed
>> 
>> * LIST (\HasNoChildren) "." INBOX.HELLO[]
> Right, I was just about to mention that. I think we have a choice:
> 
> 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.

> 2) just describe limitations (e.g. no mailbox with "]" in it can have this response code) and make them a special case.
> 
> Hopefully will discuss this later today at the interim meeting.
> 

I'd rather avoid these kind of ugly special cases. It's just going to cause bugs in both clients and servers.