On Fri Aug 10 06:47:40 2007, Mark Crispin wrote:
> 
> For what it's worth, UW imapd issues the
> 	* ESEARCH (TAG ".") UID ALL 38782:41424
> response instead of
> 	* ESEARCH (TAG ".") UID ALL 
> 38782,38789,40004,40301,40421,40814,41424
> because there are no other UIDs in that range.
> 
> 
Ah. That's definitely not what I intended, and it never crossed my 
mind that this was a possible interpretation. The second is correct.


> Pawel thought this is wrong, and that a UID range of 38782:41424 
> must mean all the possible values are in the map.
> 
> 
It does. Or, more accurately, it must mean that all those UIDs match 
the SEARCH criteria.


> I suggested that he bring the matter up on this list.  I reviewed 
> the ESEARCH RFC, and can find nothing to indicate that ESEARCH must 
> deliver a UID map (as SEARCH does) rather than a UID sequence set.
> 
> 
Ouch. I'd disagree, ALL is defined as "Return all message 
numbers/UIDs that satisfy the SEARCH criteria", not "Return all 
message numbers/UIDs that either satisfy the SEARCH criteria, or 
don't exist, if that's easier".

UID set syntax expands to all UIDs. The fact that UID FETCH etc 
happen to ignore UIDs means that clients MAY include non-existent 
UIDs as a method of reducing the bandwidth (or command length), and 
has nothing whatsoever to do with the set syntax itself. I can't find 
anything in RFC3501 which implies otherwise.

RFC4315 happens to insist on not including "extraneous UIDs", but 
that's belt and braces - I'd be happy to include such a phrase in a 
revision if it'd make people happier.


> If Pawel is correct on the intent, then the ESEARCH RFC is broken 
> since it is ambiguous on that point; either live with the 
> ambiguity, or deprecate ESEARCH and replace it with some other 
> syntax.  The horse is already out of the barn.
> 
> 
I disagree, I think you've misinterpreted the document. If enough 
people disagree, and think that UID sets are somehow defined to 
include missing UIDs - which I dispute - then I suppose we could 
issue a revision that deprecates ALL, replacing it with (perhaps) 
RANGE and MAP.


> I contend that if a client wants the map, then "UID SEARCH ALL" is 
> the correct command.  The only advantage to ESEARCH is getting the 
> tag, which I don't think is much of an advantage for that 
> particular command.

No. It's very unusual in practise for a UID map sent by UID SEARCH 
RETURN () ALL to equal the size of a UID SEARCH ALL. Normally, it's 
significantly smaller. You'd need to have a maximum of two contiguous 
UIDs anywhere in the mailbox to equal the size, and that's 
vanishingly rare in practise.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade