From ned.freed@mrochek.com Sun Feb 3 10:44:58 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7121F8731 for ; Sun, 3 Feb 2013 10:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frIcMlHn7lN3 for ; Sun, 3 Feb 2013 10:44:58 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 47CDB21F86D2 for ; Sun, 3 Feb 2013 10:44:58 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OPR4SXI7R40076U0@mauve.mrochek.com> for imapext@ietf.org; Sun, 3 Feb 2013 10:39:51 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OPEL6ZTPUO00008S@mauve.mrochek.com>; Sun, 3 Feb 2013 10:39:46 -0800 (PST) Message-id: <01OPR4SUK7B000008S@mauve.mrochek.com> Date: Sun, 03 Feb 2013 10:30:53 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 16 Jan 2013 18:42:54 -0500" References: To: Barry Leiba Cc: "imapext@ietf.org" Subject: Re: [imapext] IMAPMOVE wrapping up X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 18:44:58 -0000 I would also like to thank everyone for their participation in this group and the effort leading up to RFC 6851. It has been a geniune pleasure. I also share Barry's sentiments about this demonstrating what a narrowly focused group with cooperative participation can do, and how quickly it can be done. I note that our charter said last call in October and it actually happened November 7. I don't think I've ever seen that happen before in the IETF. Finally, thanks are also due to Mark Crispin for making all this possible. I'll also note that Mark contributed substantially to MIME; in fact he was present the very first time Nathaniel Borenstein and I discussed MIME in person (at a restaurant in St. Louis) and provided valuable insight from the start. Ned From slusarz@horde.org Tue Feb 5 15:25:44 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9089D21F8939 for ; Tue, 5 Feb 2013 15:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJLU1JRg9W8Y for ; Tue, 5 Feb 2013 15:25:44 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF221F8901 for ; Tue, 5 Feb 2013 15:25:44 -0800 (PST) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta12.emeryville.ca.mail.comcast.net with comcast id wgRW1k00J16AWCUACnRjG4; Tue, 05 Feb 2013 23:25:43 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta06.emeryville.ca.mail.comcast.net with comcast id wnRi1k00F00qwSn8SnRiRD; Tue, 05 Feb 2013 23:25:43 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by bigworm.curecanti.org (Postfix) with ESMTP id 2465470033 for ; Tue, 5 Feb 2013 16:25:42 -0700 (MST) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Tue, 05 Feb 2013 16:25:42 -0700 Date: Tue, 05 Feb 2013 16:25:42 -0700 Message-ID: <20130205162542.Horde.r2kRTnmgaKuu_TIfB9kctQ1@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20130115181839.23148.71606.idtracker@ietfa.amsl.com> <2CDBE6605058EA83E82E46F3@cyrus.local> <7C9B91F6A03F17A98EAA26EC@caldav.corp.apple.com> <20130118163818.882A421F885C@ietfa.amsl.com> In-Reply-To: <20130118163818.882A421F885C@ietfa.amsl.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.0-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360106743; bh=3nLa+wRyDAxnquO84ab/NF34QGAogn9MtjCu7VNgMY0=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=EAi1dChi9H6+FCHLVG7HQEnHK6rdUh8MSWGkdupdOsm4kDxN/rXWPizkcDSMpfcb7 ywF2RjpUrqrAeneyMoEhyOXz4HZJ+8HcUh6Pb07esEjqj7NVNBtJv5oAos/wkQ33ES QaA0mO2gertD3vxLvUnWp7z8tfwQXMR3up7Sm4kGPFkSYUSD7GJZneSJyf5KJhgSnD /jq3Kh457deEiTbNhjQcFvvMgnIIzc1YeY2gCpM9KS7t2UCjscKO6U6R6nEdn8c8Rs 50/U8YZrmNlomm5iAXzrs/V8lBJCCefnTlPHRLr4Bo24/YUsbX/6cF3+en6NKlqnWx EIRosvdJRi0ag== Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 23:25:44 -0000 Quoting Pete Maclean : > I am with Cyrus in that I would like to see this new flag defined a > little more tightly. I have major customers who are unhappy about > the lack of specificity of existing IMAP flags. A bit late to the party here, and this doesn't directly relate to the \Important flag, but the draft also discusses the more general Special-use Attributes registry so figure it was worth a mention. As has been mentioned by others, many of the special-use flags are lacking in specificity. Coupled with the fact that multiple mailboxes can contain the same flag, e.g. a MUA supporting multiple personal identities might use a different sent-mail mailbox for each identity, the special-use flags are not tremendously useful from a client's point of view. The flags would become more useful if there was a mechanism to identify the "preferred" mailbox for each of the defined flags. In other words: a way to identify if these preferred mailboxes are the system/server default. This would greatly aid in allowing a client to (automatically) setup sane defaults when doing the initial configuration. Clients would continue to be free to label mailboxes as they see fit (if CREATE-SPECIAL-USE is available) allowing, for example, showing a special icon for all mailboxes labeled as sent-mail. Just some thoughts I've had while trying to figure out how to integrate special-use flags from a client perspective. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From jkt@flaska.net Mon Feb 25 07:00:09 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18D221F9443 for ; Mon, 25 Feb 2013 07:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfz2JPq8QnEC for ; Mon, 25 Feb 2013 07:00:08 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id B369B21F9442 for ; Mon, 25 Feb 2013 07:00:08 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 09CAE62ABD; Mon, 25 Feb 2013 16:00:03 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 25 Feb 2013 15:59:58 +0100 User-Agent: trojita/v0.3.91-140-ge6887f3; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:00:09 -0000 Hi,=0Ait turned out that a certain IMAP server sends out non-standard "= ESORT" responses in response to the ESORT command (the correct way is t= o respond with an ESEARCH). I've filed a bugreport with an attached pat= ch which hopefully fixes the issue, but even if they accept it soon, th= ere's the usual problem with releases taking time and sysadmins delayin= g updates etc, and in the end, it's always the client which gets the bl= ame "because other MUAs work just fine". The server the reporter is usi= ng was released roughly 10 months ago; I have unfortunately no idea abo= ut when they started advertising the ESORT capability, the publicly ava= ilable git mirror doesn't go that far back in time.=0A=0ADo you guys se= e any problem with a client simply accepting "* ESORT ..." in the same = way and using the same syntax as an ESEARCH response? Would you leave s= uch a workaround in your codebase indefinitely, or remove it after some= time period?=0A=0AWith kind regards,=0AJan=0A=0A-- =0ATrojit=C3=A1, a = fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From barryleiba.mailing.lists@gmail.com Mon Feb 25 08:50:51 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0690B21F94D1 for ; Mon, 25 Feb 2013 08:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.808 X-Spam-Level: X-Spam-Status: No, score=-102.808 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdJ1jUJMlUUw for ; Mon, 25 Feb 2013 08:50:50 -0800 (PST) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5421F903C for ; Mon, 25 Feb 2013 08:50:46 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id 15so2371999vea.28 for ; Mon, 25 Feb 2013 08:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lX/5UOdbVhjMMBZmsA75NsryyLVu5FrksoHaAXRhOu8=; b=b4/BLl0AlZeqZboxy80NZmWdxz5ehI5n/5QvLImaz8uyh7eM2xMGJtNJmshwg6ePCQ Gdumt7bpjJ8P1jleSGLuhEHX5FaS8eOpxZJFnVmlx+Ffsl88+wS0qHxx1J4lEJuAUD44 IhAkqW7yV0CXWBFAsJhwdkz93dXvr6vdJQ1GCy8KZm4jyK8y8Us3KG3anhDZJ/wyTQ9D I3uzDNQOBzrZTgJ9D8DwlFhgMVw8ryUE+COe329YOEphv7GMGBEH6nqiyLrSwcOMfmE5 r0DhSqb+XTjEKmkXbs0Z6l3TJgIgiLd3udwoJF2SdXp0AurVe4jsqxnparlYaPverGS+ taCw== MIME-Version: 1.0 X-Received: by 10.52.37.81 with SMTP id w17mr8730732vdj.70.1361811046591; Mon, 25 Feb 2013 08:50:46 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Mon, 25 Feb 2013 08:50:46 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 11:50:46 -0500 X-Google-Sender-Auth: OjBIOQ2BCnRZozQEC5e5WCP5oII Message-ID: From: Barry Leiba To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: text/plain; charset=ISO-8859-1 Cc: "imapext@ietf.org" Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:50:51 -0000 > Do you guys see any problem with a client simply accepting "* ESORT ..." in > the same way and using the same syntax as an ESEARCH response? Sure, why not. You might also consider accepting "BURGFLUJ", "XYZZY", and "SUPERCALIFRAGILISTICEXPIALIDOCIOUS" as well. Barry From dave@cridland.net Mon Feb 25 08:58:44 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7321F9546 for ; Mon, 25 Feb 2013 08:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rLDBi3CSP2h for ; Mon, 25 Feb 2013 08:58:43 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1795B21F9517 for ; Mon, 25 Feb 2013 08:58:43 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id x4so3099614obh.30 for ; Mon, 25 Feb 2013 08:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yGO80Mh4jfwAqclsteeL81VbFozvG30OlbRDrtZ27YQ=; b=g/Tcb36Eoy540NClp4MQBSVRqyE5zgUXzFFlToVek/qnpT4We2TyK9MhQARZ06h7zx h+Pye/YFvhi3MzEuwi5rHv7FtilMYLp7R8zSQ//fotwLhKBGAQy2japkmHf3vQSEqDpI JbAgvoqVWIKQDFkwLLXAFuaNmkFtXeNoPQDOI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=yGO80Mh4jfwAqclsteeL81VbFozvG30OlbRDrtZ27YQ=; b=AHD6jNazFVkU85CclmCMiosebBwLSPE+ieQ6CZZDlxrPMdNt3pLVgMpFtAzJeDfW27 tx4L1z7b4zWw3Kg9gtrhxxqEOLOEgB1/ACj5IfkYPr8fvURLt47mr8npns7T0pDNbAIx mqwjalScDHodxP0gsbBQUW3p2tWSNTAedVkV/5HdStHZVHue7Luci5CHiUgo4XWc1zAX 2xarSo1QwrXWNfiU8c59g+PBJVQ4kSdbnlKTEprLruar6InR2HrmkBYtEUGlTtNODOpN 4gcSU7zp2urzEUxHkjpVQ6egOk5v7Dwusc413FUuBilv3WMIsX5vAL9/AuII8NQoYzci mK7w== MIME-Version: 1.0 X-Received: by 10.60.27.66 with SMTP id r2mr8372060oeg.139.1361811522576; Mon, 25 Feb 2013 08:58:42 -0800 (PST) Received: by 10.60.10.72 with HTTP; Mon, 25 Feb 2013 08:58:42 -0800 (PST) Received: by 10.60.10.72 with HTTP; Mon, 25 Feb 2013 08:58:42 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 16:58:42 +0000 Message-ID: From: Dave Cridland To: Barry Leiba Content-Type: multipart/alternative; boundary=e89a8fb206320de3af04d68f74ca X-Gm-Message-State: ALoCoQk5v22egskB3HUBxB5qq9opz79H/Z/6dzbo5jSvV412b2XzEcz/6gncaDQBOGubUFVYQFu4 Cc: =?ISO-8859-1?Q?Jan_Kundr=E1t?= , "imapext@ietf.org" Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:58:44 -0000 --e89a8fb206320de3af04d68f74ca Content-Type: text/plain; charset=ISO-8859-1 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. --e89a8fb206320de3af04d68f74ca Content-Type: text/html; charset=ISO-8859-1

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.

