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 l5TMshel044582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 15:54:43 -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 l5TMshfd044581; Fri, 29 Jun 2007 15:54:43 -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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TMsf1q044574 for ; Fri, 29 Jun 2007 15:54:42 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id B83271647215 for ; Sat, 30 Jun 2007 01:54:40 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183155114.3768.551.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> <1183155114.3768.551.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-72/H6HFLNYsYW66UmCxx" Date: Sat, 30 Jun 2007 01:54:40 +0300 Message-Id: <1183157680.3768.567.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-72/H6HFLNYsYW66UmCxx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hmm. I think I'm stuck with my implementation until I gain some clarity. Back to my first mail: > 3 list (subscribed recursivematch) "" * > * LIST (\Subscribed) "." "INBOX" > * LIST () "." "mail" ("CHILDINFO" ("SUBSCRIBED")) > * LIST () "." "mail.foo" ("CHILDINFO" ("SUBSCRIBED")) > * LIST (\Subscribed) "." "mail.foo.bar" ("CHILDINFO" ("SUBSCRIBED")) > * LIST (\Subscribed) "." "mail.foo.bar.baz" > 3 OK List completed. Are those non-\Subscribed LIST entries required? The examples in the draft are pretty confusing after all, because they seem to work differently than how standard LIST works. > C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" > S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "foo2/bar2" > S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "baz2/bar2" > S: * LIST (\Subscribed) "/" "baz2/bar22" > S: * LIST (\Subscribed) "/" "baz2/bar222" > S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "qux2/bar2" > S: D03 OK done >=20 > and the server may also include >=20 > S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED")) So are the "foo2" and "baz2" replies required? If they are, why isn't "quz2"? Why is it a special case just because it doesn't exist? > C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" > S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "foo2/bar1" > S: * LIST (\Subscribed) "/" "foo2/bar2" > S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "baz2/bar2" > S: * LIST (\Subscribed) "/" "baz2/bar22" > S: * LIST (\Subscribed) "/" "baz2/bar222" > S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "eps2/mamba" > S: * LIST (\Subscribed) "/" "qux2/bar2" > S: D03 OK done >=20 > the LIST responses for mailboxes "foo2", "baz2" and "eps2" still > have the CHILDINFO extended data item, even though this > information is redundant and the client can determine it by > itself. So they are required, also with "*" (Cyrus doesn't show) and not just with "*2" (Cyrus shows)? If they're only required with "*2", why? RFC 3501 treats '%' specially with LSUB. I don't see any such special casing with list-extensions. So: x list (subscribed recursivematch) "" box% x list (subscribed recursivematch) "" box x list (subscribed recursivematch) "" box* If box has a subscribed child mailbox, these all reply with: * LIST () "/" box (CHILDINFO (SUBSCRIBED)) Right? --=-72/H6HFLNYsYW66UmCxx 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) iD8DBQBGhY2wyUhSUUBViskRAgssAKCWUc0jtRwAibUXEc529HYGbIVR3gCfdGI9 rhwojDm2g0WjRiFVpyRSpB8= =/aFl -----END PGP SIGNATURE----- --=-72/H6HFLNYsYW66UmCxx-- 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 l5TMBw8R041487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 15:11:58 -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 l5TMBvKR041485; Fri, 29 Jun 2007 15:11:57 -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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TMBtnC041477 for ; Fri, 29 Jun 2007 15:11:56 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 199201647215 for ; Sat, 30 Jun 2007 01:11:55 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183066617.3768.458.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JMe34fpX1SNapCmgXM1F" Date: Sat, 30 Jun 2007 01:11:54 +0300 Message-Id: <1183155114.3768.551.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-JMe34fpX1SNapCmgXM1F Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-06-29 at 00:36 +0300, Timo Sirainen wrote: > On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > > Is there still something to be done? I just started implementing it and > > it looks OK to me. >=20 > Umm. Is this right? These non-existing hierarchy levels are horrible. I looked into Cyrus 2.4 CVS to see how it works with them. Looks like it's even worse than mine, assuming my guesses as to how replies should work have been correct so far. 1 list "" foo.* return (subscribed) * LIST (\Subscribed) "." "foo.bar.foo.bar" 1 OK List completed. 2 list (subscribed recursivematch) "" foo.*foo a) * LIST (\Nonexisting) "." "foo.bar.foo" ("CHILDINFO" ("SUBSCRIBED")) b) nothing? --=-JMe34fpX1SNapCmgXM1F 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) iD8DBQBGhYOqyUhSUUBViskRAvv+AJ9FsUdzPjb8Rd4g+T7Edmf+4wA2RgCggSfK gddbE3YXKO4EZeB2nEXjleg= =Uibt -----END PGP SIGNATURE----- --=-JMe34fpX1SNapCmgXM1F-- 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 l5TJNkxR025569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 12:23: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 l5TJNkeQ025568; Fri, 29 Jun 2007 12:23: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TJNilR025557 for ; Fri, 29 Jun 2007 12:23:45 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 301D916471E2 for ; Fri, 29 Jun 2007 22:23:30 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183066617.3768.458.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ba9x1sSj0jM68kvUDXqd" Date: Fri, 29 Jun 2007 22:23:29 +0300 Message-Id: <1183145009.3768.529.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-Ba9x1sSj0jM68kvUDXqd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-06-29 at 00:36 +0300, Timo Sirainen wrote: > On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > > Is there still something to be done? I just started implementing it and > > it looks OK to me. >=20 > Umm. Is this right? 1 list () "" * * LIST () "." "mail.foo.bar.baz" 1 OK List completed. 2 list () "" % * LIST (\Nonexistent) "." "mail" 2 OK List completed. 3 list "" (% *) * LIST (\Nonexistent) "." "mail" * LIST () "." "mail.foo.bar.baz" 3 OK List completed. I suppose? Or would "mail" be needed because its children get returned anyway? Or perhaps I should just forget about hiding nonexisting mailboxes and make LIST always return the whole hierarchy? --=-Ba9x1sSj0jM68kvUDXqd 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) iD8DBQBGhVwxyUhSUUBViskRAkx7AJ4uFVTMbfaa9Z+cJXB+JNTRUNroygCeIhEP thQ9IOxRfB5zzYLYZKNipjY= =eLOB -----END PGP SIGNATURE----- --=-Ba9x1sSj0jM68kvUDXqd-- 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 l5SM3qTO099402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 15:03: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 l5SM3qnb099401; Thu, 28 Jun 2007 15:03: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SM3mId099390 for ; Thu, 28 Jun 2007 15:03:51 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id F0ECA1647201 for ; Fri, 29 Jun 2007 01:03:45 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183066617.3768.458.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IJrPY0PNU5+ijQauvw74" Date: Fri, 29 Jun 2007 01:03:45 +0300 Message-Id: <1183068225.3768.461.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-IJrPY0PNU5+ijQauvw74 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-06-29 at 00:36 +0300, Timo Sirainen wrote: > On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > > Is there still something to be done? I just started implementing it and > > it looks OK to me. >=20 > Umm. Is this right? I suppose this is right as well, although a bit weird: 1 list (subscribed) "" hello* * LIST (\Subscribed \NonExistent) "/" "hello/world" * LIST (\Subscribed \NoInferiors \UnMarked) "/" "hello" --=-IJrPY0PNU5+ijQauvw74 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) iD8DBQBGhDBByUhSUUBViskRAmnkAJ9pU4N8gHrZ8gucCUm8G5YtI/BvMQCfaZhT L45HLCzJnpUI2hUxCIruhoY= =Yyzc -----END PGP SIGNATURE----- --=-IJrPY0PNU5+ijQauvw74-- 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 l5SLb9TF096800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 14:37: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 l5SLb9e8096799; Thu, 28 Jun 2007 14:37: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SLb402096764 for ; Thu, 28 Jun 2007 14:37:07 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 03D27FA89D6 for ; Fri, 29 Jun 2007 00:36:57 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1182992741.3768.428.camel@hurina> References: <1182992741.3768.428.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KoXXBQ8Ob8hCvWmQWHBy" Date: Fri, 29 Jun 2007 00:36:57 +0300 Message-Id: <1183066617.3768.458.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-KoXXBQ8Ob8hCvWmQWHBy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > Is there still something to be done? I just started implementing it and > it looks OK to me. Umm. Is this right? 1 lsub "" * * LSUB () "." "INBOX" * LSUB () "." "mail.foo.bar" * LSUB () "." "mail.foo.bar.baz" 1 OK Lsub completed. 2 list (subscribed) "" * * LIST (\Subscribed) "." "INBOX" * LIST (\Subscribed) "." "mail.foo.bar" * LIST (\Subscribed) "." "mail.foo.bar.baz" 2 OK List completed. 3 list (subscribed recursivematch) "" * * LIST (\Subscribed) "." "INBOX" * LIST () "." "mail" ("CHILDINFO" ("SUBSCRIBED")) * LIST () "." "mail.foo" ("CHILDINFO" ("SUBSCRIBED")) * LIST (\Subscribed) "." "mail.foo.bar" ("CHILDINFO" ("SUBSCRIBED")) * LIST (\Subscribed) "." "mail.foo.bar.baz" 3 OK List completed. --=-KoXXBQ8Ob8hCvWmQWHBy 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) iD8DBQBGhCn5yUhSUUBViskRAoHMAJ9u2x6H3rYrLaOhJNapMqM0ZEdVqQCggSDX OLaapKKGaTvr8KTTiaZox5E= =rAdx -----END PGP SIGNATURE----- --=-KoXXBQ8Ob8hCvWmQWHBy-- 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 l5SEGevC050321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 07:16:40 -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 l5SEGexw050320; Thu, 28 Jun 2007 07:16:40 -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 l5SEGaTM050312 for ; Thu, 28 Jun 2007 07:16:39 -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, 28 Jun 2007 15:16:34 +0100 Message-ID: <4683C26A.5000808@isode.com> Date: Thu, 28 Jun 2007 15:15:06 +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 To: Timo Sirainen CC: ietf-imapext@imc.org Subject: Re: list-extensions References: <1182992741.3768.428.camel@hurina> In-Reply-To: <1182992741.3768.428.camel@hurina> MIME-Version: 1.0 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 there still something to be done? I just started implementing it and >it looks OK to me. > > No. It is approved for publication and is being blocked on IMAP I18N. 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 l5S15nTY083088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 18:05: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 l5S15njK083087; Wed, 27 Jun 2007 18:05: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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5S15jEe083077 for ; Wed, 27 Jun 2007 18:05:48 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 61B9B16471E1 for ; Thu, 28 Jun 2007 04:05:42 +0300 (EEST) Subject: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mICEBH6inVNCtHVkI0mT" Date: Thu, 28 Jun 2007 04:05:41 +0300 Message-Id: <1182992741.3768.428.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-mICEBH6inVNCtHVkI0mT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is there still something to be done? I just started implementing it and it looks OK to me. Found one typo in the draft though: specify the RECURSIVEMATH selection option that there is a child --=-mICEBH6inVNCtHVkI0mT 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) iD8DBQBGgwllyUhSUUBViskRAlf2AJ43LvL26TWQBYLibbWojW8lBOho2ACfdKtH SMwVqUsMI4cB16xaiiFasiA= =IvVL -----END PGP SIGNATURE----- --=-mICEBH6inVNCtHVkI0mT-- 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 l5HJO4ms079536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jun 2007 12: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 l5HJO4GA079535; Sun, 17 Jun 2007 12: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 episteme-software.com (jabber.episteme-software.com [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HJO3qM079521 for ; Sun, 17 Jun 2007 12:24:03 -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.1b3) for ; Sun, 17 Jun 2007 14:24:04 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sun, 17 Jun 2007 14:24:02 -0500 To: IMAPEXT:; From: Pete Resnick Subject: Fwd: Nomcom 2007-8: First Call for Volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --- begin forwarded text Date: Mon, 04 Jun 2007 17:32:15 -0700 From: Lakshminath Dondeti To: ietf-announce@ietf.org Subject: Nomcom 2007-8: First Call for Volunteers List-Id: ietf-announce.ietf.org Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --- 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 l52DtT87047316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2007 06:55: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 l52DtT11047315; Sat, 2 Jun 2007 06:55: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 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 l52DtPWh047309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 2 Jun 2007 06:55:28 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l52DtMlm017960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Jun 2007 06:55:22 -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 l52DtAGL020561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 Jun 2007 06:55:21 -0700 Date: Sat, 2 Jun 2007 06:55:09 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: ietf-imapext@imc.org, Timo Sirainen Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt In-Reply-To: Message-ID: References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.2.63833 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: The IMAP base specification defines the semantics of an unknown CHARSET argument in SEARCH; it returns BADCHARSET followed by a list of charsets that the server does support. That is how you get the list of charsets that the server supports. As for codepoints that are not defined in the charset; this is nebulous and fungible over time. A codepoint which is undefined today may be defined tommorrow by an update to the charset. Thus, nobody should depend upon an undefined codepoint remaining undefined; nor should depend upon any particular error condition in that case. -- 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 l52CIQi9018502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2007 05:18:26 -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 l52CIQkU018501; Sat, 2 Jun 2007 05:18:26 -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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l52CIOD9018485 for ; Sat, 2 Jun 2007 05:18:25 -0700 (MST) (envelope-from tss@iki.fi) Received: from [82.197.4.29] (dyn4-29.adsl.mpynet.fi [82.197.4.29]) by dovecot.org (Postfix) with ESMTP id DD4BDFA8908; Sat, 2 Jun 2007 15:18:16 +0300 (EEST) In-Reply-To: References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-616019255" Message-Id: Cc: ietf-imapext@imc.org Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt Date: Sat, 2 Jun 2007 15:18:01 +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-616019255 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2.6.2007, at 10.41, Arnt Gulbrandsen wrote: >> 2. "Strings encoded using unknown character encodings should never >> match when using the SEARCH command, and should sort together with >> invalid input" >> >> What about matching invalid input with SEARCH? I think it should >> be handled in implementation-specific way. I still receive >> ISO-8859-1 mails without charset header and I'd like to be able to >> SEARCH them. > > My intention agrees with yours, but obviously my phrasing is *rotten*. > > I meant to say that the argument to a search key must be valid > input to the collation. Using 'search charset "iso-8859-3" > subject ...' to search for a 0xBE byte is BAD, since 8859-3 does > not define 0xBE. 'search charset "iso-8859-54" subject ...' ditto, > since 8859-54 does not exist. I did not want to to restrict the > message content, or mandate any specific way to match invalid > message content. If the search key is valid, the server is on its own. > > Do you agree with this, and can you suggest better verbiage? > Perhaps something about "when used as search key"? So if server sees messages with charset=hello-world, it's free to match it any way it wishes? If the search key itself contains invalid input, shouldn't server then reply with BAD instead of just not matching anything? Looks like my server currently is supposed to return "NO Invalid search key" but for some reason I can't get iconv() to fail with invalid input error, so I'm not sure if that ever happens. --Apple-Mail-1-616019255 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) iD8DBQFGYV/+yUhSUUBViskRAtlWAJ9oIrCBptZxBXy7Mo2sijdsrHekFACfb6qC csU5dSLGaZc75yeDv4xcD2c= =+in2 -----END PGP SIGNATURE----- --Apple-Mail-1-616019255-- 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 l527SlIM024153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2007 00:28:47 -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 l527SlDU024152; Sat, 2 Jun 2007 00:28:47 -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 l527SjJg024125 for ; Sat, 2 Jun 2007 00:28:46 -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 587C94AC1B; Sat, 2 Jun 2007 09:28:43 +0200 (CEST) Message-Id: Date: Sat, 2 Jun 2007 09:41:31 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt Cc: Timo Sirainen References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> In-Reply-To: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> 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: > Two things: > > 1. I thought i;unicode-casemap was supposed to be the only MUST implement: > http://www1.ietf.org/mail-archive/web/lemonade/current/msg03559.html > > Is this still going to change? I think i;unicode-casemap will end up as the only MTI, but there is some turbulence. We'll see how it goes. > 2. "Strings encoded using unknown character encodings should never > match when using the SEARCH command, and should sort together with > invalid input" > > What about matching invalid input with SEARCH? I think it should be > handled in implementation-specific way. I still receive ISO-8859-1 > mails without charset header and I'd like to be able to SEARCH them. My intention agrees with yours, but obviously my phrasing is *rotten*. I meant to say that the argument to a search key must be valid input to the collation. Using 'search charset "iso-8859-3" subject ...' to search for a 0xBE byte is BAD, since 8859-3 does not define 0xBE. 'search charset "iso-8859-54" subject ...' ditto, since 8859-54 does not exist. I did not want to to restrict the message content, or mandate any specific way to match invalid message content. If the search key is valid, the server is on its own. Do you agree with this, and can you suggest better verbiage? Perhaps something about "when used as search key"? 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 l51MchId078378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 15:38:43 -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 l51Mch1G078377; Fri, 1 Jun 2007 15:38:43 -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 l51McglX078361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jun 2007 15:38:42 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l51MccPu031216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jun 2007 15:38:38 -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 l51Mcb6s018719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jun 2007 15:38:38 -0700 Date: Fri, 1 Jun 2007 15:38:36 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt In-Reply-To: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> Message-ID: References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.1.151533 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, 2 Jun 2007, Timo Sirainen wrote: > 2. "Strings encoded using unknown character encodings should never match when > using the SEARCH command, and should sort together with invalid input" > > What about matching invalid input with SEARCH? I think it should be handled > in implementation-specific way. I still receive ISO-8859-1 mails without > charset header and I'd like to be able to SEARCH them. I am sympathetic to this request, and agree that it should be implementation-dependent under the principle of GIGO. Required behavior in this regard is practically guaranteed to be ignored. -- 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 l51MOoBo074436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 15:24: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 l51MOo0q074435; Fri, 1 Jun 2007 15:24: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l51MOmhN074400 for ; Fri, 1 Jun 2007 15:24:49 -0700 (MST) (envelope-from tss@iki.fi) Received: from [82.197.4.29] (dyn4-29.adsl.mpynet.fi [82.197.4.29]) by dovecot.org (Postfix) with ESMTP id B9ECDFA891D for ; Sat, 2 Jun 2007 01:24:42 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-566011736" Message-Id: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt Date: Sat, 2 Jun 2007 01:24:34 +0300 To: ietf-imapext@imc.org 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-566011736 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Two things: 1. I thought i;unicode-casemap was supposed to be the only MUST implement: http://www1.ietf.org/mail-archive/web/lemonade/current/msg03559.html Is this still going to change? 2. "Strings encoded using unknown character encodings should never match when using the SEARCH command, and should sort together with invalid input" What about matching invalid input with SEARCH? I think it should be handled in implementation-specific way. I still receive ISO-8859-1 mails without charset header and I'd like to be able to SEARCH them. --Apple-Mail-1-566011736 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) iD8DBQFGYJynyUhSUUBViskRAmkyAJ9STR/GT2Pybm8+FcH/z3jr0hZO2wCfa53z Tv9SyEJKzuqBsYYCoqa3yeU= =EN1H -----END PGP SIGNATURE----- --Apple-Mail-1-566011736-- 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 l51KASva041489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 13:10: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 l51KASJm041487; Fri, 1 Jun 2007 13:10: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 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 l51KAN2T041452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jun 2007 13:10:24 -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.05) with ESMTP id l51KAMUe027997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Jun 2007 13:10:23 -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 l51KAJJE002177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 1 Jun 2007 13:10:22 -0700 Date: Fri, 1 Jun 2007 13:10:19 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.1.122233 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: The LANGUAGE extension is technically l10n and not i18n. I won't go as far as to suggest that this document be broken up into a separate l10n and i18n document. However, the document should not blur the distinction and imply that l10n issues are i18n issues. They aren't. My suggestion is that the document should be retitled "Internet Message Access Protocol Locale and Internationalization", and then add some additional discussion about locale issues which may affect IMAP. I don't think that we need to address m17n at all in IMAP. IMAP i18n probably is sufficiently broad that it can encompass m17n. -- 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 l51Jo6ES036846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 12:50:06 -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 l51Jo6M0036845; Fri, 1 Jun 2007 12:50:06 -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 ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l51Jo2jm036836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jun 2007 12:50:05 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 70E35329C2; Fri, 1 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HuD8M-0003kC-9z; Fri, 01 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-i18n-11.txt Message-Id: Date: Fri, 01 Jun 2007 15:50:02 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : Internet Message Access Protocol Internationalization Author(s) : A. Gulbrandsen, C. Newman Filename : draft-ietf-imapext-i18n-11.txt Pages : 16 Date : 2007-6-1 Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-i18n-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-i18n-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-1105736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-1105736.I-D@ietf.org> --OtherAccess-- --NextPart-- 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 l5TMshel044582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 15:54:43 -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 l5TMshfd044581; Fri, 29 Jun 2007 15:54:43 -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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TMsf1q044574 for ; Fri, 29 Jun 2007 15:54:42 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id B83271647215 for ; Sat, 30 Jun 2007 01:54:40 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183155114.3768.551.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> <1183155114.3768.551.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-72/H6HFLNYsYW66UmCxx" Date: Sat, 30 Jun 2007 01:54:40 +0300 Message-Id: <1183157680.3768.567.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-72/H6HFLNYsYW66UmCxx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hmm. I think I'm stuck with my implementation until I gain some clarity. Back to my first mail: > 3 list (subscribed recursivematch) "" * > * LIST (\Subscribed) "." "INBOX" > * LIST () "." "mail" ("CHILDINFO" ("SUBSCRIBED")) > * LIST () "." "mail.foo" ("CHILDINFO" ("SUBSCRIBED")) > * LIST (\Subscribed) "." "mail.foo.bar" ("CHILDINFO" ("SUBSCRIBED")) > * LIST (\Subscribed) "." "mail.foo.bar.baz" > 3 OK List completed. Are those non-\Subscribed LIST entries required? The examples in the draft are pretty confusing after all, because they seem to work differently than how standard LIST works. > C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2" > S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "foo2/bar2" > S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "baz2/bar2" > S: * LIST (\Subscribed) "/" "baz2/bar22" > S: * LIST (\Subscribed) "/" "baz2/bar222" > S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "qux2/bar2" > S: D03 OK done >=20 > and the server may also include >=20 > S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED")) So are the "foo2" and "baz2" replies required? If they are, why isn't "quz2"? Why is it a special case just because it doesn't exist? > C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*" > S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "foo2/bar1" > S: * LIST (\Subscribed) "/" "foo2/bar2" > S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "baz2/bar2" > S: * LIST (\Subscribed) "/" "baz2/bar22" > S: * LIST (\Subscribed) "/" "baz2/bar222" > S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) > S: * LIST (\Subscribed) "/" "eps2/mamba" > S: * LIST (\Subscribed) "/" "qux2/bar2" > S: D03 OK done >=20 > the LIST responses for mailboxes "foo2", "baz2" and "eps2" still > have the CHILDINFO extended data item, even though this > information is redundant and the client can determine it by > itself. So they are required, also with "*" (Cyrus doesn't show) and not just with "*2" (Cyrus shows)? If they're only required with "*2", why? RFC 3501 treats '%' specially with LSUB. I don't see any such special casing with list-extensions. So: x list (subscribed recursivematch) "" box% x list (subscribed recursivematch) "" box x list (subscribed recursivematch) "" box* If box has a subscribed child mailbox, these all reply with: * LIST () "/" box (CHILDINFO (SUBSCRIBED)) Right? --=-72/H6HFLNYsYW66UmCxx 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) iD8DBQBGhY2wyUhSUUBViskRAgssAKCWUc0jtRwAibUXEc529HYGbIVR3gCfdGI9 rhwojDm2g0WjRiFVpyRSpB8= =/aFl -----END PGP SIGNATURE----- --=-72/H6HFLNYsYW66UmCxx-- 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 l5TMBw8R041487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 15:11:58 -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 l5TMBvKR041485; Fri, 29 Jun 2007 15:11:57 -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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TMBtnC041477 for ; Fri, 29 Jun 2007 15:11:56 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 199201647215 for ; Sat, 30 Jun 2007 01:11:55 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183066617.3768.458.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JMe34fpX1SNapCmgXM1F" Date: Sat, 30 Jun 2007 01:11:54 +0300 Message-Id: <1183155114.3768.551.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-JMe34fpX1SNapCmgXM1F Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-06-29 at 00:36 +0300, Timo Sirainen wrote: > On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > > Is there still something to be done? I just started implementing it and > > it looks OK to me. >=20 > Umm. Is this right? These non-existing hierarchy levels are horrible. I looked into Cyrus 2.4 CVS to see how it works with them. Looks like it's even worse than mine, assuming my guesses as to how replies should work have been correct so far. 1 list "" foo.* return (subscribed) * LIST (\Subscribed) "." "foo.bar.foo.bar" 1 OK List completed. 2 list (subscribed recursivematch) "" foo.*foo a) * LIST (\Nonexisting) "." "foo.bar.foo" ("CHILDINFO" ("SUBSCRIBED")) b) nothing? --=-JMe34fpX1SNapCmgXM1F 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) iD8DBQBGhYOqyUhSUUBViskRAvv+AJ9FsUdzPjb8Rd4g+T7Edmf+4wA2RgCggSfK gddbE3YXKO4EZeB2nEXjleg= =Uibt -----END PGP SIGNATURE----- --=-JMe34fpX1SNapCmgXM1F-- 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 l5TJNkxR025569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2007 12:23: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 l5TJNkeQ025568; Fri, 29 Jun 2007 12:23: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5TJNilR025557 for ; Fri, 29 Jun 2007 12:23:45 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 301D916471E2 for ; Fri, 29 Jun 2007 22:23:30 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183066617.3768.458.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ba9x1sSj0jM68kvUDXqd" Date: Fri, 29 Jun 2007 22:23:29 +0300 Message-Id: <1183145009.3768.529.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-Ba9x1sSj0jM68kvUDXqd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-06-29 at 00:36 +0300, Timo Sirainen wrote: > On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > > Is there still something to be done? I just started implementing it and > > it looks OK to me. >=20 > Umm. Is this right? 1 list () "" * * LIST () "." "mail.foo.bar.baz" 1 OK List completed. 2 list () "" % * LIST (\Nonexistent) "." "mail" 2 OK List completed. 3 list "" (% *) * LIST (\Nonexistent) "." "mail" * LIST () "." "mail.foo.bar.baz" 3 OK List completed. I suppose? Or would "mail" be needed because its children get returned anyway? Or perhaps I should just forget about hiding nonexisting mailboxes and make LIST always return the whole hierarchy? --=-Ba9x1sSj0jM68kvUDXqd 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) iD8DBQBGhVwxyUhSUUBViskRAkx7AJ4uFVTMbfaa9Z+cJXB+JNTRUNroygCeIhEP thQ9IOxRfB5zzYLYZKNipjY= =eLOB -----END PGP SIGNATURE----- --=-Ba9x1sSj0jM68kvUDXqd-- 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 l5SM3qTO099402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 15:03: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 l5SM3qnb099401; Thu, 28 Jun 2007 15:03: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SM3mId099390 for ; Thu, 28 Jun 2007 15:03:51 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id F0ECA1647201 for ; Fri, 29 Jun 2007 01:03:45 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1183066617.3768.458.camel@hurina> References: <1182992741.3768.428.camel@hurina> <1183066617.3768.458.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IJrPY0PNU5+ijQauvw74" Date: Fri, 29 Jun 2007 01:03:45 +0300 Message-Id: <1183068225.3768.461.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-IJrPY0PNU5+ijQauvw74 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-06-29 at 00:36 +0300, Timo Sirainen wrote: > On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > > Is there still something to be done? I just started implementing it and > > it looks OK to me. >=20 > Umm. Is this right? I suppose this is right as well, although a bit weird: 1 list (subscribed) "" hello* * LIST (\Subscribed \NonExistent) "/" "hello/world" * LIST (\Subscribed \NoInferiors \UnMarked) "/" "hello" --=-IJrPY0PNU5+ijQauvw74 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) iD8DBQBGhDBByUhSUUBViskRAmnkAJ9pU4N8gHrZ8gucCUm8G5YtI/BvMQCfaZhT L45HLCzJnpUI2hUxCIruhoY= =Yyzc -----END PGP SIGNATURE----- --=-IJrPY0PNU5+ijQauvw74-- 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 l5SLb9TF096800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 14:37: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 l5SLb9e8096799; Thu, 28 Jun 2007 14:37: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5SLb402096764 for ; Thu, 28 Jun 2007 14:37:07 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 03D27FA89D6 for ; Fri, 29 Jun 2007 00:36:57 +0300 (EEST) Subject: Re: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org In-Reply-To: <1182992741.3768.428.camel@hurina> References: <1182992741.3768.428.camel@hurina> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KoXXBQ8Ob8hCvWmQWHBy" Date: Fri, 29 Jun 2007 00:36:57 +0300 Message-Id: <1183066617.3768.458.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-KoXXBQ8Ob8hCvWmQWHBy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2007-06-28 at 04:05 +0300, Timo Sirainen wrote: > Is there still something to be done? I just started implementing it and > it looks OK to me. Umm. Is this right? 1 lsub "" * * LSUB () "." "INBOX" * LSUB () "." "mail.foo.bar" * LSUB () "." "mail.foo.bar.baz" 1 OK Lsub completed. 2 list (subscribed) "" * * LIST (\Subscribed) "." "INBOX" * LIST (\Subscribed) "." "mail.foo.bar" * LIST (\Subscribed) "." "mail.foo.bar.baz" 2 OK List completed. 3 list (subscribed recursivematch) "" * * LIST (\Subscribed) "." "INBOX" * LIST () "." "mail" ("CHILDINFO" ("SUBSCRIBED")) * LIST () "." "mail.foo" ("CHILDINFO" ("SUBSCRIBED")) * LIST (\Subscribed) "." "mail.foo.bar" ("CHILDINFO" ("SUBSCRIBED")) * LIST (\Subscribed) "." "mail.foo.bar.baz" 3 OK List completed. --=-KoXXBQ8Ob8hCvWmQWHBy 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) iD8DBQBGhCn5yUhSUUBViskRAoHMAJ9u2x6H3rYrLaOhJNapMqM0ZEdVqQCggSDX OLaapKKGaTvr8KTTiaZox5E= =rAdx -----END PGP SIGNATURE----- --=-KoXXBQ8Ob8hCvWmQWHBy-- 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 l5SEGevC050321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2007 07:16:40 -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 l5SEGexw050320; Thu, 28 Jun 2007 07:16:40 -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 l5SEGaTM050312 for ; Thu, 28 Jun 2007 07:16:39 -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, 28 Jun 2007 15:16:34 +0100 Message-ID: <4683C26A.5000808@isode.com> Date: Thu, 28 Jun 2007 15:15:06 +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 To: Timo Sirainen CC: ietf-imapext@imc.org Subject: Re: list-extensions References: <1182992741.3768.428.camel@hurina> In-Reply-To: <1182992741.3768.428.camel@hurina> MIME-Version: 1.0 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 there still something to be done? I just started implementing it and >it looks OK to me. > > No. It is approved for publication and is being blocked on IMAP I18N. 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 l5S15nTY083088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jun 2007 18:05: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 l5S15njK083087; Wed, 27 Jun 2007 18:05: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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5S15jEe083077 for ; Wed, 27 Jun 2007 18:05:48 -0700 (MST) (envelope-from tss@iki.fi) Received: from [192.168.10.2] (82-203-162-146.dsl.gohome.fi [82.203.162.146]) by dovecot.org (Postfix) with ESMTP id 61B9B16471E1 for ; Thu, 28 Jun 2007 04:05:42 +0300 (EEST) Subject: list-extensions From: Timo Sirainen To: ietf-imapext@imc.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-mICEBH6inVNCtHVkI0mT" Date: Thu, 28 Jun 2007 04:05:41 +0300 Message-Id: <1182992741.3768.428.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=-mICEBH6inVNCtHVkI0mT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is there still something to be done? I just started implementing it and it looks OK to me. Found one typo in the draft though: specify the RECURSIVEMATH selection option that there is a child --=-mICEBH6inVNCtHVkI0mT 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) iD8DBQBGgwllyUhSUUBViskRAlf2AJ43LvL26TWQBYLibbWojW8lBOho2ACfdKtH SMwVqUsMI4cB16xaiiFasiA= =IvVL -----END PGP SIGNATURE----- --=-mICEBH6inVNCtHVkI0mT-- 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 l5HJO4ms079536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jun 2007 12: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 l5HJO4GA079535; Sun, 17 Jun 2007 12: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 episteme-software.com (jabber.episteme-software.com [216.43.25.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l5HJO3qM079521 for ; Sun, 17 Jun 2007 12:24:03 -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.1b3) for ; Sun, 17 Jun 2007 14:24:04 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.3a0] Date: Sun, 17 Jun 2007 14:24:02 -0500 To: IMAPEXT:; From: Pete Resnick Subject: Fwd: Nomcom 2007-8: First Call for Volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --- begin forwarded text Date: Mon, 04 Jun 2007 17:32:15 -0700 From: Lakshminath Dondeti To: ietf-announce@ietf.org Subject: Nomcom 2007-8: First Call for Volunteers List-Id: ietf-announce.ietf.org Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --- 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 l52DtT87047316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2007 06:55: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 l52DtT11047315; Sat, 2 Jun 2007 06:55: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 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 l52DtPWh047309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 2 Jun 2007 06:55:28 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l52DtMlm017960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Jun 2007 06:55:22 -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 l52DtAGL020561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 Jun 2007 06:55:21 -0700 Date: Sat, 2 Jun 2007 06:55:09 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: ietf-imapext@imc.org, Timo Sirainen Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt In-Reply-To: Message-ID: References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.2.63833 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: The IMAP base specification defines the semantics of an unknown CHARSET argument in SEARCH; it returns BADCHARSET followed by a list of charsets that the server does support. That is how you get the list of charsets that the server supports. As for codepoints that are not defined in the charset; this is nebulous and fungible over time. A codepoint which is undefined today may be defined tommorrow by an update to the charset. Thus, nobody should depend upon an undefined codepoint remaining undefined; nor should depend upon any particular error condition in that case. -- 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 l52CIQi9018502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2007 05:18:26 -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 l52CIQkU018501; Sat, 2 Jun 2007 05:18:26 -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 [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l52CIOD9018485 for ; Sat, 2 Jun 2007 05:18:25 -0700 (MST) (envelope-from tss@iki.fi) Received: from [82.197.4.29] (dyn4-29.adsl.mpynet.fi [82.197.4.29]) by dovecot.org (Postfix) with ESMTP id DD4BDFA8908; Sat, 2 Jun 2007 15:18:16 +0300 (EEST) In-Reply-To: References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-616019255" Message-Id: Cc: ietf-imapext@imc.org Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt Date: Sat, 2 Jun 2007 15:18:01 +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-616019255 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2.6.2007, at 10.41, Arnt Gulbrandsen wrote: >> 2. "Strings encoded using unknown character encodings should never >> match when using the SEARCH command, and should sort together with >> invalid input" >> >> What about matching invalid input with SEARCH? I think it should >> be handled in implementation-specific way. I still receive >> ISO-8859-1 mails without charset header and I'd like to be able to >> SEARCH them. > > My intention agrees with yours, but obviously my phrasing is *rotten*. > > I meant to say that the argument to a search key must be valid > input to the collation. Using 'search charset "iso-8859-3" > subject ...' to search for a 0xBE byte is BAD, since 8859-3 does > not define 0xBE. 'search charset "iso-8859-54" subject ...' ditto, > since 8859-54 does not exist. I did not want to to restrict the > message content, or mandate any specific way to match invalid > message content. If the search key is valid, the server is on its own. > > Do you agree with this, and can you suggest better verbiage? > Perhaps something about "when used as search key"? So if server sees messages with charset=hello-world, it's free to match it any way it wishes? If the search key itself contains invalid input, shouldn't server then reply with BAD instead of just not matching anything? Looks like my server currently is supposed to return "NO Invalid search key" but for some reason I can't get iconv() to fail with invalid input error, so I'm not sure if that ever happens. --Apple-Mail-1-616019255 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) iD8DBQFGYV/+yUhSUUBViskRAtlWAJ9oIrCBptZxBXy7Mo2sijdsrHekFACfb6qC csU5dSLGaZc75yeDv4xcD2c= =+in2 -----END PGP SIGNATURE----- --Apple-Mail-1-616019255-- 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 l527SlIM024153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2007 00:28:47 -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 l527SlDU024152; Sat, 2 Jun 2007 00:28:47 -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 l527SjJg024125 for ; Sat, 2 Jun 2007 00:28:46 -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 587C94AC1B; Sat, 2 Jun 2007 09:28:43 +0200 (CEST) Message-Id: Date: Sat, 2 Jun 2007 09:41:31 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt Cc: Timo Sirainen References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> In-Reply-To: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> 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: > Two things: > > 1. I thought i;unicode-casemap was supposed to be the only MUST implement: > http://www1.ietf.org/mail-archive/web/lemonade/current/msg03559.html > > Is this still going to change? I think i;unicode-casemap will end up as the only MTI, but there is some turbulence. We'll see how it goes. > 2. "Strings encoded using unknown character encodings should never > match when using the SEARCH command, and should sort together with > invalid input" > > What about matching invalid input with SEARCH? I think it should be > handled in implementation-specific way. I still receive ISO-8859-1 > mails without charset header and I'd like to be able to SEARCH them. My intention agrees with yours, but obviously my phrasing is *rotten*. I meant to say that the argument to a search key must be valid input to the collation. Using 'search charset "iso-8859-3" subject ...' to search for a 0xBE byte is BAD, since 8859-3 does not define 0xBE. 'search charset "iso-8859-54" subject ...' ditto, since 8859-54 does not exist. I did not want to to restrict the message content, or mandate any specific way to match invalid message content. If the search key is valid, the server is on its own. Do you agree with this, and can you suggest better verbiage? Perhaps something about "when used as search key"? 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 l51MchId078378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 15:38:43 -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 l51Mch1G078377; Fri, 1 Jun 2007 15:38:43 -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 l51McglX078361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jun 2007 15:38:42 -0700 (MST) (envelope-from mrc@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.05) with ESMTP id l51MccPu031216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jun 2007 15:38:38 -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 l51Mcb6s018719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jun 2007 15:38:38 -0700 Date: Fri, 1 Jun 2007 15:38:36 -0700 (PDT) From: Mark Crispin To: Timo Sirainen cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt In-Reply-To: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> Message-ID: References: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.1.151533 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, 2 Jun 2007, Timo Sirainen wrote: > 2. "Strings encoded using unknown character encodings should never match when > using the SEARCH command, and should sort together with invalid input" > > What about matching invalid input with SEARCH? I think it should be handled > in implementation-specific way. I still receive ISO-8859-1 mails without > charset header and I'd like to be able to SEARCH them. I am sympathetic to this request, and agree that it should be implementation-dependent under the principle of GIGO. Required behavior in this regard is practically guaranteed to be ignored. -- 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 l51MOoBo074436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 15:24: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 l51MOo0q074435; Fri, 1 Jun 2007 15:24: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 dovecot.org (dovecot.org [82.118.211.50]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l51MOmhN074400 for ; Fri, 1 Jun 2007 15:24:49 -0700 (MST) (envelope-from tss@iki.fi) Received: from [82.197.4.29] (dyn4-29.adsl.mpynet.fi [82.197.4.29]) by dovecot.org (Postfix) with ESMTP id B9ECDFA891D for ; Sat, 2 Jun 2007 01:24:42 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-566011736" Message-Id: <0BAF4002-E2CE-4473-B096-7445FD82B225@iki.fi> Content-Transfer-Encoding: 7bit From: Timo Sirainen Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt Date: Sat, 2 Jun 2007 01:24:34 +0300 To: ietf-imapext@imc.org 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-566011736 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Two things: 1. I thought i;unicode-casemap was supposed to be the only MUST implement: http://www1.ietf.org/mail-archive/web/lemonade/current/msg03559.html Is this still going to change? 2. "Strings encoded using unknown character encodings should never match when using the SEARCH command, and should sort together with invalid input" What about matching invalid input with SEARCH? I think it should be handled in implementation-specific way. I still receive ISO-8859-1 mails without charset header and I'd like to be able to SEARCH them. --Apple-Mail-1-566011736 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) iD8DBQFGYJynyUhSUUBViskRAmkyAJ9STR/GT2Pybm8+FcH/z3jr0hZO2wCfa53z Tv9SyEJKzuqBsYYCoqa3yeU= =EN1H -----END PGP SIGNATURE----- --Apple-Mail-1-566011736-- 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 l51KASva041489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 13:10: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 l51KASJm041487; Fri, 1 Jun 2007 13:10: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 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 l51KAN2T041452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jun 2007 13:10:24 -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.05) with ESMTP id l51KAMUe027997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Jun 2007 13:10:23 -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 l51KAJJE002177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 1 Jun 2007 13:10:22 -0700 Date: Fri, 1 Jun 2007 13:10:19 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: Re: I-D ACTION:draft-ietf-imapext-i18n-11.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.6.1.122233 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: The LANGUAGE extension is technically l10n and not i18n. I won't go as far as to suggest that this document be broken up into a separate l10n and i18n document. However, the document should not blur the distinction and imply that l10n issues are i18n issues. They aren't. My suggestion is that the document should be retitled "Internet Message Access Protocol Locale and Internationalization", and then add some additional discussion about locale issues which may affect IMAP. I don't think that we need to address m17n at all in IMAP. IMAP i18n probably is sufficiently broad that it can encompass m17n. -- 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 l51Jo6ES036846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 12:50:06 -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 l51Jo6M0036845; Fri, 1 Jun 2007 12:50:06 -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 ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l51Jo2jm036836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jun 2007 12:50:05 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 70E35329C2; Fri, 1 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HuD8M-0003kC-9z; Fri, 01 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-i18n-11.txt Message-Id: Date: Fri, 01 Jun 2007 15:50:02 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : Internet Message Access Protocol Internationalization Author(s) : A. Gulbrandsen, C. Newman Filename : draft-ietf-imapext-i18n-11.txt Pages : 16 Date : 2007-6-1 Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-i18n-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-i18n-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-1105736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-1105736.I-D@ietf.org> --OtherAccess-- --NextPart--