Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH

From: Michael M Slusarz <[email-masked]>
Date: Sat, 02 Mar 2013 20:44:06 -0700

Quoting Bron Gondwana <[email-masked]>:

> On Tue, Feb 26, 2013, at 04:31 AM, Jan Kundrát wrote:
>> On Monday, 25 February 2013 17:58:42 CEST, Dave Cridland wrote:
>> > I don't see why we need standardized responses anyway; we may as  
>> well use a
>> > machine learning technique to extract the semantics of each response at
>> > runtime.
>>
>> Yes, we have to drive the line somewhere. On the other hand,  
>> Trojita is probably the only client which has ever sent ESTORE to  
>> any IMAP server out there. Yes, it sucks to be the first one.  
>> However, this won't be the first or the last interoperability quirk  
>> I add to the code base.
>>
>> I wonder what other client authors do here? Would you accept the ESORT here?
>
> I would.  But I'm a hard-core pragmatist instead of the sticklers for rules
> that seem to populate this newsgroup.

To be an even harder-corer pragmatist - what happens when a different  
broken server in the future sends back an ESORT response, and this  
response is different than a SORT response?  At that point do you try  
to workaround your workaround?  Or do you decide that trying to handle  
blatantly incorrect responses is more trouble than its worth. (I don't  
have an answer to that question.)

Personally, I would probably remove the ESORT capability from the  
cached list of available extensions for the current server and retry  
the query.  After all: if the server author couldn't get something  
right as basic as the response syntax (of which there are plain  
examples in the RFC), there's probably not a whole lot of trust that  
other aspects of the implementation are also correct.

michael

___________________________________
Michael Slusarz [[email-masked]]