On Mon, Oct 31, 2011 at 3:28 PM, Mark Crispin <mrc+imap@panda.com> wrote:
> On Mon, 31 Oct 2011, Brandon Long wrote:
>>
>> I have no idea who you talked to, but my team owns the Gmail IMAP server.
>
> In that case, at the very least, there is a lack of a consistent and
> coherant policy regarding standard compliance.
>
>> Almost all of our IMAP users mostly use the web interface, so yes,
>> they want the IMAP experience to mimic the Gmail interface. ?There are
>> settings that can be set to make the experience more "IMAP normal"
>> than "Gmail normal", but the defaults favor the more common use case.
>
> Do you actually have research and firm numbers to back up the contention
> that customers want their IMAP clients to behave incorrectly, including
> malfunctioning, so that some IMAP clients seem to mimic Gmail?
When we first released IMAP internally, the overwhelming use case was
as an adjunct to Gmail Web interface, not as a replacement to the
client. That is expected, of course. But our public usage mimic'd
this to nearly the extreme. Now, I'm willing to believe that our
choices informed the usage in some part, but the overwhelming use case
of Gmail's IMAP interface is access on mobile devices by people who
use the Gmail Web interface on the desktop.
> Or is this just a matter of religion that has never been challenged, much
> less bolstered with research?
I know the clients which use my service, since that knowledge is
important to me, even if the ID command is considered pariah to the
perfectness of the protocol.
Also see the changes that Thunderbird has made to make their client
more "Gmail" like when talking to us. Or see the Blackberry Enhanced
Gmail plug-in which tries to make the Blackberry have a more Gmail
feel. Or arguments I've gotten in on Google+ with our adoring public
who wanted us to make the usage even more Gmail like, impossible
though that was to express in the IMAP protocol.
>> I know its not compliant, we even have a support page where we list
>> the cases where we explicitly decided against compliance.
>> Interoperability is a goal, however. ?That doesn't mean we want to
>> force Gmail users to use the IMAP mailbox model, however.
>
> So, instead, you force Gmail users to use a non-compliant model that
> violates guarantees in IMAP and causes some IMAP clients to malfunction.
If we are violating guarantees that cause malfunctions, it would be
good to know that. The only one I know of is that under some
circumstances, alpine wants some combination of the header + body to
equal something, and due to our LF->CRLF shenanigans, that can be
violated. I'm not happy with it, but I have no good way to fix it,
either. Whether its an important guarantee, well, it hasn't seemed to
have affected anyone who removed the check.
I know also that some of our deletion behavior follows some of the
"non-suggested" ones from the IMAP best practices RFC, but I didn't
think doing those was actually non-compliant.
>> And I argue that we made the design decisions we did with good
>> reasons. ?I also argue that there were no perfect decisions to be
>> made, and usability was a more important goal than correctness.
>
> Thank you for confirming, in public, that the Gmail IMAP server is
> non-compliant and that Google has no intention to make it compliant.
I feel pretty safe in saying that Gmail's IMAP doesn't support
substring search of bodies and never will, and is therefore
non-compliant. At least until we can do it for a single user without
consuming the equivalent resources of a couple million users who don't
use it.
Brandon
--
?Brandon Long <blong@google.com>
?Staff Engineer
?Gmail Delivery TLM