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

[Bron Gondwana <[e-mail]>]

On Tue, Jul 14, 2020, at 01:23, Alexey Melnikov wrote:
> 
> Hi Timo,
> 
> On 10 Jul 2020, at 07:44, Timo Sirainen <[e-mail]> wrote:
>> On 6.. Jul 2020, at 20.38, Alexey Melnikov <[e-mail]> 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 :-).

I disagree - I'd rather just have it ALWAYS be in the SELECT/EXAMINE response. It will still fit within a single packet, so it's not going to cost any more on the wire.

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [e-mail]