Re: [imapext] a very simple little imap extension, really quite magnificently simple

[Arnt Gulbrandsen <[e-mail]>]

On Friday, April 25, 2014 7:28:59 PM CEST, Jan Kundrát wrote:
> On Friday, 25 April 2014 18:57:38 CEST, Arnt Gulbrandsen wrote:
>> Storing MSNs persistently so you don't have to recompute at 
>> session start (and at the same time supporting simultaneous 
>> sessions) was simply too difficult for me.
>
> Given that you already have to track UIDs, I find it hard that 
> it is expensive to take a look at the size of their set.

But I don't have to track UIDs. I just have to track the uidnext value so I 
can allocate new UIDs.

> The draft also says that the server should return a strange 
> number when it would otherwise return a MSN. I object to that.

OK, how do you think an unsolicited fetch response should look?

a) Not have a number after the leading asterisk.
b) Have a number, but it should not be strange.

> In my opinion the server should signal this in a drastic way, 
> including terminating the session if everything else fails. 
> Sending back a mock-up MSN is about as evil as one could go in 
> my book.

We're talking about unsolicited fetch responses here. Perhaps other things, 
there are dozens of IMAP extensions and I at least do not know all of them 
entirely. But practically speaking, unsolicited fetch responses.

>> Why? What's wrong with UIDNEXT?
>
> The fact that you can have gaps in UID range. The draft assumes 
> that UIDs are allocated by adding one the the previous UID. Your 
> whole scheme falls apart when this requirement does not hold. 
> That requirement is not documented anywhere in the draft.

I really do not understand this.

> If the UIDs are not allocated consequently, and the highest UID 
> right now is 12345, what does the following mean:
>
> 	* OK [UIDNEXT 12500] guess it

"There are <=5 new messages. If you want them, you can send uid fetch 
12345:* and get the details you choose you want about all the new 
messages".

> So this is an extension whose benefit is immediately 
> neutralized by a client which wants to show the user the total 
> number of messages. To me, that sounds like a very basic 
> operation.

Oh? I once asked a few colleagues at a googleapps shop about that, and none 
of them had any idea about their total number of messages. "Oh, lots", 
"I've never deleted anything", that was the sort of answer I got. None told 
me any number. One looked at his screen and told me how many per cent of 
his quota he used.

So I don't think that operation is basic or important for users of _large_ 
mailboxes.

>> Do any other RFCs require CLIENTBUG? (Not suggest, or show in 
>> examples. Require.)
>
> I'm not sure how that is relevant. This proposal is about 
> designing an extension which radically changes how IMAP 
> operates. Why not at least *mandate* a machine readable way of 
> saying "hey client, you've just shot yourself in the foot"?

I can tell you why I didn't add anything like that in 5530. 5530, as you 
may have noticed, only lists codes, it doesn't say that you have to use any 
code. If two codes apply, it doesn't say which one you must choose.

That's because when I surveyed servers for 5530, I found a few instances 
where two response codes applied. Two errors occured, and it wasn't clear 
that one response code ought to win over the other. So I decided to not 
issue a rule on that. A server can let the first response code win, the 
last one win, it doesn't matter.

I think that also applies in this case. Suppose there's a command such as 
"uid search charset iso-8859-42 1 body foo". The charset specification is 
reasonable, but the 8859 committee hasn't issued number 42 yet, so that 
causes one response code. The presence of the MSN causes another. The 
syntax only permits one, so the server has to choose which one to send. Do 
you think that in this case, the MSN-related response code ought to win 
over the charset-related code? Do you think it ought to win over EVERY 
other code in ALL cases?

I think it doesn't matter very much, so let the server do whatever comes 
easiest.

> OK, at this point I cannot imagine how such a client is 
> supposed to work *at all*. Let's start with a blank state. The 
> client knows nothing about the mailbox. It opens it and 
> presumably wants to show a list of messages to the user. What is 
> the client supposed to do now?

Something "uid search unseen", "uid search or unseen within 604800", or 
some variation.

Most clients, of course, do "fetch 1:* ..." instead, which is okay, but 
that approach means that this extension is not interesting for them.

> What if it wants to show just a subset of the mailbox, perhaps 
> last 1k items (actually it doesn't have to be 1k, anything 
> between 500 and 3000 is probably fine -- it needs *something*, 
> but not the full 4M mailbox). How to achieve that?

"Show today's mail" is trivial, "show all the unread mail" is trivial, 
"show the last five hundred messages" is difficult.

> What happens when a mail arrives?

Same as before. Think about it.

Before, you got an EXISTS for two new messages. But then someone expunges 
one before the server processes your fetch, and you get one message back. 
With UIDONLY, you get a UIDNEXT indicating that two new UIDs have been 
allocated. You issue a fetch, and get <=2 messages. There's no difference 
in principle.

> How is a resynchronization after being offline for a while 
> going to look like?

Same as before.

I'll send you a session transcript offlist. I may not get it done tonight, 
though.

Arnt