Re: [Extra] I-D Action: draft-ietf-extra-imap-uidonly-02.txt

[Arnt Gulbrandsen <[e-mail]>]

Alexey Melnikov writes:
>> You might want to drop the RECENT and EXISTS responses to 
>> SELECT. I don't care either way.
> I think RECENT and EXISTS should stay. IMAP4rev2 dropped RECENT 
> anyway, but knowing number of messages in a mailbox is still

I thought about it afterwards, and think...

1. RECENT should be dropped by this document because it extends IMAP4rev1 
(as well as r2). I think you agree with this.

2. EXISTS should be dropped in favour of a suggestion to use STATUS if the 
client wants that information. This is more controversial. Three things 
informed my thinking:
  - it's perfectly reasonable to write a client and not use it
  - it's the only MSN-related processing left in SELECT
  - STATUS provides the same information

Removing all the MSN-related processing except one bit is weird to me, so I 
suggest removing that bit too.

FWIW the client I use right now displays that information, and gets it from 
STATUS even though the server also provides it via SELECT.

>> You might want to add an appendix: "Motivation. Processing 
>> SELECT can take a long time on big mailboxes, making clients 
>> less responsive. In an experiment, UIDONLY reduced the 
>> processing time for SELECTing a 100,000-message mailbox from x 
>> to y seconds." Of course that requires testing. Ouch.
> This is hard to estimate and would be very implementation dependent.

Yes. I tried to suggest that an unnamed implementation did x→y, explicitly 
as an example, not representative. The client implementers who've heard 
users complain that opening "[Gmail]/All Mail" takes 30 seconds will get 
the point.

Arnt