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

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Jun 2020 12:00:13 +0100

Hi Timo/Bron,

On 02/02/2020 15:16, Timo Sirainen wrote:

> On 1. Feb 2020, at 21.00, Alexey Melnikov <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>>> It still doesn't mean that you can reliably tell the correct octets 
>>>> for the matching mailbox from the LIST response though :(
>>>
>>> Is it too late to add a new response code? Something like:
>>>
>>> * OK [CREATED] TAG "a123" NAME "Denormalized name"
>>
>> Response codes are cheap and don’t break older clients, so I am happy 
>> to add one.
I agreed to this in principle, but now is the time to see if we can make 
this work ;-).
> I guess an optional reply which can send both the changed name and/or 
> mailboxid. Maybe something like:
>
> * OK [CREATED] TAG "a123" NAME "Denormalized name" MAILBOXID "123456"

In IMAP, the part after the response code "[CREATED]" is human readable 
and has no structure. Making it structured in general or making it 
structured for some responses and not others is going to be a major 
change in IMAP handling, so I don't think we should go there.

> Although I'm not sure if some part of it would be nicer inside 
> parenthesis.

Yes, that is my point above: it has to be inside [].

This would makes it something like:

* OK [CREATED TAG "a123" NAME "Denormalized name" MAILBOXID "123456"]

We can even drop some labels that provide no value, because the 
corresponding value is required:

* OK [CREATED  "a123" "Denormalized name" MAILBOXID "123456"]

So ABNF for the latter is going to be something like this:

   created = "CREATED" SP tag SP mailbox-quoted ["MAILBOXID" SP aquoted]

   aquoted = 1*ATOM-CHAR / quoted

   mailbox-quoted = "INBOX" / aquoted
                  ; Same as "mailbox", but without
                  ; allowing for "literal" string

And also add "created" as one of "resp-text-code" choices.

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.

Best Regards,

Alexey

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 17 Jun 2020 21:07:32 +1000

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:

> 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[]

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Jun 2020 12:51:35 +0100

> * 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.

or

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.

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 17 Jun 2020 15:15:29 +0300

On 17. Jun 2020, at 14.51, Alexey Melnikov <[email-masked]> wrote:
>  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.
> 

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

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 17 Jun 2020 22:27:09 +1000

> 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…

I like this. Only send if IMAP4REV2 is enabled and all[tm] your problems go away.

Bron.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Jun 2020 13:32:23 +0100

On 17/06/2020 13:15, Timo Sirainen wrote:

> On 17. Jun 2020, at 14.51, Alexey Melnikov <[email-masked] 
> 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.
Yes, I have some discomfort about this as well.
> We could of course send it only when client has used ENABLE IMAP4REV2 
> and then there wouldn't be any problems.
Right, this seems to be sufficient.
> cause bugs in both clients and servers.

I would rather avoid special cases as well.

I also noticed that tags also allow for "]".