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

[Timo Sirainen <[e-mail]>]

On 10. Jul 2020, at 13.47, Alexey Melnikov <[e-mail]> 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? 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.