[Tickets #13153] Re: Bugs in the current implementation for PARTIAL limiting (RFC 5267 [4.4]) in Horde's Imap_Client library

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13153
------------------------------------------------------------------------------
  Ticket             | 13153
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Bugs in the current implementation for PARTIAL limiting
                     | (RFC 5267 [4.4]) in Horde's Imap_Client library
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
-State              | Feedback
+State              | Resolved
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2014-05-14 00:42) wrote:

> There is a small difference between a partial range and a sequence  
> range of message UIDs. The latter is described in RFC 3501 [9]:
> seq-range       = seq-number ":" seq-number
> and since PARTIAL syntax does not support '*', as described in RFC  
> 5267 [4.4], a partial range is not exactly the same as a seq-range  
> of message UIDs, but a range like nz-number ":" nz-number.

Guess I'm still not seeing the issue(?).  If you, as a client author,  
wants to pass invalid data into the partial field, that's your  
prerogative.  You're not going to get any data that makes any sense  
back, but that's your own fault.

After all, a client author can do something like extend  
Horde_Imap_Client_Ids to cause it to return nothing but "X"s.  So even  
if we did type checking we are still not going to catch this issue.   
In other words... at some point, it is no longer a library's job to  
make sure the input is spotless ... especially in a language like PHP  
where you are not worried about things like memory/buffers either  
(this might be a different discussion if the library was programmed in  
C.  It's not.)

> I might be wrong, but for me this is neither really correct, nor  
> clear/intuitive, and certainly not inferable only from the (mixed)  
> type hint and the description for the 'partial' option available in  
> the documentation.

Any specific documentation tweaks/changes/revisions are always greatly  
appreciated.

> Yes, you are correct. I'm using Dovecot.

And verified with Timo... Dovecot does not currently support CONTEXT=SORT.

http://marc.info/?l=dovecot&m=139928889515465&w=2

> Thank you for your prompt replies and for the clarification about  
> Dovecot's quirky behavior which actually explains the weird issue  
> mentioned above.

The bigger issue is that Dovecot's PARTIAL results have actually be  
broken the last few releases.  (See above email).

As mentioned in previous post, we should abstract partial behavior for  
IMAP servers that don't support CONTEXT.  You are going to lose a lot  
of the performance benefits, since the PHP server still needs to grab  
the entire search results list, but there's not much you can do about  
it.  (It is still more efficient since it will release memory sooner  
in the process and without the need for further user intervention.)