[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UID SEARCH responses
On Sat, 11 Aug 2007, Dave Cridland wrote:
Ah. That's definitely not what I intended, and it never crossed my mind that
this was a possible interpretation. The second is correct.
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.
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
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:
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
. 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 --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.