Subject: [Extra] imap-uniqueid and response codes

From: Bron Gondwana <[email-masked]>
Date: Sat, 24 Mar 2018 00:09:07 +1100

This looks pretty nice:

C: 3 create user.cassandane
S: 3 OK [MAILBOXID 87nn6m5t8azrrrywp4qfxkez] Completed

This looks a little more weird for a basic append:

S: 5 OK [APPENDUID 1521809303 1] [EMAILID (M0685889f69dc2ecf04a0abbe)] [THREADID (T9776517e62b525dd)] Completed
I'm not sure that the syntax is strictly right there.  And it gets
particularly messy when you do multiappend:
S: 30 OK [APPENDUID 1521810470 4:5] [EMAILID (Mdeafec675369c08d9b50da49 M1fb935aca6bc7afce76f6016)] [THREADID (T4f5c35865800cb9f T8e4aec4dadd571ee)] Completed

But - it's pretty valuable to have that data at append time, in exactly
the same way that UIDPLUS was good.  Can anyone think of a better way?
Thanks,

Bron.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 23 Mar 2018 13:13:40 +0000

Bron Gondwana writes:
> S: 5 OK [APPENDUID 1521809303 1] [EMAILID 
> (M0685889f69dc2ecf04a0abbe)] [THREADID (T9776517e62b525dd)] 
> Completed
>
> I'm not sure that the syntax is strictly right there.  And it 
> gets particularly messy when you do multiappend:

Can you even send several of those? Doesn't the syntax restrict you to one 
resp-text?

You can achieve the same with an unsolicited FETCH though.

Arnt

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 24 Mar 2018 00:17:11 +1100

On Sat, 24 Mar 2018, at 00:13, Arnt Gulbrandsen wrote:
> Can you even send several of those? Doesn't the syntax restrict
> you to one> resp-text?
> 

That's exactly what I was looking for :)

Of course, an unsolicited FETCH is going to require an ENABLE, and I'd
hoped to avoid one of those.  But it's obvious that I need it.  Our
server doesn't even add UID to unsolicited FETCHes unless
QRESYNC/CONDSTORE is enabled due to the fact that some clients can't
(or at least couldn't once) handle anything but FLAGS in the
unsolicited data.
Bron.

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 24 Mar 2018 00:34:33 +1100

On Sat, 24 Mar 2018, at 00:17, Bron Gondwana wrote:
>> you to one>> resp-text?
Dammit, no it isn't :(

You can't do an unsolicited FETCH response to an APPEND because you're
not in SELECTED state.  *sigh*.
So it's either a new unsolicited response, or it's a response tag, or
it's "sorry, you'll just have to fetch it yourself based on the UIDs".
Bron.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 23 Mar 2018 13:53:34 +0000

Bron Gondwana writes:
> Dammit, no it isn't :(
>
> You can't do an unsolicited FETCH response to an APPEND because 
> you're not in SELECTED state.  *sigh*.
>
> So it's either a new unsolicited response, or it's a response 
> tag, or it's "sorry, you'll just have to fetch it yourself based 
> on the UIDs".

Why aren't you in selected state? Append in selected state isn't forbidden?

I think you may assume that that all clients that care about thread-IDs and 
so on are able to a) select a mailbox and b) parse FETCH …THREADID, and 
another solution can hardly be as simple. As a wise old colleague of mine 
once said, you don't always have to make those people happy who choose to 
stay off the happy path.

Arnt

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 24 Mar 2018 01:55:16 +1100

On Sat, 24 Mar 2018, at 00:53, Arnt Gulbrandsen wrote:
>> you're not in SELECTED state.  **sigh**.
>> 
True.  It's more in our implementation at least, the selected state is
very much not required for APPEND and hence the codepath is parallel and
doesn't know anything about the index state, which means if you start
doing unsolicited FETCH responses you aren't updating the toldmodseq and
other interesting bits.
Alternatively, the index code could always send EMAILID and THREADID as
part of the unsolicited update, but it would want to make sure it
doesn't keep sending them if there are further keyword updates, because
that's wasteful.
Bron.

> I think you may assume that that all clients that care about
> thread-IDs and> so on are able to a) select a mailbox and b) parse FETCH
> …THREADID, and> another solution can hardly be as simple. As a wise old
> colleague of mine> once said, you don't always have to make those people happy who
> choose to> stay off the happy path.
> 
> Arnt
> 
> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra