Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R4xcGO069035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 21:59:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3R4xcxJ069034; Thu, 26 Apr 2007 21:59:38 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R4xbK1069017; Thu, 26 Apr 2007 21:59:37 -0700 (MST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Thu, 26 Apr 2007 23:59:38 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Thu, 26 Apr 2007 23:59:37 -0500 To: IETF-POP3EXT:;, IETF-IMAPEXT:;, IETF-SMTP:;, LEMONADE:;, IMA:; From: Pete Resnick Subject: Fwd: draft-resnick-2822upd-01 posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please follow the discussion on ietf-822@imc.org. --- begin forwarded text Date: Thu, 26 Apr 2007 16:55:06 -0500 To: ietf-822@imc.org From: Pete Resnick Subject: draft-resnick-2822upd-01 posted You may have noticed that 2822upd-01 was posted. Also: To make rfcdiff work, I've put a copy of RFC 2822 on my web site with some of the later sections rearranged so that they're in the same order as the current draft. You can see the diffs between the two here: Though overall very few, there are real changes from 2822 in this document that need review. See the changes section at the bottom. I did *not* go whole hog and switch to Bruce's syntax, simply because I wanted to limit the number of changes and see if we can't get this thing to Draft along with 2821bis. But I did incorporate (hopefully all of) the corrections that you all have pointed out over the last couple of years. Please review with a fine toothed comb. If there are more than just a few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who have at assorted time offered assistance) to start an issues list. Thanks in advance for your assistance. pr --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J5oAHt043151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 22:50:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3J5oA5k043150; Wed, 18 Apr 2007 22:50:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J5nmKE043122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Apr 2007 22:50:08 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3J5nf0Q022729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2007 22:49:42 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3J5ncL7018323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2007 22:49:40 -0700 Date: Wed, 18 Apr 2007 22:49:37 -0700 (PDT) From: Mark Crispin To: Dan Karp cc: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments , IMAP Protocol Interest List Subject: Re: [lemonade] SURVEY: How does SEARCH match in your IMAP server? In-Reply-To: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.com> Message-ID: References: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.co m> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-559819627-1176960403=:11458" Content-ID: X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.4.18.223836 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_AGE_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HIGHBITS 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SUBJ_PHRASE5 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-559819627-1176960403=:11458 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Your test examples aren't any good, because your message is in UTF-8 but=20 you have texts that are claimed to be ISO 8859-1. I will try to answer=20 what I *think* you intended. If my presumptions are wrong, then I reserve the right to change my=20 answers. On Wed, 18 Apr 2007, Dan Karp wrote: > server's name and version UW imapd, version imap-2006 series unless noted otherwise. > I love M=C3=B6tley Cr=C3=BCe ! Presumably, you mean "I love M" 0xf6 "tley Cr" 0xfc "e" > A001 SEARCH BODY "love" matches > A002 SEARCH BODY "LOVE" matches > A003 SEARCH CHARSET "iso-8859-1" BODY {4} > Cr=C3=BCe Presumably, you mean "Cr" 0xfc "e" matches in all versions since imap-4.1 error in imap-4 and earlier (10+ year old US-ASCII only version) > A004 SEARCH CHARSET "utf-8" BODY {5} > Cr=C3=83=C2=BCe Presuably, you mean "Cr" 0xc3 0xbc "e" matches in all versions since imap-4.1 error in imap-4 and earlier (10+ year old US-ASCII only version) > A005 SEARCH CHARSET "iso-8859-1" BODY {4} > CR=C3=9CE Presumably, you mean "CR" 0xdc "E" matches in imap-2006 series. does not match in earlier versions (earlier versions did i;ascii-casemap). error in imap-4 and earlier (10+ year old US-ASCII only version) -- 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. --0-559819627-1176960403=:11458-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4NWqP037408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 21:23:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3J4NWww037404; Wed, 18 Apr 2007 21:23:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4NVX1037394 for ; Wed, 18 Apr 2007 21:23:31 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id D8BF6810C3B; Wed, 18 Apr 2007 21:17:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 6908AFA864; Wed, 18 Apr 2007 21:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Djy+-tDvVZO3; Wed, 18 Apr 2007 21:23:29 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8258DFA863; Wed, 18 Apr 2007 21:23:29 -0700 (PDT) Date: Wed, 18 Apr 2007 21:23:29 -0700 (PDT) From: Dan Karp To: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments , IMAP Protocol Interest List Cc: Arnt Gulbrandsen Message-ID: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.com> Subject: SURVEY: How does SEARCH match in your IMAP server? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Originating-IP: [75.31.46.252] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3J4NVX1037395 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We're collecting hard data to help refine an upcoming IMAP extension (http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-10.txt). If you're developing an IMAP server, it would be a *great* help if you could take 3 minutes to answer a few questions about your server implementation. If you email responses back to me along with your server's name and version, I'll compile the results. Assume that you've just injected the following message into an empty INBOX: ---------------------------------------------------------------------- Subject: Music Date: Tue, 17 Apr 2007 16:53:02 -0700 (PDT) From: user1@example.com To: user2@example.com Content-Type: text/plain; charset="iso-8859-1" I love Mötley Crüe ! ---------------------------------------------------------------------- For each of the following SEARCH requests, would your server match the message, not match the message, return NO [BADCHARSET], or return some other NO or BAD response? A001 SEARCH BODY "love" A002 SEARCH BODY "LOVE" A003 SEARCH CHARSET "iso-8859-1" BODY {4} Crüe A004 SEARCH CHARSET "utf-8" BODY {5} Crüe A005 SEARCH CHARSET "iso-8859-1" BODY {4} CRÜE Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4JTfI037275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 21:19:29 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3J4JTXt037274; Wed, 18 Apr 2007 21:19:29 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4J7Aw037241 for ; Wed, 18 Apr 2007 21:19:27 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 1FB88810C38; Wed, 18 Apr 2007 21:12:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 9CF57FA863; Wed, 18 Apr 2007 21:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeWu0WpAvU2o; Wed, 18 Apr 2007 21:19:04 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 890F0FA862; Wed, 18 Apr 2007 21:19:04 -0700 (PDT) Date: Wed, 18 Apr 2007 21:19:04 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <594230642.32611176956344320.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Is this true? Do these servers really implement i;ascii-casemap as > > defined in RFC 4790? I'd expect any RFC 3501-compliant server that > > knows about more charsets than just US-ASCII to be supporting > > i;unicode-casemap and *not* i;ascii-casemap because of > > case-insensitive "SEARCH CHARSET". > > Build some consensus please. I chatted with Arnt, and he thinks it'd be worthwhile to canvas the troops and get some hard data on what various servers actually implement for their default SEARCH comparator. I've thrown together a little 5-question survey which I'll send out under separate cover. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIsxk1001241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 11:54:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HIsx7F001240; Tue, 17 Apr 2007 11:54:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIscsJ001163 for ; Tue, 17 Apr 2007 11:54:58 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 87CA1F0B59; Tue, 17 Apr 2007 21:54:36 +0300 (EEST) Subject: Re: ANNOTATEMORE and COMPARATOR From: Timo Sirainen To: Arnt Gulbrandsen Cc: lemonade@ietf.org, ietf-imapext@imc.org, Eric Burger , Alexey Melnikov , Dan Karp , Cyrus Daboo In-Reply-To: References: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-baA9QaoKY2tQJvsfXhIn" Date: Tue, 17 Apr 2007 21:54:36 +0300 Message-Id: <1176836076.16189.465.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-baA9QaoKY2tQJvsfXhIn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-17 at 20:25 +0200, Arnt Gulbrandsen wrote: > >> > If your aim is to make baseline COMPARATOR support fairly > >> > lightweight for IMAP servers, you may be constrained to only > >> > requiring i;unicode-casemap. > >> > >> Mumble. Given how many IMAP servers actually implement=20 > >> i;ascii-casemap and nothing else, I'm not happy doing that. Make=20 > >> some other people agree with you so Pete will say "WG consensus". > > > > Is this true? Do these servers really implement i;ascii-casemap as=20 > > defined in RFC 4790? I'd expect any RFC 3501-compliant server that=20 > > knows about more charsets than just US-ASCII to be supporting=20 > > i;unicode-casemap and *not* i;ascii-casemap because of=20 > > case-insensitive "SEARCH CHARSET". >=20 > Build some consensus please. My server implements only i;ascii-casemap currently, but that's just because I've been busy getting it stable and no-one's complained. I'm going to move to i;unicode-casemap soon, and I don't see a need for i;ascii-casemap. I'd think anyone who is going to implement COMPARATOR won't see i;unicode-casemap requirement as a problem. --=-baA9QaoKY2tQJvsfXhIn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQBGJRfsyUhSUUBViskRAltsAJ9lvWGeuiDlYgewmyoC8ySIphqyUwCYs/wm tKhlQLVXb9mHL+rS34DO7Q== =tFd3 -----END PGP SIGNATURE----- --=-baA9QaoKY2tQJvsfXhIn-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIq3ZF000511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 11:52:03 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HIq3p9000510; Tue, 17 Apr 2007 11:52:03 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIq29Q000496 for ; Tue, 17 Apr 2007 11:52:02 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6A7CC4AC22; Tue, 17 Apr 2007 20:52:03 +0200 (CEST) Message-Id: <7VZQvTpQsFkd+xU8NO8x8g.md5@libertango.oryx.com> Date: Tue, 17 Apr 2007 20:51:24 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Philip Guenther References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That shouldn't apply to someone like Dan, since he stores the data as UTF-16. He may have a nasty problem converting some of his Subject fields to unicode, but it's not a collation problem in his case. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIQGia092648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 11:26:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HIQGds092647; Tue, 17 Apr 2007 11:26:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIQEsb092639 for ; Tue, 17 Apr 2007 11:26:15 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id CA9AE4AC22; Tue, 17 Apr 2007 20:26:15 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 20:25:36 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: >> I wanted to permit implementations of i;ascii-casemap to do whatever >> comes easiest outside US-ASCII. However, the final RFC doesn't >> reflect my viewpoint in this respect. I don't remember why and >> don't feel like searching my archive. I certainly wasn't aware of >> the argument you bring up now. >> >> Do you think this is a signficant issue? It doesn't affect searching >> to a noticeable degree, and its impact on sorting is O(size of >> result set), not O(size of mailbox). > > Actually, yeah, it does impact search. If you search for > "Mtley Cre", i;ascii-casemap doesn't allow that > to match "MTLEY CRE". If you've only stored an > upcased version of the text, you can't tell the case on the original > and thus you can't determine if the non-ASCII accented characters > match under i;octet. By the time you get that far, you've eliminated almost all messages not in the actual result set, so opening and rechecking isn't so awfully expensive. >> > If your aim is to make baseline COMPARATOR support fairly >> > lightweight for IMAP servers, you may be constrained to only >> > requiring i;unicode-casemap. >> >> Mumble. Given how many IMAP servers actually implement >> i;ascii-casemap and nothing else, I'm not happy doing that. Make >> some other people agree with you so Pete will say "WG consensus". > > Is this true? Do these servers really implement i;ascii-casemap as > defined in RFC 4790? I'd expect any RFC 3501-compliant server that > knows about more charsets than just US-ASCII to be supporting > i;unicode-casemap and *not* i;ascii-casemap because of > case-insensitive "SEARCH CHARSET". Build some consensus please. I don't want to argue today - I'm in a mood to help little old ladies halfway across the street. Being civil is a strain. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HH6Cll075402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 10:06:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HH6CkO075401; Tue, 17 Apr 2007 10:06:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HH6AqT075394 for ; Tue, 17 Apr 2007 10:06:12 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 2197A810C8B; Tue, 17 Apr 2007 09:59:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id AAE8DFA865; Tue, 17 Apr 2007 10:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgb4PgawmRSa; Tue, 17 Apr 2007 10:06:04 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id E00B5FA862; Tue, 17 Apr 2007 10:06:04 -0700 (PDT) Date: Tue, 17 Apr 2007 10:06:04 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I wanted to permit implementations of i;ascii-casemap to do whatever > comes easiest outside US-ASCII. However, the final RFC doesn't reflect > my viewpoint in this respect. I don't remember why and don't feel like > searching my archive. I certainly wasn't aware of the argument you > bring up now. > > Do you think this is a signficant issue? It doesn't affect searching > to a noticeable degree, and its impact on sorting is O(size of result > set), not O(size of mailbox). Actually, yeah, it does impact search. If you search for "Mtley Cre", i;ascii-casemap doesn't allow that to match "MTLEY CRE". If you've only stored an upcased version of the text, you can't tell the case on the original and thus you can't determine if the non-ASCII accented characters match under i;octet. > > If your aim is to make baseline COMPARATOR support fairly > > lightweight for IMAP servers, you may be constrained to only > > requiring i;unicode-casemap. > > Mumble. Given how many IMAP servers actually implement i;ascii-casemap > and nothing else, I'm not happy doing that. Make some other people > agree with you so Pete will say "WG consensus". Is this true? Do these servers really implement i;ascii-casemap as defined in RFC 4790? I'd expect any RFC 3501-compliant server that knows about more charsets than just US-ASCII to be supporting i;unicode-casemap and *not* i;ascii-casemap because of case-insensitive "SEARCH CHARSET". Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGkKwf071708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 09:46:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HGkK5u071707; Tue, 17 Apr 2007 09:46:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGjwEe071648 for ; Tue, 17 Apr 2007 09:46:19 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 2DFB14AC22; Tue, 17 Apr 2007 18:45:59 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 18:45:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > i;ascii-casemap is problematic as well, for roughly the same reasons: > > Its equality, ordering, and substring operations are as for > i;octet, except that at first, the lower-case letters (octet > values 97-122) in each input string are changed to upper case > (octet values 65-90). > > Servers wishing to optimize i;unicode-casemap may well store only a > searchable upper case version of the text, which will sort > incorrectly under i;ascii-casemap. Good point. I wanted to permit implementations of i;ascii-casemap to do whatever comes easiest outside US-ASCII. However, the final RFC doesn't reflect my viewpoint in this respect. I don't remember why and don't feel like searching my archive. I certainly wasn't aware of the argument you bring up now. Do you think this is a signficant issue? It doesn't affect searching to a noticeable degree, and its impact on sorting is O(size of result set), not O(size of mailbox). > If your aim is to make baseline COMPARATOR support fairly lightweight > for IMAP servers, you may be constrained to only requiring > i;unicode-casemap. Mumble. Given how many IMAP servers actually implement i;ascii-casemap and nothing else, I'm not happy doing that. Make some other people agree with you so Pete will say "WG consensus". Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFqgiq061943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 08:52:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HFqgD7061942; Tue, 17 Apr 2007 08:52:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFqLr5061907 for ; Tue, 17 Apr 2007 08:52:42 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 993FA810C89; Tue, 17 Apr 2007 08:45:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 5F01DFA862; Tue, 17 Apr 2007 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxampf6gfOw6; Tue, 17 Apr 2007 08:52:18 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id A5685FA863; Tue, 17 Apr 2007 08:52:18 -0700 (PDT) Date: Tue, 17 Apr 2007 08:52:18 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > IMAP (via SEARCH) essentially requires that message content be > > searchable in some intermediate transcoded form (we chose UTF-16). > > COMPARATOR (via "i;octet") requires that message content be > > searchable in its original form pace content-encoding. > > Only i;octet does that... we did a lot of work for RFC4790 to allow > your kind of implementation, so I think it should be reasonable that > COMPARATOR allows it too. > > As far as I can see, the mention of i;octet in > draft-crispin-collation-unicasemap is the only substantial requirement > on i;octet, and it's weak. The one in draft-ietf-imapext-i18n is a > leftover - something I forgot to delete when its rationale > disappeared. i;ascii-casemap is problematic as well, for roughly the same reasons: Its equality, ordering, and substring operations are as for i;octet, except that at first, the lower-case letters (octet values 97-122) in each input string are changed to upper case (octet values 65-90). Servers wishing to optimize i;unicode-casemap may well store only a searchable upper case version of the text, which will sort incorrectly under i;ascii-casemap. COMPARATOR requires servers to implement both i;ascii-casemap and i;octet (though i;octet sounds like it may be on the way out). If your aim is to make baseline COMPARATOR support fairly lightweight for IMAP servers, you may be constrained to only requiring i;unicode-casemap. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFKGc9055167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 08:20:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HFKG0F055166; Tue, 17 Apr 2007 08:20:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFKEsS055159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 08:20:15 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9E6BF49800C; Tue, 17 Apr 2007 16:20:13 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17729-03; Tue, 17 Apr 2007 16:20:07 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id CC2E1498002; Tue, 17 Apr 2007 16:20:06 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> <4156.1176801621.000131@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <26269.1176823206.810258@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 16:20:06 +0100 From: Dave Cridland To: Mark Crispin Cc: Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Apr 17 14:30:14 2007, Mark Crispin wrote: > > On Tue, 17 Apr 2007, Dave Cridland wrote: >> I don't think it's quite right to state that "everything in IMAP >> is case-insensitive", since it seems intuitive to me that subject >> lines and other human-orientated text is demonstratively >> case-sensitive; it merely may be more useful to search it >> case-insensitively for much of the time. > > Take a time machine back 21 years and tell me that I am wrong for > specifying that everything in IMAP is case-insensitive. I would > have told you back then that you are wrong, and I see no good cause > to reverse that choice today. NO, ON FURTHER CONSIDERATION YOU'RE ABSOLUTELY RIGHT. CASE IS NEVER INDICATIVE OF ANYTHING, THEREFORE IT MAKES NO SENSE TO SEARCH FOR IT IN ANY INSTANCE. ALSO, ALL EMAIL SHOULD BE PRESENTED ON PROPER 80 COLUMN DISPLAYS, WITH NICE GREEN TEXT ON A PALE GREY SMEARED BACKGROUND YOU'RE ENCOURAGED TO CALL BLACK. Seriously, though, while I'd readily agree that case should be irrelevant in IMAP protocol elements - we've already had that argument, in fact - I don't see that the same applies to human-created, human-directed text, such as subject fields, where the paragraph above does show that case conveys information. It seems reasonable that we wouldn't want to mandate that clients should be prevented from searching case-sensitively. Similarly, many IMAP servers, by stripping away spaces and punctuation before the search test, can harm the usability of searches. Not always. Just sometimes. I don't think that's a contentious statement, and I suspect I've worded this badly if you're disagreeing with me this strongly. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HDUoA8039985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 06:30:51 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HDUo0K039984; Tue, 17 Apr 2007 06:30:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HDUTHF039932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Apr 2007 06:30:50 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3HDULhg032731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Apr 2007 06:30:21 -0700 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3HDUI75031000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Apr 2007 06:30:20 -0700 Date: Tue, 17 Apr 2007 06:30:14 -0700 From: Mark Crispin To: Dave Cridland cc: Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <4156.1176801621.000131@peirce.dave.cridland.net> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> <4156.1176801621.000131@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.17.61834 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 17 Apr 2007, Dave Cridland wrote: > I don't think it's quite right to state that "everything in IMAP is > case-insensitive", since it seems intuitive to me that subject lines and > other human-orientated text is demonstratively case-sensitive; it merely may > be more useful to search it case-insensitively for much of the time. Take a time machine back 21 years and tell me that I am wrong for specifying that everything in IMAP is case-insensitive. I would have told you back then that you are wrong, and I see no good cause to reverse that choice today. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9KU5R012805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 02:20:30 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H9KUoL012804; Tue, 17 Apr 2007 02:20:30 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9KR2N012798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 02:20:29 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3002F49800C; Tue, 17 Apr 2007 10:20:27 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14023-10; Tue, 17 Apr 2007 10:20:21 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 02038498002; Tue, 17 Apr 2007 10:20:21 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <4156.1176801621.000131@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 10:20:20 +0100 From: Dave Cridland To: Mark Crispin Cc: Arnt Gulbrandsen , Timo Sirainen , Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Apr 17 00:04:24 2007, Mark Crispin wrote: > > On Mon, 16 Apr 2007, Dave Cridland wrote: >> ACAP deals in arbitrary binary data which *might* be treatable as >> text - the server has no way of knowing. "i;octet" is remarkably >> useful at doing exact matches, whether text or binary, and was the >> only comparator capable of doing case-sensitive matching on text. >> In IMAP, this is the only use, and there are undoubtedly better >> ways of doing this. > > I don't understand. Everything in IMAP is case-insensitive by > definition. There is, AFAIK, no need or use for i;octet anywhere in > IMAP. As I said, I was searching for OMA in subject lines rather a lot yesterday - if I were able to have specified a case-sensitive match, I would have done, since the sequence "oma" appears rather a lot in spurious results. (Such as "Domain", "Automaton", and rather interestingly, "to make" and "from a" on several implementations). I don't think it's quite right to state that "everything in IMAP is case-insensitive", since it seems intuitive to me that subject lines and other human-orientated text is demonstratively case-sensitive; it merely may be more useful to search it case-insensitively for much of the time. (This is not a demand for an "i;unicode-not-casemap" or anything, merely an observation.) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9Br8f012121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 02:11:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H9BrFT012120; Tue, 17 Apr 2007 02:11:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9BVDj012075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 02:11:52 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3A5C649800C; Tue, 17 Apr 2007 10:11:28 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14023-05; Tue, 17 Apr 2007 10:11:22 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id E539D498002; Tue, 17 Apr 2007 10:11:21 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> In-Reply-To: <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> MIME-Version: 1.0 Message-Id: <4156.1176801081.929064@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 10:11:21 +0100 From: Dave Cridland To: Arnt Gulbrandsen Cc: Alexey Melnikov , Mark Crispin , Timo Sirainen , Cyrus Daboo , Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Apr 17 09:38:31 2007, Arnt Gulbrandsen wrote: > i;unicode-casemap contains a sentence which might be construed as > "and use i;octet from this point on". I'll try to suggest a > alternative wording there, something that reads naturally for an > UCS-4 implementation without i;octet. Well, to do "i;octet" would mean encoding to UTF-8 first. However, you get the same result if you perform a dictionary-like ordering over UCS-4, as far as I'm aware, so it's not a problem for collations, and equality tests work fine too. It's things like substring matching which cause problems, since you can search for a substring matching partial UTF-8 sequences in principle, however, if you've already called those out as illegal input at a protocol level (or "super-comparator" level in this case), even that's blocked. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8iapW009087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 01:44:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H8ia12009085; Tue, 17 Apr 2007 01:44:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8iYLm009073 for ; Tue, 17 Apr 2007 01:44:35 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 83DEC4AC22; Tue, 17 Apr 2007 10:44:35 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 10:43:54 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > IMAP (via SEARCH) essentially requires that message content be > searchable in some intermediate transcoded form (we chose UTF-16). > COMPARATOR (via "i;octet") requires that message content be > searchable in its original form pace content-encoding. Only i;octet does that... we did a lot of work for RFC4790 to allow your kind of implementation, so I think it should be reasonable that COMPARATOR allows it too. As far as I can see, the mention of i;octet in draft-crispin-collation-unicasemap is the only substantial requirement on i;octet, and it's weak. The one in draft-ietf-imapext-i18n is a leftover - something I forgot to delete when its rationale disappeared. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8dWsr008616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 01:39:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H8dWcV008615; Tue, 17 Apr 2007 01:39:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8dBqx008472 for ; Tue, 17 Apr 2007 01:39:31 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 349AD4AC22; Tue, 17 Apr 2007 10:39:12 +0200 (CEST) Message-Id: <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> Date: Tue, 17 Apr 2007 10:38:31 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Alexey Melnikov , Mark Crispin , Timo Sirainen , Cyrus Daboo References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Mon, 16 Apr 2007, Arnt Gulbrandsen wrote: >>> The only place I see i;octet required is i18n draft, so I guess it's >>> still possible to change it? >> That's the stated requirement. There may be an actual requirement >> elsewhere. SORT comes to mind. > > No. SORT would use i;unicode-casemap or (older servers) > i;ascii-casemap. I always assumed that i;octet was there as a > baseline for documentation purposes. I never implemen ted it. SORT requires a complete sort, doesn't it? Nothing other than i;octet provides that any more. i;unicode-casemap contains a sentence which might be construed as "and use i;octet from this point on". I'll try to suggest a alternative wording there, something that reads naturally for an UCS-4 implementation without i;octet. >>> Is there a reason why a client should be able to force a server to >>> use i;ascii-casemap if i;unicode-casemap is also available? >> Yes, but they're odd and weird. > > Examples, please? Any test suite. A test client wishing to test everything required by lemonade would append some carefully constructed messages and use search on them with i;ascii-casemap. An IMAP client which connects to n IMAP servers and executes the same commands on each, noting any differences between the server responses. I thought of something rather different last night, can't remember what it was. But odd and weird - nothing a MUA would do. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GNwkGJ041110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 16:58:46 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GNwkhE041109; Mon, 16 Apr 2007 16:58:46 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GNwPXX041098 for ; Mon, 16 Apr 2007 16:58:45 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A91D14225E; Mon, 16 Apr 2007 16:58:25 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSxavQh4htWb; Mon, 16 Apr 2007 16:58:19 -0700 (PDT) Received: from [192.168.20.132] (207.47.10.130.static.nextweb.net [207.47.10.130]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 733E914225D; Mon, 16 Apr 2007 16:58:18 -0700 (PDT) In-Reply-To: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06587902-2E31-44DC-883F-AB7E0E2150AE@osafoundation.org> Cc: ietf-imapext@imc.org, Mark Crispin , Cyrus Daboo , Dave Cridland , Kjetil Torgrim Homme Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: SORT on addresses Date: Mon, 16 Apr 2007 16:58:14 -0700 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Apr 12, 2007, at 7:05 AM, Arnt Gulbrandsen wrote: > > Dave Cridland writes: >> Yes, exactly - you've put it clearer than I did, but that's my >> intention. > > Fine phrasing. > >> I'd add a caveat that while I'll like to go all the way with the >> examination of what's needed, I wouldn't want to commit to >> producing capabilities to cover everything we find. > > Charter: Examine the types of sort, search and thread features > offered by modern email clients. Provide server-side extensions (to > IMAP, SMTP or other protocols) for that which it can be done faster > and/or better on the server. Speaking personally, +1 Email clients like OSAF's Chandler and Opera M2 are ill-served by servers that assume that mail is divided into digestible chunks in child mailboxes/folders and that folders are the primary way users find emails. Synch errors seem commoner (not assigning blame, merely noting what may be a spurious connection; I actually have no idea why this would be the case). Faceted browsers are potentially a strong UI model for applications where the user wants to find a particular object among thousands in a library or repository (MP3s in a music library, email, files on disk, bookmarks, etc). Many users are unwilling to sort all their data objects into folders and keywords or tags are not always filled in for individual objects even in a system that supports tagging. Most users can't easily construct search queries with multiple terms from scratch, yet they can use faceted browsers which implicitly do multiple term queries. Faceted browsing in some sense transcends both folder-sorted browsing and tagging/searching. In order to work well however it needs well-indexed data and good search functions. Lisa Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GN57vj028870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 16:05:08 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GN57Om028868; Mon, 16 Apr 2007 16:05:07 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GN4jlb028796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 16:05:06 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GN4dHX003440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 16:04:39 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GN4dpw027585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 16:04:39 -0700 Date: Mon, 16 Apr 2007 16:04:24 -0700 (Pacific Daylight Time) From: Mark Crispin To: Dave Cridland cc: Arnt Gulbrandsen , Timo Sirainen , Enhancements to Internet email to support diverse service enivronments , ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <4156.1176760749.310421@peirce.dave.cridland.net> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.155034 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 16 Apr 2007, Dave Cridland wrote: > ACAP deals in arbitrary binary data which *might* be treatable as text - the > server has no way of knowing. "i;octet" is remarkably useful at doing exact > matches, whether text or binary, and was the only comparator capable of doing > case-sensitive matching on text. > In IMAP, this is the only use, and there are undoubtedly better ways of doing > this. I don't understand. Everything in IMAP is case-insensitive by definition. There is, AFAIK, no need or use for i;octet anywhere in IMAP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GLxdsv015367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 14:59:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GLxdf0015366; Mon, 16 Apr 2007 14:59:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GLxHdY015297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2007 14:59:38 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 01C8849800C; Mon, 16 Apr 2007 22:59:15 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07595-07; Mon, 16 Apr 2007 22:59:09 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 52B46498002; Mon, 16 Apr 2007 22:59:09 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: MIME-Version: 1.0 Message-Id: <4156.1176760749.310421@peirce.dave.cridland.net> Date: Mon, 16 Apr 2007 22:59:09 +0100 From: Dave Cridland To: Arnt Gulbrandsen Cc: Mark Crispin , Timo Sirainen , Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Apr 16 20:38:51 2007, Arnt Gulbrandsen wrote: > Mark Crispin writes: >> AFAIK, i;octet was documented for completeness. > > FWIW: 2244 specified it, I don't know why, although I'm sure the > reason is in an archive somewhere. 4790 defined a registry and > inserted the preexisting collations. ACAP deals in arbitrary binary data which *might* be treatable as text - the server has no way of knowing. "i;octet" is remarkably useful at doing exact matches, whether text or binary, and was the only comparator capable of doing case-sensitive matching on text. In IMAP, this is the only use, and there are undoubtedly better ways of doing this. (I do feel the need, sometimes, for case sensitivity - as today, when searching for messages with the subject line including "OMA"). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJsdnJ089745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:54:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJsdnm089744; Mon, 16 Apr 2007 12:54:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJsHIm089694 for ; Mon, 16 Apr 2007 12:54:38 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.217] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 2EB14F0BCC; Mon, 16 Apr 2007 22:54:17 +0300 (EEST) In-Reply-To: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-877554154" Message-Id: Cc: lemonade@ietf.org, ietf-imapext@imc.org, Alexey Melnikov , Cyrus Daboo Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Date: Mon, 16 Apr 2007 22:54:09 +0300 To: Arnt Gulbrandsen X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-877554154 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 16.4.2007, at 22.35, Arnt Gulbrandsen wrote: >> I would also want to see i;octet requirement gone. Actually I'd go >> even a bit further. Is there a reason why a client should be able >> to force a server to use i;ascii-casemap if i;unicode-casemap is >> also available? > > Yes, but they're odd and weird. > >> I can't think of any, but it would reduce optimization >> possibilities for server implementations. > > i;ascii-casemap is the same as i;unicode-casemap for the > intersection of their definition set, which would give you these > optimisations back. (IIRC, and it's late and...) I'm just worried that some clients (or users) would select the i;ascii-casemap even when they could (or should) use i;unicode-casemap. Non-ASCII characters with i;ascii-casemap are different, so if the server optimized i;unicode-casemap searches and a client did a non- ASCII search with i;ascii-casemap, the server would have to verify the unicode-optimized matches by searching through the messages to see if the non-ASCII casing matches exactly or not. Probably not that big of a deal, but it would be pretty pointless extra code. --Apple-Mail-1-877554154 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD4DBQFGI9RlyUhSUUBViskRAuJVAJ0STb33TJNhAsj4cT/k+5gTe+9HeACWN+sZ 8yDs/02Q92RYgCbHqI2Hng== =SGj+ -----END PGP SIGNATURE----- --Apple-Mail-1-877554154-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJjtZd088603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:45:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJjtM8088602; Mon, 16 Apr 2007 12:45:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJjYst088521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 12:45:55 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GJjNYx009434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 12:45:23 -0700 X-Auth-Received: from Ningyo-no-Mori.Panda.COM ([166.129.255.148]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GJj7f2023754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 12:45:18 -0700 Date: Mon, 16 Apr 2007 12:44:33 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen cc: lemonade@ietf.org, ietf-imapext@imc.org, Cyrus Daboo , Alexey Melnikov , Timo Sirainen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.123434 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 16 Apr 2007, Arnt Gulbrandsen wrote: >> The only place I see i;octet required is i18n draft, so I guess it's still >> possible to change it? > That's the stated requirement. There may be an actual requirement elsewhere. > SORT comes to mind. No. SORT would use i;unicode-casemap or (older servers) i;ascii-casemap. I always assumed that i;octet was there as a baseline for documentation purposes. I never implemen ted it. >> Is there a reason why a client should be able to force a >> server to use i;ascii-casemap if i;unicode-casemap is also available? > Yes, but they're odd and weird. Examples, please? My software did i;ascii-casemap, but only in old versions as an interim measure. Newer versions are i;unicode-casemap only. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJdZBD087699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:39:35 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJdZGA087698; Mon, 16 Apr 2007 12:39:35 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJdXtV087689 for ; Mon, 16 Apr 2007 12:39:34 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E327D4AC22; Mon, 16 Apr 2007 21:39:34 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 21:38:51 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Mark Crispin , Timo Sirainen References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > AFAIK, i;octet was documented for completeness. FWIW: 2244 specified it, I don't know why, although I'm sure the reason is in an archive somewhere. 4790 defined a registry and inserted the preexisting collations. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJajkQ087272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:36:45 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJajCf087271; Mon, 16 Apr 2007 12:36:45 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJaNu4087173 for ; Mon, 16 Apr 2007 12:36:44 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 82E7F4AC23; Mon, 16 Apr 2007 21:36:24 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 21:35:41 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Alexey Melnikov , Timo Sirainen , Cyrus Daboo References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: <1176745413.16189.379.camel@hurina> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: > On Mon, 2007-04-16 at 19:08 +0200, Arnt Gulbrandsen wrote: >> I'm wondering whether the i;octet requirement has outlived its >> rationale. I know why it needed to be there in the early drafts >> (other collations fell back to i;octet for some input), but I don't >> know whether it needs to any more...? > > The only place I see i;octet required is i18n draft, so I guess it's > still possible to change it? That's the stated requirement. There may be an actual requirement elsewhere. SORT comes to mind. > I would also want to see i;octet requirement gone. Actually I'd go > even a bit further. Is there a reason why a client should be able to > force a server to use i;ascii-casemap if i;unicode-casemap is also > available? Yes, but they're odd and weird. > I can't think of any, but it would reduce optimization possibilities > for server implementations. i;ascii-casemap is the same as i;unicode-casemap for the intersection of their definition set, which would give you these optimisations back. (IIRC, and it's late and...) Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GI1JTK066077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 11:01:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GI1JMW066076; Mon, 16 Apr 2007 11:01:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GI0wxV065948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 11:01:18 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GI0o7b028048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 11:00:51 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GI0mDn004763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2007 11:00:49 -0700 Date: Mon, 16 Apr 2007 11:00:47 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: lemonade@ietf.org, IMAP Extensions WG Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <1176745413.16189.379.camel@hurina> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.104634 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: IMHO: i;ascii-casemap is important because there are legacy implementations that implement it. Specifically, i;ascii-casemap *is* effectively the comparator of IMAP since its creation in 1986. I believe that most modern IMAP server implementations do some version of i;unicode-casemap instead of i;ascii-casemap, and there is no way for the client to know with a server that does not otherwise support COMPARATOR. I can't imagine that a client would choose i;ascii-casemap instead of i;unicode-casemap. AFAIK, i;octet was documented for completeness. I would be alright with i;unicode-casemap as being mandatory-to-implement for COMPARATOR, and optional-to-implement (albeit with a SHOULD) instead of i;ascii-casemap for non-COMPARATOR servers. -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHqsuf063103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:52:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHqsb5063102; Mon, 16 Apr 2007 10:52:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHqXkb063038 for ; Mon, 16 Apr 2007 10:52:54 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 16 Apr 2007 18:52:33 +0100 Message-ID: <4623B7AC.10600@isode.com> Date: Mon, 16 Apr 2007 18:51:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: <1176745413.16189.379.camel@hurina> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: >Is the i;basic mentioned in i18n draft the same as i;octet? > > No. i;basic is defined in draft-gulbrandsen-collation-basic-01.txt. Note that the mandatory-to-implement in i18n draft is going to be i;unicode-casemap. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHhZfr061615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:43:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHhZGl061614; Mon, 16 Apr 2007 10:43:35 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHhYfk061607 for ; Mon, 16 Apr 2007 10:43:34 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id C6B56F0BBA; Mon, 16 Apr 2007 20:43:33 +0300 (EEST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR From: Timo Sirainen To: Arnt Gulbrandsen Cc: lemonade@ietf.org, ietf-imapext@imc.org, Alexey Melnikov , Cyrus Daboo In-Reply-To: <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K+TEBP4YHYMuMTvRZ4hT" Date: Mon, 16 Apr 2007 20:43:33 +0300 Message-Id: <1176745413.16189.379.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-K+TEBP4YHYMuMTvRZ4hT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-04-16 at 19:08 +0200, Arnt Gulbrandsen wrote: > I'm wondering whether the i;octet requirement has outlived its=20 > rationale. I know why it needed to be there in the early drafts (other=20 > collations fell back to i;octet for some input), but I don't know=20 > whether it needs to any more...? The only place I see i;octet required is i18n draft, so I guess it's still possible to change it? I would also want to see i;octet requirement gone. Actually I'd go even a bit further. Is there a reason why a client should be able to force a server to use i;ascii-casemap if i;unicode-casemap is also available? I can't think of any, but it would reduce optimization possibilities for server implementations. Is the i;basic mentioned in i18n draft the same as i;octet? --=-K+TEBP4YHYMuMTvRZ4hT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGI7XFyUhSUUBViskRAmXNAKCJDUxvg+eySM2NZbTNMdhPMwGTLwCfd5tA GoS1+Hnef8yXW7NZoKhQeoI= =WJFi -----END PGP SIGNATURE----- --=-K+TEBP4YHYMuMTvRZ4hT-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHKnF6057496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:20:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHKnna057495; Mon, 16 Apr 2007 10:20:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHKmN7057481 for ; Mon, 16 Apr 2007 10:20:49 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E69034AC23; Mon, 16 Apr 2007 19:20:48 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 19:20:05 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Mark Crispin , Timo Sirainen References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <1176742390.16189.364.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > For collations in the IMAP context, UTF-16 is problematic for i;octet, yes. > i;ascii-casemap, and i;unicode-casemap. I'm not sure about i;basic. None of these - the problem was raised about a year ago by an RFC 4790 reviewer and we solved it. Using UTF-16 or UTF-8 instead of a sensible unicode encoding may make it more difficult to implement e.g. i;ascii-casemap, but not especially. Every kind of processing is more difficult in UTF-* than in UCS-*, IMO, and most collations are just specific examples of this general rules. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHJIkb056872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:19:18 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHJIbV056871; Mon, 16 Apr 2007 10:19:18 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHJInP056863 for ; Mon, 16 Apr 2007 10:19:18 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id A7B0F810C47; Mon, 16 Apr 2007 10:12:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id BF44DF2923; Mon, 16 Apr 2007 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NRc8PyFwBp9; Mon, 16 Apr 2007 10:19:17 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 74602F2922; Mon, 16 Apr 2007 10:19:17 -0700 (PDT) Date: Mon, 16 Apr 2007 10:19:17 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > a) COMPARATOR is a reasonably heavy extension to implement > > I don't think COMPARATOR ought to be that. Various other extensions > require it, and it seems wrong for me that COMPARATOR should be > heavier than its users. Tail wagging dog. > > Tell me what makes COMPARATOR heavy? IMAP (via SEARCH) essentially requires that message content be searchable in some intermediate transcoded form (we chose UTF-16). COMPARATOR (via "i;octet") requires that message content be searchable in its original form pace content-encoding. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHFa8H056291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:15:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHFasg056290; Mon, 16 Apr 2007 10:15:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHFFHg056245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 10:15:36 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GHF8l8022755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 10:15:09 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GHF5Ug028505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2007 10:15:07 -0700 Date: Mon, 16 Apr 2007 10:15:04 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Dan Karp , lemonade@ietf.org, IMAP Extensions WG Subject: Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <1176742390.16189.364.camel@hurina> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <1176742390.16189.364.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.95936 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 16 Apr 2007, Timo Sirainen wrote: > On Mon, 2007-04-16 at 09:41 -0700, Dan Karp wrote: >> Searchable content is effectively transcoded to UTF-16. The original >> content needed for "i;octet" is available only by serially opening, >> reading, and reparsing each message in the mailbox (stored 1 file per >> message), which is sufficiently nonperformant that we can't permit it. > Do you support full substring searches as standard SEARCH command > requires? In Zimbra's feature list I see "Ability to search using a > prefix plus a wildcard", which seems like a "no" answer. In that case > you're already noncompliant. True. I'm not sure what "search using a prefix plus a wildcard" is supposed to mean in IMAP searching, which is of substrings only. For collations in the IMAP context, UTF-16 is problematic for i;octet, i;ascii-casemap, and i;unicode-casemap. I'm not sure about i;basic. I suggest that you use either UTF-8 or UCS-4. The attraction of UTF-16 is to save memory space and a mostly-constant width if most characters are in the BMP (thus effectively the same as UCS-2 handling), but at the cost of MUCH more complex handling of non-BMP characters. -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHD9fQ055830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:13:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHD9vL055829; Mon, 16 Apr 2007 10:13:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHD8FN055822 for ; Mon, 16 Apr 2007 10:13:08 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 49BA84AC22; Mon, 16 Apr 2007 19:13:09 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 19:12:25 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > a) COMPARATOR is a reasonably heavy extension to implement I don't think COMPARATOR ought to be that. Various other extensions require it, and it seems wrong for me that COMPARATOR should be heavier than its users. Tail wagging dog. Tell me what makes COMPATOR heavy? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH9L73055290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:09:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GH9LPm055289; Mon, 16 Apr 2007 10:09:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH9J9M055275 for ; Mon, 16 Apr 2007 10:09:20 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ED8754AC22; Mon, 16 Apr 2007 19:09:20 +0200 (CEST) Message-Id: <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> Date: Mon, 16 Apr 2007 19:08:37 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Cyrus Daboo References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > Searchable content is effectively transcoded to UTF-16. The original > content needed for "i;octet" is available only by serially opening, > reading, and reparsing each message in the mailbox (stored 1 file per > message), which is sufficiently nonperformant that we can't permit > it. Makes sense. (We do something similar, although in our case it the problem is mitigated by other circumstances.) I'm wondering whether the i;octet requirement has outlived its rationale. I know why it needed to be there in the early drafts (other collations fell back to i;octet for some input), but I don't know whether it needs to any more...? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH3reD053613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:03:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GH3rUT053612; Mon, 16 Apr 2007 10:03:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH3qHq053603 for ; Mon, 16 Apr 2007 10:03:52 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 59AE3810C45; Mon, 16 Apr 2007 09:57:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 7060FF2923; Mon, 16 Apr 2007 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+tM-HXrTYcC; Mon, 16 Apr 2007 10:03:52 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 482BDF2922; Mon, 16 Apr 2007 10:03:52 -0700 (PDT) Date: Mon, 16 Apr 2007 10:03:51 -0700 (PDT) From: Dan Karp To: Timo Sirainen Cc: Arnt Gulbrandsen , Eric Burger , Alexey Melnikov , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1176742390.16189.364.camel@hurina> Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Searchable content is effectively transcoded to UTF-16. The > > original content needed for "i;octet" is available only by serially > > opening, reading, and reparsing each message in the mailbox (stored 1 > > file per message), which is sufficiently nonperformant that we can't > > permit it. > > Do you support full substring searches as standard SEARCH command > requires? In Zimbra's feature list I see "Ability to search using a > prefix plus a wildcard", which seems like a "no" answer. In that case > you're already noncompliant. *That* is a red herring, and I believe that you know it. Can we please redirect the discussion back to the core issue, which is that a) COMPARATOR is a reasonably heavy extension to implement b) METADATA is meant to be a reasonably light extension to implement c) METADATA is being positioned as a prerequisite for many new extensions d) No METADATA entries appear able to make use of the COMPARATOR functionality Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGrnuv051098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:53:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGrnKb051097; Mon, 16 Apr 2007 09:53:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGrSPr051009 for ; Mon, 16 Apr 2007 09:53:48 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id BD932F0BF8; Mon, 16 Apr 2007 19:53:10 +0300 (EEST) Subject: Re: ANNOTATEMORE and COMPARATOR From: Timo Sirainen To: Dan Karp Cc: Arnt Gulbrandsen , Eric Burger , Alexey Melnikov , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org In-Reply-To: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fYPDKaFTsPDGb6/paBZs" Date: Mon, 16 Apr 2007 19:53:10 +0300 Message-Id: <1176742390.16189.364.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-fYPDKaFTsPDGb6/paBZs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-04-16 at 09:41 -0700, Dan Karp wrote: > > > Unfortunately, my server implementation is not compatible with=20 > > > COMPARATOR, in particular the requirement to support i;octet in=20 > > > SEARCH. > >=20 > > Why not? >=20 > Searchable content is effectively transcoded to UTF-16. The original con= tent needed for "i;octet" is available only by serially opening, reading, a= nd reparsing each message in the mailbox (stored 1 file per message), which= is sufficiently nonperformant that we can't permit it. Do you support full substring searches as standard SEARCH command requires? In Zimbra's feature list I see "Ability to search using a prefix plus a wildcard", which seems like a "no" answer. In that case you're already noncompliant. --=-fYPDKaFTsPDGb6/paBZs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGI6n1yUhSUUBViskRAqOyAJ4v8JioTLJXABDMMQTsJkHI2GIVFQCZAdXa DV+uZVkeW2hKLPcIvZGdXMU= =fkR5 -----END PGP SIGNATURE----- --=-fYPDKaFTsPDGb6/paBZs-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGfYCE048690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:41:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGfYYC048689; Mon, 16 Apr 2007 09:41:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGfXhs048683 for ; Mon, 16 Apr 2007 09:41:33 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 5AB9B810C48; Mon, 16 Apr 2007 09:35:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8B464F2923; Mon, 16 Apr 2007 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt0DP9Ysv3AF; Mon, 16 Apr 2007 09:41:33 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 90F12F2922; Mon, 16 Apr 2007 09:41:33 -0700 (PDT) Date: Mon, 16 Apr 2007 09:41:33 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Unfortunately, my server implementation is not compatible with > > COMPARATOR, in particular the requirement to support i;octet in > > SEARCH. > > Why not? Searchable content is effectively transcoded to UTF-16. The original content needed for "i;octet" is available only by serially opening, reading, and reparsing each message in the mailbox (stored 1 file per message), which is sufficiently nonperformant that we can't permit it. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGZqZX048162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:35:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGZqYn048161; Mon, 16 Apr 2007 09:35:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGZU0l048097 for ; Mon, 16 Apr 2007 09:35:51 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6FC664AC23; Mon, 16 Apr 2007 18:35:31 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 18:34:46 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Cyrus Daboo References: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > Unfortunately, my server implementation is not compatible with > COMPARATOR, in particular the requirement to support i;octet in > SEARCH. Why not? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGFMHL044951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:15:22 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGFM3V044950; Mon, 16 Apr 2007 09:15:22 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGF164044912 for ; Mon, 16 Apr 2007 09:15:21 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 9D714810C47; Mon, 16 Apr 2007 09:08:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id CA590F2923; Mon, 16 Apr 2007 09:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsauBtrqkC7C; Mon, 16 Apr 2007 09:14:57 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id CC622F2922; Mon, 16 Apr 2007 09:14:57 -0700 (PDT) Date: Mon, 16 Apr 2007 09:14:57 -0700 (PDT) From: Dan Karp To: Alexey Melnikov Cc: Eric Burger , Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG , Cyrus Daboo Message-ID: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <461A8EFC.5050208@isode.com> Subject: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd really like to implement LEMONADE. LEMONADE consists of several IMAP extensions which require METADATA, and the current METADATA draft in turn requires LIST-EXTENDED and COMPARATOR. Unfortunately, my server implementation is not compatible with COMPARATOR, in particular the requirement to support i;octet in SEARCH. I'm hoping that there's a way to come to a compromise whereby METADATA can return to not requiring COMPARATOR while still maintaining all its core functionality. I'd hate for such a small thing to be a roadblock for my and others' LEMONADE implementations. Right now, METADATA uses COMPARATOR to specify LIST-EXTENDED selection constraints. The GETMETADATA command doesn't appear to support these constraints at present (though this may be an oversight): getmetadata = "GETMETADATA" SP entries SP attribs entries = entry-match / "(" entry-match *(SP entry-match) ")" entry-match = list-mailbox attribs = attrib / "(" attrib *(SP attrib) ")" attrib = astring I've looked through all the entries defined by the base METADATA draft as well as those defined by several of the LEMONADE drafts that metion METADATA (/comment, /motd, /admin, /sort, /thread, /check, /checkperiod, /convert/..., etc.). None of these appear to benefit in a meaningful way from the LIST-EXTENDED match/collation feature, so I'm gathering that the inclusion of COMPARATOR is intended as more of a nice-to-have with an eye towards accommodating possible future needs rather than a real core METADATA feature. If this is the case -- and towards the end of making METADATA a workable foundation extension that every server can implement -- I'd like to request that the LIST-EXTENDED METADATA selection option type be removed from the METADATA draft. If in the future there is a new METADATA entry that would substantially benefit from using COMPARATOR with LIST-EXTENDED, it should be possible to reintroduce this functionality (or a subset thereof) in the same RFC that registers the new entry. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3FABFnn065642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Apr 2007 03:11:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3FABFoB065641; Sun, 15 Apr 2007 03:11:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3FAApcK065615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 15 Apr 2007 03:11:13 -0700 (MST) (envelope-from Zoltan.Ordogh@nokia.com) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3FAAUKa026889; Sun, 15 Apr 2007 13:10:46 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:10:43 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:10:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [lemonade] Deprecate IMAP IDLE? Date: Sun, 15 Apr 2007 13:08:52 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15753D1A6@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Deprecate IMAP IDLE? Thread-Index: Acd+0X4e+5zWMdevTxyR0B6qrbM66wAdB4wA References: From: To: , Cc: X-OriginalArrivalTime: 15 Apr 2007 10:10:43.0076 (UTC) FILETIME=[539FAC40:01C77F46] X-Nokia-AV: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3FABEcJ065636 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Pete, You said: >Take a look at LEMONADE, >for example. There is really little going on in LEMONADE that >could not have been done in IMAPEXT. It's pretty much the same >people and it's mostly IMAP work. I think that this one might argue that deprecating IMAP IDLE is in fact in the charter for LEMONADE. Joke level: 10%. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EK2FMo096238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 13:02:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EK2FWv096237; Sat, 14 Apr 2007 13:02:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EK2Eg9096231 for ; Sat, 14 Apr 2007 13:02:14 -0700 (MST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Sat, 14 Apr 2007 15:02:14 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sat, 14 Apr 2007 15:02:08 -0500 To: Arnt Gulbrandsen From: Pete Resnick Subject: Re: [lemonade] Deprecate IMAP IDLE? Cc: IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 4/14/07 at 9:16 PM +0200, Arnt Gulbrandsen wrote: >Don't you think we should prolong the life of IMAPEXT by keeping it >alive until each of its standards-track products either has reached >full standard or certainly won't proceed further along the standards >track? > >(I'm only half joking. Well, only 60% joking.) OK, so since we're only half joking, let me be half (well, maybe three-quarters) serious. Working groups are supposed to be short-lived task-oriented groups, not long lived review bodies looking for things to do. Aside from the organizational reasons to do that, I think there is a good (albeit sociological/psychological) reason to shut down old working groups and start up new ones: People simply run out of energy to do good work in long ongoing efforts and get re-energized when there is a new, specific effort. Take a look at LEMONADE, for example. There is really little going on in LEMONADE that could not have been done in IMAPEXT. It's pretty much the same people and it's mostly IMAP work. But the fact that it was a new effort with a specific (well, mostly specific) goal in mind re-energized people and got them working toward that goal. The act of chartering (getting everyone to step back and decide what they're doing in the "bigger picture", coming up with a case for the IESG and the rest of the community, dividing up the tasks, etc.), writing -00 drafts, getting new chairs and document editors, along with the simple fact that the work *feels* new, makes the work go forward. So, no, I don't think it's good to keep working groups around when they get really old. (This does leave open the question of how to progress things along the standards track without a WG, and I think that the IESG should--and is starting to--look at that issue.) pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EJHXYR093361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 12:17:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EJHXnZ093360; Sat, 14 Apr 2007 12:17:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EJHCD3093270 for ; Sat, 14 Apr 2007 12:17:33 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 417A54AC22; Sat, 14 Apr 2007 21:17:13 +0200 (CEST) Message-Id: Date: Sat, 14 Apr 2007 21:16:20 +0200 From: Arnt Gulbrandsen To: Pete Resnick Subject: Re: [lemonade] Deprecate IMAP IDLE? Cc: IMAP Extensions WG References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Mr. Chair. Don't you think we should prolong the life of IMAPEXT by keeping it alive until each of its standards-track products either has reached full standard or certainly won't proceed further along the standards track? (I'm only half joking. Well, only 60% joking.) Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EIuJ4S090058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 11:56:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EIuJW6090057; Sat, 14 Apr 2007 11:56:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EItwfo090034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 14 Apr 2007 11:56:18 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3EItv3Y021665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Apr 2007 11:55:57 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3EItkRk004342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Apr 2007 11:55:56 -0700 Date: Sat, 14 Apr 2007 11:55:45 -0700 (PDT) From: Mark Crispin To: Pete Resnick cc: IMAP Extensions WG Subject: Re: SORT on addresses In-Reply-To: Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> <461E64F8.6030206@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.14.114434 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 14 Apr 2007, Pete Resnick wrote: > On 4/12/07 at 5:57 PM +0100, Alexey Melnikov wrote: >> Mark Crispin wrote: >>> And once again, IMAPEXT finds yet another way to prolong its life. >> IMHO, for this work to happen as an official WG, either IMAPEXT needs to >> recharter, or a new WG should be formed. >> I am slightly in favor of the latter. > *If* this work happens, I am *overwhelmingly* in favor of the later. +1 (in case it wasn't obvious) -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EIrGfF089943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 11:53:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EIrGDR089942; Sat, 14 Apr 2007 11:53:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EIqtTK089930 for ; Sat, 14 Apr 2007 11:53:15 -0700 (MST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Sat, 14 Apr 2007 13:52:55 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <461E64F8.6030206@isode.com> References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> <461E64F8.6030206@isode.com> X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sat, 14 Apr 2007 13:52:49 -0500 To: Alexey Melnikov From: Pete Resnick Subject: Re: SORT on addresses Cc: Mark Crispin , IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 4/12/07 at 5:57 PM +0100, Alexey Melnikov wrote: >Mark Crispin wrote: > >>And once again, IMAPEXT finds yet another way to prolong its life. > >IMHO, for this work to happen as an official WG, either IMAPEXT >needs to recharter, or a new WG should be formed. >I am slightly in favor of the latter. *If* this work happens, I am *overwhelmingly* in favor of the later. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CIRo6V031096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:27:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CIRo4w031095; Thu, 12 Apr 2007 11:27:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CIRTdE031072 for ; Thu, 12 Apr 2007 11:27:49 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CIRTTI024601 for ; Thu, 12 Apr 2007 18:27:29 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00901DXK0K00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 12:27:29 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE00318DXRLQE4@mail-amer.sun.com> for ietf-imapext@imc.org; Thu, 12 Apr 2007 12:27:28 -0600 (MDT) Date: Thu, 12 Apr 2007 11:26:28 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: ietf-imapext@imc.org Message-id: <004401c77d30$16d330b0$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9Lr05zglNFgO7S3GvMgOYc93okQAAIcDw References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> <003c01c77d2b$9f8ca990$e2239681@Tundra> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To: "Fredrick the Great" , friends: bob@domain, sally@domain; Sort on Fredrick the Great To: fred@domain, friends: bob@domain, sally@domain; Sort on fred@domain To: friends: bob@domain, sally@domain;, fred@domain Sort friends To: friends: "Robert the Bruce", sally@domain;, fred@domain Sort friends Peter -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Philip Guenther Sent: April 12, 2007 11:02 To: Peter Coates Cc: ietf-imapext@imc.org Subject: RE: SORT on addresses On Thu, 12 Apr 2007, Peter Coates wrote: > The display name of the group if there is one, failing which the > display name of the first address, failing which the first address. Is > the algorithm. So this: To: fred@domain, friends: bob@domain, sally@domain; will sort on 'friends' and not 'fred'? Interesting. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI6YdI028807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:06:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CI6YWA028806; Thu, 12 Apr 2007 11:06:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI6DjC028776 for ; Thu, 12 Apr 2007 11:06:33 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CI6Dqe003749 for ; Thu, 12 Apr 2007 18:06:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00H01CXXUK00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 12:06:13 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE003TUCYBLTL3@mail-amer.sun.com>; Thu, 12 Apr 2007 12:06:13 -0600 (MDT) Date: Thu, 12 Apr 2007 11:05:12 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: "'Philip Guenther'" Cc: ietf-imapext@imc.org Message-id: <003e01c77d2d$1e76a200$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9LLmlH/VVGgSWQ2+Qzk3ZsPvfbgAAFlAw References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> <003c01c77d2b$9f8ca990$e2239681@Tundra> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: No. The algorithm uses the first address it finds. If that is a group, OK, but in this case the first thing it finds is fred@domain, so that is what it uses Peter -----Original Message----- From: Philip Guenther [mailto:guenther+imap@sendmail.com] Sent: April 12, 2007 11:02 To: Peter Coates Cc: ietf-imapext@imc.org Subject: RE: SORT on addresses On Thu, 12 Apr 2007, Peter Coates wrote: > The display name of the group if there is one, failing which the > display name of the first address, failing which the first address. Is > the algorithm. So this: To: fred@domain, friends: bob@domain, sally@domain; will sort on 'friends' and not 'fred'? Interesting. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI2CV8028561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:02:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CI2Cuj028560; Thu, 12 Apr 2007 11:02:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI2BYK028554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 11:02:12 -0700 (MST) (envelope-from guenther+imap@sendmail.com) Received: from [192.168.123.102] (71-218-108-183.hlrn.qwest.net [71.218.108.183]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l3CI4sgf023810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:04:56 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l3CI4sgf023810 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1176401097; bh=GMJzgaeM6fg1r9MSeCpIUW6bRY4=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=WFyGNnbVSn9Ca0hT 5vEXYLQDngLppzsDl1X5VymaJKEW87HEHYcSBEEg/9R+JDUKU8k9zv9eU9adCgm6/Sv CeLiBkP78NT2bMdDlNPOaOesUaXNcMQ541/3VL9Olrtj7N7OpIZuDR6J9mXNb/9LvXE cJyTF86V1NxXQqe5b4toc= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l3CI4sgf023810 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=BOOakgUZpgICCGWTjYKpqzVdTzqwwCiLn/2VdAEjp+oxoHkgOjRVmrOOBsyL642+5 iYDdQVe5QZVdHLxYnGWiXYu523fqDlwzQ9ROIhI1Syg1pj7I1XyZezqDLkRM9f2peht VDKNa1gbC4HRF94V0TzO2a4u2Skp97kHTI0Akew= Date: Thu, 12 Apr 2007 12:02:01 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Peter Coates cc: ietf-imapext@imc.org Subject: RE: SORT on addresses In-Reply-To: <003c01c77d2b$9f8ca990$e2239681@Tundra> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> <003c01c77d2b$9f8ca990$e2239681@Tundra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 12 Apr 2007, Peter Coates wrote: > The display name of the group if there is one, failing which the display > name of the first address, failing which the first address. Is the > algorithm. So this: To: fred@domain, friends: bob@domain, sally@domain; will sort on 'friends' and not 'fred'? Interesting. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHtqu4027793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:55:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CHtqvi027792; Thu, 12 Apr 2007 10:55:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHtVK5027769 for ; Thu, 12 Apr 2007 10:55:52 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CHtVnq018902 for ; Thu, 12 Apr 2007 17:55:31 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00601C9SRQ00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 11:55:31 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE00JPBCGH3TB2@mail-amer.sun.com>; Thu, 12 Apr 2007 11:55:30 -0600 (MDT) Date: Thu, 12 Apr 2007 10:54:30 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: "'Philip Guenther'" Cc: ietf-imapext@imc.org Message-id: <003c01c77d2b$9f8ca990$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9KMMsHBU/RC5QTJWjHzZQVcecwQAAtjpQ References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The display name of the group if there is one, failing which the display name of the first address, failing which the first address. Is the algorithm. -----Original Message----- From: Philip Guenther [mailto:guenther+imap@sendmail.com] Sent: April 12, 2007 10:33 To: Peter Coates Cc: ietf-imapext@imc.org Subject: RE: SORT on addresses On Thu, 12 Apr 2007, Peter Coates wrote: > Being incompetent, I replied, rather than replied all when I sent a > note saying that the Sun imap server uses sort keys X-SUN-TO, > X-SUN-CC, X-SUN-FROM to sort by display-name or if display name is not > present the email address. For obvious reasons I like that algorithm. The display-name of the first actual address or will it use the display-name of a group? Hmm, the current SORT address keys use the first addr-mailbox, so they don't skip groups but will sort something like To: friends: bob@domain, sally@domain; with the key "friends"...which will be annoying if the display-name contains an RFC 2047 word, as there's no mention of decoding them like there is for the SUBJECT key. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHXsZs025666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:33:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CHXsJs025665; Thu, 12 Apr 2007 10:33:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHXXwI025628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 10:33:54 -0700 (MST) (envelope-from guenther+imap@sendmail.com) Received: from [192.168.123.102] (71-218-108-183.hlrn.qwest.net [71.218.108.183]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l3CHaF6I020111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:36:18 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l3CHaF6I020111 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1176399379; bh=YoiRmCGNe43nr3tfQdT78hU4mHw=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=bYXMCQSxpPwtIjnw 3JPC0pZOHFjNWRSmJaNxxk59DrQy+cCV83Sk275axwpXPFkCSJq9WBSMIxWfeu13a5l tomJKy4jjmv5uEv+rSQtDY6AX22kH34ARw5d1kOhEEyRleTkKC3KY2ySF/mLkT7pxVz vXGGsBo19wtbD2/ygF1c0= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l3CHaF6I020111 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=k7WaAYABx7+qq4/hAi6B8/g2QkpiWiRe6zzi5UmbU8lGLfwipiX0iWSzAjdAvuvr8 xYBNYm4iCuDUBb+Z9oXevZKNmshdwYw+6ePxYO30sEBJeKhIEXkdLlglZwOq/OQ2BQM uz0gJW/D8W7pJD6F2P4kACQ07V3C2k1zHvubQN8= Date: Thu, 12 Apr 2007 11:33:21 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Peter Coates cc: ietf-imapext@imc.org Subject: RE: SORT on addresses In-Reply-To: <002501c77d1f$eeafdf30$e2239681@Tundra> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 12 Apr 2007, Peter Coates wrote: > Being incompetent, I replied, rather than replied all when I sent a note > saying that the Sun imap server uses sort keys X-SUN-TO, X-SUN-CC, > X-SUN-FROM to sort by display-name or if display name is not present the > email address. For obvious reasons I like that algorithm. The display-name of the first actual address or will it use the display-name of a group? Hmm, the current SORT address keys use the first addr-mailbox, so they don't skip groups but will sort something like To: friends: bob@domain, sally@domain; with the key "friends"...which will be annoying if the display-name contains an RFC 2047 word, as there's no mention of decoding them like there is for the SUBJECT key. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHI24r024489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:18:02 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CHI2gg024488; Thu, 12 Apr 2007 10:18:02 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHHf3w024462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 10:18:01 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CHHc8Z022481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2007 10:17:38 -0700 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CHHZHW028815 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Apr 2007 10:17:37 -0700 Date: Thu, 12 Apr 2007 10:16:58 -0700 From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: SORT on addresses In-Reply-To: <461E64F8.6030206@isode.com> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> <461E64F8.6030206@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.12.100735 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 12 Apr 2007, Alexey Melnikov wrote: > IMHO, for this work to happen as an official WG, either IMAPEXT needs to > recharter, or a new WG should be formed. > I am slightly in favor of the latter. Personally, I feel that it is long past time for IMAPEXT to die. Nor should there be a replacement any time in the short-term future. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGwgx3022583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 09:58:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CGwgO9022582; Thu, 12 Apr 2007 09:58:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGwM6N022569 for ; Thu, 12 Apr 2007 09:58:42 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 12 Apr 2007 17:58:21 +0100 Message-ID: <461E64F8.6030206@isode.com> Date: Thu, 12 Apr 2007 17:57:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > And once again, IMAPEXT finds yet another way to prolong its life. IMHO, for this work to happen as an official WG, either IMAPEXT needs to recharter, or a new WG should be formed. I am slightly in favor of the latter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGWK19020568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 09:32:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CGWKPX020567; Thu, 12 Apr 2007 09:32:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGVxU6020544 for ; Thu, 12 Apr 2007 09:32:19 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CGVo9x013117 for ; Thu, 12 Apr 2007 16:31:59 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00H018APOT00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 10:31:50 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE00LHW8KZIXH0@mail-amer.sun.com>; Thu, 12 Apr 2007 10:31:49 -0600 (MDT) Date: Thu, 12 Apr 2007 09:30:47 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: "'Cyrus Daboo'" , "'Dave Cridland'" , "'Mark Crispin'" Cc: ietf-imapext@imc.org, "'Kjetil Torgrim Homme'" Message-id: <002501c77d1f$eeafdf30$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9CJgy2MM85ObHTDWWOCrD6bs4rwAFrRXA References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are a class of clients that DO use server side sort and search, and those are web clients. These are probably used more than desktop imap clients. And lemonade is premised on the assumption that mobile devices will use imap and are too strapped for processing power to do more than the necessary. Being incompetent, I replied, rather than replied all when I sent a note saying that the Sun imap server uses sort keys X-SUN-TO, X-SUN-CC, X-SUN-FROM to sort by display-name or if display name is not present the email address. For obvious reasons I like that algorithm. Peter -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Cyrus Daboo Sent: April 12, 2007 06:27 To: Dave Cridland; Mark Crispin Cc: ietf-imapext@imc.org; Kjetil Torgrim Homme Subject: Re: SORT on addresses Hi Dave, --On April 12, 2007 10:03:46 AM +0100 Dave Cridland wrote: > I think that there would be serious advantage to taking a step back at > this point, and examining how users and UAs are currently searching > through mail, and see how we could make this both more efficient and > closer to the end-users' requirements. Right now, I think that IMAP > provides only rudimentary "organizational" abilities, and I think that > they're showing up as a weak point in IMAP. Lets face it, very few clients really use server-side sort/thread/search. Most download and cache and do local operations because they can offer much, much more in the way of features for that. If we are going to make changes to the server-side behavior we should go all the way. Examine the types of features offered by desktop clients doing local operations and match those with server-side capabilities. Anything less is a poor half-measure. -- Cyrus Daboo Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CFTLdL015367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 08:29:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CFTLqS015366; Thu, 12 Apr 2007 08:29:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CFTJiv015351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 08:29:21 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 059D549800E; Thu, 12 Apr 2007 16:29:19 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30401-09; Thu, 12 Apr 2007 16:29:12 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id DEDED49800B; Thu, 12 Apr 2007 16:29:12 +0100 (BST) Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <6701.1176391752.909903@peirce.dave.cridland.net> Date: Thu, 12 Apr 2007 16:29:12 +0100 From: Dave Cridland To: Mark Crispin Cc: Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Apr 12 15:29:27 2007, Mark Crispin wrote: > > And once again, IMAPEXT finds yet another way to prolong its life. No, we should come up with a much more contrived acronym than that. :-) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CFO4Wh014524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 08:24:04 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CFO433014523; Thu, 12 Apr 2007 08:24:04 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3CFNhxU014381 for ; Thu, 12 Apr 2007 08:24:03 -0700 (MST) (envelope-from tony@att.com) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1176391417!23078218!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1725 invoked from network); 12 Apr 2007 15:23:37 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 12 Apr 2007 15:23:37 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3CFNSqg016993 for ; Thu, 12 Apr 2007 11:23:28 -0400 (EDT) Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3CFMgoR016532 for ; Thu, 12 Apr 2007 11:22:43 -0400 (EDT) Received: from [135.210.81.204] (unknown[135.210.81.204](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070412152242gw10010g62e> (Authid: tony); Thu, 12 Apr 2007 15:22:42 +0000 Message-ID: <461E4FE5.8000104@att.com> Date: Thu, 12 Apr 2007 11:27:33 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 CC: IMAP Extensions WG Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: what, you expected a rest? Silly Pooh Bear, in the words of the immortal Christopher Robin. :-) Mark Crispin wrote: > > And once again, IMAPEXT finds yet another way to prolong its life. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEkfeJ010628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:46:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CEkfCf010627; Thu, 12 Apr 2007 07:46:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEkePX010620 for ; Thu, 12 Apr 2007 07:46:41 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B6B034AC44; Thu, 12 Apr 2007 16:46:41 +0200 (CEST) Message-Id: Date: Thu, 12 Apr 2007 16:45:38 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: SORT on addresses Cc: Mark Crispin References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > And once again, IMAPEXT finds yet another way to prolong its life. IMAP is the protocol that just won't lie down and die. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEgNhY010107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:42:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CEgNL0010106; Thu, 12 Apr 2007 07:42:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEgLaL010090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 07:42:22 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hc0V8-00083g-Q2; Thu, 12 Apr 2007 16:42:18 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hc0V8-0007jW-4g; Thu, 12 Apr 2007 16:42:18 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx8.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1Hc0V8-0007jT-16; Thu, 12 Apr 2007 16:42:18 +0200 Subject: Re: SORT on addresses From: Kjetil Torgrim Homme To: Cyrus Daboo Cc: ietf-imapext@imc.org In-Reply-To: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain Date: Thu, 12 Apr 2007 16:42:16 +0200 Message-Id: <1176388937.1096.29.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=12.0, autolearn=disabled, AWL=0.148,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: E951D6C56428B3628905DF987DC3D124053500E7 X-UiO-Ratelimit-Test: Ratelimit X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: -48 maxlevel 200 minaction 2 bait 0 mail/h: 1357 total 1021701 max/h 7466 blacklist 0 greylist 0 ratelimit 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2007-04-12 at 09:27 -0400, Cyrus Daboo wrote: > Lets face it, very few clients really use server-side sort/thread/search. > Most download and cache and do local operations because they can offer > much, much more in the way of features for that. ironically(?), webmail applications are probably the most common user of "stateless" IMAP. this is a space where improvements in server and client are relatively easily deployed, so it's not a bad space to work in. > If we are going to make changes to the server-side behavior we should go > all the way. Examine the types of features offered by desktop clients doing > local operations and match those with server-side capabilities. Anything > less is a poor half-measure. I wouldn't word it that strongly, but sure -- sounds like you have the work cut out for us. one thing is to finalise complicated stuff like "context", there are also simple things like standardise on flags for "Spam" and "Ham" which could do wonders for client interoperability. -- Kjetil T. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CETxSf007917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:29:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CETxra007916; Thu, 12 Apr 2007 07:29:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CETcrd007893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 07:29:58 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CETb2r008365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Apr 2007 07:29:37 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CETSw1003233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Apr 2007 07:29:36 -0700 Date: Thu, 12 Apr 2007 07:29:27 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: Re: SORT on addresses In-Reply-To: Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.12.71634 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: And once again, IMAPEXT finds yet another way to prolong its life. -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CE6uXX005364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:06:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CE6ugJ005363; Thu, 12 Apr 2007 07:06:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CE6Ztb005344 for ; Thu, 12 Apr 2007 07:06:55 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3619D4AC44; Thu, 12 Apr 2007 16:06:36 +0200 (CEST) Message-Id: Date: Thu, 12 Apr 2007 16:05:32 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: SORT on addresses Cc: Mark Crispin , Cyrus Daboo , Dave Cridland , Kjetil Torgrim Homme References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: <6701.1176385567.036132@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: > Yes, exactly - you've put it clearer than I did, but that's my intention. Fine phrasing. > I'd add a caveat that while I'll like to go all the way with the > examination of what's needed, I wouldn't want to commit to producing > capabilities to cover everything we find. Charter: Examine the types of sort, search and thread features offered by modern email clients. Provide server-side extensions (to IMAP, SMTP or other protocols) for that which it can be done faster and/or better on the server. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDkb50004085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:46:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDkb80004084; Thu, 12 Apr 2007 06:46:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDkEwM004044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:46:36 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 12CDB49800C; Thu, 12 Apr 2007 14:46:14 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17132-07; Thu, 12 Apr 2007 14:46:07 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 0A8AC49800B; Thu, 12 Apr 2007 14:46:07 +0100 (BST) Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <6701.1176385567.036132@peirce.dave.cridland.net> Date: Thu, 12 Apr 2007 14:46:07 +0100 From: Dave Cridland To: Cyrus Daboo Cc: , Kjetil Torgrim Homme , Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Apr 12 14:27:19 2007, Cyrus Daboo wrote: > > Hi Dave, > > --On April 12, 2007 10:03:46 AM +0100 Dave Cridland > wrote: > >> I think that there would be serious advantage to taking a step >> back at >> this point, and examining how users and UAs are currently searching >> through mail, and see how we could make this both more efficient >> and >> closer to the end-users' requirements. Right now, I think that IMAP >> provides only rudimentary "organizational" abilities, and I think >> that >> they're showing up as a weak point in IMAP. > > Lets face it, very few clients really use server-side > sort/thread/search. Most download and cache and do local operations > because they can offer much, much more in the way of features for > that. > > If we are going to make changes to the server-side behavior we > should go all the way. Examine the types of features offered by > desktop clients doing local operations and match those with > server-side capabilities. Anything less is a poor half-measure. Yes, exactly - you've put it clearer than I did, but that's my intention. I'd add a caveat that while I'll like to go all the way with the examination of what's needed, I wouldn't want to commit to producing capabilities to cover everything we find. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDjSYs003957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:45:28 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDjS7v003956; Thu, 12 Apr 2007 06:45:28 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDj6IS003913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:45:27 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hbzbl-0005F8-N1 for ietf-imapext@imc.org; Thu, 12 Apr 2007 15:45:05 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hbzbl-00010M-FZ for ietf-imapext@imc.org; Thu, 12 Apr 2007 15:45:05 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1Hbzbl-000108-DN for ietf-imapext@imc.org; Thu, 12 Apr 2007 15:45:05 +0200 Subject: Re: SORT on addresses From: Kjetil Torgrim Homme To: ietf-imapext@imc.org In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain Date: Thu, 12 Apr 2007 15:45:02 +0200 Message-Id: <1176385504.1096.19.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=12.0, autolearn=disabled, AWL=0.078,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 347666EAC46D514C249A0509ED49B413DA4BDDDE X-UiO-Ratelimit-Test: Ratelimit X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: -48 maxlevel 200 minaction 2 bait 0 mail/h: 1753 total 1019908 max/h 7466 blacklist 0 greylist 0 ratelimit 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: first, I'd like to thank everyone for their reasoned and constructive responses. On Thu, 2007-04-12 at 10:03 +0100, Dave Cridland wrote: > On Thu Apr 12 02:38:18 2007, Mark Crispin wrote: > > Now, with that said, I would not oppose a SORTEXT proposal that > > adds new keys (as opposed to changing the current keys) that work > > as you propose. > > I would oppose a proposal *now*. I don't think we know nearly enough > to base a decision on concerning which keys to add. fair enough. Peter Coates told me in a private reply that Sun has an extension which sorts on display-name, which very well may be more aligned with what users want/expect anyway. there are probably other options. > So, here's a counter-proposal: > > We setup a mailing list, or at least agree to use an existing one, > invite a few UA developers and search-agent people [since we're heavy > on the server-side as usual], and start to figure out what's needed, > what's practical, and get to work on it. If we seem to be making > progress, we turn it into a WG if it seems to suit. sounds good to me. -- Kjetil T. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDS9gq001910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:28:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDS9Jw001909; Thu, 12 Apr 2007 06:28:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDRlNT001869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:28:08 -0700 (MST) (envelope-from cyrus@daboo.name) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l3CDROZN031942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 09:27:27 -0400 Date: Thu, 12 Apr 2007 09:27:19 -0400 From: Cyrus Daboo To: Dave Cridland , Mark Crispin cc: ietf-imapext@imc.org, Kjetil Torgrim Homme Subject: Re: SORT on addresses Message-ID: In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Dave, --On April 12, 2007 10:03:46 AM +0100 Dave Cridland wrote: > I think that there would be serious advantage to taking a step back at > this point, and examining how users and UAs are currently searching > through mail, and see how we could make this both more efficient and > closer to the end-users' requirements. Right now, I think that IMAP > provides only rudimentary "organizational" abilities, and I think that > they're showing up as a weak point in IMAP. Lets face it, very few clients really use server-side sort/thread/search. Most download and cache and do local operations because they can offer much, much more in the way of features for that. If we are going to make changes to the server-side behavior we should go all the way. Examine the types of features offered by desktop clients doing local operations and match those with server-side capabilities. Anything less is a poor half-measure. -- Cyrus Daboo Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDGqx1000692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:16:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDGq3q000691; Thu, 12 Apr 2007 06:16:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDGUlo000656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:16:51 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id l3CDGP7I023773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Apr 2007 09:16:29 -0400 Message-ID: <461E3127.7040507@andrew.cmu.edu> Date: Thu, 12 Apr 2007 09:16:23 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland wrote: > So, here's a counter-proposal: > > We setup a mailing list, or at least agree to use an existing one, > invite a few UA developers and search-agent people [since we're heavy on > the server-side as usual], and start to figure out what's needed, what's > practical, and get to work on it. If we seem to be making progress, we > turn it into a WG if it seems to suit. > > The aim would be to get, or look into: > - a set of useful SEARCH keys, SORT keys, etc. > - multimailbox SEARCHing. > - Inexact searching, such as SCAN provides. > - Sorting by relevance. > - probably other search and organizational things. (Perhaps we could > stretch to a re-examination of ANNOTATE, or resurrect Alexey's keywords > draft - not saying we should do either, but looking into them might be > useful). > > I have no clear idea if this would be considered IETF or IRTF territory > - I suspect it might start out informal, and become formalized in one or > other or both. > > Who's willing to participate in something like this? I would be (speaking for CMU). -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CAVLWL085622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 03:31:22 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CAVL3P085621; Thu, 12 Apr 2007 03:31:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CAVKJK085614 for ; Thu, 12 Apr 2007 03:31:21 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BAD0D4AC48; Thu, 12 Apr 2007 12:31:21 +0200 (CEST) Message-Id: Date: Thu, 12 Apr 2007 12:30:17 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: SORT on addresses Cc: Mark Crispin , Dave Cridland , Kjetil Torgrim Homme References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: > I spoke to a few people in Prague about IMAP and email, and the > general area of searching and managing large quantities of email was > raised by several of them, so perhaps the time is right. Indeed. > So, here's a counter-proposal: > > We setup a mailing list, or at least agree to use an existing one, > invite a few UA developers and search-agent people [since we're heavy > on the server-side as usual], and start to figure out what's needed, > what's practical, and get to work on it. If we seem to be making > progress, we turn it into a WG if it seems to suit. > > The aim would be to get, or look into: > - a set of useful SEARCH keys, SORT keys, etc. > - multimailbox SEARCHing. > - Inexact searching, such as SCAN provides. > - Sorting by relevance. > - probably other search and organizational things. (Perhaps we could > stretch to a re-examination of ANNOTATE, or resurrect Alexey's > keywords draft - not saying we should do either, but looking into > them might be useful). > > I have no clear idea if this would be considered IETF or IRTF > territory - I suspect it might start out informal, and become > formalized in one or other or both. > > Who's willing to participate in something like this? Arnt is. No surprise I'm sure. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C94JN0078801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 02:04:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C94JeB078800; Thu, 12 Apr 2007 02:04:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C93v5I078754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 02:04:18 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 16703498004; Thu, 12 Apr 2007 10:03:54 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31194-01; Thu, 12 Apr 2007 10:03:46 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id B2A3A498001; Thu, 12 Apr 2007 10:03:46 +0100 (BST) Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> In-Reply-To: MIME-Version: 1.0 Message-Id: <6701.1176368626.798998@peirce.dave.cridland.net> Date: Thu, 12 Apr 2007 10:03:46 +0100 From: Dave Cridland To: Mark Crispin Cc: , Kjetil Torgrim Homme Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Apr 12 02:38:18 2007, Mark Crispin wrote: > > On Wed, 11 Apr 2007, Kjetil Torgrim Homme wrote: >> it seems to me that this behaviour is mostly useful in "old-skool" >> environments, where username@host was common. e.g., I could be >> kjetilho@tag.uio.no, kjetilho@hal.uio.no or kjetilho@bilbo.uio.no >> depending on which workstation I was logged in that day. I >> sincerely >> doubt this is widespread today. > > Please be assured that it is still quite common and still very much > a fact of life for many people. > > It is for you. Not for me, and I suspect that sorting by phrase would provide a much more useful method than looking at the address at all. (For you: mrc@ is almost uniformly Mark Crispin, and "SORT (FROM) UTF-8 ..." sorts all your mails the "right" way. For me: I'm dave@ for home, and dave.cridland@ for work. I'm pretty sure I'm not the only dave@, too. SORT (FROM) is useless for my mails as a result.) >> * will end-users think that changing the sort key to be the >> complete RFC2822 addr-spec (or RFC2822 group) is an >> improvement? >> my answer is, to the extent they notice it, an emphatic yes. > > What surety is there that such is the case? Your opinion that this > is an "improvement" has been noted. That does not constitute > research. > > I certainly agree that *a* sort key needs to exist to allow for collating the results by "the user". I'm even convinced that blindly changing FROM/TO/CC would benefit the majority of users, but ... >> * is it problematic that current deployments of the draft >> break >> wrt compliance? >> my answer is, not really. this is not a behavioural change which >> affects clients, it only affects the humans who use the clients. > > Ahem. > > A change in behavior that has been implemented and documented for > over a decade is quite problematic. > > ... the above point unnerves me, and moreover I cannot be certain that the assertion that the sort results are blindly passed through to the user is correct. > Now, with that said, I would not oppose a SORTEXT proposal that > adds new keys (as opposed to changing the current keys) that work > as you propose. I would oppose a proposal *now*. I don't think we know nearly enough to base a decision on concerning which keys to add. I think that there would be serious advantage to taking a step back at this point, and examining how users and UAs are currently searching through mail, and see how we could make this both more efficient and closer to the end-users' requirements. Right now, I think that IMAP provides only rudimentary "organizational" abilities, and I think that they're showing up as a weak point in IMAP. I spoke to a few people in Prague about IMAP and email, and the general area of searching and managing large quantities of email was raised by several of them, so perhaps the time is right. So, here's a counter-proposal: We setup a mailing list, or at least agree to use an existing one, invite a few UA developers and search-agent people [since we're heavy on the server-side as usual], and start to figure out what's needed, what's practical, and get to work on it. If we seem to be making progress, we turn it into a WG if it seems to suit. The aim would be to get, or look into: - a set of useful SEARCH keys, SORT keys, etc. - multimailbox SEARCHing. - Inexact searching, such as SCAN provides. - Sorting by relevance. - probably other search and organizational things. (Perhaps we could stretch to a re-examination of ANNOTATE, or resurrect Alexey's keywords draft - not saying we should do either, but looking into them might be useful). I have no clear idea if this would be considered IETF or IRTF territory - I suspect it might start out informal, and become formalized in one or other or both. Who's willing to participate in something like this? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C8F1T3074680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 01:15:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C8F1K6074679; Thu, 12 Apr 2007 01:15:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C8EbIS074654 for ; Thu, 12 Apr 2007 01:15:00 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 581BEF0B31; Thu, 12 Apr 2007 11:14:24 +0300 (EEST) Subject: Re: SORT on addresses From: Timo Sirainen To: Mark Crispin Cc: Kjetil Torgrim Homme , ietf-imapext@imc.org In-Reply-To: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cH0f2lcWAd7jk9WgZyt8" Date: Thu, 12 Apr 2007 11:14:24 +0300 Message-Id: <1176365664.16189.97.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-cH0f2lcWAd7jk9WgZyt8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-04-11 at 18:38 -0700, Mark Crispin wrote: > Now, with that said, I would not oppose a SORTEXT proposal that adds new=20 > keys (as opposed to changing the current keys) that work as you propose. If someone starts that, perhaps it could also include REFERENCES2? http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-December/0003= 22.html Or maybe I'll just need to write a draft myself some day. --=-cH0f2lcWAd7jk9WgZyt8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGHepgyUhSUUBViskRAljkAKCIxNKxfAV+wwBX5BgZ3W5wlwRcgQCfWGqM QeF5swizM26EyKzFzsk2XvY= =iI4k -----END PGP SIGNATURE----- --=-cH0f2lcWAd7jk9WgZyt8-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C1ebXn040654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 18:40:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C1ebLa040653; Wed, 11 Apr 2007 18:40:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C1eFJZ040601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 Apr 2007 18:40:36 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3C1e2u0009947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2007 18:40:02 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3C1dxv5012491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Apr 2007 18:40:01 -0700 Date: Wed, 11 Apr 2007 18:38:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Kjetil Torgrim Homme cc: ietf-imapext@imc.org Subject: Re: SORT on addresses In-Reply-To: <1176269275.26687.293.camel@havhest.ifi.uio.no> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.11.183034 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 11 Apr 2007, Kjetil Torgrim Homme wrote: > it seems to me that this behaviour is mostly useful in "old-skool" > environments, where username@host was common. e.g., I could be > kjetilho@tag.uio.no, kjetilho@hal.uio.no or kjetilho@bilbo.uio.no > depending on which workstation I was logged in that day. I sincerely > doubt this is widespread today. Please be assured that it is still quite common and still very much a fact of life for many people. > * will end-users think that changing the sort key to be the > complete RFC2822 addr-spec (or RFC2822 group) is an improvement? > my answer is, to the extent they notice it, an emphatic yes. What surety is there that such is the case? Your opinion that this is an "improvement" has been noted. That does not constitute research. > * is it problematic that current deployments of the draft break > wrt compliance? > my answer is, not really. this is not a behavioural change which > affects clients, it only affects the humans who use the clients. Ahem. A change in behavior that has been implemented and documented for over a decade is quite problematic. A declaration that software which has been distributed for more than a decade is suddenly "non-compliant" is quite problematic. The only reason why SORT is "still a draft" is that it got hung up on i18n collation. SORT has been a cast-in-stone specification for production software for many years. It can not be arbitrarily changed. Now, with that said, I would not oppose a SORTEXT proposal that adds new keys (as opposed to changing the current keys) that work as you propose. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B5SJFR034012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 22:28:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3B5SJYx034011; Tue, 10 Apr 2007 22:28:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B5RuXs033958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Apr 2007 22:28:18 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HbVN5-0001Yg-Vb for ietf-imapext@imc.org; Wed, 11 Apr 2007 07:27:56 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HbVN5-00027I-MN for ietf-imapext@imc.org; Wed, 11 Apr 2007 07:27:55 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx8.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1HbVN5-00027F-JR for ietf-imapext@imc.org; Wed, 11 Apr 2007 07:27:55 +0200 Subject: SORT on addresses From: Kjetil Torgrim Homme To: ietf-imapext@imc.org Content-Type: text/plain Date: Wed, 11 Apr 2007 07:27:54 +0200 Message-Id: <1176269275.26687.293.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.8, required=12.0, autolearn=disabled, AWL=0.154,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: F532DBCDE2FE64470DC34052B90BF100063D264D X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -47 maxlevel 200 minaction 2 bait 0 mail/h: 150 total 974842 max/h 7466 blacklist 0 greylist 0 ratelimit 0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I came across some grumblings on the info-cyrus mailing list about the behaviour of SORT with respect to FROM and TO. [Rob Mueller]: > It's defined by the IMAP sort extension. > > http://tools.ietf.org/html/draft-ietf-imapext-sort-19 > > FROM > [IMAP] addr-mailbox of the first "From" address. > > TO > [IMAP] addr-mailbox of the first "To" address. > > So it really only sorts by the localpart of the email address, not > even the domain is included, something that's annoyed our users as > well since you basically end up with UID sorting for the localparts > that are the same but different domains. That's the "standard" > though... *sigh* I was surprised to see this explanation of the behaviour, so I had to look it up (addr-mailbox being local-part wasn't obvious to me), and tried to find the justification for it in the archives. way back in 2004-11-09, Dave Cridland wrote about the mismatch between SEARCH and SORT (SEARCH looks at the headers verbatim, SORT does decoding first), and went on to say: [Dave Cridland]: > I confess to being totally bewildered by the FROM, TO and CC sort > keys, as they all appear to only sort on the local-part of the email > address - that *is* the "bit before the @", right? So different > domains collate equally? I can't understand why this should be the > case. [Mark Crispin] responded: > In practice, not all that many people use those keys. > > The idea is to tend to collect messages from a single person together, > based upon the tendency of people to have the same local-part for his > email address even though they may use many different sites. Note > that word "tend". > > It's useful, in some very limited cases. it seems to me that this behaviour is mostly useful in "old-skool" environments, where username@host was common. e.g., I could be kjetilho@tag.uio.no, kjetilho@hal.uio.no or kjetilho@bilbo.uio.no depending on which workstation I was logged in that day. I sincerely doubt this is widespread today. a given localpart will typically belong to a single entity within a given mailbox, e.g., in my personal INBOX, "christb" is unique, and there are "only" three distinct people with localpart "chris" (in my INBOX.lists there are 12 "chris"). role addresses increase the chance of mixups, though: "info", "noreply", "orders", "post", "service", "support", "webmaster" are all examples from my INBOX which belong to numerous domains and companies, and it's not at all intuitive to me that all addresses sharing one of these localparts are sorted as the same address. to give an example of when this is annoying, consider when I want to file messages from certain people into separate folders. most clients allow selecting a block by specifying the start and end in the message list, so I can operate on all of them. when the FROM criteria is equal, it falls back on sequence number, which means I have to pick messages individually since the senders are interleaved. in this scenario, even if I wanted to move all messages from "chris" regardless of domain, it's not a problem, since I can still select them as a single block. the change in behaviour is only observable in edge cases, which is why I dare bring it up at all so late in the game. I'd like to pose two questions: * will end-users think that changing the sort key to be the complete RFC2822 addr-spec (or RFC2822 group) is an improvement? my answer is, to the extent they notice it, an emphatic yes. * is it problematic that current deployments of the draft break wrt compliance? my answer is, not really. this is not a behavioural change which affects clients, it only affects the humans who use the clients. -- thank you for reading, Kjetil T. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3ABC0YW041016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 04:12:00 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3ABC0Iw041015; Tue, 10 Apr 2007 04:12:00 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3ABBcII040956 for ; Tue, 10 Apr 2007 04:11:59 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 10 Apr 2007 12:11:32 +0100 Message-ID: <461A8EFC.5050208@isode.com> Date: Mon, 09 Apr 2007 20:07:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Karp , Cyrus Daboo CC: Eric Burger , Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp wrote: >>http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt >> >> >Comments interspersed btween snippets of the draft: > > Hi Dan, > Changes from -10 to -11: > 7. Added match type and collation identifier to the LIST-EXTENDED > selection option. > 8. Made support for IMAP-I18N a requirement. > > Text comparisons may be done as part of the GETMETADATA or LIST- > EXTENDED commands. As a result, support for the COMPARATOR > [I-D.ietf-imapext-i18n] extension is REQUIRED. > >GETMETADATA doesn't actually do text comparisons, right? The BNF >doesn't seem to tie in the "matchtype" or "collation" productions. > > Check the , it references both. >But more to the point, I believe that the intention was that METADATA >should be a simple, baseline extenstion that will be required by a wide >range of other extensions. If that's the case, *PLEASE* reconsider the >wisdom of adding the LT, LE, GT, and GE matchers (and thus the >COMPARATOR requirement) to this draft. It doesn't apear to be core >functionality for METADATA, and since COMPARATOR appears nontrivial to >implement > Can you please elaborate on this? (Note that the COMPARATOR extension is about to switch to i;unicode-casemap collation (as mandatory to implement), which is much easier to implement than i;basic) > this may not only prevent server authors from implementing >METADATA but also keep us from impelenting any future extension that >requires METADATA. > > > A user can only set and retrieve private or shared annotations on a > mailbox which exists and is returned to them via a LIST or LSUB > command, irrespective of whether they have read or write access to > the actual message content of the mailbox. If the client attempts to > set or retrieve annotations on other mailboxes, the server MUST > respond with a NO response. > >I can understand the logic behind requiring LIST/LSUB access for reading >public mailbox annotations and for setting private annotations. But >that seems to be a very low bar for setting public mailbox annotations. >Adding a new ACL permission for setting annotations would make this >extension more complex and would also introduce a dependency on the ACL >extension, > Dependency in what sense? > but perhaps requiring [READ-WRITE] access to the mailbox >might be reasonable? > > > The new SETMETADATA command and the METADATA response each have a > mailbox name argument, indicating that the annotations being referred > to are attached to the specified mailbox. An empty string can be > used for the mailbox name to signify server annotations. > >What rights are required to set public and private annotations on the >server? > > None. But maybe this should be stated explicitly. > This command sets the specified list of entries by adding or > replacing the specified attributes with the values provided, on the > specified existing mailboxes. Clients can use NIL for values of > attributes it wants to remove from entries. The server MAY return a > METADATA response containing the updated annotation data. > >In this case, the server may return a METADATA response that doesn't >contain the updated annotation data or a LIST response that does, >correct? > > > This extension adds the GETMETADATA command. This allows clients to > retrieve server annotations. Mailbox annotations are retrieved via > the extended LIST command described in the next section. > > This extension adds the SETMETADATA command. This allows clients to > set annotations. > >It's a little incongruous that GETMETADATA is used only to retrieve >server annotations, but SETMETADATA can be used to set both server and >mailbox annotations. I understand that the mailbox-level function of >GETMETADATA has been passed to the LIST-EXTENDED feature, but generally >it's clearer when a GETFOO and SETFOO pair cover the same target space. > > Yes, but the alternative is to have 2 ways of getting annotations, which is worse. > If the METADATA extension is present, support for shared annotations > is REQUIRED, whilst support for private annotations is OPTIONAL. > This recognizes the fact that support for private annotations may > introduce significantly more complexity to a server in terms of > tracking ownership of the annotations, how quota is determined for > users based on their own annotations etc. Clients that support the > METADATA extension MUST handle both shared and private annotations. > >Is there a mechanism for informing clients that a server does not >support private annotations? Or is a client expected to determine this >from METADATA NOPRIVATE response codes on a SETMETADATA NO response? > > Currently the latter. >If the latter is the case, won't client implementations end up allowing >users one attempt to set private annotations and only then inform them >that the functionality is not supported by the server? > Clients can try to workaround this by trying to set an annotation to a fake value. Yes, this doesn't look very nice, but works. Defining a new capability wouldn't work, because in general case NOPRIVATE can be namespace or even mailbox-specific. We can add a new \NoPrivate per mailbox attribute to return this in LIST? > (This would probably occur once per IMAP session...) > > > If the server is unable to set an annotation because the size of its > value is too large, the server MUST return a tagged NO response with > a "[METADATA TOOBIG]" response code. > >Likewise, is there a mechanism for a server to tell its clients the >maximum annotation length it supports? Or is it up to the client to >determine this from METADATA TOOBIG error code responses? > > The latter. Also note, that the server might return TOOBIG because it simply ran out of storage space, so advertising the maximum might not be that helpful to the client. > Entry and attribute names are case-sensitive. > > Entry and attribute names MUST NOT contain asterisk ("*") or percent > ("%") characters and MUST NOT contain non-ASCII characters or the NUL > octet. Invalid entry or attribute names result in a BAD response in > any IMAP commands where they are used. > > Use of control or punctuation characters in entry and attribute names > is strongly discouraged. > >It's probably cleaner in the long run to use the BNF to explicitly >specify a limited set of permitted characters for entry and attribute >names. Constraining them to something like "atom" plus the delimiters >is probably not a bad idea. > >Given that these names are already constrained to ASCII, > I don't think this is the case! Annotation names can contain UTF-8. > I'd favor eliminating the case-sensitivity requirement. It differs from other >IMAP commands and extensions' general consistent overall case- >insensitivity (e.g. RFC 3501 keywords). > > > value > A string or binary data representing the value of the annotation. > To delete an annotation, the client can store "NIL" into the > value. The content represented by the string is determined by the > Content-Type used to register the entry (see Section 6.1 for entry > registration templates). Where applicable, the registered > Content-Type MUST include a charset parameter. Text values SHOULD > use the utf-8 [RFC3629] character set. > >Is there any reason not to mandate UTF-8 for text values? > Values can also be binary and not every binary value is a valid UTF-8. > We seem to be >moving towards standardizing on UTF-8 in IMAP, and this seems a good >opportunity to draw a line. > > "Values for annotations published on Standard track MUST use charset=UTF-8"? This still allows vendors to do whatever they want with their private annotations. > /sort > Defines the default sort criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > sorting is not required. Note that the presence of this attribute > does not imply that the server supports the IMAP SORT > [I-D.ietf-imapext-sort] extension - servers can choose to support > or not support SORT independently of this extension. In the > absence of the SORT extension, clients can choose to interpret > this entry as suggesting a client-side sort ordering of the > corresponding mailbox. > > /thread > Defines the default thread criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > threading is not required. If both sort and thread are not NIL, > then threading should take precedence over sorting. Note that the > presence of this attribute does not imply that the server supports > the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can > choose to support or not support THREAD independently of this > extension. In the absence of the THREAD extension, clients can > choose to interpret this entry as a client-side thread ordering of > the corresponding mailbox. > >These registered annotations are odd ducks. They seem most appropriate >as private annotations on a mailbox, but in practice they may be >confusing to the end user because sorting and threading preferences are >often client-specific, not user-specific. > >For instance, a user may prefer to read their mail nonthreaded on the >desktop, but on a mobile device they may want to make use of the reduced >visual footprint of a threaded display. Likewise, more likely than not >a user won't expect their sort preferences to automatically be >transferred between their devices and clients. > > I would let other people comment on this. > Mailboxes or the server as a whole may have zero or more annotations > associated with them. An annotation contains a uniquely named entry > with a set of uniquely named attributes, each of which has a value. > Annotations can be added to mailboxes when a mailbox name is provided > as the first argument to the new command, or to the server as a whole > when the empty string is provided as the first argument to the new > command. > >Just a nitpick here, but you should probably refer to SETMETADATA >command by name since (a) it hasn't been introduced at this point in the >document and (b) there is more than one new command added by the draft. > > Agreed. > Each annotation is an entry that has a hierarchical name, with each > component of the name separated by a slash ("/"). An entry name MUST > NOT contain two consecutive "/" characters and MUST NOT end with a > "/" character. > > Each entry is made up of a set of attributes. Each attribute has a > hierarchical name, with each component of the name separated by a > period ("."). An attribute name MUST NOT contain two consecutive "." > characters and MUST NOT end with a "." character. > >My last comment is personal preference: I fear that this may be a bit of >overkill for folder annotation. I understand the need for this type of >flexible syntax for ACAP's purposes, but the use cases for IMAP appear >significantly more limited in scope. In accordance with the KISS >philosophy, is there any chance I might be able to convince everyone to >consider shedding a layer of hierarchy here? > > This is not going to be a problem in practice. IMHO, new attributes are unlikely to be standardized. IMHO, the current model of value.priv + value.shared per annotation should work for 99% cases. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l396pt8j064312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Apr 2007 23:51:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l396ptxp064311; Sun, 8 Apr 2007 23:51:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l396pTwv064291 for ; Sun, 8 Apr 2007 23:51:50 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BAE1C4AC22; Mon, 9 Apr 2007 08:51:30 +0200 (CEST) Message-Id: Date: Mon, 9 Apr 2007 08:50:10 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Deprecate IMAP IDLE? Cc: Eric Burger References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Burger writes: > Because of this, it was proposed that IMAP NOTIFY would supercede IMAP > IDLE, leading to its deprecation. > > What do we think of this? As chair, my only care is whether we say it > obsoletes RFC 2177 or not. I think obsoleting 2177 is out of scope for Lemonade. All Lemonade can/should do is say things in profile-bis. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IcXQJ010385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:38:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36IcXaZ010384; Fri, 6 Apr 2007 11:38:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IcCmD010339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Apr 2007 11:38:32 -0700 (MST) (envelope-from leiba@watson.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l36Ic7jC005039 for ; Fri, 6 Apr 2007 14:38:07 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l36Ic78Z155960 for ; Fri, 6 Apr 2007 12:38:07 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l36Ic7kH010264 for ; Fri, 6 Apr 2007 12:38:07 -0600 Received: from [9.2.42.86] (Saturn.watson.ibm.com [9.2.42.86]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l36Ic6wl010259 for ; Fri, 6 Apr 2007 12:38:06 -0600 Message-ID: <461693AB.4080902@watson.ibm.com> Date: Fri, 06 Apr 2007 14:38:35 -0400 From: Barry Leiba User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: friends of imap dinner tonight References: <0e3+uqQ0qRTXTxltw3os8A.md5@dhcp-1715.ietf68.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A little late here, but... > It was a pleasant dinner. I'm sure it was, and I'm sorry to've missed it. Perhaps in future, we should make sure that the friends of IMAP and the friends of DKIM coordinate, so those of us who have lots of friends can do both. :-) Barry Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l334VftL022924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 21:31:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l334VfXG022923; Mon, 2 Apr 2007 21:31:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l334VKYa022914 for ; Mon, 2 Apr 2007 21:31:41 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id EB791810397; Mon, 2 Apr 2007 21:24:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id C47CF47943; Mon, 2 Apr 2007 21:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtH-7sZdNMoF; Mon, 2 Apr 2007 21:31:15 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 0ADF347942; Mon, 2 Apr 2007 21:31:15 -0700 (PDT) Date: Mon, 2 Apr 2007 21:31:14 -0700 (PDT) From: Dan Karp To: Eric Burger Cc: Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG Message-ID: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.193.195] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt Comments interspersed btween snippets of the draft: Changes from -10 to -11: 7. Added match type and collation identifier to the LIST-EXTENDED selection option. 8. Made support for IMAP-I18N a requirement. Text comparisons may be done as part of the GETMETADATA or LIST- EXTENDED commands. As a result, support for the COMPARATOR [I-D.ietf-imapext-i18n] extension is REQUIRED. GETMETADATA doesn't actually do text comparisons, right? The BNF doesn't seem to tie in the "matchtype" or "collation" productions. But more to the point, I believe that the intention was that METADATA should be a simple, baseline extenstion that will be required by a wide range of other extensions. If that's the case, *PLEASE* reconsider the wisdom of adding the LT, LE, GT, and GE matchers (and thus the COMPARATOR requirement) to this draft. It doesn't apear to be core functionality for METADATA, and since COMPARATOR appears nontrivial to implement this may not only prevent server authors from implementing METADATA but also keep us from impelenting any future extension that requires METADATA. A user can only set and retrieve private or shared annotations on a mailbox which exists and is returned to them via a LIST or LSUB command, irrespective of whether they have read or write access to the actual message content of the mailbox. If the client attempts to set or retrieve annotations on other mailboxes, the server MUST respond with a NO response. I can understand the logic behind requiring LIST/LSUB access for reading public mailbox annotations and for setting private annotations. But that seems to be a very low bar for setting public mailbox annotations. Adding a new ACL permission for setting annotations would make this extension more complex and would also introduce a dependency on the ACL extension, but perhaps requiring [READ-WRITE] access to the mailbox might be reasonable? The new SETMETADATA command and the METADATA response each have a mailbox name argument, indicating that the annotations being referred to are attached to the specified mailbox. An empty string can be used for the mailbox name to signify server annotations. What rights are required to set public and private annotations on the server? This command sets the specified list of entries by adding or replacing the specified attributes with the values provided, on the specified existing mailboxes. Clients can use NIL for values of attributes it wants to remove from entries. The server MAY return a METADATA response containing the updated annotation data. In this case, the server may return a METADATA response that doesn't contain the updated annotation data or a LIST response that does, correct? This extension adds the GETMETADATA command. This allows clients to retrieve server annotations. Mailbox annotations are retrieved via the extended LIST command described in the next section. This extension adds the SETMETADATA command. This allows clients to set annotations. It's a little incongruous that GETMETADATA is used only to retrieve server annotations, but SETMETADATA can be used to set both server and mailbox annotations. I understand that the mailbox-level function of GETMETADATA has been passed to the LIST-EXTENDED feature, but generally it's clearer when a GETFOO and SETFOO pair cover the same target space. If the METADATA extension is present, support for shared annotations is REQUIRED, whilst support for private annotations is OPTIONAL. This recognizes the fact that support for private annotations may introduce significantly more complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations etc. Clients that support the METADATA extension MUST handle both shared and private annotations. Is there a mechanism for informing clients that a server does not support private annotations? Or is a client expected to determine this from METADATA NOPRIVATE response codes on a SETMETADATA NO response? If the latter is the case, won't client implementations end up allowing users one attempt to set private annotations and only then inform them that the functionality is not supported by the server? (This would probably occur once per IMAP session...) If the server is unable to set an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[METADATA TOOBIG]" response code. Likewise, is there a mechanism for a server to tell its clients the maximum annotation length it supports? Or is it up to the client to determine this from METADATA TOOBIG error code responses? Entry and attribute names are case-sensitive. Entry and attribute names MUST NOT contain asterisk ("*") or percent ("%") characters and MUST NOT contain non-ASCII characters or the NUL octet. Invalid entry or attribute names result in a BAD response in any IMAP commands where they are used. Use of control or punctuation characters in entry and attribute names is strongly discouraged. It's probably cleaner in the long run to use the BNF to explicitly specify a limited set of permitted characters for entry and attribute names. Constraining them to something like "atom" plus the delimiters is probably not a bad idea. Given that these names are already constrained to ASCII, I'd favor eliminating the case-sensitivity requirement. It differs from other IMAP commands and extensions' general consistent overall case- insensitivity (e.g. RFC 3501 keywords). value A string or binary data representing the value of the annotation. To delete an annotation, the client can store "NIL" into the value. The content represented by the string is determined by the Content-Type used to register the entry (see Section 6.1 for entry registration templates). Where applicable, the registered Content-Type MUST include a charset parameter. Text values SHOULD use the utf-8 [RFC3629] character set. Is there any reason not to mandate UTF-8 for text values? We seem to be moving towards standardizing on UTF-8 in IMAP, and this seems a good opportunity to draw a line. /sort Defines the default sort criteria [I-D.ietf-imapext-sort] to use when first displaying the mailbox contents to the user, or NIL if sorting is not required. Note that the presence of this attribute does not imply that the server supports the IMAP SORT [I-D.ietf-imapext-sort] extension - servers can choose to support or not support SORT independently of this extension. In the absence of the SORT extension, clients can choose to interpret this entry as suggesting a client-side sort ordering of the corresponding mailbox. /thread Defines the default thread criteria [I-D.ietf-imapext-sort] to use when first displaying the mailbox contents to the user, or NIL if threading is not required. If both sort and thread are not NIL, then threading should take precedence over sorting. Note that the presence of this attribute does not imply that the server supports the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can choose to support or not support THREAD independently of this extension. In the absence of the THREAD extension, clients can choose to interpret this entry as a client-side thread ordering of the corresponding mailbox. These registered annotations are odd ducks. They seem most appropriate as private annotations on a mailbox, but in practice they may be confusing to the end user because sorting and threading preferences are often client-specific, not user-specific. For instance, a user may prefer to read their mail nonthreaded on the desktop, but on a mobile device they may want to make use of the reduced visual footprint of a threaded display. Likewise, more likely than not a user won't expect their sort preferences to automatically be transferred between their devices and clients. Mailboxes or the server as a whole may have zero or more annotations associated with them. An annotation contains a uniquely named entry with a set of uniquely named attributes, each of which has a value. Annotations can be added to mailboxes when a mailbox name is provided as the first argument to the new command, or to the server as a whole when the empty string is provided as the first argument to the new command. Just a nitpick here, but you should probably refer to SETMETADATA command by name since (a) it hasn't been introduced at this point in the document and (b) there is more than one new command added by the draft. Each annotation is an entry that has a hierarchical name, with each component of the name separated by a slash ("/"). An entry name MUST NOT contain two consecutive "/" characters and MUST NOT end with a "/" character. Each entry is made up of a set of attributes. Each attribute has a hierarchical name, with each component of the name separated by a period ("."). An attribute name MUST NOT contain two consecutive "." characters and MUST NOT end with a "." character. My last comment is personal preference: I fear that this may be a bit of overkill for folder annotation. I understand the need for this type of flexible syntax for ACAP's purposes, but the use cases for IMAP appear significantly more limited in scope. In accordance with the KISS philosophy, is there any chance I might be able to convince everyone to consider shedding a layer of hierarchy here? Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R4xcGO069035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2007 21:59:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3R4xcxJ069034; Thu, 26 Apr 2007 21:59:38 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3R4xbK1069017; Thu, 26 Apr 2007 21:59:37 -0700 (MST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Thu, 26 Apr 2007 23:59:38 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Thu, 26 Apr 2007 23:59:37 -0500 To: IETF-POP3EXT:;, IETF-IMAPEXT:;, IETF-SMTP:;, LEMONADE:;, IMA:; From: Pete Resnick Subject: Fwd: draft-resnick-2822upd-01 posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please follow the discussion on ietf-822@imc.org. --- begin forwarded text Date: Thu, 26 Apr 2007 16:55:06 -0500 To: ietf-822@imc.org From: Pete Resnick Subject: draft-resnick-2822upd-01 posted You may have noticed that 2822upd-01 was posted. Also: To make rfcdiff work, I've put a copy of RFC 2822 on my web site with some of the later sections rearranged so that they're in the same order as the current draft. You can see the diffs between the two here: Though overall very few, there are real changes from 2822 in this document that need review. See the changes section at the bottom. I did *not* go whole hog and switch to Bruce's syntax, simply because I wanted to limit the number of changes and see if we can't get this thing to Draft along with 2821bis. But I did incorporate (hopefully all of) the corrections that you all have pointed out over the last couple of years. Please review with a fine toothed comb. If there are more than just a few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who have at assorted time offered assistance) to start an issues list. Thanks in advance for your assistance. pr --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J5oAHt043151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 22:50:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3J5oA5k043150; Wed, 18 Apr 2007 22:50:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J5nmKE043122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 18 Apr 2007 22:50:08 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3J5nf0Q022729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2007 22:49:42 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3J5ncL7018323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2007 22:49:40 -0700 Date: Wed, 18 Apr 2007 22:49:37 -0700 (PDT) From: Mark Crispin To: Dan Karp cc: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments , IMAP Protocol Interest List Subject: Re: [lemonade] SURVEY: How does SEARCH match in your IMAP server? In-Reply-To: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.com> Message-ID: References: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.co m> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-559819627-1176960403=:11458" Content-ID: X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.4.18.223836 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_AGE_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HIGHBITS 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SUBJ_PHRASE5 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-559819627-1176960403=:11458 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Your test examples aren't any good, because your message is in UTF-8 but=20 you have texts that are claimed to be ISO 8859-1. I will try to answer=20 what I *think* you intended. If my presumptions are wrong, then I reserve the right to change my=20 answers. On Wed, 18 Apr 2007, Dan Karp wrote: > server's name and version UW imapd, version imap-2006 series unless noted otherwise. > I love M=C3=B6tley Cr=C3=BCe ! Presumably, you mean "I love M" 0xf6 "tley Cr" 0xfc "e" > A001 SEARCH BODY "love" matches > A002 SEARCH BODY "LOVE" matches > A003 SEARCH CHARSET "iso-8859-1" BODY {4} > Cr=C3=BCe Presumably, you mean "Cr" 0xfc "e" matches in all versions since imap-4.1 error in imap-4 and earlier (10+ year old US-ASCII only version) > A004 SEARCH CHARSET "utf-8" BODY {5} > Cr=C3=83=C2=BCe Presuably, you mean "Cr" 0xc3 0xbc "e" matches in all versions since imap-4.1 error in imap-4 and earlier (10+ year old US-ASCII only version) > A005 SEARCH CHARSET "iso-8859-1" BODY {4} > CR=C3=9CE Presumably, you mean "CR" 0xdc "E" matches in imap-2006 series. does not match in earlier versions (earlier versions did i;ascii-casemap). error in imap-4 and earlier (10+ year old US-ASCII only version) -- 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. --0-559819627-1176960403=:11458-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4NWqP037408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 21:23:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3J4NWww037404; Wed, 18 Apr 2007 21:23:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4NVX1037394 for ; Wed, 18 Apr 2007 21:23:31 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id D8BF6810C3B; Wed, 18 Apr 2007 21:17:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 6908AFA864; Wed, 18 Apr 2007 21:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Djy+-tDvVZO3; Wed, 18 Apr 2007 21:23:29 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8258DFA863; Wed, 18 Apr 2007 21:23:29 -0700 (PDT) Date: Wed, 18 Apr 2007 21:23:29 -0700 (PDT) From: Dan Karp To: IMAP Extensions WG , Enhancements to Internet email to support diverse service enivronments , IMAP Protocol Interest List Cc: Arnt Gulbrandsen Message-ID: <827372203.32641176956609326.JavaMail.root@dogfood.liquidsys.com> Subject: SURVEY: How does SEARCH match in your IMAP server? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Originating-IP: [75.31.46.252] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3J4NVX1037395 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We're collecting hard data to help refine an upcoming IMAP extension (http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-10.txt). If you're developing an IMAP server, it would be a *great* help if you could take 3 minutes to answer a few questions about your server implementation. If you email responses back to me along with your server's name and version, I'll compile the results. Assume that you've just injected the following message into an empty INBOX: ---------------------------------------------------------------------- Subject: Music Date: Tue, 17 Apr 2007 16:53:02 -0700 (PDT) From: user1@example.com To: user2@example.com Content-Type: text/plain; charset="iso-8859-1" I love Mötley Crüe ! ---------------------------------------------------------------------- For each of the following SEARCH requests, would your server match the message, not match the message, return NO [BADCHARSET], or return some other NO or BAD response? A001 SEARCH BODY "love" A002 SEARCH BODY "LOVE" A003 SEARCH CHARSET "iso-8859-1" BODY {4} Crüe A004 SEARCH CHARSET "utf-8" BODY {5} Crüe A005 SEARCH CHARSET "iso-8859-1" BODY {4} CRÜE Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4JTfI037275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 21:19:29 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3J4JTXt037274; Wed, 18 Apr 2007 21:19:29 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3J4J7Aw037241 for ; Wed, 18 Apr 2007 21:19:27 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 1FB88810C38; Wed, 18 Apr 2007 21:12:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 9CF57FA863; Wed, 18 Apr 2007 21:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeWu0WpAvU2o; Wed, 18 Apr 2007 21:19:04 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 890F0FA862; Wed, 18 Apr 2007 21:19:04 -0700 (PDT) Date: Wed, 18 Apr 2007 21:19:04 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <594230642.32611176956344320.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Is this true? Do these servers really implement i;ascii-casemap as > > defined in RFC 4790? I'd expect any RFC 3501-compliant server that > > knows about more charsets than just US-ASCII to be supporting > > i;unicode-casemap and *not* i;ascii-casemap because of > > case-insensitive "SEARCH CHARSET". > > Build some consensus please. I chatted with Arnt, and he thinks it'd be worthwhile to canvas the troops and get some hard data on what various servers actually implement for their default SEARCH comparator. I've thrown together a little 5-question survey which I'll send out under separate cover. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIsxk1001241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 11:54:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HIsx7F001240; Tue, 17 Apr 2007 11:54:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIscsJ001163 for ; Tue, 17 Apr 2007 11:54:58 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 87CA1F0B59; Tue, 17 Apr 2007 21:54:36 +0300 (EEST) Subject: Re: ANNOTATEMORE and COMPARATOR From: Timo Sirainen To: Arnt Gulbrandsen Cc: lemonade@ietf.org, ietf-imapext@imc.org, Eric Burger , Alexey Melnikov , Dan Karp , Cyrus Daboo In-Reply-To: References: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-baA9QaoKY2tQJvsfXhIn" Date: Tue, 17 Apr 2007 21:54:36 +0300 Message-Id: <1176836076.16189.465.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-baA9QaoKY2tQJvsfXhIn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-17 at 20:25 +0200, Arnt Gulbrandsen wrote: > >> > If your aim is to make baseline COMPARATOR support fairly > >> > lightweight for IMAP servers, you may be constrained to only > >> > requiring i;unicode-casemap. > >> > >> Mumble. Given how many IMAP servers actually implement=20 > >> i;ascii-casemap and nothing else, I'm not happy doing that. Make=20 > >> some other people agree with you so Pete will say "WG consensus". > > > > Is this true? Do these servers really implement i;ascii-casemap as=20 > > defined in RFC 4790? I'd expect any RFC 3501-compliant server that=20 > > knows about more charsets than just US-ASCII to be supporting=20 > > i;unicode-casemap and *not* i;ascii-casemap because of=20 > > case-insensitive "SEARCH CHARSET". >=20 > Build some consensus please. My server implements only i;ascii-casemap currently, but that's just because I've been busy getting it stable and no-one's complained. I'm going to move to i;unicode-casemap soon, and I don't see a need for i;ascii-casemap. I'd think anyone who is going to implement COMPARATOR won't see i;unicode-casemap requirement as a problem. --=-baA9QaoKY2tQJvsfXhIn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQBGJRfsyUhSUUBViskRAltsAJ9lvWGeuiDlYgewmyoC8ySIphqyUwCYs/wm tKhlQLVXb9mHL+rS34DO7Q== =tFd3 -----END PGP SIGNATURE----- --=-baA9QaoKY2tQJvsfXhIn-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIq3ZF000511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 11:52:03 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HIq3p9000510; Tue, 17 Apr 2007 11:52:03 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIq29Q000496 for ; Tue, 17 Apr 2007 11:52:02 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6A7CC4AC22; Tue, 17 Apr 2007 20:52:03 +0200 (CEST) Message-Id: <7VZQvTpQsFkd+xU8NO8x8g.md5@libertango.oryx.com> Date: Tue, 17 Apr 2007 20:51:24 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Philip Guenther References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: That shouldn't apply to someone like Dan, since he stores the data as UTF-16. He may have a nasty problem converting some of his Subject fields to unicode, but it's not a collation problem in his case. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIQGia092648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 11:26:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HIQGds092647; Tue, 17 Apr 2007 11:26:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HIQEsb092639 for ; Tue, 17 Apr 2007 11:26:15 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id CA9AE4AC22; Tue, 17 Apr 2007 20:26:15 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 20:25:36 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: >> I wanted to permit implementations of i;ascii-casemap to do whatever >> comes easiest outside US-ASCII. However, the final RFC doesn't >> reflect my viewpoint in this respect. I don't remember why and >> don't feel like searching my archive. I certainly wasn't aware of >> the argument you bring up now. >> >> Do you think this is a signficant issue? It doesn't affect searching >> to a noticeable degree, and its impact on sorting is O(size of >> result set), not O(size of mailbox). > > Actually, yeah, it does impact search. If you search for > "Mtley Cre", i;ascii-casemap doesn't allow that > to match "MTLEY CRE". If you've only stored an > upcased version of the text, you can't tell the case on the original > and thus you can't determine if the non-ASCII accented characters > match under i;octet. By the time you get that far, you've eliminated almost all messages not in the actual result set, so opening and rechecking isn't so awfully expensive. >> > If your aim is to make baseline COMPARATOR support fairly >> > lightweight for IMAP servers, you may be constrained to only >> > requiring i;unicode-casemap. >> >> Mumble. Given how many IMAP servers actually implement >> i;ascii-casemap and nothing else, I'm not happy doing that. Make >> some other people agree with you so Pete will say "WG consensus". > > Is this true? Do these servers really implement i;ascii-casemap as > defined in RFC 4790? I'd expect any RFC 3501-compliant server that > knows about more charsets than just US-ASCII to be supporting > i;unicode-casemap and *not* i;ascii-casemap because of > case-insensitive "SEARCH CHARSET". Build some consensus please. I don't want to argue today - I'm in a mood to help little old ladies halfway across the street. Being civil is a strain. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HH6Cll075402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 10:06:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HH6CkO075401; Tue, 17 Apr 2007 10:06:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HH6AqT075394 for ; Tue, 17 Apr 2007 10:06:12 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 2197A810C8B; Tue, 17 Apr 2007 09:59:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id AAE8DFA865; Tue, 17 Apr 2007 10:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgb4PgawmRSa; Tue, 17 Apr 2007 10:06:04 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id E00B5FA862; Tue, 17 Apr 2007 10:06:04 -0700 (PDT) Date: Tue, 17 Apr 2007 10:06:04 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <7760328.3981176829564724.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I wanted to permit implementations of i;ascii-casemap to do whatever > comes easiest outside US-ASCII. However, the final RFC doesn't reflect > my viewpoint in this respect. I don't remember why and don't feel like > searching my archive. I certainly wasn't aware of the argument you > bring up now. > > Do you think this is a signficant issue? It doesn't affect searching > to a noticeable degree, and its impact on sorting is O(size of result > set), not O(size of mailbox). Actually, yeah, it does impact search. If you search for "Mtley Cre", i;ascii-casemap doesn't allow that to match "MTLEY CRE". If you've only stored an upcased version of the text, you can't tell the case on the original and thus you can't determine if the non-ASCII accented characters match under i;octet. > > If your aim is to make baseline COMPARATOR support fairly > > lightweight for IMAP servers, you may be constrained to only > > requiring i;unicode-casemap. > > Mumble. Given how many IMAP servers actually implement i;ascii-casemap > and nothing else, I'm not happy doing that. Make some other people > agree with you so Pete will say "WG consensus". Is this true? Do these servers really implement i;ascii-casemap as defined in RFC 4790? I'd expect any RFC 3501-compliant server that knows about more charsets than just US-ASCII to be supporting i;unicode-casemap and *not* i;ascii-casemap because of case-insensitive "SEARCH CHARSET". Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGkKwf071708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 09:46:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HGkK5u071707; Tue, 17 Apr 2007 09:46:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HGjwEe071648 for ; Tue, 17 Apr 2007 09:46:19 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 2DFB14AC22; Tue, 17 Apr 2007 18:45:59 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 18:45:19 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > i;ascii-casemap is problematic as well, for roughly the same reasons: > > Its equality, ordering, and substring operations are as for > i;octet, except that at first, the lower-case letters (octet > values 97-122) in each input string are changed to upper case > (octet values 65-90). > > Servers wishing to optimize i;unicode-casemap may well store only a > searchable upper case version of the text, which will sort > incorrectly under i;ascii-casemap. Good point. I wanted to permit implementations of i;ascii-casemap to do whatever comes easiest outside US-ASCII. However, the final RFC doesn't reflect my viewpoint in this respect. I don't remember why and don't feel like searching my archive. I certainly wasn't aware of the argument you bring up now. Do you think this is a signficant issue? It doesn't affect searching to a noticeable degree, and its impact on sorting is O(size of result set), not O(size of mailbox). > If your aim is to make baseline COMPARATOR support fairly lightweight > for IMAP servers, you may be constrained to only requiring > i;unicode-casemap. Mumble. Given how many IMAP servers actually implement i;ascii-casemap and nothing else, I'm not happy doing that. Make some other people agree with you so Pete will say "WG consensus". Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFqgiq061943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 08:52:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HFqgD7061942; Tue, 17 Apr 2007 08:52:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFqLr5061907 for ; Tue, 17 Apr 2007 08:52:42 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 993FA810C89; Tue, 17 Apr 2007 08:45:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 5F01DFA862; Tue, 17 Apr 2007 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxampf6gfOw6; Tue, 17 Apr 2007 08:52:18 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id A5685FA863; Tue, 17 Apr 2007 08:52:18 -0700 (PDT) Date: Tue, 17 Apr 2007 08:52:18 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <957519398.13721176825138535.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.31.46.252] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > IMAP (via SEARCH) essentially requires that message content be > > searchable in some intermediate transcoded form (we chose UTF-16). > > COMPARATOR (via "i;octet") requires that message content be > > searchable in its original form pace content-encoding. > > Only i;octet does that... we did a lot of work for RFC4790 to allow > your kind of implementation, so I think it should be reasonable that > COMPARATOR allows it too. > > As far as I can see, the mention of i;octet in > draft-crispin-collation-unicasemap is the only substantial requirement > on i;octet, and it's weak. The one in draft-ietf-imapext-i18n is a > leftover - something I forgot to delete when its rationale > disappeared. i;ascii-casemap is problematic as well, for roughly the same reasons: Its equality, ordering, and substring operations are as for i;octet, except that at first, the lower-case letters (octet values 97-122) in each input string are changed to upper case (octet values 65-90). Servers wishing to optimize i;unicode-casemap may well store only a searchable upper case version of the text, which will sort incorrectly under i;ascii-casemap. COMPARATOR requires servers to implement both i;ascii-casemap and i;octet (though i;octet sounds like it may be on the way out). If your aim is to make baseline COMPARATOR support fairly lightweight for IMAP servers, you may be constrained to only requiring i;unicode-casemap. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFKGc9055167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 08:20:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HFKG0F055166; Tue, 17 Apr 2007 08:20:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HFKEsS055159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 08:20:15 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9E6BF49800C; Tue, 17 Apr 2007 16:20:13 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17729-03; Tue, 17 Apr 2007 16:20:07 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id CC2E1498002; Tue, 17 Apr 2007 16:20:06 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> <4156.1176801621.000131@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <26269.1176823206.810258@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 16:20:06 +0100 From: Dave Cridland To: Mark Crispin Cc: Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Apr 17 14:30:14 2007, Mark Crispin wrote: > > On Tue, 17 Apr 2007, Dave Cridland wrote: >> I don't think it's quite right to state that "everything in IMAP >> is case-insensitive", since it seems intuitive to me that subject >> lines and other human-orientated text is demonstratively >> case-sensitive; it merely may be more useful to search it >> case-insensitively for much of the time. > > Take a time machine back 21 years and tell me that I am wrong for > specifying that everything in IMAP is case-insensitive. I would > have told you back then that you are wrong, and I see no good cause > to reverse that choice today. NO, ON FURTHER CONSIDERATION YOU'RE ABSOLUTELY RIGHT. CASE IS NEVER INDICATIVE OF ANYTHING, THEREFORE IT MAKES NO SENSE TO SEARCH FOR IT IN ANY INSTANCE. ALSO, ALL EMAIL SHOULD BE PRESENTED ON PROPER 80 COLUMN DISPLAYS, WITH NICE GREEN TEXT ON A PALE GREY SMEARED BACKGROUND YOU'RE ENCOURAGED TO CALL BLACK. Seriously, though, while I'd readily agree that case should be irrelevant in IMAP protocol elements - we've already had that argument, in fact - I don't see that the same applies to human-created, human-directed text, such as subject fields, where the paragraph above does show that case conveys information. It seems reasonable that we wouldn't want to mandate that clients should be prevented from searching case-sensitively. Similarly, many IMAP servers, by stripping away spaces and punctuation before the search test, can harm the usability of searches. Not always. Just sometimes. I don't think that's a contentious statement, and I suspect I've worded this badly if you're disagreeing with me this strongly. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HDUoA8039985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 06:30:51 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3HDUo0K039984; Tue, 17 Apr 2007 06:30:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3HDUTHF039932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Apr 2007 06:30:50 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3HDULhg032731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Apr 2007 06:30:21 -0700 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3HDUI75031000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Apr 2007 06:30:20 -0700 Date: Tue, 17 Apr 2007 06:30:14 -0700 From: Mark Crispin To: Dave Cridland cc: Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <4156.1176801621.000131@peirce.dave.cridland.net> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> <4156.1176801621.000131@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.17.61834 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 17 Apr 2007, Dave Cridland wrote: > I don't think it's quite right to state that "everything in IMAP is > case-insensitive", since it seems intuitive to me that subject lines and > other human-orientated text is demonstratively case-sensitive; it merely may > be more useful to search it case-insensitively for much of the time. Take a time machine back 21 years and tell me that I am wrong for specifying that everything in IMAP is case-insensitive. I would have told you back then that you are wrong, and I see no good cause to reverse that choice today. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9KU5R012805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 02:20:30 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H9KUoL012804; Tue, 17 Apr 2007 02:20:30 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9KR2N012798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 02:20:29 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3002F49800C; Tue, 17 Apr 2007 10:20:27 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14023-10; Tue, 17 Apr 2007 10:20:21 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 02038498002; Tue, 17 Apr 2007 10:20:21 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <4156.1176801621.000131@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 10:20:20 +0100 From: Dave Cridland To: Mark Crispin Cc: Arnt Gulbrandsen , Timo Sirainen , Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Apr 17 00:04:24 2007, Mark Crispin wrote: > > On Mon, 16 Apr 2007, Dave Cridland wrote: >> ACAP deals in arbitrary binary data which *might* be treatable as >> text - the server has no way of knowing. "i;octet" is remarkably >> useful at doing exact matches, whether text or binary, and was the >> only comparator capable of doing case-sensitive matching on text. >> In IMAP, this is the only use, and there are undoubtedly better >> ways of doing this. > > I don't understand. Everything in IMAP is case-insensitive by > definition. There is, AFAIK, no need or use for i;octet anywhere in > IMAP. As I said, I was searching for OMA in subject lines rather a lot yesterday - if I were able to have specified a case-sensitive match, I would have done, since the sequence "oma" appears rather a lot in spurious results. (Such as "Domain", "Automaton", and rather interestingly, "to make" and "from a" on several implementations). I don't think it's quite right to state that "everything in IMAP is case-insensitive", since it seems intuitive to me that subject lines and other human-orientated text is demonstratively case-sensitive; it merely may be more useful to search it case-insensitively for much of the time. (This is not a demand for an "i;unicode-not-casemap" or anything, merely an observation.) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9Br8f012121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 02:11:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H9BrFT012120; Tue, 17 Apr 2007 02:11:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H9BVDj012075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2007 02:11:52 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 3A5C649800C; Tue, 17 Apr 2007 10:11:28 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14023-05; Tue, 17 Apr 2007 10:11:22 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id E539D498002; Tue, 17 Apr 2007 10:11:21 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> In-Reply-To: <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> MIME-Version: 1.0 Message-Id: <4156.1176801081.929064@peirce.dave.cridland.net> Date: Tue, 17 Apr 2007 10:11:21 +0100 From: Dave Cridland To: Arnt Gulbrandsen Cc: Alexey Melnikov , Mark Crispin , Timo Sirainen , Cyrus Daboo , Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue Apr 17 09:38:31 2007, Arnt Gulbrandsen wrote: > i;unicode-casemap contains a sentence which might be construed as > "and use i;octet from this point on". I'll try to suggest a > alternative wording there, something that reads naturally for an > UCS-4 implementation without i;octet. Well, to do "i;octet" would mean encoding to UTF-8 first. However, you get the same result if you perform a dictionary-like ordering over UCS-4, as far as I'm aware, so it's not a problem for collations, and equality tests work fine too. It's things like substring matching which cause problems, since you can search for a substring matching partial UTF-8 sequences in principle, however, if you've already called those out as illegal input at a protocol level (or "super-comparator" level in this case), even that's blocked. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8iapW009087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 01:44:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H8ia12009085; Tue, 17 Apr 2007 01:44:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8iYLm009073 for ; Tue, 17 Apr 2007 01:44:35 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 83DEC4AC22; Tue, 17 Apr 2007 10:44:35 +0200 (CEST) Message-Id: Date: Tue, 17 Apr 2007 10:43:54 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > IMAP (via SEARCH) essentially requires that message content be > searchable in some intermediate transcoded form (we chose UTF-16). > COMPARATOR (via "i;octet") requires that message content be > searchable in its original form pace content-encoding. Only i;octet does that... we did a lot of work for RFC4790 to allow your kind of implementation, so I think it should be reasonable that COMPARATOR allows it too. As far as I can see, the mention of i;octet in draft-crispin-collation-unicasemap is the only substantial requirement on i;octet, and it's weak. The one in draft-ietf-imapext-i18n is a leftover - something I forgot to delete when its rationale disappeared. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8dWsr008616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Apr 2007 01:39:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3H8dWcV008615; Tue, 17 Apr 2007 01:39:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3H8dBqx008472 for ; Tue, 17 Apr 2007 01:39:31 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 349AD4AC22; Tue, 17 Apr 2007 10:39:12 +0200 (CEST) Message-Id: <8gaeE7PoQbWWOorzLZI+dw.md5@libertango.oryx.com> Date: Tue, 17 Apr 2007 10:38:31 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Alexey Melnikov , Mark Crispin , Timo Sirainen , Cyrus Daboo References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Mon, 16 Apr 2007, Arnt Gulbrandsen wrote: >>> The only place I see i;octet required is i18n draft, so I guess it's >>> still possible to change it? >> That's the stated requirement. There may be an actual requirement >> elsewhere. SORT comes to mind. > > No. SORT would use i;unicode-casemap or (older servers) > i;ascii-casemap. I always assumed that i;octet was there as a > baseline for documentation purposes. I never implemen ted it. SORT requires a complete sort, doesn't it? Nothing other than i;octet provides that any more. i;unicode-casemap contains a sentence which might be construed as "and use i;octet from this point on". I'll try to suggest a alternative wording there, something that reads naturally for an UCS-4 implementation without i;octet. >>> Is there a reason why a client should be able to force a server to >>> use i;ascii-casemap if i;unicode-casemap is also available? >> Yes, but they're odd and weird. > > Examples, please? Any test suite. A test client wishing to test everything required by lemonade would append some carefully constructed messages and use search on them with i;ascii-casemap. An IMAP client which connects to n IMAP servers and executes the same commands on each, noting any differences between the server responses. I thought of something rather different last night, can't remember what it was. But odd and weird - nothing a MUA would do. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GNwkGJ041110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 16:58:46 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GNwkhE041109; Mon, 16 Apr 2007 16:58:46 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GNwPXX041098 for ; Mon, 16 Apr 2007 16:58:45 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A91D14225E; Mon, 16 Apr 2007 16:58:25 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSxavQh4htWb; Mon, 16 Apr 2007 16:58:19 -0700 (PDT) Received: from [192.168.20.132] (207.47.10.130.static.nextweb.net [207.47.10.130]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 733E914225D; Mon, 16 Apr 2007 16:58:18 -0700 (PDT) In-Reply-To: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06587902-2E31-44DC-883F-AB7E0E2150AE@osafoundation.org> Cc: ietf-imapext@imc.org, Mark Crispin , Cyrus Daboo , Dave Cridland , Kjetil Torgrim Homme Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: SORT on addresses Date: Mon, 16 Apr 2007 16:58:14 -0700 To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Apr 12, 2007, at 7:05 AM, Arnt Gulbrandsen wrote: > > Dave Cridland writes: >> Yes, exactly - you've put it clearer than I did, but that's my >> intention. > > Fine phrasing. > >> I'd add a caveat that while I'll like to go all the way with the >> examination of what's needed, I wouldn't want to commit to >> producing capabilities to cover everything we find. > > Charter: Examine the types of sort, search and thread features > offered by modern email clients. Provide server-side extensions (to > IMAP, SMTP or other protocols) for that which it can be done faster > and/or better on the server. Speaking personally, +1 Email clients like OSAF's Chandler and Opera M2 are ill-served by servers that assume that mail is divided into digestible chunks in child mailboxes/folders and that folders are the primary way users find emails. Synch errors seem commoner (not assigning blame, merely noting what may be a spurious connection; I actually have no idea why this would be the case). Faceted browsers are potentially a strong UI model for applications where the user wants to find a particular object among thousands in a library or repository (MP3s in a music library, email, files on disk, bookmarks, etc). Many users are unwilling to sort all their data objects into folders and keywords or tags are not always filled in for individual objects even in a system that supports tagging. Most users can't easily construct search queries with multiple terms from scratch, yet they can use faceted browsers which implicitly do multiple term queries. Faceted browsing in some sense transcends both folder-sorted browsing and tagging/searching. In order to work well however it needs well-indexed data and good search functions. Lisa Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GN57vj028870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 16:05:08 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GN57Om028868; Mon, 16 Apr 2007 16:05:07 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GN4jlb028796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 16:05:06 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GN4dHX003440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 16:04:39 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GN4dpw027585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 16:04:39 -0700 Date: Mon, 16 Apr 2007 16:04:24 -0700 (Pacific Daylight Time) From: Mark Crispin To: Dave Cridland cc: Arnt Gulbrandsen , Timo Sirainen , Enhancements to Internet email to support diverse service enivronments , ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <4156.1176760749.310421@peirce.dave.cridland.net> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> <4156.1176760749.310421@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.155034 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 16 Apr 2007, Dave Cridland wrote: > ACAP deals in arbitrary binary data which *might* be treatable as text - the > server has no way of knowing. "i;octet" is remarkably useful at doing exact > matches, whether text or binary, and was the only comparator capable of doing > case-sensitive matching on text. > In IMAP, this is the only use, and there are undoubtedly better ways of doing > this. I don't understand. Everything in IMAP is case-insensitive by definition. There is, AFAIK, no need or use for i;octet anywhere in IMAP. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GLxdsv015367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 14:59:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GLxdf0015366; Mon, 16 Apr 2007 14:59:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GLxHdY015297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2007 14:59:38 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 01C8849800C; Mon, 16 Apr 2007 22:59:15 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07595-07; Mon, 16 Apr 2007 22:59:09 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 52B46498002; Mon, 16 Apr 2007 22:59:09 +0100 (BST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: MIME-Version: 1.0 Message-Id: <4156.1176760749.310421@peirce.dave.cridland.net> Date: Mon, 16 Apr 2007 22:59:09 +0100 From: Dave Cridland To: Arnt Gulbrandsen Cc: Mark Crispin , Timo Sirainen , Enhancements to Internet email to support diverse service enivronments , Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon Apr 16 20:38:51 2007, Arnt Gulbrandsen wrote: > Mark Crispin writes: >> AFAIK, i;octet was documented for completeness. > > FWIW: 2244 specified it, I don't know why, although I'm sure the > reason is in an archive somewhere. 4790 defined a registry and > inserted the preexisting collations. ACAP deals in arbitrary binary data which *might* be treatable as text - the server has no way of knowing. "i;octet" is remarkably useful at doing exact matches, whether text or binary, and was the only comparator capable of doing case-sensitive matching on text. In IMAP, this is the only use, and there are undoubtedly better ways of doing this. (I do feel the need, sometimes, for case sensitivity - as today, when searching for messages with the subject line including "OMA"). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJsdnJ089745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:54:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJsdnm089744; Mon, 16 Apr 2007 12:54:39 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJsHIm089694 for ; Mon, 16 Apr 2007 12:54:38 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.217] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 2EB14F0BCC; Mon, 16 Apr 2007 22:54:17 +0300 (EEST) In-Reply-To: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-877554154" Message-Id: Cc: lemonade@ietf.org, ietf-imapext@imc.org, Alexey Melnikov , Cyrus Daboo Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Date: Mon, 16 Apr 2007 22:54:09 +0300 To: Arnt Gulbrandsen X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-877554154 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 16.4.2007, at 22.35, Arnt Gulbrandsen wrote: >> I would also want to see i;octet requirement gone. Actually I'd go >> even a bit further. Is there a reason why a client should be able >> to force a server to use i;ascii-casemap if i;unicode-casemap is >> also available? > > Yes, but they're odd and weird. > >> I can't think of any, but it would reduce optimization >> possibilities for server implementations. > > i;ascii-casemap is the same as i;unicode-casemap for the > intersection of their definition set, which would give you these > optimisations back. (IIRC, and it's late and...) I'm just worried that some clients (or users) would select the i;ascii-casemap even when they could (or should) use i;unicode-casemap. Non-ASCII characters with i;ascii-casemap are different, so if the server optimized i;unicode-casemap searches and a client did a non- ASCII search with i;ascii-casemap, the server would have to verify the unicode-optimized matches by searching through the messages to see if the non-ASCII casing matches exactly or not. Probably not that big of a deal, but it would be pretty pointless extra code. --Apple-Mail-1-877554154 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD4DBQFGI9RlyUhSUUBViskRAuJVAJ0STb33TJNhAsj4cT/k+5gTe+9HeACWN+sZ 8yDs/02Q92RYgCbHqI2Hng== =SGj+ -----END PGP SIGNATURE----- --Apple-Mail-1-877554154-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJjtZd088603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:45:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJjtM8088602; Mon, 16 Apr 2007 12:45:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJjYst088521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 12:45:55 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GJjNYx009434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 12:45:23 -0700 X-Auth-Received: from Ningyo-no-Mori.Panda.COM ([166.129.255.148]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GJj7f2023754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 12:45:18 -0700 Date: Mon, 16 Apr 2007 12:44:33 -0700 (Pacific Daylight Time) From: Mark Crispin To: Arnt Gulbrandsen cc: lemonade@ietf.org, ietf-imapext@imc.org, Cyrus Daboo , Alexey Melnikov , Timo Sirainen Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.123434 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 16 Apr 2007, Arnt Gulbrandsen wrote: >> The only place I see i;octet required is i18n draft, so I guess it's still >> possible to change it? > That's the stated requirement. There may be an actual requirement elsewhere. > SORT comes to mind. No. SORT would use i;unicode-casemap or (older servers) i;ascii-casemap. I always assumed that i;octet was there as a baseline for documentation purposes. I never implemen ted it. >> Is there a reason why a client should be able to force a >> server to use i;ascii-casemap if i;unicode-casemap is also available? > Yes, but they're odd and weird. Examples, please? My software did i;ascii-casemap, but only in old versions as an interim measure. Newer versions are i;unicode-casemap only. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJdZBD087699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:39:35 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJdZGA087698; Mon, 16 Apr 2007 12:39:35 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJdXtV087689 for ; Mon, 16 Apr 2007 12:39:34 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E327D4AC22; Mon, 16 Apr 2007 21:39:34 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 21:38:51 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Mark Crispin , Timo Sirainen References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > AFAIK, i;octet was documented for completeness. FWIW: 2244 specified it, I don't know why, although I'm sure the reason is in an archive somewhere. 4790 defined a registry and inserted the preexisting collations. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJajkQ087272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 12:36:45 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GJajCf087271; Mon, 16 Apr 2007 12:36:45 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GJaNu4087173 for ; Mon, 16 Apr 2007 12:36:44 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 82E7F4AC23; Mon, 16 Apr 2007 21:36:24 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 21:35:41 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Alexey Melnikov , Timo Sirainen , Cyrus Daboo References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: <1176745413.16189.379.camel@hurina> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen writes: > On Mon, 2007-04-16 at 19:08 +0200, Arnt Gulbrandsen wrote: >> I'm wondering whether the i;octet requirement has outlived its >> rationale. I know why it needed to be there in the early drafts >> (other collations fell back to i;octet for some input), but I don't >> know whether it needs to any more...? > > The only place I see i;octet required is i18n draft, so I guess it's > still possible to change it? That's the stated requirement. There may be an actual requirement elsewhere. SORT comes to mind. > I would also want to see i;octet requirement gone. Actually I'd go > even a bit further. Is there a reason why a client should be able to > force a server to use i;ascii-casemap if i;unicode-casemap is also > available? Yes, but they're odd and weird. > I can't think of any, but it would reduce optimization possibilities > for server implementations. i;ascii-casemap is the same as i;unicode-casemap for the intersection of their definition set, which would give you these optimisations back. (IIRC, and it's late and...) Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GI1JTK066077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 11:01:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GI1JMW066076; Mon, 16 Apr 2007 11:01:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GI0wxV065948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 11:01:18 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GI0o7b028048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 11:00:51 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GI0mDn004763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2007 11:00:49 -0700 Date: Mon, 16 Apr 2007 11:00:47 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: lemonade@ietf.org, IMAP Extensions WG Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <1176745413.16189.379.camel@hurina> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.104634 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: IMHO: i;ascii-casemap is important because there are legacy implementations that implement it. Specifically, i;ascii-casemap *is* effectively the comparator of IMAP since its creation in 1986. I believe that most modern IMAP server implementations do some version of i;unicode-casemap instead of i;ascii-casemap, and there is no way for the client to know with a server that does not otherwise support COMPARATOR. I can't imagine that a client would choose i;ascii-casemap instead of i;unicode-casemap. AFAIK, i;octet was documented for completeness. I would be alright with i;unicode-casemap as being mandatory-to-implement for COMPARATOR, and optional-to-implement (albeit with a SHOULD) instead of i;ascii-casemap for non-COMPARATOR servers. -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHqsuf063103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:52:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHqsb5063102; Mon, 16 Apr 2007 10:52:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHqXkb063038 for ; Mon, 16 Apr 2007 10:52:54 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 16 Apr 2007 18:52:33 +0100 Message-ID: <4623B7AC.10600@isode.com> Date: Mon, 16 Apr 2007 18:51:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> <1176745413.16189.379.camel@hurina> In-Reply-To: <1176745413.16189.379.camel@hurina> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: >Is the i;basic mentioned in i18n draft the same as i;octet? > > No. i;basic is defined in draft-gulbrandsen-collation-basic-01.txt. Note that the mandatory-to-implement in i18n draft is going to be i;unicode-casemap. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHhZfr061615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:43:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHhZGl061614; Mon, 16 Apr 2007 10:43:35 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHhYfk061607 for ; Mon, 16 Apr 2007 10:43:34 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id C6B56F0BBA; Mon, 16 Apr 2007 20:43:33 +0300 (EEST) Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR From: Timo Sirainen To: Arnt Gulbrandsen Cc: lemonade@ietf.org, ietf-imapext@imc.org, Alexey Melnikov , Cyrus Daboo In-Reply-To: <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K+TEBP4YHYMuMTvRZ4hT" Date: Mon, 16 Apr 2007 20:43:33 +0300 Message-Id: <1176745413.16189.379.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-K+TEBP4YHYMuMTvRZ4hT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-04-16 at 19:08 +0200, Arnt Gulbrandsen wrote: > I'm wondering whether the i;octet requirement has outlived its=20 > rationale. I know why it needed to be there in the early drafts (other=20 > collations fell back to i;octet for some input), but I don't know=20 > whether it needs to any more...? The only place I see i;octet required is i18n draft, so I guess it's still possible to change it? I would also want to see i;octet requirement gone. Actually I'd go even a bit further. Is there a reason why a client should be able to force a server to use i;ascii-casemap if i;unicode-casemap is also available? I can't think of any, but it would reduce optimization possibilities for server implementations. Is the i;basic mentioned in i18n draft the same as i;octet? --=-K+TEBP4YHYMuMTvRZ4hT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGI7XFyUhSUUBViskRAmXNAKCJDUxvg+eySM2NZbTNMdhPMwGTLwCfd5tA GoS1+Hnef8yXW7NZoKhQeoI= =WJFi -----END PGP SIGNATURE----- --=-K+TEBP4YHYMuMTvRZ4hT-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHKnF6057496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:20:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHKnna057495; Mon, 16 Apr 2007 10:20:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHKmN7057481 for ; Mon, 16 Apr 2007 10:20:49 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id E69034AC23; Mon, 16 Apr 2007 19:20:48 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 19:20:05 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Re: ANNOTATEMORE and COMPARATOR Cc: Mark Crispin , Timo Sirainen References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <1176742390.16189.364.camel@hurina> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > For collations in the IMAP context, UTF-16 is problematic for i;octet, yes. > i;ascii-casemap, and i;unicode-casemap. I'm not sure about i;basic. None of these - the problem was raised about a year ago by an RFC 4790 reviewer and we solved it. Using UTF-16 or UTF-8 instead of a sensible unicode encoding may make it more difficult to implement e.g. i;ascii-casemap, but not especially. Every kind of processing is more difficult in UTF-* than in UCS-*, IMO, and most collations are just specific examples of this general rules. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHJIkb056872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:19:18 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHJIbV056871; Mon, 16 Apr 2007 10:19:18 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHJInP056863 for ; Mon, 16 Apr 2007 10:19:18 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id A7B0F810C47; Mon, 16 Apr 2007 10:12:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id BF44DF2923; Mon, 16 Apr 2007 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NRc8PyFwBp9; Mon, 16 Apr 2007 10:19:17 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 74602F2922; Mon, 16 Apr 2007 10:19:17 -0700 (PDT) Date: Mon, 16 Apr 2007 10:19:17 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Timo Sirainen , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <1318894583.60131176743957154.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > a) COMPARATOR is a reasonably heavy extension to implement > > I don't think COMPARATOR ought to be that. Various other extensions > require it, and it seems wrong for me that COMPARATOR should be > heavier than its users. Tail wagging dog. > > Tell me what makes COMPARATOR heavy? IMAP (via SEARCH) essentially requires that message content be searchable in some intermediate transcoded form (we chose UTF-16). COMPARATOR (via "i;octet") requires that message content be searchable in its original form pace content-encoding. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHFa8H056291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:15:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHFasg056290; Mon, 16 Apr 2007 10:15:36 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHFFHg056245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 10:15:36 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GHF8l8022755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2007 10:15:09 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3GHF5Ug028505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Apr 2007 10:15:07 -0700 Date: Mon, 16 Apr 2007 10:15:04 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: Dan Karp , lemonade@ietf.org, IMAP Extensions WG Subject: Re: ANNOTATEMORE and COMPARATOR In-Reply-To: <1176742390.16189.364.camel@hurina> Message-ID: References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> <1176742390.16189.364.camel@hurina> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.16.95936 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 16 Apr 2007, Timo Sirainen wrote: > On Mon, 2007-04-16 at 09:41 -0700, Dan Karp wrote: >> Searchable content is effectively transcoded to UTF-16. The original >> content needed for "i;octet" is available only by serially opening, >> reading, and reparsing each message in the mailbox (stored 1 file per >> message), which is sufficiently nonperformant that we can't permit it. > Do you support full substring searches as standard SEARCH command > requires? In Zimbra's feature list I see "Ability to search using a > prefix plus a wildcard", which seems like a "no" answer. In that case > you're already noncompliant. True. I'm not sure what "search using a prefix plus a wildcard" is supposed to mean in IMAP searching, which is of substrings only. For collations in the IMAP context, UTF-16 is problematic for i;octet, i;ascii-casemap, and i;unicode-casemap. I'm not sure about i;basic. I suggest that you use either UTF-8 or UCS-4. The attraction of UTF-16 is to save memory space and a mostly-constant width if most characters are in the BMP (thus effectively the same as UCS-2 handling), but at the cost of MUCH more complex handling of non-BMP characters. -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHD9fQ055830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:13:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GHD9vL055829; Mon, 16 Apr 2007 10:13:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GHD8FN055822 for ; Mon, 16 Apr 2007 10:13:08 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 49BA84AC22; Mon, 16 Apr 2007 19:13:09 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 19:12:25 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Timo Sirainen , Cyrus Daboo References: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > a) COMPARATOR is a reasonably heavy extension to implement I don't think COMPARATOR ought to be that. Various other extensions require it, and it seems wrong for me that COMPARATOR should be heavier than its users. Tail wagging dog. Tell me what makes COMPATOR heavy? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH9L73055290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:09:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GH9LPm055289; Mon, 16 Apr 2007 10:09:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH9J9M055275 for ; Mon, 16 Apr 2007 10:09:20 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id ED8754AC22; Mon, 16 Apr 2007 19:09:20 +0200 (CEST) Message-Id: <0+Ht87fjsijKPsZrVgWMKQ.md5@libertango.oryx.com> Date: Mon, 16 Apr 2007 19:08:37 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Cyrus Daboo References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > Searchable content is effectively transcoded to UTF-16. The original > content needed for "i;octet" is available only by serially opening, > reading, and reparsing each message in the mailbox (stored 1 file per > message), which is sufficiently nonperformant that we can't permit > it. Makes sense. (We do something similar, although in our case it the problem is mitigated by other circumstances.) I'm wondering whether the i;octet requirement has outlived its rationale. I know why it needed to be there in the early drafts (other collations fell back to i;octet for some input), but I don't know whether it needs to any more...? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH3reD053613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 10:03:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GH3rUT053612; Mon, 16 Apr 2007 10:03:53 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GH3qHq053603 for ; Mon, 16 Apr 2007 10:03:52 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 59AE3810C45; Mon, 16 Apr 2007 09:57:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 7060FF2923; Mon, 16 Apr 2007 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+tM-HXrTYcC; Mon, 16 Apr 2007 10:03:52 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 482BDF2922; Mon, 16 Apr 2007 10:03:52 -0700 (PDT) Date: Mon, 16 Apr 2007 10:03:51 -0700 (PDT) From: Dan Karp To: Timo Sirainen Cc: Arnt Gulbrandsen , Eric Burger , Alexey Melnikov , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <779866965.59281176743031963.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1176742390.16189.364.camel@hurina> Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Searchable content is effectively transcoded to UTF-16. The > > original content needed for "i;octet" is available only by serially > > opening, reading, and reparsing each message in the mailbox (stored 1 > > file per message), which is sufficiently nonperformant that we can't > > permit it. > > Do you support full substring searches as standard SEARCH command > requires? In Zimbra's feature list I see "Ability to search using a > prefix plus a wildcard", which seems like a "no" answer. In that case > you're already noncompliant. *That* is a red herring, and I believe that you know it. Can we please redirect the discussion back to the core issue, which is that a) COMPARATOR is a reasonably heavy extension to implement b) METADATA is meant to be a reasonably light extension to implement c) METADATA is being positioned as a prerequisite for many new extensions d) No METADATA entries appear able to make use of the COMPARATOR functionality Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGrnuv051098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:53:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGrnKb051097; Mon, 16 Apr 2007 09:53:49 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGrSPr051009 for ; Mon, 16 Apr 2007 09:53:48 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id BD932F0BF8; Mon, 16 Apr 2007 19:53:10 +0300 (EEST) Subject: Re: ANNOTATEMORE and COMPARATOR From: Timo Sirainen To: Dan Karp Cc: Arnt Gulbrandsen , Eric Burger , Alexey Melnikov , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org In-Reply-To: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> References: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fYPDKaFTsPDGb6/paBZs" Date: Mon, 16 Apr 2007 19:53:10 +0300 Message-Id: <1176742390.16189.364.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-fYPDKaFTsPDGb6/paBZs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2007-04-16 at 09:41 -0700, Dan Karp wrote: > > > Unfortunately, my server implementation is not compatible with=20 > > > COMPARATOR, in particular the requirement to support i;octet in=20 > > > SEARCH. > >=20 > > Why not? >=20 > Searchable content is effectively transcoded to UTF-16. The original con= tent needed for "i;octet" is available only by serially opening, reading, a= nd reparsing each message in the mailbox (stored 1 file per message), which= is sufficiently nonperformant that we can't permit it. Do you support full substring searches as standard SEARCH command requires? In Zimbra's feature list I see "Ability to search using a prefix plus a wildcard", which seems like a "no" answer. In that case you're already noncompliant. --=-fYPDKaFTsPDGb6/paBZs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGI6n1yUhSUUBViskRAqOyAJ4v8JioTLJXABDMMQTsJkHI2GIVFQCZAdXa DV+uZVkeW2hKLPcIvZGdXMU= =fkR5 -----END PGP SIGNATURE----- --=-fYPDKaFTsPDGb6/paBZs-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGfYCE048690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:41:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGfYYC048689; Mon, 16 Apr 2007 09:41:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGfXhs048683 for ; Mon, 16 Apr 2007 09:41:33 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 5AB9B810C48; Mon, 16 Apr 2007 09:35:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 8B464F2923; Mon, 16 Apr 2007 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kt0DP9Ysv3AF; Mon, 16 Apr 2007 09:41:33 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 90F12F2922; Mon, 16 Apr 2007 09:41:33 -0700 (PDT) Date: Mon, 16 Apr 2007 09:41:33 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Cc: Eric Burger , Alexey Melnikov , Cyrus Daboo , lemonade@ietf.org, ietf-imapext@imc.org Message-ID: <1371854251.56951176741693461.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Unfortunately, my server implementation is not compatible with > > COMPARATOR, in particular the requirement to support i;octet in > > SEARCH. > > Why not? Searchable content is effectively transcoded to UTF-16. The original content needed for "i;octet" is available only by serially opening, reading, and reparsing each message in the mailbox (stored 1 file per message), which is sufficiently nonperformant that we can't permit it. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGZqZX048162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:35:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGZqYn048161; Mon, 16 Apr 2007 09:35:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGZU0l048097 for ; Mon, 16 Apr 2007 09:35:51 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 6FC664AC23; Mon, 16 Apr 2007 18:35:31 +0200 (CEST) Message-Id: Date: Mon, 16 Apr 2007 18:34:46 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: ANNOTATEMORE and COMPARATOR Cc: Eric Burger , Alexey Melnikov , Dan Karp , Cyrus Daboo References: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp writes: > Unfortunately, my server implementation is not compatible with > COMPARATOR, in particular the requirement to support i;octet in > SEARCH. Why not? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGFMHL044951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2007 09:15:22 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3GGFM3V044950; Mon, 16 Apr 2007 09:15:22 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3GGF164044912 for ; Mon, 16 Apr 2007 09:15:21 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id 9D714810C47; Mon, 16 Apr 2007 09:08:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id CA590F2923; Mon, 16 Apr 2007 09:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsauBtrqkC7C; Mon, 16 Apr 2007 09:14:57 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id CC622F2922; Mon, 16 Apr 2007 09:14:57 -0700 (PDT) Date: Mon, 16 Apr 2007 09:14:57 -0700 (PDT) From: Dan Karp To: Alexey Melnikov Cc: Eric Burger , Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG , Cyrus Daboo Message-ID: <1552818881.54571176740097615.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <461A8EFC.5050208@isode.com> Subject: ANNOTATEMORE and COMPARATOR MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.198.166] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd really like to implement LEMONADE. LEMONADE consists of several IMAP extensions which require METADATA, and the current METADATA draft in turn requires LIST-EXTENDED and COMPARATOR. Unfortunately, my server implementation is not compatible with COMPARATOR, in particular the requirement to support i;octet in SEARCH. I'm hoping that there's a way to come to a compromise whereby METADATA can return to not requiring COMPARATOR while still maintaining all its core functionality. I'd hate for such a small thing to be a roadblock for my and others' LEMONADE implementations. Right now, METADATA uses COMPARATOR to specify LIST-EXTENDED selection constraints. The GETMETADATA command doesn't appear to support these constraints at present (though this may be an oversight): getmetadata = "GETMETADATA" SP entries SP attribs entries = entry-match / "(" entry-match *(SP entry-match) ")" entry-match = list-mailbox attribs = attrib / "(" attrib *(SP attrib) ")" attrib = astring I've looked through all the entries defined by the base METADATA draft as well as those defined by several of the LEMONADE drafts that metion METADATA (/comment, /motd, /admin, /sort, /thread, /check, /checkperiod, /convert/..., etc.). None of these appear to benefit in a meaningful way from the LIST-EXTENDED match/collation feature, so I'm gathering that the inclusion of COMPARATOR is intended as more of a nice-to-have with an eye towards accommodating possible future needs rather than a real core METADATA feature. If this is the case -- and towards the end of making METADATA a workable foundation extension that every server can implement -- I'd like to request that the LIST-EXTENDED METADATA selection option type be removed from the METADATA draft. If in the future there is a new METADATA entry that would substantially benefit from using COMPARATOR with LIST-EXTENDED, it should be possible to reintroduce this functionality (or a subset thereof) in the same RFC that registers the new entry. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3FABFnn065642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Apr 2007 03:11:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3FABFoB065641; Sun, 15 Apr 2007 03:11:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3FAApcK065615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 15 Apr 2007 03:11:13 -0700 (MST) (envelope-from Zoltan.Ordogh@nokia.com) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3FAAUKa026889; Sun, 15 Apr 2007 13:10:46 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:10:43 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:10:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [lemonade] Deprecate IMAP IDLE? Date: Sun, 15 Apr 2007 13:08:52 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA15753D1A6@esebe199.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lemonade] Deprecate IMAP IDLE? Thread-Index: Acd+0X4e+5zWMdevTxyR0B6qrbM66wAdB4wA References: From: To: , Cc: X-OriginalArrivalTime: 15 Apr 2007 10:10:43.0076 (UTC) FILETIME=[539FAC40:01C77F46] X-Nokia-AV: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l3FABEcJ065636 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Pete, You said: >Take a look at LEMONADE, >for example. There is really little going on in LEMONADE that >could not have been done in IMAPEXT. It's pretty much the same >people and it's mostly IMAP work. I think that this one might argue that deprecating IMAP IDLE is in fact in the charter for LEMONADE. Joke level: 10%. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EK2FMo096238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 13:02:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EK2FWv096237; Sat, 14 Apr 2007 13:02:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EK2Eg9096231 for ; Sat, 14 Apr 2007 13:02:14 -0700 (MST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Sat, 14 Apr 2007 15:02:14 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sat, 14 Apr 2007 15:02:08 -0500 To: Arnt Gulbrandsen From: Pete Resnick Subject: Re: [lemonade] Deprecate IMAP IDLE? Cc: IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 4/14/07 at 9:16 PM +0200, Arnt Gulbrandsen wrote: >Don't you think we should prolong the life of IMAPEXT by keeping it >alive until each of its standards-track products either has reached >full standard or certainly won't proceed further along the standards >track? > >(I'm only half joking. Well, only 60% joking.) OK, so since we're only half joking, let me be half (well, maybe three-quarters) serious. Working groups are supposed to be short-lived task-oriented groups, not long lived review bodies looking for things to do. Aside from the organizational reasons to do that, I think there is a good (albeit sociological/psychological) reason to shut down old working groups and start up new ones: People simply run out of energy to do good work in long ongoing efforts and get re-energized when there is a new, specific effort. Take a look at LEMONADE, for example. There is really little going on in LEMONADE that could not have been done in IMAPEXT. It's pretty much the same people and it's mostly IMAP work. But the fact that it was a new effort with a specific (well, mostly specific) goal in mind re-energized people and got them working toward that goal. The act of chartering (getting everyone to step back and decide what they're doing in the "bigger picture", coming up with a case for the IESG and the rest of the community, dividing up the tasks, etc.), writing -00 drafts, getting new chairs and document editors, along with the simple fact that the work *feels* new, makes the work go forward. So, no, I don't think it's good to keep working groups around when they get really old. (This does leave open the question of how to progress things along the standards track without a WG, and I think that the IESG should--and is starting to--look at that issue.) pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EJHXYR093361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 12:17:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EJHXnZ093360; Sat, 14 Apr 2007 12:17:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EJHCD3093270 for ; Sat, 14 Apr 2007 12:17:33 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 417A54AC22; Sat, 14 Apr 2007 21:17:13 +0200 (CEST) Message-Id: Date: Sat, 14 Apr 2007 21:16:20 +0200 From: Arnt Gulbrandsen To: Pete Resnick Subject: Re: [lemonade] Deprecate IMAP IDLE? Cc: IMAP Extensions WG References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi there Mr. Chair. Don't you think we should prolong the life of IMAPEXT by keeping it alive until each of its standards-track products either has reached full standard or certainly won't proceed further along the standards track? (I'm only half joking. Well, only 60% joking.) Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EIuJ4S090058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 11:56:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EIuJW6090057; Sat, 14 Apr 2007 11:56:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EItwfo090034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 14 Apr 2007 11:56:18 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3EItv3Y021665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Apr 2007 11:55:57 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3EItkRk004342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Apr 2007 11:55:56 -0700 Date: Sat, 14 Apr 2007 11:55:45 -0700 (PDT) From: Mark Crispin To: Pete Resnick cc: IMAP Extensions WG Subject: Re: SORT on addresses In-Reply-To: Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> <461E64F8.6030206@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.14.114434 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 14 Apr 2007, Pete Resnick wrote: > On 4/12/07 at 5:57 PM +0100, Alexey Melnikov wrote: >> Mark Crispin wrote: >>> And once again, IMAPEXT finds yet another way to prolong its life. >> IMHO, for this work to happen as an official WG, either IMAPEXT needs to >> recharter, or a new WG should be formed. >> I am slightly in favor of the latter. > *If* this work happens, I am *overwhelmingly* in favor of the later. +1 (in case it wasn't obvious) -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EIrGfF089943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2007 11:53:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3EIrGDR089942; Sat, 14 Apr 2007 11:53:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3EIqtTK089930 for ; Sat, 14 Apr 2007 11:53:15 -0700 (MST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3.1b2); Sat, 14 Apr 2007 13:52:55 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <461E64F8.6030206@isode.com> References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> <461E64F8.6030206@isode.com> X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sat, 14 Apr 2007 13:52:49 -0500 To: Alexey Melnikov From: Pete Resnick Subject: Re: SORT on addresses Cc: Mark Crispin , IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 4/12/07 at 5:57 PM +0100, Alexey Melnikov wrote: >Mark Crispin wrote: > >>And once again, IMAPEXT finds yet another way to prolong its life. > >IMHO, for this work to happen as an official WG, either IMAPEXT >needs to recharter, or a new WG should be formed. >I am slightly in favor of the latter. *If* this work happens, I am *overwhelmingly* in favor of the later. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CIRo6V031096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:27:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CIRo4w031095; Thu, 12 Apr 2007 11:27:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CIRTdE031072 for ; Thu, 12 Apr 2007 11:27:49 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CIRTTI024601 for ; Thu, 12 Apr 2007 18:27:29 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00901DXK0K00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 12:27:29 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE00318DXRLQE4@mail-amer.sun.com> for ietf-imapext@imc.org; Thu, 12 Apr 2007 12:27:28 -0600 (MDT) Date: Thu, 12 Apr 2007 11:26:28 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: ietf-imapext@imc.org Message-id: <004401c77d30$16d330b0$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9Lr05zglNFgO7S3GvMgOYc93okQAAIcDw References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> <003c01c77d2b$9f8ca990$e2239681@Tundra> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To: "Fredrick the Great" , friends: bob@domain, sally@domain; Sort on Fredrick the Great To: fred@domain, friends: bob@domain, sally@domain; Sort on fred@domain To: friends: bob@domain, sally@domain;, fred@domain Sort friends To: friends: "Robert the Bruce", sally@domain;, fred@domain Sort friends Peter -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Philip Guenther Sent: April 12, 2007 11:02 To: Peter Coates Cc: ietf-imapext@imc.org Subject: RE: SORT on addresses On Thu, 12 Apr 2007, Peter Coates wrote: > The display name of the group if there is one, failing which the > display name of the first address, failing which the first address. Is > the algorithm. So this: To: fred@domain, friends: bob@domain, sally@domain; will sort on 'friends' and not 'fred'? Interesting. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI6YdI028807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:06:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CI6YWA028806; Thu, 12 Apr 2007 11:06:34 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI6DjC028776 for ; Thu, 12 Apr 2007 11:06:33 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CI6Dqe003749 for ; Thu, 12 Apr 2007 18:06:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00H01CXXUK00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 12:06:13 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE003TUCYBLTL3@mail-amer.sun.com>; Thu, 12 Apr 2007 12:06:13 -0600 (MDT) Date: Thu, 12 Apr 2007 11:05:12 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: "'Philip Guenther'" Cc: ietf-imapext@imc.org Message-id: <003e01c77d2d$1e76a200$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9LLmlH/VVGgSWQ2+Qzk3ZsPvfbgAAFlAw References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> <003c01c77d2b$9f8ca990$e2239681@Tundra> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: No. The algorithm uses the first address it finds. If that is a group, OK, but in this case the first thing it finds is fred@domain, so that is what it uses Peter -----Original Message----- From: Philip Guenther [mailto:guenther+imap@sendmail.com] Sent: April 12, 2007 11:02 To: Peter Coates Cc: ietf-imapext@imc.org Subject: RE: SORT on addresses On Thu, 12 Apr 2007, Peter Coates wrote: > The display name of the group if there is one, failing which the > display name of the first address, failing which the first address. Is > the algorithm. So this: To: fred@domain, friends: bob@domain, sally@domain; will sort on 'friends' and not 'fred'? Interesting. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI2CV8028561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:02:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CI2Cuj028560; Thu, 12 Apr 2007 11:02:12 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CI2BYK028554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 11:02:12 -0700 (MST) (envelope-from guenther+imap@sendmail.com) Received: from [192.168.123.102] (71-218-108-183.hlrn.qwest.net [71.218.108.183]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l3CI4sgf023810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 11:04:56 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l3CI4sgf023810 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1176401097; bh=GMJzgaeM6fg1r9MSeCpIUW6bRY4=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=WFyGNnbVSn9Ca0hT 5vEXYLQDngLppzsDl1X5VymaJKEW87HEHYcSBEEg/9R+JDUKU8k9zv9eU9adCgm6/Sv CeLiBkP78NT2bMdDlNPOaOesUaXNcMQ541/3VL9Olrtj7N7OpIZuDR6J9mXNb/9LvXE cJyTF86V1NxXQqe5b4toc= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l3CI4sgf023810 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=BOOakgUZpgICCGWTjYKpqzVdTzqwwCiLn/2VdAEjp+oxoHkgOjRVmrOOBsyL642+5 iYDdQVe5QZVdHLxYnGWiXYu523fqDlwzQ9ROIhI1Syg1pj7I1XyZezqDLkRM9f2peht VDKNa1gbC4HRF94V0TzO2a4u2Skp97kHTI0Akew= Date: Thu, 12 Apr 2007 12:02:01 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Peter Coates cc: ietf-imapext@imc.org Subject: RE: SORT on addresses In-Reply-To: <003c01c77d2b$9f8ca990$e2239681@Tundra> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> <003c01c77d2b$9f8ca990$e2239681@Tundra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 12 Apr 2007, Peter Coates wrote: > The display name of the group if there is one, failing which the display > name of the first address, failing which the first address. Is the > algorithm. So this: To: fred@domain, friends: bob@domain, sally@domain; will sort on 'friends' and not 'fred'? Interesting. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHtqu4027793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:55:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CHtqvi027792; Thu, 12 Apr 2007 10:55:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHtVK5027769 for ; Thu, 12 Apr 2007 10:55:52 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CHtVnq018902 for ; Thu, 12 Apr 2007 17:55:31 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00601C9SRQ00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 11:55:31 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE00JPBCGH3TB2@mail-amer.sun.com>; Thu, 12 Apr 2007 11:55:30 -0600 (MDT) Date: Thu, 12 Apr 2007 10:54:30 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: "'Philip Guenther'" Cc: ietf-imapext@imc.org Message-id: <003c01c77d2b$9f8ca990$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9KMMsHBU/RC5QTJWjHzZQVcecwQAAtjpQ References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The display name of the group if there is one, failing which the display name of the first address, failing which the first address. Is the algorithm. -----Original Message----- From: Philip Guenther [mailto:guenther+imap@sendmail.com] Sent: April 12, 2007 10:33 To: Peter Coates Cc: ietf-imapext@imc.org Subject: RE: SORT on addresses On Thu, 12 Apr 2007, Peter Coates wrote: > Being incompetent, I replied, rather than replied all when I sent a > note saying that the Sun imap server uses sort keys X-SUN-TO, > X-SUN-CC, X-SUN-FROM to sort by display-name or if display name is not > present the email address. For obvious reasons I like that algorithm. The display-name of the first actual address or will it use the display-name of a group? Hmm, the current SORT address keys use the first addr-mailbox, so they don't skip groups but will sort something like To: friends: bob@domain, sally@domain; with the key "friends"...which will be annoying if the display-name contains an RFC 2047 word, as there's no mention of decoding them like there is for the SUBJECT key. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHXsZs025666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:33:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CHXsJs025665; Thu, 12 Apr 2007 10:33:54 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHXXwI025628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 10:33:54 -0700 (MST) (envelope-from guenther+imap@sendmail.com) Received: from [192.168.123.102] (71-218-108-183.hlrn.qwest.net [71.218.108.183]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l3CHaF6I020111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:36:18 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l3CHaF6I020111 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1176399379; bh=YoiRmCGNe43nr3tfQdT78hU4mHw=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=bYXMCQSxpPwtIjnw 3JPC0pZOHFjNWRSmJaNxxk59DrQy+cCV83Sk275axwpXPFkCSJq9WBSMIxWfeu13a5l tomJKy4jjmv5uEv+rSQtDY6AX22kH34ARw5d1kOhEEyRleTkKC3KY2ySF/mLkT7pxVz vXGGsBo19wtbD2/ygF1c0= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l3CHaF6I020111 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=k7WaAYABx7+qq4/hAi6B8/g2QkpiWiRe6zzi5UmbU8lGLfwipiX0iWSzAjdAvuvr8 xYBNYm4iCuDUBb+Z9oXevZKNmshdwYw+6ePxYO30sEBJeKhIEXkdLlglZwOq/OQ2BQM uz0gJW/D8W7pJD6F2P4kACQ07V3C2k1zHvubQN8= Date: Thu, 12 Apr 2007 11:33:21 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Peter Coates cc: ietf-imapext@imc.org Subject: RE: SORT on addresses In-Reply-To: <002501c77d1f$eeafdf30$e2239681@Tundra> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <002501c77d1f$eeafdf30$e2239681@Tundra> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 12 Apr 2007, Peter Coates wrote: > Being incompetent, I replied, rather than replied all when I sent a note > saying that the Sun imap server uses sort keys X-SUN-TO, X-SUN-CC, > X-SUN-FROM to sort by display-name or if display name is not present the > email address. For obvious reasons I like that algorithm. The display-name of the first actual address or will it use the display-name of a group? Hmm, the current SORT address keys use the first addr-mailbox, so they don't skip groups but will sort something like To: friends: bob@domain, sally@domain; with the key "friends"...which will be annoying if the display-name contains an RFC 2047 word, as there's no mention of decoding them like there is for the SUBJECT key. Philip Guenther Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHI24r024489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 10:18:02 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CHI2gg024488; Thu, 12 Apr 2007 10:18:02 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CHHf3w024462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 10:18:01 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CHHc8Z022481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2007 10:17:38 -0700 X-Auth-Received: from Shimo-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CHHZHW028815 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Apr 2007 10:17:37 -0700 Date: Thu, 12 Apr 2007 10:16:58 -0700 From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: SORT on addresses In-Reply-To: <461E64F8.6030206@isode.com> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> <461E64F8.6030206@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.12.100735 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 12 Apr 2007, Alexey Melnikov wrote: > IMHO, for this work to happen as an official WG, either IMAPEXT needs to > recharter, or a new WG should be formed. > I am slightly in favor of the latter. Personally, I feel that it is long past time for IMAPEXT to die. Nor should there be a replacement any time in the short-term future. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGwgx3022583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 09:58:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CGwgO9022582; Thu, 12 Apr 2007 09:58:42 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGwM6N022569 for ; Thu, 12 Apr 2007 09:58:42 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 12 Apr 2007 17:58:21 +0100 Message-ID: <461E64F8.6030206@isode.com> Date: Thu, 12 Apr 2007 17:57:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > And once again, IMAPEXT finds yet another way to prolong its life. IMHO, for this work to happen as an official WG, either IMAPEXT needs to recharter, or a new WG should be formed. I am slightly in favor of the latter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGWK19020568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 09:32:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CGWKPX020567; Thu, 12 Apr 2007 09:32:20 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CGVxU6020544 for ; Thu, 12 Apr 2007 09:32:19 -0700 (MST) (envelope-from peter.coates@sun.com) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l3CGVo9x013117 for ; Thu, 12 Apr 2007 16:31:59 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JGE00H018APOT00@mail-amer.sun.com> (original mail from peter.coates@sun.com) for ietf-imapext@imc.org; Thu, 12 Apr 2007 10:31:50 -0600 (MDT) Received: from Tundra ([129.150.35.226]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JGE00LHW8KZIXH0@mail-amer.sun.com>; Thu, 12 Apr 2007 10:31:49 -0600 (MDT) Date: Thu, 12 Apr 2007 09:30:47 -0700 From: Peter Coates Subject: RE: SORT on addresses In-reply-to: To: "'Cyrus Daboo'" , "'Dave Cridland'" , "'Mark Crispin'" Cc: ietf-imapext@imc.org, "'Kjetil Torgrim Homme'" Message-id: <002501c77d1f$eeafdf30$e2239681@Tundra> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9CJgy2MM85ObHTDWWOCrD6bs4rwAFrRXA References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There are a class of clients that DO use server side sort and search, and those are web clients. These are probably used more than desktop imap clients. And lemonade is premised on the assumption that mobile devices will use imap and are too strapped for processing power to do more than the necessary. Being incompetent, I replied, rather than replied all when I sent a note saying that the Sun imap server uses sort keys X-SUN-TO, X-SUN-CC, X-SUN-FROM to sort by display-name or if display name is not present the email address. For obvious reasons I like that algorithm. Peter -----Original Message----- From: owner-ietf-imapext@mail.imc.org [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Cyrus Daboo Sent: April 12, 2007 06:27 To: Dave Cridland; Mark Crispin Cc: ietf-imapext@imc.org; Kjetil Torgrim Homme Subject: Re: SORT on addresses Hi Dave, --On April 12, 2007 10:03:46 AM +0100 Dave Cridland wrote: > I think that there would be serious advantage to taking a step back at > this point, and examining how users and UAs are currently searching > through mail, and see how we could make this both more efficient and > closer to the end-users' requirements. Right now, I think that IMAP > provides only rudimentary "organizational" abilities, and I think that > they're showing up as a weak point in IMAP. Lets face it, very few clients really use server-side sort/thread/search. Most download and cache and do local operations because they can offer much, much more in the way of features for that. If we are going to make changes to the server-side behavior we should go all the way. Examine the types of features offered by desktop clients doing local operations and match those with server-side capabilities. Anything less is a poor half-measure. -- Cyrus Daboo Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CFTLdL015367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 08:29:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CFTLqS015366; Thu, 12 Apr 2007 08:29:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CFTJiv015351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 08:29:21 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 059D549800E; Thu, 12 Apr 2007 16:29:19 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30401-09; Thu, 12 Apr 2007 16:29:12 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id DEDED49800B; Thu, 12 Apr 2007 16:29:12 +0100 (BST) Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <6701.1176391752.909903@peirce.dave.cridland.net> Date: Thu, 12 Apr 2007 16:29:12 +0100 From: Dave Cridland To: Mark Crispin Cc: Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Apr 12 15:29:27 2007, Mark Crispin wrote: > > And once again, IMAPEXT finds yet another way to prolong its life. No, we should come up with a much more contrived acronym than that. :-) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CFO4Wh014524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 08:24:04 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CFO433014523; Thu, 12 Apr 2007 08:24:04 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l3CFNhxU014381 for ; Thu, 12 Apr 2007 08:24:03 -0700 (MST) (envelope-from tony@att.com) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1176391417!23078218!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1725 invoked from network); 12 Apr 2007 15:23:37 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-120.messagelabs.com with SMTP; 12 Apr 2007 15:23:37 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3CFNSqg016993 for ; Thu, 12 Apr 2007 11:23:28 -0400 (EDT) Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by attrh3i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3CFMgoR016532 for ; Thu, 12 Apr 2007 11:22:43 -0400 (EDT) Received: from [135.210.81.204] (unknown[135.210.81.204](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070412152242gw10010g62e> (Authid: tony); Thu, 12 Apr 2007 15:22:42 +0000 Message-ID: <461E4FE5.8000104@att.com> Date: Thu, 12 Apr 2007 11:27:33 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 CC: IMAP Extensions WG Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: what, you expected a rest? Silly Pooh Bear, in the words of the immortal Christopher Robin. :-) Mark Crispin wrote: > > And once again, IMAPEXT finds yet another way to prolong its life. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEkfeJ010628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:46:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CEkfCf010627; Thu, 12 Apr 2007 07:46:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEkePX010620 for ; Thu, 12 Apr 2007 07:46:41 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id B6B034AC44; Thu, 12 Apr 2007 16:46:41 +0200 (CEST) Message-Id: Date: Thu, 12 Apr 2007 16:45:38 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: SORT on addresses Cc: Mark Crispin References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > And once again, IMAPEXT finds yet another way to prolong its life. IMAP is the protocol that just won't lie down and die. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEgNhY010107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:42:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CEgNL0010106; Thu, 12 Apr 2007 07:42:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CEgLaL010090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 07:42:22 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hc0V8-00083g-Q2; Thu, 12 Apr 2007 16:42:18 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hc0V8-0007jW-4g; Thu, 12 Apr 2007 16:42:18 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx8.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1Hc0V8-0007jT-16; Thu, 12 Apr 2007 16:42:18 +0200 Subject: Re: SORT on addresses From: Kjetil Torgrim Homme To: Cyrus Daboo Cc: ietf-imapext@imc.org In-Reply-To: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain Date: Thu, 12 Apr 2007 16:42:16 +0200 Message-Id: <1176388937.1096.29.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=12.0, autolearn=disabled, AWL=0.148,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: E951D6C56428B3628905DF987DC3D124053500E7 X-UiO-Ratelimit-Test: Ratelimit X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: -48 maxlevel 200 minaction 2 bait 0 mail/h: 1357 total 1021701 max/h 7466 blacklist 0 greylist 0 ratelimit 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2007-04-12 at 09:27 -0400, Cyrus Daboo wrote: > Lets face it, very few clients really use server-side sort/thread/search. > Most download and cache and do local operations because they can offer > much, much more in the way of features for that. ironically(?), webmail applications are probably the most common user of "stateless" IMAP. this is a space where improvements in server and client are relatively easily deployed, so it's not a bad space to work in. > If we are going to make changes to the server-side behavior we should go > all the way. Examine the types of features offered by desktop clients doing > local operations and match those with server-side capabilities. Anything > less is a poor half-measure. I wouldn't word it that strongly, but sure -- sounds like you have the work cut out for us. one thing is to finalise complicated stuff like "context", there are also simple things like standardise on flags for "Spam" and "Ham" which could do wonders for client interoperability. -- Kjetil T. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CETxSf007917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:29:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CETxra007916; Thu, 12 Apr 2007 07:29:59 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CETcrd007893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Apr 2007 07:29:58 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CETb2r008365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Apr 2007 07:29:37 -0700 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3CETSw1003233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Apr 2007 07:29:36 -0700 Date: Thu, 12 Apr 2007 07:29:27 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: Re: SORT on addresses In-Reply-To: Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.12.71634 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: And once again, IMAPEXT finds yet another way to prolong its life. -- 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. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CE6uXX005364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 07:06:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CE6ugJ005363; Thu, 12 Apr 2007 07:06:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CE6Ztb005344 for ; Thu, 12 Apr 2007 07:06:55 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 3619D4AC44; Thu, 12 Apr 2007 16:06:36 +0200 (CEST) Message-Id: Date: Thu, 12 Apr 2007 16:05:32 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: SORT on addresses Cc: Mark Crispin , Cyrus Daboo , Dave Cridland , Kjetil Torgrim Homme References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> <6701.1176385567.036132@peirce.dave.cridland.net> In-Reply-To: <6701.1176385567.036132@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: > Yes, exactly - you've put it clearer than I did, but that's my intention. Fine phrasing. > I'd add a caveat that while I'll like to go all the way with the > examination of what's needed, I wouldn't want to commit to producing > capabilities to cover everything we find. Charter: Examine the types of sort, search and thread features offered by modern email clients. Provide server-side extensions (to IMAP, SMTP or other protocols) for that which it can be done faster and/or better on the server. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDkb50004085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:46:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDkb80004084; Thu, 12 Apr 2007 06:46:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDkEwM004044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:46:36 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 12CDB49800C; Thu, 12 Apr 2007 14:46:14 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17132-07; Thu, 12 Apr 2007 14:46:07 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id 0A8AC49800B; Thu, 12 Apr 2007 14:46:07 +0100 (BST) Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <6701.1176385567.036132@peirce.dave.cridland.net> Date: Thu, 12 Apr 2007 14:46:07 +0100 From: Dave Cridland To: Cyrus Daboo Cc: , Kjetil Torgrim Homme , Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Apr 12 14:27:19 2007, Cyrus Daboo wrote: > > Hi Dave, > > --On April 12, 2007 10:03:46 AM +0100 Dave Cridland > wrote: > >> I think that there would be serious advantage to taking a step >> back at >> this point, and examining how users and UAs are currently searching >> through mail, and see how we could make this both more efficient >> and >> closer to the end-users' requirements. Right now, I think that IMAP >> provides only rudimentary "organizational" abilities, and I think >> that >> they're showing up as a weak point in IMAP. > > Lets face it, very few clients really use server-side > sort/thread/search. Most download and cache and do local operations > because they can offer much, much more in the way of features for > that. > > If we are going to make changes to the server-side behavior we > should go all the way. Examine the types of features offered by > desktop clients doing local operations and match those with > server-side capabilities. Anything less is a poor half-measure. Yes, exactly - you've put it clearer than I did, but that's my intention. I'd add a caveat that while I'll like to go all the way with the examination of what's needed, I wouldn't want to commit to producing capabilities to cover everything we find. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDjSYs003957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:45:28 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDjS7v003956; Thu, 12 Apr 2007 06:45:28 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDj6IS003913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:45:27 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hbzbl-0005F8-N1 for ietf-imapext@imc.org; Thu, 12 Apr 2007 15:45:05 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1Hbzbl-00010M-FZ for ietf-imapext@imc.org; Thu, 12 Apr 2007 15:45:05 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1Hbzbl-000108-DN for ietf-imapext@imc.org; Thu, 12 Apr 2007 15:45:05 +0200 Subject: Re: SORT on addresses From: Kjetil Torgrim Homme To: ietf-imapext@imc.org In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain Date: Thu, 12 Apr 2007 15:45:02 +0200 Message-Id: <1176385504.1096.19.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=12.0, autolearn=disabled, AWL=0.078,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 347666EAC46D514C249A0509ED49B413DA4BDDDE X-UiO-Ratelimit-Test: Ratelimit X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: -48 maxlevel 200 minaction 2 bait 0 mail/h: 1753 total 1019908 max/h 7466 blacklist 0 greylist 0 ratelimit 1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: first, I'd like to thank everyone for their reasoned and constructive responses. On Thu, 2007-04-12 at 10:03 +0100, Dave Cridland wrote: > On Thu Apr 12 02:38:18 2007, Mark Crispin wrote: > > Now, with that said, I would not oppose a SORTEXT proposal that > > adds new keys (as opposed to changing the current keys) that work > > as you propose. > > I would oppose a proposal *now*. I don't think we know nearly enough > to base a decision on concerning which keys to add. fair enough. Peter Coates told me in a private reply that Sun has an extension which sorts on display-name, which very well may be more aligned with what users want/expect anyway. there are probably other options. > So, here's a counter-proposal: > > We setup a mailing list, or at least agree to use an existing one, > invite a few UA developers and search-agent people [since we're heavy > on the server-side as usual], and start to figure out what's needed, > what's practical, and get to work on it. If we seem to be making > progress, we turn it into a WG if it seems to suit. sounds good to me. -- Kjetil T. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDS9gq001910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:28:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDS9Jw001909; Thu, 12 Apr 2007 06:28:09 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDRlNT001869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:28:08 -0700 (MST) (envelope-from cyrus@daboo.name) Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l3CDROZN031942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 09:27:27 -0400 Date: Thu, 12 Apr 2007 09:27:19 -0400 From: Cyrus Daboo To: Dave Cridland , Mark Crispin cc: ietf-imapext@imc.org, Kjetil Torgrim Homme Subject: Re: SORT on addresses Message-ID: In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Dave, --On April 12, 2007 10:03:46 AM +0100 Dave Cridland wrote: > I think that there would be serious advantage to taking a step back at > this point, and examining how users and UAs are currently searching > through mail, and see how we could make this both more efficient and > closer to the end-users' requirements. Right now, I think that IMAP > provides only rudimentary "organizational" abilities, and I think that > they're showing up as a weak point in IMAP. Lets face it, very few clients really use server-side sort/thread/search. Most download and cache and do local operations because they can offer much, much more in the way of features for that. If we are going to make changes to the server-side behavior we should go all the way. Examine the types of features offered by desktop clients doing local operations and match those with server-side capabilities. Anything less is a poor half-measure. -- Cyrus Daboo Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDGqx1000692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 06:16:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CDGq3q000691; Thu, 12 Apr 2007 06:16:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CDGUlo000656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 06:16:51 -0700 (MST) (envelope-from murch@andrew.cmu.edu) Received: from [192.168.137.23] (ntonawnd-cuda1-cable-bundle-68-69-73-26.kntnny.adelphia.net [68.69.73.26]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.6/8.13.6) with ESMTP id l3CDGP7I023773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Apr 2007 09:16:29 -0400 Message-ID: <461E3127.7040507@andrew.cmu.edu> Date: Thu, 12 Apr 2007 09:16:23 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland wrote: > So, here's a counter-proposal: > > We setup a mailing list, or at least agree to use an existing one, > invite a few UA developers and search-agent people [since we're heavy on > the server-side as usual], and start to figure out what's needed, what's > practical, and get to work on it. If we seem to be making progress, we > turn it into a WG if it seems to suit. > > The aim would be to get, or look into: > - a set of useful SEARCH keys, SORT keys, etc. > - multimailbox SEARCHing. > - Inexact searching, such as SCAN provides. > - Sorting by relevance. > - probably other search and organizational things. (Perhaps we could > stretch to a re-examination of ANNOTATE, or resurrect Alexey's keywords > draft - not saying we should do either, but looking into them might be > useful). > > I have no clear idea if this would be considered IETF or IRTF territory > - I suspect it might start out informal, and become formalized in one or > other or both. > > Who's willing to participate in something like this? I would be (speaking for CMU). -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CAVLWL085622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 03:31:22 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3CAVL3P085621; Thu, 12 Apr 2007 03:31:21 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3CAVKJK085614 for ; Thu, 12 Apr 2007 03:31:21 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BAD0D4AC48; Thu, 12 Apr 2007 12:31:21 +0200 (CEST) Message-Id: Date: Thu, 12 Apr 2007 12:30:17 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: SORT on addresses Cc: Mark Crispin , Dave Cridland , Kjetil Torgrim Homme References: <1176269275.26687.293.camel@havhest.ifi.uio.no> <6701.1176368626.798998@peirce.dave.cridland.net> In-Reply-To: <6701.1176368626.798998@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave Cridland writes: > I spoke to a few people in Prague about IMAP and email, and the > general area of searching and managing large quantities of email was > raised by several of them, so perhaps the time is right. Indeed. > So, here's a counter-proposal: > > We setup a mailing list, or at least agree to use an existing one, > invite a few UA developers and search-agent people [since we're heavy > on the server-side as usual], and start to figure out what's needed, > what's practical, and get to work on it. If we seem to be making > progress, we turn it into a WG if it seems to suit. > > The aim would be to get, or look into: > - a set of useful SEARCH keys, SORT keys, etc. > - multimailbox SEARCHing. > - Inexact searching, such as SCAN provides. > - Sorting by relevance. > - probably other search and organizational things. (Perhaps we could > stretch to a re-examination of ANNOTATE, or resurrect Alexey's > keywords draft - not saying we should do either, but looking into > them might be useful). > > I have no clear idea if this would be considered IETF or IRTF > territory - I suspect it might start out informal, and become > formalized in one or other or both. > > Who's willing to participate in something like this? Arnt is. No surprise I'm sure. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C94JN0078801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 02:04:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C94JeB078800; Thu, 12 Apr 2007 02:04:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk [217.155.137.60]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C93v5I078754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2007 02:04:18 -0700 (MST) (envelope-from dave@cridland.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 16703498004; Thu, 12 Apr 2007 10:03:54 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31194-01; Thu, 12 Apr 2007 10:03:46 +0100 (BST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by turner.dave.cridland.net (Postfix) with ESMTP id B2A3A498001; Thu, 12 Apr 2007 10:03:46 +0100 (BST) Subject: Re: SORT on addresses References: <1176269275.26687.293.camel@havhest.ifi.uio.no> In-Reply-To: MIME-Version: 1.0 Message-Id: <6701.1176368626.798998@peirce.dave.cridland.net> Date: Thu, 12 Apr 2007 10:03:46 +0100 From: Dave Cridland To: Mark Crispin Cc: , Kjetil Torgrim Homme Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: Debian amavisd-new at turner.dave.cridland.net Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu Apr 12 02:38:18 2007, Mark Crispin wrote: > > On Wed, 11 Apr 2007, Kjetil Torgrim Homme wrote: >> it seems to me that this behaviour is mostly useful in "old-skool" >> environments, where username@host was common. e.g., I could be >> kjetilho@tag.uio.no, kjetilho@hal.uio.no or kjetilho@bilbo.uio.no >> depending on which workstation I was logged in that day. I >> sincerely >> doubt this is widespread today. > > Please be assured that it is still quite common and still very much > a fact of life for many people. > > It is for you. Not for me, and I suspect that sorting by phrase would provide a much more useful method than looking at the address at all. (For you: mrc@ is almost uniformly Mark Crispin, and "SORT (FROM) UTF-8 ..." sorts all your mails the "right" way. For me: I'm dave@ for home, and dave.cridland@ for work. I'm pretty sure I'm not the only dave@, too. SORT (FROM) is useless for my mails as a result.) >> * will end-users think that changing the sort key to be the >> complete RFC2822 addr-spec (or RFC2822 group) is an >> improvement? >> my answer is, to the extent they notice it, an emphatic yes. > > What surety is there that such is the case? Your opinion that this > is an "improvement" has been noted. That does not constitute > research. > > I certainly agree that *a* sort key needs to exist to allow for collating the results by "the user". I'm even convinced that blindly changing FROM/TO/CC would benefit the majority of users, but ... >> * is it problematic that current deployments of the draft >> break >> wrt compliance? >> my answer is, not really. this is not a behavioural change which >> affects clients, it only affects the humans who use the clients. > > Ahem. > > A change in behavior that has been implemented and documented for > over a decade is quite problematic. > > ... the above point unnerves me, and moreover I cannot be certain that the assertion that the sort results are blindly passed through to the user is correct. > Now, with that said, I would not oppose a SORTEXT proposal that > adds new keys (as opposed to changing the current keys) that work > as you propose. I would oppose a proposal *now*. I don't think we know nearly enough to base a decision on concerning which keys to add. I think that there would be serious advantage to taking a step back at this point, and examining how users and UAs are currently searching through mail, and see how we could make this both more efficient and closer to the end-users' requirements. Right now, I think that IMAP provides only rudimentary "organizational" abilities, and I think that they're showing up as a weak point in IMAP. I spoke to a few people in Prague about IMAP and email, and the general area of searching and managing large quantities of email was raised by several of them, so perhaps the time is right. So, here's a counter-proposal: We setup a mailing list, or at least agree to use an existing one, invite a few UA developers and search-agent people [since we're heavy on the server-side as usual], and start to figure out what's needed, what's practical, and get to work on it. If we seem to be making progress, we turn it into a WG if it seems to suit. The aim would be to get, or look into: - a set of useful SEARCH keys, SORT keys, etc. - multimailbox SEARCHing. - Inexact searching, such as SCAN provides. - Sorting by relevance. - probably other search and organizational things. (Perhaps we could stretch to a re-examination of ANNOTATE, or resurrect Alexey's keywords draft - not saying we should do either, but looking into them might be useful). I have no clear idea if this would be considered IETF or IRTF territory - I suspect it might start out informal, and become formalized in one or other or both. Who's willing to participate in something like this? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C8F1T3074680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 01:15:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C8F1K6074679; Thu, 12 Apr 2007 01:15:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from dovecot.org (dovecot.org [213.157.71.38]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C8EbIS074654 for ; Thu, 12 Apr 2007 01:15:00 -0700 (MST) (envelope-from tss@iki.fi) Received: from hurina (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 581BEF0B31; Thu, 12 Apr 2007 11:14:24 +0300 (EEST) Subject: Re: SORT on addresses From: Timo Sirainen To: Mark Crispin Cc: Kjetil Torgrim Homme , ietf-imapext@imc.org In-Reply-To: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cH0f2lcWAd7jk9WgZyt8" Date: Thu, 12 Apr 2007 11:14:24 +0300 Message-Id: <1176365664.16189.97.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-cH0f2lcWAd7jk9WgZyt8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-04-11 at 18:38 -0700, Mark Crispin wrote: > Now, with that said, I would not oppose a SORTEXT proposal that adds new=20 > keys (as opposed to changing the current keys) that work as you propose. If someone starts that, perhaps it could also include REFERENCES2? http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-December/0003= 22.html Or maybe I'll just need to write a draft myself some day. --=-cH0f2lcWAd7jk9WgZyt8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGHepgyUhSUUBViskRAljkAKCIxNKxfAV+wwBX5BgZ3W5wlwRcgQCfWGqM QeF5swizM26EyKzFzsk2XvY= =iI4k -----END PGP SIGNATURE----- --=-cH0f2lcWAd7jk9WgZyt8-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C1ebXn040654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2007 18:40:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3C1ebLa040653; Wed, 11 Apr 2007 18:40:37 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3C1eFJZ040601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 Apr 2007 18:40:36 -0700 (MST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3C1e2u0009947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2007 18:40:02 -0700 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l3C1dxv5012491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Apr 2007 18:40:01 -0700 Date: Wed, 11 Apr 2007 18:38:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Kjetil Torgrim Homme cc: ietf-imapext@imc.org Subject: Re: SORT on addresses In-Reply-To: <1176269275.26687.293.camel@havhest.ifi.uio.no> Message-ID: References: <1176269275.26687.293.camel@havhest.ifi.uio.no> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.4.11.183034 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 11 Apr 2007, Kjetil Torgrim Homme wrote: > it seems to me that this behaviour is mostly useful in "old-skool" > environments, where username@host was common. e.g., I could be > kjetilho@tag.uio.no, kjetilho@hal.uio.no or kjetilho@bilbo.uio.no > depending on which workstation I was logged in that day. I sincerely > doubt this is widespread today. Please be assured that it is still quite common and still very much a fact of life for many people. > * will end-users think that changing the sort key to be the > complete RFC2822 addr-spec (or RFC2822 group) is an improvement? > my answer is, to the extent they notice it, an emphatic yes. What surety is there that such is the case? Your opinion that this is an "improvement" has been noted. That does not constitute research. > * is it problematic that current deployments of the draft break > wrt compliance? > my answer is, not really. this is not a behavioural change which > affects clients, it only affects the humans who use the clients. Ahem. A change in behavior that has been implemented and documented for over a decade is quite problematic. A declaration that software which has been distributed for more than a decade is suddenly "non-compliant" is quite problematic. The only reason why SORT is "still a draft" is that it got hung up on i18n collation. SORT has been a cast-in-stone specification for production software for many years. It can not be arbitrarily changed. Now, with that said, I would not oppose a SORTEXT proposal that adds new keys (as opposed to changing the current keys) that work as you propose. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B5SJFR034012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 22:28:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3B5SJYx034011; Tue, 10 Apr 2007 22:28:19 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3B5RuXs033958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Apr 2007 22:28:18 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HbVN5-0001Yg-Vb for ietf-imapext@imc.org; Wed, 11 Apr 2007 07:27:56 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.66) (envelope-from ) id 1HbVN5-00027I-MN for ietf-imapext@imc.org; Wed, 11 Apr 2007 07:27:55 +0200 Received: from havhest.ifi.uio.no ([129.240.68.231]) by mail-mx8.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.66) (envelope-from ) id 1HbVN5-00027F-JR for ietf-imapext@imc.org; Wed, 11 Apr 2007 07:27:55 +0200 Subject: SORT on addresses From: Kjetil Torgrim Homme To: ietf-imapext@imc.org Content-Type: text/plain Date: Wed, 11 Apr 2007 07:27:54 +0200 Message-Id: <1176269275.26687.293.camel@havhest.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.8, required=12.0, autolearn=disabled, AWL=0.154,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: F532DBCDE2FE64470DC34052B90BF100063D264D X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -47 maxlevel 200 minaction 2 bait 0 mail/h: 150 total 974842 max/h 7466 blacklist 0 greylist 0 ratelimit 0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I came across some grumblings on the info-cyrus mailing list about the behaviour of SORT with respect to FROM and TO. [Rob Mueller]: > It's defined by the IMAP sort extension. > > http://tools.ietf.org/html/draft-ietf-imapext-sort-19 > > FROM > [IMAP] addr-mailbox of the first "From" address. > > TO > [IMAP] addr-mailbox of the first "To" address. > > So it really only sorts by the localpart of the email address, not > even the domain is included, something that's annoyed our users as > well since you basically end up with UID sorting for the localparts > that are the same but different domains. That's the "standard" > though... *sigh* I was surprised to see this explanation of the behaviour, so I had to look it up (addr-mailbox being local-part wasn't obvious to me), and tried to find the justification for it in the archives. way back in 2004-11-09, Dave Cridland wrote about the mismatch between SEARCH and SORT (SEARCH looks at the headers verbatim, SORT does decoding first), and went on to say: [Dave Cridland]: > I confess to being totally bewildered by the FROM, TO and CC sort > keys, as they all appear to only sort on the local-part of the email > address - that *is* the "bit before the @", right? So different > domains collate equally? I can't understand why this should be the > case. [Mark Crispin] responded: > In practice, not all that many people use those keys. > > The idea is to tend to collect messages from a single person together, > based upon the tendency of people to have the same local-part for his > email address even though they may use many different sites. Note > that word "tend". > > It's useful, in some very limited cases. it seems to me that this behaviour is mostly useful in "old-skool" environments, where username@host was common. e.g., I could be kjetilho@tag.uio.no, kjetilho@hal.uio.no or kjetilho@bilbo.uio.no depending on which workstation I was logged in that day. I sincerely doubt this is widespread today. a given localpart will typically belong to a single entity within a given mailbox, e.g., in my personal INBOX, "christb" is unique, and there are "only" three distinct people with localpart "chris" (in my INBOX.lists there are 12 "chris"). role addresses increase the chance of mixups, though: "info", "noreply", "orders", "post", "service", "support", "webmaster" are all examples from my INBOX which belong to numerous domains and companies, and it's not at all intuitive to me that all addresses sharing one of these localparts are sorted as the same address. to give an example of when this is annoying, consider when I want to file messages from certain people into separate folders. most clients allow selecting a block by specifying the start and end in the message list, so I can operate on all of them. when the FROM criteria is equal, it falls back on sequence number, which means I have to pick messages individually since the senders are interleaved. in this scenario, even if I wanted to move all messages from "chris" regardless of domain, it's not a problem, since I can still select them as a single block. the change in behaviour is only observable in edge cases, which is why I dare bring it up at all so late in the game. I'd like to pose two questions: * will end-users think that changing the sort key to be the complete RFC2822 addr-spec (or RFC2822 group) is an improvement? my answer is, to the extent they notice it, an emphatic yes. * is it problematic that current deployments of the draft break wrt compliance? my answer is, not really. this is not a behavioural change which affects clients, it only affects the humans who use the clients. -- thank you for reading, Kjetil T. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3ABC0YW041016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 04:12:00 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3ABC0Iw041015; Tue, 10 Apr 2007 04:12:00 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3ABBcII040956 for ; Tue, 10 Apr 2007 04:11:59 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 10 Apr 2007 12:11:32 +0100 Message-ID: <461A8EFC.5050208@isode.com> Date: Mon, 09 Apr 2007 20:07:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Karp , Cyrus Daboo CC: Eric Burger , Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) References: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dan Karp wrote: >>http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt >> >> >Comments interspersed btween snippets of the draft: > > Hi Dan, > Changes from -10 to -11: > 7. Added match type and collation identifier to the LIST-EXTENDED > selection option. > 8. Made support for IMAP-I18N a requirement. > > Text comparisons may be done as part of the GETMETADATA or LIST- > EXTENDED commands. As a result, support for the COMPARATOR > [I-D.ietf-imapext-i18n] extension is REQUIRED. > >GETMETADATA doesn't actually do text comparisons, right? The BNF >doesn't seem to tie in the "matchtype" or "collation" productions. > > Check the , it references both. >But more to the point, I believe that the intention was that METADATA >should be a simple, baseline extenstion that will be required by a wide >range of other extensions. If that's the case, *PLEASE* reconsider the >wisdom of adding the LT, LE, GT, and GE matchers (and thus the >COMPARATOR requirement) to this draft. It doesn't apear to be core >functionality for METADATA, and since COMPARATOR appears nontrivial to >implement > Can you please elaborate on this? (Note that the COMPARATOR extension is about to switch to i;unicode-casemap collation (as mandatory to implement), which is much easier to implement than i;basic) > this may not only prevent server authors from implementing >METADATA but also keep us from impelenting any future extension that >requires METADATA. > > > A user can only set and retrieve private or shared annotations on a > mailbox which exists and is returned to them via a LIST or LSUB > command, irrespective of whether they have read or write access to > the actual message content of the mailbox. If the client attempts to > set or retrieve annotations on other mailboxes, the server MUST > respond with a NO response. > >I can understand the logic behind requiring LIST/LSUB access for reading >public mailbox annotations and for setting private annotations. But >that seems to be a very low bar for setting public mailbox annotations. >Adding a new ACL permission for setting annotations would make this >extension more complex and would also introduce a dependency on the ACL >extension, > Dependency in what sense? > but perhaps requiring [READ-WRITE] access to the mailbox >might be reasonable? > > > The new SETMETADATA command and the METADATA response each have a > mailbox name argument, indicating that the annotations being referred > to are attached to the specified mailbox. An empty string can be > used for the mailbox name to signify server annotations. > >What rights are required to set public and private annotations on the >server? > > None. But maybe this should be stated explicitly. > This command sets the specified list of entries by adding or > replacing the specified attributes with the values provided, on the > specified existing mailboxes. Clients can use NIL for values of > attributes it wants to remove from entries. The server MAY return a > METADATA response containing the updated annotation data. > >In this case, the server may return a METADATA response that doesn't >contain the updated annotation data or a LIST response that does, >correct? > > > This extension adds the GETMETADATA command. This allows clients to > retrieve server annotations. Mailbox annotations are retrieved via > the extended LIST command described in the next section. > > This extension adds the SETMETADATA command. This allows clients to > set annotations. > >It's a little incongruous that GETMETADATA is used only to retrieve >server annotations, but SETMETADATA can be used to set both server and >mailbox annotations. I understand that the mailbox-level function of >GETMETADATA has been passed to the LIST-EXTENDED feature, but generally >it's clearer when a GETFOO and SETFOO pair cover the same target space. > > Yes, but the alternative is to have 2 ways of getting annotations, which is worse. > If the METADATA extension is present, support for shared annotations > is REQUIRED, whilst support for private annotations is OPTIONAL. > This recognizes the fact that support for private annotations may > introduce significantly more complexity to a server in terms of > tracking ownership of the annotations, how quota is determined for > users based on their own annotations etc. Clients that support the > METADATA extension MUST handle both shared and private annotations. > >Is there a mechanism for informing clients that a server does not >support private annotations? Or is a client expected to determine this >from METADATA NOPRIVATE response codes on a SETMETADATA NO response? > > Currently the latter. >If the latter is the case, won't client implementations end up allowing >users one attempt to set private annotations and only then inform them >that the functionality is not supported by the server? > Clients can try to workaround this by trying to set an annotation to a fake value. Yes, this doesn't look very nice, but works. Defining a new capability wouldn't work, because in general case NOPRIVATE can be namespace or even mailbox-specific. We can add a new \NoPrivate per mailbox attribute to return this in LIST? > (This would probably occur once per IMAP session...) > > > If the server is unable to set an annotation because the size of its > value is too large, the server MUST return a tagged NO response with > a "[METADATA TOOBIG]" response code. > >Likewise, is there a mechanism for a server to tell its clients the >maximum annotation length it supports? Or is it up to the client to >determine this from METADATA TOOBIG error code responses? > > The latter. Also note, that the server might return TOOBIG because it simply ran out of storage space, so advertising the maximum might not be that helpful to the client. > Entry and attribute names are case-sensitive. > > Entry and attribute names MUST NOT contain asterisk ("*") or percent > ("%") characters and MUST NOT contain non-ASCII characters or the NUL > octet. Invalid entry or attribute names result in a BAD response in > any IMAP commands where they are used. > > Use of control or punctuation characters in entry and attribute names > is strongly discouraged. > >It's probably cleaner in the long run to use the BNF to explicitly >specify a limited set of permitted characters for entry and attribute >names. Constraining them to something like "atom" plus the delimiters >is probably not a bad idea. > >Given that these names are already constrained to ASCII, > I don't think this is the case! Annotation names can contain UTF-8. > I'd favor eliminating the case-sensitivity requirement. It differs from other >IMAP commands and extensions' general consistent overall case- >insensitivity (e.g. RFC 3501 keywords). > > > value > A string or binary data representing the value of the annotation. > To delete an annotation, the client can store "NIL" into the > value. The content represented by the string is determined by the > Content-Type used to register the entry (see Section 6.1 for entry > registration templates). Where applicable, the registered > Content-Type MUST include a charset parameter. Text values SHOULD > use the utf-8 [RFC3629] character set. > >Is there any reason not to mandate UTF-8 for text values? > Values can also be binary and not every binary value is a valid UTF-8. > We seem to be >moving towards standardizing on UTF-8 in IMAP, and this seems a good >opportunity to draw a line. > > "Values for annotations published on Standard track MUST use charset=UTF-8"? This still allows vendors to do whatever they want with their private annotations. > /sort > Defines the default sort criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > sorting is not required. Note that the presence of this attribute > does not imply that the server supports the IMAP SORT > [I-D.ietf-imapext-sort] extension - servers can choose to support > or not support SORT independently of this extension. In the > absence of the SORT extension, clients can choose to interpret > this entry as suggesting a client-side sort ordering of the > corresponding mailbox. > > /thread > Defines the default thread criteria [I-D.ietf-imapext-sort] to use > when first displaying the mailbox contents to the user, or NIL if > threading is not required. If both sort and thread are not NIL, > then threading should take precedence over sorting. Note that the > presence of this attribute does not imply that the server supports > the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can > choose to support or not support THREAD independently of this > extension. In the absence of the THREAD extension, clients can > choose to interpret this entry as a client-side thread ordering of > the corresponding mailbox. > >These registered annotations are odd ducks. They seem most appropriate >as private annotations on a mailbox, but in practice they may be >confusing to the end user because sorting and threading preferences are >often client-specific, not user-specific. > >For instance, a user may prefer to read their mail nonthreaded on the >desktop, but on a mobile device they may want to make use of the reduced >visual footprint of a threaded display. Likewise, more likely than not >a user won't expect their sort preferences to automatically be >transferred between their devices and clients. > > I would let other people comment on this. > Mailboxes or the server as a whole may have zero or more annotations > associated with them. An annotation contains a uniquely named entry > with a set of uniquely named attributes, each of which has a value. > Annotations can be added to mailboxes when a mailbox name is provided > as the first argument to the new command, or to the server as a whole > when the empty string is provided as the first argument to the new > command. > >Just a nitpick here, but you should probably refer to SETMETADATA >command by name since (a) it hasn't been introduced at this point in the >document and (b) there is more than one new command added by the draft. > > Agreed. > Each annotation is an entry that has a hierarchical name, with each > component of the name separated by a slash ("/"). An entry name MUST > NOT contain two consecutive "/" characters and MUST NOT end with a > "/" character. > > Each entry is made up of a set of attributes. Each attribute has a > hierarchical name, with each component of the name separated by a > period ("."). An attribute name MUST NOT contain two consecutive "." > characters and MUST NOT end with a "." character. > >My last comment is personal preference: I fear that this may be a bit of >overkill for folder annotation. I understand the need for this type of >flexible syntax for ACAP's purposes, but the use cases for IMAP appear >significantly more limited in scope. In accordance with the KISS >philosophy, is there any chance I might be able to convince everyone to >consider shedding a layer of hierarchy here? > > This is not going to be a problem in practice. IMHO, new attributes are unlikely to be standardized. IMHO, the current model of value.priv + value.shared per annotation should work for 99% cases. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l396pt8j064312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Apr 2007 23:51:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l396ptxp064311; Sun, 8 Apr 2007 23:51:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l396pTwv064291 for ; Sun, 8 Apr 2007 23:51:50 -0700 (MST) (envelope-from arnt@oryx.com) Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BAE1C4AC22; Mon, 9 Apr 2007 08:51:30 +0200 (CEST) Message-Id: Date: Mon, 9 Apr 2007 08:50:10 +0200 From: Arnt Gulbrandsen To: lemonade@ietf.org, ietf-imapext@imc.org Subject: Re: [lemonade] Deprecate IMAP IDLE? Cc: Eric Burger References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric Burger writes: > Because of this, it was proposed that IMAP NOTIFY would supercede IMAP > IDLE, leading to its deprecation. > > What do we think of this? As chair, my only care is whether we say it > obsoletes RFC 2177 or not. I think obsoleting 2177 is out of scope for Lemonade. All Lemonade can/should do is say things in profile-bis. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IcXQJ010385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2007 11:38:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l36IcXaZ010384; Fri, 6 Apr 2007 11:38:33 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l36IcCmD010339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Apr 2007 11:38:32 -0700 (MST) (envelope-from leiba@watson.ibm.com) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l36Ic7jC005039 for ; Fri, 6 Apr 2007 14:38:07 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l36Ic78Z155960 for ; Fri, 6 Apr 2007 12:38:07 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l36Ic7kH010264 for ; Fri, 6 Apr 2007 12:38:07 -0600 Received: from [9.2.42.86] (Saturn.watson.ibm.com [9.2.42.86]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l36Ic6wl010259 for ; Fri, 6 Apr 2007 12:38:06 -0600 Message-ID: <461693AB.4080902@watson.ibm.com> Date: Fri, 06 Apr 2007 14:38:35 -0400 From: Barry Leiba User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: Re: friends of imap dinner tonight References: <0e3+uqQ0qRTXTxltw3os8A.md5@dhcp-1715.ietf68.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: A little late here, but... > It was a pleasant dinner. I'm sure it was, and I'm sorry to've missed it. Perhaps in future, we should make sure that the friends of IMAP and the friends of DKIM coordinate, so those of us who have lots of friends can do both. :-) Barry Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l334VftL022924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 21:31:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l334VfXG022923; Mon, 2 Apr 2007 21:31:41 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mta02.zimbra.com (mta02.zimbra.com [4.78.240.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l334VKYa022914 for ; Mon, 2 Apr 2007 21:31:41 -0700 (MST) (envelope-from dkarp@zimbra.com) Received: from dogfood.zimbra.com (dogfood.liquidsys.com [66.92.25.198]) by mta02.zimbra.com (Postfix) with ESMTP id EB791810397; Mon, 2 Apr 2007 21:24:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id C47CF47943; Mon, 2 Apr 2007 21:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at dogfood.zimbra.com Received: from dogfood.zimbra.com ([127.0.0.1]) by localhost (dogfood.zimbra.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtH-7sZdNMoF; Mon, 2 Apr 2007 21:31:15 -0700 (PDT) Received: from dogfood.zimbra.com (localhost.localdomain [127.0.0.1]) by dogfood.zimbra.com (Postfix) with ESMTP id 0ADF347942; Mon, 2 Apr 2007 21:31:15 -0700 (PDT) Date: Mon, 2 Apr 2007 21:31:14 -0700 (PDT) From: Dan Karp To: Eric Burger Cc: Enhancements to Internet email to support diverse service enivronments , IMAP Extensions WG Message-ID: <1259253957.4021175574674855.JavaMail.root@dogfood.liquidsys.com> In-Reply-To: Subject: Re: [lemonade] Expert Review: annotatemore (like WGLC) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [75.24.193.195] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt Comments interspersed btween snippets of the draft: Changes from -10 to -11: 7. Added match type and collation identifier to the LIST-EXTENDED selection option. 8. Made support for IMAP-I18N a requirement. Text comparisons may be done as part of the GETMETADATA or LIST- EXTENDED commands. As a result, support for the COMPARATOR [I-D.ietf-imapext-i18n] extension is REQUIRED. GETMETADATA doesn't actually do text comparisons, right? The BNF doesn't seem to tie in the "matchtype" or "collation" productions. But more to the point, I believe that the intention was that METADATA should be a simple, baseline extenstion that will be required by a wide range of other extensions. If that's the case, *PLEASE* reconsider the wisdom of adding the LT, LE, GT, and GE matchers (and thus the COMPARATOR requirement) to this draft. It doesn't apear to be core functionality for METADATA, and since COMPARATOR appears nontrivial to implement this may not only prevent server authors from implementing METADATA but also keep us from impelenting any future extension that requires METADATA. A user can only set and retrieve private or shared annotations on a mailbox which exists and is returned to them via a LIST or LSUB command, irrespective of whether they have read or write access to the actual message content of the mailbox. If the client attempts to set or retrieve annotations on other mailboxes, the server MUST respond with a NO response. I can understand the logic behind requiring LIST/LSUB access for reading public mailbox annotations and for setting private annotations. But that seems to be a very low bar for setting public mailbox annotations. Adding a new ACL permission for setting annotations would make this extension more complex and would also introduce a dependency on the ACL extension, but perhaps requiring [READ-WRITE] access to the mailbox might be reasonable? The new SETMETADATA command and the METADATA response each have a mailbox name argument, indicating that the annotations being referred to are attached to the specified mailbox. An empty string can be used for the mailbox name to signify server annotations. What rights are required to set public and private annotations on the server? This command sets the specified list of entries by adding or replacing the specified attributes with the values provided, on the specified existing mailboxes. Clients can use NIL for values of attributes it wants to remove from entries. The server MAY return a METADATA response containing the updated annotation data. In this case, the server may return a METADATA response that doesn't contain the updated annotation data or a LIST response that does, correct? This extension adds the GETMETADATA command. This allows clients to retrieve server annotations. Mailbox annotations are retrieved via the extended LIST command described in the next section. This extension adds the SETMETADATA command. This allows clients to set annotations. It's a little incongruous that GETMETADATA is used only to retrieve server annotations, but SETMETADATA can be used to set both server and mailbox annotations. I understand that the mailbox-level function of GETMETADATA has been passed to the LIST-EXTENDED feature, but generally it's clearer when a GETFOO and SETFOO pair cover the same target space. If the METADATA extension is present, support for shared annotations is REQUIRED, whilst support for private annotations is OPTIONAL. This recognizes the fact that support for private annotations may introduce significantly more complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations etc. Clients that support the METADATA extension MUST handle both shared and private annotations. Is there a mechanism for informing clients that a server does not support private annotations? Or is a client expected to determine this from METADATA NOPRIVATE response codes on a SETMETADATA NO response? If the latter is the case, won't client implementations end up allowing users one attempt to set private annotations and only then inform them that the functionality is not supported by the server? (This would probably occur once per IMAP session...) If the server is unable to set an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[METADATA TOOBIG]" response code. Likewise, is there a mechanism for a server to tell its clients the maximum annotation length it supports? Or is it up to the client to determine this from METADATA TOOBIG error code responses? Entry and attribute names are case-sensitive. Entry and attribute names MUST NOT contain asterisk ("*") or percent ("%") characters and MUST NOT contain non-ASCII characters or the NUL octet. Invalid entry or attribute names result in a BAD response in any IMAP commands where they are used. Use of control or punctuation characters in entry and attribute names is strongly discouraged. It's probably cleaner in the long run to use the BNF to explicitly specify a limited set of permitted characters for entry and attribute names. Constraining them to something like "atom" plus the delimiters is probably not a bad idea. Given that these names are already constrained to ASCII, I'd favor eliminating the case-sensitivity requirement. It differs from other IMAP commands and extensions' general consistent overall case- insensitivity (e.g. RFC 3501 keywords). value A string or binary data representing the value of the annotation. To delete an annotation, the client can store "NIL" into the value. The content represented by the string is determined by the Content-Type used to register the entry (see Section 6.1 for entry registration templates). Where applicable, the registered Content-Type MUST include a charset parameter. Text values SHOULD use the utf-8 [RFC3629] character set. Is there any reason not to mandate UTF-8 for text values? We seem to be moving towards standardizing on UTF-8 in IMAP, and this seems a good opportunity to draw a line. /sort Defines the default sort criteria [I-D.ietf-imapext-sort] to use when first displaying the mailbox contents to the user, or NIL if sorting is not required. Note that the presence of this attribute does not imply that the server supports the IMAP SORT [I-D.ietf-imapext-sort] extension - servers can choose to support or not support SORT independently of this extension. In the absence of the SORT extension, clients can choose to interpret this entry as suggesting a client-side sort ordering of the corresponding mailbox. /thread Defines the default thread criteria [I-D.ietf-imapext-sort] to use when first displaying the mailbox contents to the user, or NIL if threading is not required. If both sort and thread are not NIL, then threading should take precedence over sorting. Note that the presence of this attribute does not imply that the server supports the IMAP THREAD [I-D.ietf-imapext-sort] extension - servers can choose to support or not support THREAD independently of this extension. In the absence of the THREAD extension, clients can choose to interpret this entry as a client-side thread ordering of the corresponding mailbox. These registered annotations are odd ducks. They seem most appropriate as private annotations on a mailbox, but in practice they may be confusing to the end user because sorting and threading preferences are often client-specific, not user-specific. For instance, a user may prefer to read their mail nonthreaded on the desktop, but on a mobile device they may want to make use of the reduced visual footprint of a threaded display. Likewise, more likely than not a user won't expect their sort preferences to automatically be transferred between their devices and clients. Mailboxes or the server as a whole may have zero or more annotations associated with them. An annotation contains a uniquely named entry with a set of uniquely named attributes, each of which has a value. Annotations can be added to mailboxes when a mailbox name is provided as the first argument to the new command, or to the server as a whole when the empty string is provided as the first argument to the new command. Just a nitpick here, but you should probably refer to SETMETADATA command by name since (a) it hasn't been introduced at this point in the document and (b) there is more than one new command added by the draft. Each annotation is an entry that has a hierarchical name, with each component of the name separated by a slash ("/"). An entry name MUST NOT contain two consecutive "/" characters and MUST NOT end with a "/" character. Each entry is made up of a set of attributes. Each attribute has a hierarchical name, with each component of the name separated by a period ("."). An attribute name MUST NOT contain two consecutive "." characters and MUST NOT end with a "." character. My last comment is personal preference: I fear that this may be a bit of overkill for folder annotation. I understand the need for this type of flexible syntax for ACAP's purposes, but the use cases for IMAP appear significantly more limited in scope. In accordance with the KISS philosophy, is there any chance I might be able to convince everyone to consider shedding a layer of hierarchy here?