[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UID SEARCH responses
On Mon, 13 Aug 2007, Dave Cridland wrote:
RFC4731 defines MIN, MAX, and COUNT - none of which are part of this
discussion - and ALL - which you are contending is broken. ALL can be
deprecated and replaced by something else quite easily without affecting MIN,
MAX, COUNT, or the ESEARCH response as a whole.
You'll still have to create a new capability. Otherwise the client won't
know the difference between RFC 4731 compliant servers and RFC xxxx
In addition, I still do not believe that there is consensus to do this - as
far as I can tell, there is only one voice in support of such an action. That
voice happens to have substantial weight as the author of RFC3501, however
neither author of RFC4731, nor any other implementor, has leant any support
to it, whereas there appears to me to be wide support in favour of retaining
the intended behaviour, and clarifying it in errata and a subsequent
I will vigorously oppose such a "clarification", including IESG appeals if
I believe that I have strong arguments:
. although RFC 4315 has a syntax for UID sequence ranges that seem to
have the same semantics as the authors of RFC 4731 claim to have
intended, RFC 4315 uses its own rules to describe those ranges and
does not use sequence-set in order to indicate differing semantics.
. unlike RFC 4315, RFC 4466/4731 uses RFC 3501's sequence-set rule.
. there are two other ways in the base specification to accomplish
the functionality of acquiring the UID/msgno map.
. RFC 4731 says nothing about acquiring the UID/msgno map.
. RFC 4731 mentions use of the returned UID sequence-set in the
IMAP commands which have the RFC 3501 sequence-set semantics. My
interpretation is fully in compliance with this use.
. RFC 4731 gives, as a motivation, the desire to return a "more
compact" representation. My interpretation is fully in compliance
with this motivation, and in fact it is demonstrably more compact
than the contrary interpretation.
. The operation of obtaining the UID/msgno map is typically a one-time
operation in a session. Once the map is known to the client,
removal from the map can be mathematically calculated from an EXPUNGE
response, and additional to the map can be obtained with a short
. Searches typically are done many times in a session, and as noted
above the re-fetch of the map data is unnecessary.
. INBOX tends to have frequent expunges, and consequently the UID space
in an INBOX can become very sparse. Anecdotally (I can collect the
data if you insist), some people have very large INBOXes. In one
interpretation, ESEARCH optimizes search results; in the other, it
. In one interpretation, ESEARCH optimizes search results even if the
server does not allocate contiguous UID values in a mailbox. In
the other, it does not.
. I contend that the optimizing interpretion in the two previous points
. No evidence has been offered to debunk the assertation that RFC 4731
. Assuming that RFC 4731 is ambiguous, server implementations with
either interpretation are fully compliant. The only issue is that a
client must be aware of the issue.
. Assuming that RFC 4731 is ambiguous on this point, there is an
existing deployed implementation that is fully compliant with RFC
4731 and would be broken by the proposed clarification. This is
therefore an incompatible change, not a clarification, and must be
designed and published as such.
I will also oppose, but less vigorously, a new specification that
deprecates ESEARCH entirely in favor of a new capability.
-- Mark --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.