--e89a8fb206320de3af04d68f74ca-- From jkt@flaska.net Mon Feb 25 09:31:35 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1601E21F937C for ; Mon, 25 Feb 2013 09:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzpOe71bCdeO for ; Mon, 25 Feb 2013 09:31:33 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A221F92E4 for ; Mon, 25 Feb 2013 09:31:32 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 4B1B262ABD; Mon, 25 Feb 2013 18:31:30 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 25 Feb 2013 18:31:31 +0100 User-Agent: trojita/v0.3.91-140-ge6887f3; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: <8f052fc1-7b93-4ab7-a5f2-93b1f9e30734@flaska.net> In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] Re: Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:31:35 -0000 On Monday, 25 February 2013 17:58:42 CEST, Dave Cridland wrote:=0A> I d= on't see why we need standardized responses anyway; we may as well use = a=0A> machine learning technique to extract the semantics of each respo= nse at=0A> runtime.=0A=0AWell, I have some experience with consulting m= y crystal ball when deciphering responses from various servers. Most of= that is documented on this ML or on the imap-protocol. The bugs are in= proprietry and OSS servers alike. I report them when I hit them, and m= ost of them get fixed, eventually. The server instances which manifest = the problem are also upgraded most of the time. Eventually. Some of the= m never are, though.=0A=0ATrojita is a small project, there's no compan= y backing up its development with a pile of cash to hand out on a regul= ar basis. Work is done in the free time of the contributors (with some = occasional consulting in my case). In order to sustain the development,= I try to attract new people to the project, and I guess the correct wa= y to do so is by showing some flexibility and accomodating their needs = to a certain extent. In this case, it's likely that they want to access= their mail even when their company's server of choice sends garbage in= violation of the relevant RFCs. Someone made a mistake in the code; th= at's not a big deal. Mistakes happen, I've done my fair share of them.=0A= =0AYes, 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 ser= ver out there. Yes, it sucks to be the first one. However, this won't b= e the first or the last interoperability quirk I add to the code base.=0A= =0AI wonder what other client authors do here? Would you accept the ESO= RT here?=0A=0ACheers,=0AJan=0A=0A-- =0ATrojit=C3=A1, a fast Qt IMAP e-m= ail client -- http://trojita.flaska.net/ From brong@fastmail.fm Mon Feb 25 17:05:34 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E504A21E8127 for ; Mon, 25 Feb 2013 17:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9xwnRux-9N0 for ; Mon, 25 Feb 2013 17:05:34 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 183A221E80B6 for ; Mon, 25 Feb 2013 17:05:34 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8FFD8207D7; Mon, 25 Feb 2013 20:05:33 -0500 (EST) Received: from web3.nyi.mail.srv.osa ([10.202.2.213]) by compute5.internal (MEProxy); Mon, 25 Feb 2013 20:05:33 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= l48B4tplWfC+AnDFOoI3fa8NoH4=; b=ooPZRp4SQwcfw3gz1Z8PKUfuJxQGVaKO xm0IQF7iPUABW1eW3S/bM+KLR826XjLDweiDFQK/Nazbi+3o8QdBU6+0+FcBolY1 q73zlzQj8hAe91HMxm01xg4LrbUy3nss4pm5Q8yWfV0wDis/cESBbu6hXiChr5hY G0Mi1zCe8Sc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=l48B4tplWfC+AnDFOoI3fa8NoH4=; b=auSH5 3S2vaf8pEN1D9kDP5vduFUuyUbrkg8ZMEBTTJmZSFETpMAhnV39nT4TGhTSvLQEZ pwoi2A9xapDyZcF6cZS3bMJYHtJCSBxlRLi54x3VkHvaD+uLfJIaYi8PrQi/basJ morpchJGXq6+FZErwHUJc1PzmTmgUW4udP8l+A= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 68DC0B2B47F; Mon, 25 Feb 2013 20:05:33 -0500 (EST) Message-Id: <1361840733.26475.140661196848569.316FD765@webmail.messagingengine.com> X-Sasl-Enc: 88blrR/X7/MlZngctfgyAl2Zr0EBSTnNzOeurO5lvQK1 1361840733 From: Bron Gondwana To: =?ISO-8859-1?Q?Jan=20Kundr=E1t?= , imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: MessagingEngine.com Webmail Interface - html Date: Tue, 26 Feb 2013 12:05:33 +1100 In-Reply-To: <8f052fc1-7b93-4ab7-a5f2-93b1f9e30734@flaska.net> References: <8f052fc1-7b93-4ab7-a5f2-93b1f9e30734@flaska.net> Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 01:05:35 -0000 On Tue, Feb 26, 2013, at 04:31 AM, Jan Kundr=E1t 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 u= se 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 p= robably the only client which has ever sent ESTORE to any IMAP server out t= here. Yes, it sucks to be the first one. However, this won't be the first o= r the last interoperability quirk I add to the code base. >=20 > I wonder what other client authors do here? Would you accept the ESORT he= re? I would. But I'm a hard-core pragmatist instead of the sticklers for rules that seem to populate this newsgroup. What would your users prefer, someth= ing which copes, or something which tells them to make a snarky phonecall to th= eir email software vendor? The other possibility is to detect that the response is broken and to fall = back to using other techniques to obtain the information (standard SORT - you ne= ed to support is anyway for server which don't have all the fancy), even if they = are less efficient. As for how long I'd support workarounds for - until the servers which need = them are no longer common is probably long enough. The same way that websites a= re starting to no longer actively support IE6 quirks. Then again I work for Opera which has recently stopped building their own b= rowser engine because too many mobile websites only work with Webkit these days. = The reality is that unless you have a standard test-suite which implementations= have to pass to claim to be "compliant" and you write that into the standard, yo= u will get buggy implementations - and you'll either need quirks to work around th= em or you will find your users go to someone who gets the job done rather than qu= otes a rulebook at them. Bron. --=20 Bron Gondwana brong@fastmail.fm From ned.freed@mrochek.com Wed Feb 27 19:26:23 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE421F89E5 for ; Wed, 27 Feb 2013 19:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X4AlHcZTBys for ; Wed, 27 Feb 2013 19:26:23 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0279E21F8698 for ; Wed, 27 Feb 2013 19:26:20 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OQP60M014G000K3J@mauve.mrochek.com> for imapext@ietf.org; Wed, 27 Feb 2013 19:21:13 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OQH0ICCQ1C000054@mauve.mrochek.com>; Wed, 27 Feb 2013 19:21:10 -0800 (PST) Message-id: <01OQP60K8K8E000054@mauve.mrochek.com> Date: Wed, 27 Feb 2013 19:02:09 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 26 Feb 2013 12:05:33 +1100" <1361840733.26475.140661196848569.316FD765@webmail.messagingengine.com> References: <8f052fc1-7b93-4ab7-a5f2-93b1f9e30734@flaska.net> <1361840733.26475.140661196848569.316FD765@webmail.messagingengine.com> To: Bron Gondwana Cc: =?ISO-8859-1?Q?Jan=20Kundr=E1t?= , imapext@ietf.org Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 03:26:24 -0000 > 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. In my case at least, you're waaaaay off base. > What would your users prefer, something > which copes, or something which tells them to make a snarky phonecall to their > email software vendor? If only the tradeoff were always this simple. Sure, there are cases, like the one I encountered the other day in my managesieve server were there were a couple of clients that wouldn't accept literal responses in one place, only quoted strings. So I change our server to output quoted strings. Problem solved. Oh, wait. There's another client, a much more popular one, as a matter of fact, that has a bug in its quoted string processing. Tickle that bug and only one did the managesieve part of the client wedge, when the connection timed out the entire client basically fell over. Since the more popular client is the more important case to accomodate I filed a bug. It turned out the problem had been partly, but not completely, solved in the development branch. A few iterations with the author and now the problem is completely fixed. So much far "pragmatic" accomodation of broken behavior. In this case the truly pragmatic approach was to actively work with the client author and get the actual problem resolved. Now, maybe with this ESORT business it's an incorrect string, nothing more. But how sure are you of that? You filed a bug, have you followed up on that? > The other possibility is to detect that the response is broken and to fall back > to using other techniques to obtain the information (standard SORT - you need to > support is anyway for server which don't have all the fancy), even if they are > less efficient. Given the complexity of IMAP this sounds safer to me, and less likely to result in snarky phone calls, this time to you. Ned From brong@fastmail.fm Thu Feb 28 15:17:21 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834C921F8AEA for ; Thu, 28 Feb 2013 15:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mzODFo6yIiD for ; Thu, 28 Feb 2013 15:17:20 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id AE24221F8AE3 for ; Thu, 28 Feb 2013 15:17:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DC9D020A14; Thu, 28 Feb 2013 18:17:19 -0500 (EST) Received: from web2.nyi.mail.srv.osa ([10.202.2.212]) by compute4.internal (MEProxy); Thu, 28 Feb 2013 18:17:19 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= 87szvBCAzZ3b3vezOassA7SW0CE=; b=C8v9Yz3Y33itV7spw7ECuttCUdqkyAXI 1oYR93xstgvtaX6p6alj0+M9Ydn1W+KzPmyaqnueV9VWeSoF+hW+ZqAefNmJvvYp gBdjP9Q+EIIZjn+Ey4ni9NuFOjClxdZO06uk2rk5uAwQYn3ZhvhPpRPLJ57Q6S9a jPCjTswMou0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=87szvBCAzZ3b3vezOassA7SW0CE=; b=G0j Ed65IuYQijfAsfNYyV/n6g9wL/TxE6DASPkmy1w04qFF9ndMf3bHX3dGaoPxqUlU LQeWLKKOlCTtOI6FORIF/E1ilUhBKsVN+m/uVHgL6cD1hMEmuffQZbZtkM+LbG9d kDoDfiKRrJMMrpu7lDhX3GmZKKHvC1DJhCBLrPlQ= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id A97FC201108; Thu, 28 Feb 2013 18:17:19 -0500 (EST) Message-Id: <1362093439.24752.140661198412837.455D416C@webmail.messagingengine.com> X-Sasl-Enc: Sn1mPJQcIcyRfLyk5YOvkjRdqCZdPBj/pTfeM42b2KYB 1362093439 From: Bron Gondwana To: Ned Freed MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html In-Reply-To: <01OQP60K8K8E000054@mauve.mrochek.com> References: <8f052fc1-7b93-4ab7-a5f2-93b1f9e30734@flaska.net> <1361840733.26475.140661196848569.316FD765@webmail.messagingengine.com> <01OQP60K8K8E000054@mauve.mrochek.com> Date: Fri, 01 Mar 2013 10:17:19 +1100 Cc: =?ISO-8859-1?Q?Jan=20Kundr=E1t?= , imapext@ietf.org Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 23:17:21 -0000 On Thu, Feb 28, 2013, at 02:02 PM, Ned Freed wrote: > > What would your users prefer, something > > which copes, or something which tells them to make a snarky phonecall to their > > email software vendor? > > If only the tradeoff were always this simple. Sure, there are cases, like the > one I encountered the other day in my managesieve server were there were a > couple of clients that wouldn't accept literal responses in one place, only > quoted strings. So I change our server to output quoted strings. Problem > solved. And we have something in Cyrus interop that's the other way - some old versions of XFER require everything to be literals. Thankfully it's all internal, so we just send literals. > Oh, wait. There's another client, a much more popular one, as a matter of fact, > that has a bug in its quoted string processing. Tickle that bug and only > one did the managesieve part of the client wedge, when the connection timed > out the entire client basically fell over. > > Since the more popular client is the more important case to accomodate I filed > a bug. It turned out the problem had been partly, but not completely, solved in > the development branch. A few iterations with the author and now the problem is > completely fixed. > > So much far "pragmatic" accomodation of broken behavior. In this case the truly > pragmatic approach was to actively work with the client author and get the > actual problem resolved. That's great if you can also make sure that all the clients upgrade. Servers tend to be on a slower cycle - so you have to do both - work with the authors to get the bug fixed, and try to work around it. > Now, maybe with this ESORT business it's an incorrect string, nothing more. But > how sure are you of that? You filed a bug, have you followed up on that? Is there significant correlation between incorrect strings and other bugs? There's (in general) no way to tell how buggy the implementation you're talking to actually is short of sanity checking its response. Obviously, the sort could be totally bogus. > > The other possibility is to detect that the response is broken and to fall back > > to using other techniques to obtain the information (standard SORT - you need to > > support is anyway for server which don't have all the fancy), even if they are > > less efficient. > > Given the complexity of IMAP this sounds safer to me, and less likely to result > in snarky phone calls, this time to you. Yep - good old RFC3501 - fallback for everything! Bron. -- Bron Gondwana brong@fastmail.fm From ned.freed@mrochek.com Thu Feb 28 17:57:03 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490CE21F8561 for ; Thu, 28 Feb 2013 17:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZtomv0z3F42 for ; Thu, 28 Feb 2013 17:57:02 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F521F855A for ; Thu, 28 Feb 2013 17:57:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OQQH64X58G000LED@mauve.mrochek.com> for imapext@ietf.org; Thu, 28 Feb 2013 17:51:50 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OQH0ICCQ1C000054@mauve.mrochek.com>; Thu, 28 Feb 2013 17:51:45 -0800 (PST) Message-id: <01OQQH610SWQ000054@mauve.mrochek.com> Date: Thu, 28 Feb 2013 17:48:40 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 01 Mar 2013 10:17:19 +1100" <1362093439.24752.140661198412837.455D416C@webmail.messagingengine.com> References: <8f052fc1-7b93-4ab7-a5f2-93b1f9e30734@flaska.net> <1361840733.26475.140661196848569.316FD765@webmail.messagingengine.com> <01OQP60K8K8E000054@mauve.mrochek.com> <1362093439.24752.140661198412837.455D416C@webmail.messagingengine.com> To: Bron Gondwana Cc: =?ISO-8859-1?Q?Jan=20Kundr=E1t?= , Ned Freed , imapext@ietf.org Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:57:03 -0000 > Is there significant correlation between incorrect strings and other bugs? Decades of experience says implementations that are sloppy about one thing are far more likely to be sloppy about other things. > There's > (in general) no way to tell how buggy the implementation you're talking to actually > is short of sanity checking its response. Obviously, the sort could be totally > bogus. Indeed. And of course some imlementations are so buggy it's a waste of time to even try. In such cases setting customer expectations early and correctly tends to have a much better outcome then iterating many times before finding yourself up against something you can't possibly work around. Ned From brong@fastmail.fm Thu Feb 28 18:14:39 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3A921F86F2 for ; Thu, 28 Feb 2013 18:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXNutZYWG5Fw for ; Thu, 28 Feb 2013 18:14:38 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id AD14F21F86F0 for ; Thu, 28 Feb 2013 18:14:38 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 28B7220B4A; Thu, 28 Feb 2013 21:14:38 -0500 (EST) Received: from web2.nyi.mail.srv.osa ([10.202.2.212]) by compute5.internal (MEProxy); Thu, 28 Feb 2013 21:14:38 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= zAuqlbe5wKbB0TUWlXXAYtqW7EU=; b=R5hVLH7P08pBn3ejGEpTSlW7viTtesvx g79KcbjAGwelETNx2AA36qSB3aryKV9HAMYSuKGRCrK3UvUq0ujdRHEfGbZO9DFV RBPBNp+fJchxWj9wxhlXFixPmbdgH2Zek7tlpowY/T1/HamUwgNSzEUqrDJyxkBE VyRJ4oVQwSI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=zAuqlbe5wKbB0TUWlXXAYtqW7EU=; b=Rky VYv4LsaISDUa6d+LyAU6U8ehAp1xakjM8grlj5ovLudwO4qLH1mtxVK+uxbRQEKQ pxBLums9eCO2VeOcBHQ8bkbyKNEE3+pl1c/Xi1EeXXIaEjl1NYSdlQHwlBGZpX19 p6QADtNJXBs5wB7QqTibF84S4f5dpw0x5c+vSI9o= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id F38EB201108; Thu, 28 Feb 2013 21:14:37 -0500 (EST) Message-Id: <1362104077.20908.140661198465145.61226F24@webmail.messagingengine.com> X-Sasl-Enc: N9pAjz2pmxpZeRyL7cCE8juEaOveMXO/kPPsDHcO+MQM 1362104077 From: Bron Gondwana To: Ned Freed MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html In-Reply-To: <01OQQH610SWQ000054@mauve.mrochek.com> References: <8f052fc1-7b93-4ab7-a5f2-93b1f9e30734@flaska.net> <1361840733.26475.140661196848569.316FD765@webmail.messagingengine.com> <01OQP60K8K8E000054@mauve.mrochek.com> <1362093439.24752.140661198412837.455D416C@webmail.messagingengine.com> <01OQQH610SWQ000054@mauve.mrochek.com> Date: Fri, 01 Mar 2013 13:14:37 +1100 Cc: =?ISO-8859-1?Q?Jan=20Kundr=E1t?= , imapext@ietf.org Subject: Re: [imapext] Accepting an "ESORT" response instead of an ESEARCH X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 02:14:39 -0000 On Fri, Mar 1, 2013, at 12:48 PM, Ned Freed wrote: > > Is there significant correlation between incorrect strings and other bugs? > > Decades of experience says implementations that are sloppy about one thing are > far more likely to be sloppy about other things. Yep. So you fall back to just downloading all the message bodies locally and doing your own sort. That tends to work pretty well (unless it's Lotus Notes, in which case all bets are off, because it mangles the raw message too) > > There's > > (in general) no way to tell how buggy the implementation you're talking to actually > > is short of sanity checking its response. Obviously, the sort could be totally > > bogus. > > Indeed. And of course some imlementations are so buggy it's a waste of time to > even try. In such cases setting customer expectations early and correctly tends > to have a much better outcome then iterating many times before finding yourself > up against something you can't possibly work around. Without an agreed-upon test suite, you get into he said/she said. Java nearly got this right, except for the whole keeping the test compatibility kit under obnoxious licensing. Bron. -- Bron Gondwana brong@fastmail.fm