[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UID SEARCH responses


On Sat, 11 Aug 2007, Dave Cridland 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. 

Please quote me anyplace in RFC 4731 where it says that.
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".
You didn't pay adequate attention to the definition of UIDs in RFC 3501. Pay particular attention to the text on page 61. 

Unlike message numbers, the UID sets
	38782:41424
and
	38782,38789,40004,40301,40421,40814,41424
are exactly equivalent if no other UIDs exist within that range.
Furthermore, RFC 4731 specifically refers to the ESEARCH result being interpreted as in the base specification: 
	 A sequence-set
         representation may be more compact and can be used as is in a
         subsequent command that accepts sequence-set.
If it was your intention to require that ESEARCH returns the map with UIDs then RFC 4731 failed to state so.
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.
You have to do more than that. You have to deprecate all of ESEARCH, and replace it with different syntax.
The horse is out of the barn. RFC 4731 does not forbid my interpretation, and my interpretation is out in the field.
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. 

That statement makes no sense at all!
In your interpretation (that a UID range must encompass contiguous extant UIDs) ESEARCH responses will always be larger than SEARCH responses (due to the additional stuff in SEARCH responses) UNLESS there are at least three contiguous extant UIDs. It is LESS likely that there be three contiguous extant UIDs than there be two contiguous extant UIDs. 

I'm taking a hard line, because:
 . UID SEARCH ALL exists as a command to get the map
 . RFC 4731 specifically refers to the ESEARCH result being a sequence-set
    usable in other IMAP commands
 . my interpretation returns a valid sequence-set usable in other IMAP
    commands
 . my interpretation optimizes ESEARCH return results
 . your interpretation prevents optimization unless there are at least
    three contiguous extant UIDs matching the result; without such the
    ESEARCH response is larger than the SEARCH result
 . the sole benefit of your interpretion is to be able to use ESEARCH as
    an alternative to get the map
 . RFC 4731 says nothing about UID ranges in ESEARCH being different from
    IMAP ranges.  IMAP does not require that UID ranges refer to
    contiguous extant UIDs; in fact RFC 3501 says quite the opposite.
 . RFC 4731 uses the same syntax rule as RFC 3501 for UID ranges.
That isn't to say that I am not sympathetic. I am. Nonetheless, the shoe has been on the other foot many times in the past, and I've had to deal with the resulting fiasco.
I recommend living with the unexpected consequence. Trying to fix ESEARCH (which I argue isn't broken) will just diminish what little credibility IMAP extensions still have. 

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.