Re: UID SEARCH responses

[Mark Crispin <mrc@xxxxxxxxxxxxxxxxxx>]

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 
compliant servers.

> 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 
> revision.

I will vigorously oppose such a "clarification", including IESG appeals if 
necessary.

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
    map fetch.
 . 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
    does not.
 . 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
    is superior.
 . No evidence has been offered to debunk the assertation that RFC 4731
    is ambiguous.
 . 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 --

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.