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 i3UEhCC4004901; Fri, 30 Apr 2004 07:43: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 i3UEhCRe004900; Fri, 30 Apr 2004 07:43:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UEhB0B004870 for ; Fri, 30 Apr 2004 07:43:12 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L9IC5P9K8G0062TI@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Fri, 30 Apr 2004 07:43:08 -0700 (PDT) Date: Fri, 30 Apr 2004 07:42:38 -0700 (PDT) From: ned+imapext@innosoft.com Subject: Re: No editor for draft-ietf-imapext-i18n In-reply-to: "Your message dated Wed, 28 Apr 2004 11:30:28 -0700 (PDT)" To: Mark Crispin Cc: Lisa Dusseault , IMAP Extensions WG Message-id: <01L9J7SAWLFQ0062TI@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT Virus-test: FALSE References: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Wed, 28 Apr 2004, Lisa Dusseault wrote: > > As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order > > to unblock the sort draft. > This is correct. draft-newman-i18n-comparator also needs to proceed, > although I *think* that Ned may be doing this. Yes, I plan to try and handle this one. Ned 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 i3TCXJWk094485; Thu, 29 Apr 2004 05:33:19 -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 i3TCXJUv094484; Thu, 29 Apr 2004 05:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCXGx9094461 for ; Thu, 29 Apr 2004 05:33:17 -0700 (PDT) (envelope-from presnick@qualcomm.com) Date: Thu, 29 Apr 2004 13:38:17 +0000 To: "Ietf-imapext" From: "Presnick" Subject: Re: Msg reply Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fxqeqassmcqwleoenfgb" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------fxqeqassmcqwleoenfgb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------fxqeqassmcqwleoenfgb Content-Type: application/octet-stream; name="text_document.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="text_document.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------fxqeqassmcqwleoenfgb-- 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 i3SIUPSw034640; Wed, 28 Apr 2004 11:30:25 -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 i3SIUPJh034639; Wed, 28 Apr 2004 11:30:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SIUPXW034633 for ; Wed, 28 Apr 2004 11:30:25 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3SIUSMB011288; Wed, 28 Apr 2004 11:30:28 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3SIUSo5023224; Wed, 28 Apr 2004 11:30:28 -0700 Date: Wed, 28 Apr 2004 11:30:28 -0700 (PDT) From: Mark Crispin To: Lisa Dusseault cc: IMAP Extensions WG Subject: Re: No editor for draft-ietf-imapext-i18n In-Reply-To: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> Message-ID: References: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> 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 Wed, 28 Apr 2004, Lisa Dusseault wrote: > As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order > to unblock the sort draft. This is correct. draft-newman-i18n-comparator also needs to proceed, although I *think* that Ned may be doing this. The most urgent issue is that these documents need a few clarifications in order to remove a Discuss status on the SORT document. I don't think that these documents need to be Last Called or anything like that (yet). I will be happy to detail what's needed with whomever wants to take this on. > However, Chris Newman is no longer able to > continue as editor of the i18n draft, so we need volunteers to take on the > task. Chris says the source is in RFC2629 XML format currently which he's > happy to provide. Someone, please!!! -- 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 i3SIBepc033151; Wed, 28 Apr 2004 11:11: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 i3SIBe29033150; Wed, 28 Apr 2004 11:11:40 -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 i3SIBeOV033144 for ; Wed, 28 Apr 2004 11:11:40 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3SIBDhV017031 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 28 Apr 2004 11:11:15 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: No editor for draft-ietf-imapext-i18n Date: Wed, 28 Apr 2004 11:11:32 -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: As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order to unblock the sort draft. However, Chris Newman is no longer able to continue as editor of the i18n draft, so we need volunteers to take on the task. Chris says the source is in RFC2629 XML format currently which he's happy to provide. Any takers? 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 i3QIfXpr055274; Mon, 26 Apr 2004 11:41: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 i3QIfX04055273; Mon, 26 Apr 2004 11:41:33 -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 i3QIfWix055265 for ; Mon, 26 Apr 2004 11:41:32 -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; Mon, 26 Apr 2004 19:41:27 +0100 Message-ID: <408D57D6.6070701@isode.com> Date: Mon, 26 Apr 2004 19:41:26 +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: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> <408AE9D5.1030309@isode.com> <822DA79B746C62233036D9D3@ninevah.local> In-Reply-To: <822DA79B746C62233036D9D3@ninevah.local> 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 Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov > wrote: > > | Ok, I will try to give several examples to demonstrate how the server > | works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This > is a > | bit lengthy, but I hope this will clarify some things. > > OK - thanks for the explanation - it does seem to me that this is > trying to tackle a mailbox synchronization problem as I originally > thought. Note that the RLIST document does not say anything about its > referral mechanism being used as a means to keep disconnected clients > in sync. It also explicitly states that the referral mechanism it > describes is meant to be used for cases where mailboxes are moved > between different servers, whereas REFERRAL in LISTEXT also includes > the case for mailboxes moved on the same server. Why does this make any difference? > I don't think what's in LISTEXT will work - there are several cases I > can give. Perhaps the best is how to deal with a mailbox that's been > renamed multiple times whilst a client was disconnected (e.g. a > mailbox that is archived at regular intervals - daily, weekly etc). > What will happen in that case? IMHO, the server should only return the most recent referral. > Will there be multiple LISTEXT REFERRAL responses for each of the > renames? How is the client to determine which one of those corresponds > to the one it has cached (yes it could do STATUS on each of the > referral items listed and try to match UIDVALIDITY but that's ugly)? ... or referrals can be returned together with UIDVALIDITY for the renamed mailboxes. > How long is the server supposed to maintain the referral information? We can define some minimal required period, something around 1 week should be a reasonable default. In the IMAP server I used to write this information was retained indefinitely, because developers didn't have time to write a utility to expire this data. Alexey __________________________________________ Isode Limited, http://www.isode.comhttp://www.melnikov.ca/mel/devel/Links.htmlhttp://www.melnikov.ca IETF standard related pages: Personal Home Page: __________________________________________ 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 i3PHViZI041576; Sun, 25 Apr 2004 10:31: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 i3PHVio3041575; Sun, 25 Apr 2004 10:31:44 -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 i3PHVhZA041564; Sun, 25 Apr 2004 10:31:44 -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, 25 Apr 2004 18:31:34 +0100 Message-ID: <408BF5F6.9060707@isode.com> Date: Sun, 25 Apr 2004 18:31:34 +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: Paul Hoffman / IMC CC: ietf-imapext@imc.org Subject: Re: Extensions map References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@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: Paul Hoffman / IMC wrote: > At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote: > >> I agree. But we should probably start with IMC web page, as it is the >> most obvious starting point when looking for this kind of information. > > I'm happy to make such a document available if someone else edits it. > If someone volunteers and creates a first draft, and the IMAP > community agrees that the person is a good keeper of the document, let > me know: I'll make it easy for the document to live on the IMAPext web > page. Actually, I was thinking about starting with something simple. For example a table that shows which extensions have dependencies, and which RFC/draft defines them. 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 i3PHS3UR041326; Sun, 25 Apr 2004 10:28:03 -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 i3PHS3L5041325; Sun, 25 Apr 2004 10:28:03 -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 i3PHS2KW041318 for ; Sun, 25 Apr 2004 10:28:02 -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, 25 Apr 2004 18:28:03 +0100 Message-ID: <408BF522.4090603@isode.com> Date: Sun, 25 Apr 2004 18:28:02 +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: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.com> <34CD329BC0205D0CD69BB95B@ninevah.local> <408BF19E.2010306@isode.com> In-Reply-To: <408BF19E.2010306@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: > Cyrus Daboo wrote: > >> Hi Alexey, >> >> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov >> wrote: >> >> |> However, I agree it is easy to overlook interactions like this. So as >> |> an alternative, how about requiring IMAP extension documents (new >> ones >> |> and revisions to old ones) to include an 'Implementation >> |> Considerations' section that explicitly tells implementers to take >> |> into account the interaction of the new extension with any existing >> |> ones supported, or other new ones being added at the same time. >> | >> | Sounds good. So, you will do a quick revision with this change? >> >> OK. Below is some proposed text which I can add to ANNOTATE and >> ANNOTATEMORE right after the Security Considerations section in each. >> Lets see if we can agree on some general text for this that can be >> reused in other extensions. >> >> >> Implementation Considerations >> >> When adding support for this extension you MUST check all other >> extensions currently supported, and any additional extensions being >> added at the same time, to ensure that all dependencies and >> interactions between the different extensions are fully implemented. >> This is important as the dependency between different extensions may >> only be described in one of the extension documents - likely the one >> that was defined after the other - yet extensions may be implemented >> in any order. Thus support for existing extensions may need to be >> modified when new ones are added. > One of the advantages of having separate SORT=ANNOTATE and ANNOTATE is that it is nearly impossible to make such mistake. In order for the server to be able to sort annotations, the server implementers must explicitly report new capability. I suspect that most server vendors implement a particular extension once (and very often an early draft). Not everybody is going to track changes to extensions. 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 i3PHE9FS039818; Sun, 25 Apr 2004 10:14:09 -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 i3PHE9KN039817; Sun, 25 Apr 2004 10:14:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from [63.202.92.148] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PHE6R0039809 for ; Sun, 25 Apr 2004 10:14:08 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <408BEB2A.2040705@isode.com> References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.com> Date: Sun, 25 Apr 2004 10:14:09 -0700 To: ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: Extensions map (was: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote: >I agree. But we should probably start with IMC web page, as it is >the most obvious starting point when looking for this kind of >information. I'm happy to make such a document available if someone else edits it. If someone volunteers and creates a first draft, and the IMAP community agrees that the person is a good keeper of the document, let me know: I'll make it easy for the document to live on the IMAPext web page. --Paul Hoffman, Director --Internet Mail Consortium 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 i3PHD30H039719; Sun, 25 Apr 2004 10:13:03 -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 i3PHD3G4039718; Sun, 25 Apr 2004 10:13:03 -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 i3PHD299039708; Sun, 25 Apr 2004 10:13:02 -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, 25 Apr 2004 18:13:03 +0100 Message-ID: <408BF19E.2010306@isode.com> Date: Sun, 25 Apr 2004 18:13:02 +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: ietf-imapext@imc.org, Paul Hoffman Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.com> <34CD329BC0205D0CD69BB95B@ninevah.local> In-Reply-To: <34CD329BC0205D0CD69BB95B@ninevah.local> 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 Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov > wrote: > > |> However, I agree it is easy to overlook interactions like this. So as > |> an alternative, how about requiring IMAP extension documents (new ones > |> and revisions to old ones) to include an 'Implementation > |> Considerations' section that explicitly tells implementers to take > |> into account the interaction of the new extension with any existing > |> ones supported, or other new ones being added at the same time. > | > | Sounds good. So, you will do a quick revision with this change? > > OK. Below is some proposed text which I can add to ANNOTATE and > ANNOTATEMORE right after the Security Considerations section in each. > Lets see if we can agree on some general text for this that can be > reused in other extensions. > > > Implementation Considerations > > When adding support for this extension you MUST check all other > extensions currently supported, and any additional extensions being > added at the same time, to ensure that all dependencies and > interactions between the different extensions are fully implemented. > This is important as the dependency between different extensions may > only be described in one of the extension documents - likely the one > that was defined after the other - yet extensions may be implemented > in any order. Thus support for existing extensions may need to be > modified when new ones are added. Although, I agree with the text, I don't think it really helps to solve the problem. I would rather if you add a new section called "Dependencies" and mention interaction between SORT and ANNOTATE. 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 i3PHBWJp039488; Sun, 25 Apr 2004 10:11: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 i3PHBWAO039487; Sun, 25 Apr 2004 10:11: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 i3PHBVEF039481 for ; Sun, 25 Apr 2004 10:11:32 -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, 25 Apr 2004 18:09:59 +0100 Message-ID: <408BF0E6.9080309@isode.com> Date: Sun, 25 Apr 2004 18:09:58 +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: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> <408AE9D5.1030309@isode.com> <822DA79B746C62233036D9D3@ninevah.local> In-Reply-To: <822DA79B746C62233036D9D3@ninevah.local> 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: > This brings up another issue - isn't LISTEXT supposed to replace RLIST? Yes. > Right now a server would have to support both the RLIST command and > LISTEXT commands. Ideally the server should only have to support > LISTEXT and the referral responses codes in the RLIST extension, > without having to implement the RLIST command itself. Yes. That is why I've mentioned that we need to make a revision of the RFC 2193 ("IMAP4 Mailbox Referrals"). 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 i3PH4B7m038717; Sun, 25 Apr 2004 10:04: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 i3PH4BqX038716; Sun, 25 Apr 2004 10:04:11 -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 i3PH4A4W038704; Sun, 25 Apr 2004 10:04:11 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.2] (pool-141-151-176-74.pitt.east.verizon.net [141.151.176.74]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i3PGpgme022230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2004 12:51:47 -0400 Date: Sun, 25 Apr 2004 13:04:09 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org, Paul Hoffman Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt Message-ID: <34CD329BC0205D0CD69BB95B@ninevah.local> In-Reply-To: <408BEB2A.2040705@isode.com> References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.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=2.0 tests=NEW_DOMAIN_EXTENSIONS X-Spam-Level: * Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov wrote: |> However, I agree it is easy to overlook interactions like this. So as |> an alternative, how about requiring IMAP extension documents (new ones |> and revisions to old ones) to include an 'Implementation |> Considerations' section that explicitly tells implementers to take |> into account the interaction of the new extension with any existing |> ones supported, or other new ones being added at the same time. | | Sounds good. So, you will do a quick revision with this change? OK. Below is some proposed text which I can add to ANNOTATE and ANNOTATEMORE right after the Security Considerations section in each. Lets see if we can agree on some general text for this that can be reused in other extensions. Implementation Considerations When adding support for this extension you MUST check all other extensions currently supported, and any additional extensions being added at the same time, to ensure that all dependencies and interactions between the different extensions are fully implemented. This is important as the dependency between different extensions may only be described in one of the extension documents - likely the one that was defined after the other - yet extensions may be implemented in any order. Thus support for existing extensions may need to be modified when new ones are added. -- 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 i3PGsIk7037547; Sun, 25 Apr 2004 09:54: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 i3PGsIsZ037546; Sun, 25 Apr 2004 09:54:18 -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 i3PGsHH6037540 for ; Sun, 25 Apr 2004 09:54:17 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.2] (pool-141-151-176-74.pitt.east.verizon.net [141.151.176.74]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i3PGfpme021904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2004 12:41:53 -0400 Date: Sun, 25 Apr 2004 12:54:17 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT Message-ID: <822DA79B746C62233036D9D3@ninevah.local> In-Reply-To: <408AE9D5.1030309@isode.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> <408AE9D5.1030309@isode.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 Alexey, --On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov wrote: | Ok, I will try to give several examples to demonstrate how the server | works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a | bit lengthy, but I hope this will clarify some things. OK - thanks for the explanation - it does seem to me that this is trying to tackle a mailbox synchronization problem as I originally thought. Note that the RLIST document does not say anything about its referral mechanism being used as a means to keep disconnected clients in sync. It also explicitly states that the referral mechanism it describes is meant to be used for cases where mailboxes are moved between different servers, whereas REFERRAL in LISTEXT also includes the case for mailboxes moved on the same server. I don't think what's in LISTEXT will work - there are several cases I can give. Perhaps the best is how to deal with a mailbox that's been renamed multiple times whilst a client was disconnected (e.g. a mailbox that is archived at regular intervals - daily, weekly etc). What will happen in that case? Will there be multiple LISTEXT REFERRAL responses for each of the renames? How is the client to determine which one of those corresponds to the one it has cached (yes it could do STATUS on each of the referral items listed and try to match UIDVALIDITY but that's ugly)? How long is the server supposed to maintain the referral information? This brings up another issue - isn't LISTEXT supposed to replace RLIST? Right now a server would have to support both the RLIST command and LISTEXT commands. Ideally the server should only have to support LISTEXT and the referral responses codes in the RLIST extension, without having to implement the RLIST command itself. -- 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 i3PGjWvh036874; Sun, 25 Apr 2004 09:45: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 i3PGjWZU036873; Sun, 25 Apr 2004 09:45: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 i3PGjVY3036863; Sun, 25 Apr 2004 09:45: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 (internal)) with ESMTPA; Sun, 25 Apr 2004 17:45:30 +0100 Message-ID: <408BEB2A.2040705@isode.com> Date: Sun, 25 Apr 2004 17:45:30 +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: ietf-imapext@imc.org, Paul Hoffman Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> In-Reply-To: <52EB6A51D84E73885FCCBCF6@ninevah.local> 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 Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov > wrote: > > | I've sent a list of (mostly) editorial issues to Randy and Cyrus and > they > | got addressed by the latest revision. > | But one question still remains. Cyrus has asked me to forward it to the > | mailing list: > | > | Section "8.9 ANNOTATION Key in SORT" > | > | > ANNOTATION > | > > The ANNOTATION criterion for the SORT command [SORT] > instructs the > | > server to return the message numbers or UIDs of a mailbox, sorted > | > using the values of the specified annotations. The ANNOTATION > | > criterion is available if the server returns both "ANNOTATE" and > | > "SORT" as supported capabilities in the CAPABILITY command > response. > | > | I really don't like when new functionality is required if two other > | extensions are implemented. > | If somebody implements ANNOTATE in a server first and than adds SORT > | support, it is very easy to miss this bit. Unfortunately I've seen > | several documents already that do this. So I would recommend new > | capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE > | document). > > I am just worried about the possibility of combinatorial explosion of > capabilities as a result of this. Frankly I am not that worried (yet). > However, I agree it is easy to overlook interactions like this. So as > an alternative, how about requiring IMAP extension documents (new ones > and revisions to old ones) to include an 'Implementation > Considerations' section that explicitly tells implementers to take > into account the interaction of the new extension with any existing > ones supported, or other new ones being added at the same time. Sounds good. So, you will do a quick revision with this change? > That reminder in the document may suffice. It might also be useful to > have an informational document that gets updated at regular intervals > that summarizes all existing extensions and describes the dependencies > between each of them. That could be part of a revised implementation > guide or a separate document. I agree. But we should probably start with IMC web page, as it is the most obvious starting point when looking for this kind of information. 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 i3PG8i8d034523; Sun, 25 Apr 2004 09:08: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 i3PG8iLG034522; Sun, 25 Apr 2004 09:08: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 i3PG8dMw034513 for ; Sun, 25 Apr 2004 09:08:39 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.2] (pool-141-151-176-74.pitt.east.verizon.net [141.151.176.74]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i3PFuAme021047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2004 11:56:13 -0400 Date: Sun, 25 Apr 2004 12:08:36 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt Message-ID: <52EB6A51D84E73885FCCBCF6@ninevah.local> In-Reply-To: <408AC98B.2080504@isode.com> References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.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=2.0 tests=NEW_DOMAIN_EXTENSIONS X-Spam-Level: * Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov wrote: | I've sent a list of (mostly) editorial issues to Randy and Cyrus and they | got addressed by the latest revision. | But one question still remains. Cyrus has asked me to forward it to the | mailing list: | | Section "8.9 ANNOTATION Key in SORT" | | > ANNOTATION | > > The ANNOTATION criterion for the SORT command [SORT] instructs the | > server to return the message numbers or UIDs of a mailbox, sorted | > using the values of the specified annotations. The ANNOTATION | > criterion is available if the server returns both "ANNOTATE" and | > "SORT" as supported capabilities in the CAPABILITY command response. | | I really don't like when new functionality is required if two other | extensions are implemented. | If somebody implements ANNOTATE in a server first and than adds SORT | support, it is very easy to miss this bit. Unfortunately I've seen | several documents already that do this. So I would recommend new | capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE | document). I am just worried about the possibility of combinatorial explosion of capabilities as a result of this. However, I agree it is easy to overlook interactions like this. So as an alternative, how about requiring IMAP extension documents (new ones and revisions to old ones) to include an 'Implementation Considerations' section that explicitly tells implementers to take into account the interaction of the new extension with any existing ones supported, or other new ones being added at the same time. That reminder in the document may suffice. It might also be useful to have an informational document that gets updated at regular intervals that summarizes all existing extensions and describes the dependencies between each of them. That could be part of a revised implementation guide or a separate document. -- 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 i3PEUmiM028848; Sun, 25 Apr 2004 07:30: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 i3PEUmuY028846; Sun, 25 Apr 2004 07:30: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 i3PEUf90028818 for ; Sun, 25 Apr 2004 07:30:48 -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, 25 Apr 2004 15:30:31 +0100 Message-ID: <408AEB3C.3080804@isode.com> Date: Sat, 24 Apr 2004 23:33:32 +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: Alexey Melnikov wrote: > 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. The relevant ABNF bit would be: referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")" urlstring = <"> url <"> ; See [RFC-1738] for definition It seems that the current ABNF can't cope with this ("referral_data" (if taken in ()) should match "mbox-list-extended-item"): 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 Anyway, no matter whether people think that REFERRAL belongs to the LISTEXT extension or not, I would like to change LISTEXT ABNF for additional LIST data to allow sending REFERRAL response as suggested above. Any objections? 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 i3PEUmZF028847; Sun, 25 Apr 2004 07:30: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 i3PEUmbR028845; Sun, 25 Apr 2004 07:30: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 i3PEUf8x028818 for ; Sun, 25 Apr 2004 07:30:46 -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, 25 Apr 2004 15:30:31 +0100 Message-ID: <408AE9D5.1030309@isode.com> Date: Sat, 24 Apr 2004 23:27: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: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> In-Reply-To: <2147483647.1081854599@ninevah.cyrusoft.com> Content-Type: multipart/alternative; boundary="------------020404000502090201040907" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020404000502090201040907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Alexey, > > --On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov > wrote: > > |> I believe REFERRAL, as envisioned by Larry is designed for clusters > |> like the Cyrus Murder so that a referral capable client can determine > |> which mailboxes are located on a different server(s) w/o having to > |> attempt a SELECT and wait for the referral to get the location of the > |> mailbox. > | > | That was my idea as well. > > That's fine but trying to indicate rename's is going to be too > complicated. Perhaps you can write up a more detailed account of > exactly what REFERRAL is supposed to do, then maybe I will understand > the issues better... Ok, I will try to give several examples to demonstrate how the server works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a bit lengthy, but I hope this will clarify some things. I will use the following list of local mailboxes: C: A01 LIST "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done And let's assume there are two remote mailboxes visible locally (i.e. they are part of LIST (REMOTE) output) as "Bread" and "Meat". Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and "Tofu" was renamed to "SoyProducts/Tofu". And finally, let's assume that the name of the IMAP server is "imap.example.com". In all cases below assume that the client is a disconnected client. An online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE REFERRAL). Let's also assume that the client wants to synchronize the following mailboxes: "inbox", "Fruit/Apple", "Fruit/Banana", "Tofu". Scenario 1). LISTEXT-unaware client that doesn't care about remote mailboxes: C: A01 LIST "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done (case a - the client is a disconnected client that doesn't support remote mailboxes or referrals). As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local cache for those mailboxes and the changes would be lost. (case b - same as case a, but it also supports MAILBOX-REFERRAL). If the client (and the server) also supports MAILBOX-REFERRAL, before blowing away its cache it will try to select each of those mailboxes in a hope of figuring out if they were actually renamed: C: A02 SELECT "Fruit/Apple" S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/Fruit/Orange] Renamed mailbox. C: A03 SELECT "Fruit/Orange" ...synchronization... C: A12 SELECT "Tofu" S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu] Renamed mailbox. C: A13 SELECT "SoyProducts/Tofu" ...synchronization... Synchronization of "inbox" and "Fruit/Banana" proceeds as usual: C: A22 SELECT "Fruit/Banana" ...synchronization... Scenario 2). LISTEXT-aware client that doesn't care about remote mailboxes and doesn't support referrals: This is very much the same as scenario 1a). C: A01 LIST () "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local changes to those mailboxes. Scenario 3). LISTEXT-aware client that doesn't care about remote mailboxes, but supports referrals. C: A01 LIST (REFERRAL) "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange") S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu") S: A01 OK done The referral aware client will be able to synchronize changes even if some mailboxes are renamed (assuming the server is also able to report this information). In addition, two unnecessary SELECT commands are eliminated and the client can proceed with mailbox synchronization for the renamed mailboxes: C: A02 SELECT "Fruit/Orange" ...synchronization... C: A12 SELECT "SoyProducts/Tofu" ...synchronization... (Note, that the server is not allowed to return remote mailboxes when just REFERRAL is requested, the client doesn't even have to match the server name in URLs with the local IMAP server name). Further synchronization proceeds as usual. Scenario 4). LISTEXT-aware client that supports both referrals and remote mailboxes. C: A01 LIST (REMOTE REFERRAL) "" "%" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange") S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu") S: * LIST () "/" "Bread" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap1.example.com/Bread")) S: * LIST () "/" "Meat" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap.example.com/Meat" "IMAP://user;AUTH=*@other-imap2.example.com/SharedFolders/Meat")) S: A01 OK done The client knows that "imap.example.com" is the name of the IMAP server the client is connected to, so it will be able to figure out that "Bread" and "Meat" are located on a different server(s). The client should also be able to synchronize with a mailbox moved across servers. Alexey --------------020404000502090201040907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cyrus Daboo wrote:
Hi Alexey,

--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov <Alexey.Melnikov@isode.com> wrote:

|> I believe REFERRAL, as envisioned by Larry is designed for clusters
|> like the Cyrus Murder so that a referral capable client can determine
|> which mailboxes are located on a different server(s) w/o having to
|> attempt a SELECT and wait for the referral to get the location of the
|> mailbox.
|
| That was my idea as well.

That's fine but trying to indicate rename's is going to be too complicated. Perhaps you can write up a more detailed account of exactly what REFERRAL is supposed to do, then maybe I will understand the issues better...
Ok, I will try to give several examples to demonstrate how the server works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a bit lengthy, but I hope this will clarify some things.

I will use the following list of local mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

And let's assume there are two remote mailboxes visible locally (i.e. they are part of LIST (REMOTE) output) as "Bread" and "Meat".
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and "Tofu" was renamed to "SoyProducts/Tofu".
And finally, let's assume that the name of the IMAP server is "imap.example.com".

In all cases below assume that the client is a disconnected client. An online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE REFERRAL).
Let's also assume that the client wants to synchronize the following mailboxes: "inbox", "Fruit/Apple", "Fruit/Banana", "Tofu".

Scenario 1). LISTEXT-unaware client that doesn't care about remote mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

(case a - the client is a disconnected client that doesn't support remote mailboxes or referrals).

As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local cache for those mailboxes and the changes would be lost.

(case b - same as case a, but it also supports MAILBOX-REFERRAL).

If the client (and the server) also supports MAILBOX-REFERRAL, before blowing away its cache it will try to select each of those mailboxes in a hope of figuring out if they were actually renamed:

      C: A02 SELECT "Fruit/Apple"
      S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/Fruit/Orange] Renamed mailbox.

      C: A03 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "Tofu"
      S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu] Renamed mailbox.

      C: A13 SELECT "SoyProducts/Tofu"
       ...synchronization...

Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:

      C: A22 SELECT "Fruit/Banana"
       ...synchronization...

Scenario 2). LISTEXT-aware client that doesn't care about remote mailboxes and doesn't support referrals:

This is very much the same as scenario 1a).

       C: A01 LIST () "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local changes to those mailboxes.

Scenario 3). LISTEXT-aware client that doesn't care about remote mailboxes, but supports referrals.

       C: A01 LIST (REFERRAL) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange")
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")
       S: A01 OK done


The referral aware client will be able to synchronize changes even if some mailboxes are renamed (assuming the server is also able to report this information).
In addition, two unnecessary SELECT commands are eliminated and the client can proceed with mailbox synchronization for the renamed mailboxes:
      C: A02 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "SoyProducts/Tofu"
       ...synchronization...

(Note, that the server is not allowed to return remote mailboxes when just REFERRAL is requested, the client doesn't even have to match
the server name in URLs with the local IMAP server name).

Further synchronization proceeds as usual.

Scenario 4). LISTEXT-aware client that supports both referrals and remote mailboxes.

       C: A01 LIST (REMOTE REFERRAL) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange")
        S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")
       S: * LIST () "/" "Bread" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap1.example.com/Bread"))
       S: * LIST () "/" "Meat" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap.example.com/Meat" "IMAP://user;AUTH=*@other-imap2.example.com/SharedFolders/Meat"))
       S: A01 OK done

The client knows that "imap.example.com" is the name of the IMAP server the client is connected to, so it will be able to figure out that "Bread" and "Meat" are located on a different server(s).  The client should also be able to synchronize with a mailbox moved across servers.

Alexey

 --------------020404000502090201040907-- 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 i3PEUkiC028828; Sun, 25 Apr 2004 07:30: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 i3PEUkG5028827; Sun, 25 Apr 2004 07:30: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 i3PEUf8w028818 for ; Sun, 25 Apr 2004 07:30:46 -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, 25 Apr 2004 15:30:27 +0100 Message-ID: <408AC98B.2080504@isode.com> Date: Sat, 24 Apr 2004 21:09:47 +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 CC: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> In-Reply-To: <200404201951.PAA18183@ietf.org> 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 sent a list of (mostly) editorial issues to Randy and Cyrus and they got addressed by the latest revision. But one question still remains. Cyrus has asked me to forward it to the mailing list: Section "8.9 ANNOTATION Key in SORT" > ANNOTATION > > The ANNOTATION criterion for the SORT command [SORT] instructs the > server to return the message numbers or UIDs of a mailbox, sorted > using the values of the specified annotations. The ANNOTATION > criterion is available if the server returns both "ANNOTATE" and > "SORT" as supported capabilities in the CAPABILITY command response. I really don't like when new functionality is required if two other extensions are implemented. If somebody implements ANNOTATE in a server first and than adds SORT support, it is very easy to miss this bit. Unfortunately I've seen several documents already that do this. So I would recommend new capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE document). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3KJpd9F011827; Tue, 20 Apr 2004 12:51: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 i3KJpdGF011826; Tue, 20 Apr 2004 12:51:39 -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.8) with ESMTP id i3KJpcRF011819 for ; Tue, 20 Apr 2004 12:51:39 -0700 (PDT) (envelope-from rbunch@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 PAA18183; Tue, 20 Apr 2004 15:51:41 -0400 (EDT) Message-Id: <200404201951.PAA18183@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-annotate-09.txt Date: Tue, 20 Apr 2004 15:51:41 -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 : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-09.txt Pages : 26 Date : 2004-4-20 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.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-annotate-09.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-annotate-09.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-4-20160809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160809.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.8) with ESMTP id i3EFn9Tv005291; Wed, 14 Apr 2004 08:49:09 -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 i3EFn8r2005290; Wed, 14 Apr 2004 08:49:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EFn7vd005271 for ; Wed, 14 Apr 2004 08:49:07 -0700 (PDT) (envelope-from leiba@watson.ibm.com) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i3EFn5q32382 for ; Wed, 14 Apr 2004 11:49:05 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i3EFn4O56074 for ; Wed, 14 Apr 2004 11:49:04 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with SMTP id i3EFn3x54398 for ; Wed, 14 Apr 2004 11:49:03 -0400 Message-ID: <003201c42238$032759c0$40280209@watson.ibm.com> From: "Barry Leiba" To: "IMAP extensions Mailing List" References: <407955E1.90005@isode.com> <407AD059.2000109@isode.com> Subject: Re: Collected issues with LISTEXT Date: Wed, 14 Apr 2004 11:49:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think this is the case for LISTEXT as written now. I.e. unless the client > specified LIST (CHILDREN), the server is not required to return \HasChildren > or \HasNoChildren. Yes, Alexey is correct that this was the intent of LISTEXT. > I don't care either way. I can live with mandatory-to-implement children > functionality as long as it is not mandatory-to-execute. And that was the point, and Mark's objection is the reason it was written that way. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DF9xCT048327; Tue, 13 Apr 2004 08:09: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 i3DF9xdG048326; Tue, 13 Apr 2004 08:09: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.8) with ESMTP id i3DF9xg7048320 for ; Tue, 13 Apr 2004 08:09: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 i3DExPme005284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2004 10:59:26 -0400 Date: Tue, 13 Apr 2004 11:09:59 -0400 From: Cyrus Daboo To: Alexey Melnikov , Ken Murchison cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT Message-ID: <2147483647.1081854599@ninevah.cyrusoft.com> In-Reply-To: <407BB975.7000808@isode.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> X-Mailer: Mulberry/3.1.2 (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, April 13, 2004 10:57 AM +0100 Alexey Melnikov wrote: |> I believe REFERRAL, as envisioned by Larry is designed for clusters |> like the Cyrus Murder so that a referral capable client can determine |> which mailboxes are located on a different server(s) w/o having to |> attempt a SELECT and wait for the referral to get the location of the |> mailbox. | | That was my idea as well. That's fine but trying to indicate rename's is going to be too complicated. Perhaps you can write up a more detailed account of exactly what REFERRAL is supposed to do, then maybe I will understand the issues better... -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DA0hGG025743; Tue, 13 Apr 2004 03:00:43 -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 i3DA0hsh025742; Tue, 13 Apr 2004 03:00:43 -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.8) with ESMTP id i3DA0gU6025735 for ; Tue, 13 Apr 2004 03:00:42 -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, 13 Apr 2004 11:00:01 +0100 Message-ID: <407BBA1E.6080201@isode.com> Date: Tue, 13 Apr 2004 10:59:58 +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: Philip Guenther CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> In-Reply-To: <200404121937.i3CJbRHe067636@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: Philip Guenther wrote: >>> b) actually, wouldn't the "* NO [REFERRAL ....]" response be good >>> enough for them? >>> >>> >>This will work, but the client will have to SELECT each one of them in >>order to find out. A LIST will return this information in one go. >> >> > >Doesn't a disconnected client normally SELECT each synchronized >mailbox whenever it connects so that it can pull down updates from >the server? How often is a client *only* interested in whether the >mailbox was renamed (or deleted) and no in whether its contents >changed? > The client is not interested in selecting the old name, it will select the new one (target of the referral). LIST (REFERRAL) will give this information. >>> (Oh, and they're going to have a fun time synchronizing, given that >>> the UIDVALIDITY on the mailbox was probably changed by the RENAME...) >>> >>> >>RENAME is required to preserve UIDVALIDITY. >> >> > >That certainly isn't in rfc3501. If a server can give two mailboxes >the same UIDVALIDITY then it's possible to set up a situation where >RENAME MUST change the UIDVALIDITY of the renamed mailbox: > let TARG and SRC be mailboxes with the same UIDVALIDITY > a1 RENAME TARG SOMETHING-ELSE > a2 RENAME SRC TARG > that second RENAME can't preserve TARG's UIDVALIDITY across the > rename without violating the last item in section 2.3.1.1 > >This was discussed here at some point and led to some discussion >of a possible NEW-UIDVALIDITY response code for telling clients >that the UIDVALIDITY on a mailbox changed during a RENAME without >actually altering UIDs. > Ok, I remember about this case ;-), however it is less common in real life. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D9vRg0025567; Tue, 13 Apr 2004 02:57:27 -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 i3D9vR4m025566; Tue, 13 Apr 2004 02:57:27 -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.8) with ESMTP id i3D9vQvY025560 for ; Tue, 13 Apr 2004 02:57:27 -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, 13 Apr 2004 10:57:12 +0100 Message-ID: <407BB975.7000808@isode.com> Date: Tue, 13 Apr 2004 10:57: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: Ken Murchison CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> In-Reply-To: <407B3914.5000101@oceana.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: Ken Murchison wrote: > Cyrus Daboo wrote: > >> It seems to me that the REFERRAL is an attempt to implement some kind >> of mailbox list synchronisation feature to allow disconnected clients >> to sync there mailbox state with the server - if that is not the >> intent than can Alexey explain in more detail what its supposed to >> do. What was proposed by Alexey is not sufficient to do mailbox list >> sync properly. I think REFERRAL should not be implemented in LISTEXT >> right now. Instead, if there is demand, a proper mailbox list sync >> extension (that may or may not use LISTEXT) should be designed to do >> the job properly. I suspect that some form of mailbox UID, globally >> unique across the server's mailstore, will be the best way to do that >> so that clients and servers can use the MUIDs to sync up their lists. >> However this is out of scope for LISTEXT and imapext right now. > > I believe REFERRAL, as envisioned by Larry is designed for clusters > like the Cyrus Murder so that a referral capable client can determine > which mailboxes are located on a different server(s) w/o having to > attempt a SELECT and wait for the referral to get the location of the > mailbox. That was my idea as well. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0nQbN082206; Mon, 12 Apr 2004 17:49: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 i3D0nQBc082205; Mon, 12 Apr 2004 17:49:26 -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 ([208.17.123.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0nPOH082184 for ; Mon, 12 Apr 2004 17:49:25 -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 i3D0nN7D017952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Apr 2004 20:49:24 -0400 (EDT) Message-ID: <407B3914.5000101@oceana.com> Date: Mon, 12 Apr 2004 20:49:24 -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: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> In-Reply-To: <9560000.1081803699@ninevah.cyrusoft.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: Cyrus Daboo wrote: > It seems to me that the REFERRAL is an attempt to implement some kind of > mailbox list synchronisation feature to allow disconnected clients to > sync there mailbox state with the server - if that is not the intent > than can Alexey explain in more detail what its supposed to do. What was > proposed by Alexey is not sufficient to do mailbox list sync properly. I > think REFERRAL should not be implemented in LISTEXT right now. Instead, > if there is demand, a proper mailbox list sync extension (that may or > may not use LISTEXT) should be designed to do the job properly. I > suspect that some form of mailbox UID, globally unique across the > server's mailstore, will be the best way to do that so that clients and > servers can use the MUIDs to sync up their lists. However this is out of > scope for LISTEXT and imapext right now. I believe REFERRAL, as envisioned by Larry is designed for clusters like the Cyrus Murder so that a referral capable client can determine which mailboxes are located on a different server(s) w/o having to attempt a SELECT and wait for the referral to get the location of the mailbox. -- 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.8) with ESMTP id i3CL1WNS050445; Mon, 12 Apr 2004 14:01: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 i3CL1WIh050444; Mon, 12 Apr 2004 14:01:32 -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.8) with ESMTP id i3CL1Vrq050438 for ; Mon, 12 Apr 2004 14:01:31 -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 i3CKp6me018243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2004 16:51:07 -0400 Date: Mon, 12 Apr 2004 17:01:39 -0400 From: Cyrus Daboo To: Philip Guenther , Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT Message-ID: <9560000.1081803699@ninevah.cyrusoft.com> In-Reply-To: <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> X-Mailer: Mulberry/3.1.2 (Linux/PPC) 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 Philip, --On Monday, April 12, 2004 12:37:27 PM -0700 Philip Guenther wrote: |> This will work, but the client will have to SELECT each one of them in |> order to find out. A LIST will return this information in one go. | | Doesn't a disconnected client normally SELECT each synchronized | mailbox whenever it connects so that it can pull down updates from | the server? How often is a client *only* interested in whether the | mailbox was renamed (or deleted) and no in whether its contents | changed? | | |>> (Oh, and they're going to have a fun time synchronizing, given that |>> the UIDVALIDITY on the mailbox was probably changed by the RENAME...) |>> |> RENAME is required to preserve UIDVALIDITY. | | That certainly isn't in rfc3501. If a server can give two mailboxes | the same UIDVALIDITY then it's possible to set up a situation where | RENAME MUST change the UIDVALIDITY of the renamed mailbox: | let TARG and SRC be mailboxes with the same UIDVALIDITY | a1 RENAME TARG SOMETHING-ELSE | a2 RENAME SRC TARG | that second RENAME can't preserve TARG's UIDVALIDITY across the | rename without violating the last item in section 2.3.1.1 | | This was discussed here at some point and led to some discussion | of a possible NEW-UIDVALIDITY response code for telling clients | that the UIDVALIDITY on a mailbox changed during a RENAME without | actually altering UIDs. | | | ... |>> It's never been entirely clear to me how mailbox referrals (in the |>> rfc2193 sense) were intended to be presented by clients. While I'm not |>> a client implementor and therefore don't *need* an answer to that, it |>> does seem to bear on whether it's wise to reuse the same mechanism for |>> the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. |>> When a client that displays the mailbox hierarchy in some form gets back |>> a referral response, should it use the referral to the alter/update the |>> display or should it hide the indirection from the end user? |>> |> It depends. Some clients allow to configure different choices, like |> "resolve referrals automatically", "don't show referrals", etc. Other |> will show a different icon in a mailbox tree. The user has to double |> click on the icon to resolve it. I don't think there is a single right |> answer to this question. | | So some clients or users may choose to handle them differently then | they would handle a "mailbox rename" REFERRAL? How is a client | supposed to tell apart "rename" and "remote" REFERRALs, given that | the server may have a different idea than the client of what the | server's hostname is? Is the server required to use relative IMAP | URLs for "rename" REFERRALs? It seems to me that the REFERRAL is an attempt to implement some kind of mailbox list synchronisation feature to allow disconnected clients to sync there mailbox state with the server - if that is not the intent than can Alexey explain in more detail what its supposed to do. What was proposed by Alexey is not sufficient to do mailbox list sync properly. I think REFERRAL should not be implemented in LISTEXT right now. Instead, if there is demand, a proper mailbox list sync extension (that may or may not use LISTEXT) should be designed to do the job properly. I suspect that some form of mailbox UID, globally unique across the server's mailstore, will be the best way to do that so that clients and servers can use the MUIDs to sync up their lists. However this is out of scope for LISTEXT and imapext right now. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJbQh6038890; Mon, 12 Apr 2004 12:37: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 i3CJbQoa038889; Mon, 12 Apr 2004 12:37:26 -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.8) with ESMTP id i3CJbQKo038883 for ; Mon, 12 Apr 2004 12:37:26 -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 i3CJbUOx003430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 12:37:30 -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 i3CJbUfZ028479 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 12:37:30 -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 i3CJbRHe067636; Mon, 12 Apr 2004 12:37:30 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT In-reply-to: <407AE741.4060900@isode.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> Date: Mon, 12 Apr 2004 12:37:27 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Philip Guenther wrote: >>Alexey Melnikov writes: ... >>So this is suggesting that LIST (REFERRAL) would show all the matching >>mailboxes that either ... >>b) currently exist as a referral to another server, or > >No, b) is only returned for LIST (REFERRAL REMOTE) Ah, okay. ... >>- what's a client supposed to do with a "renamed" referral anyway? If >> it's for synchronization of disconnected clients then >> >yes. >> b) actually, wouldn't the "* NO [REFERRAL ....]" response be good >> enough for them? >> >This will work, but the client will have to SELECT each one of them in >order to find out. A LIST will return this information in one go. Doesn't a disconnected client normally SELECT each synchronized mailbox whenever it connects so that it can pull down updates from the server? How often is a client *only* interested in whether the mailbox was renamed (or deleted) and no in whether its contents changed? >> (Oh, and they're going to have a fun time synchronizing, given that >> the UIDVALIDITY on the mailbox was probably changed by the RENAME...) >> >RENAME is required to preserve UIDVALIDITY. That certainly isn't in rfc3501. If a server can give two mailboxes the same UIDVALIDITY then it's possible to set up a situation where RENAME MUST change the UIDVALIDITY of the renamed mailbox: let TARG and SRC be mailboxes with the same UIDVALIDITY a1 RENAME TARG SOMETHING-ELSE a2 RENAME SRC TARG that second RENAME can't preserve TARG's UIDVALIDITY across the rename without violating the last item in section 2.3.1.1 This was discussed here at some point and led to some discussion of a possible NEW-UIDVALIDITY response code for telling clients that the UIDVALIDITY on a mailbox changed during a RENAME without actually altering UIDs. ... >>It's never been entirely clear to me how mailbox referrals (in the >>rfc2193 sense) were intended to be presented by clients. While I'm not >>a client implementor and therefore don't *need* an answer to that, it >>does seem to bear on whether it's wise to reuse the same mechanism for >>the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. >>When a client that displays the mailbox hierarchy in some form gets back >>a referral response, should it use the referral to the alter/update the >>display or should it hide the indirection from the end user? >> >It depends. Some clients allow to configure different choices, like >"resolve referrals automatically", "don't show referrals", etc. Other >will show a different icon in a mailbox tree. The user has to double >click on the icon to resolve it. I don't think there is a single right >answer to this question. So some clients or users may choose to handle them differently then they would handle a "mailbox rename" REFERRAL? How is a client supposed to tell apart "rename" and "remote" REFERRALs, given that the server may have a different idea than the client of what the server's hostname is? Is the server required to use relative IMAP URLs for "rename" REFERRALs? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWfE2037945; Mon, 12 Apr 2004 12:32:41 -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 i3CJWfcv037944; Mon, 12 Apr 2004 12:32:41 -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.8) with ESMTP id i3CJWeXp037926 for ; Mon, 12 Apr 2004 12:32:40 -0700 (PDT) (envelope-from rbunch@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 PAA08786; Mon, 12 Apr 2004 15:32:42 -0400 (EDT) Message-Id: <200404121932.PAA08786@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-05.txt Date: Mon, 12 Apr 2004 15:32:42 -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-05.txt Pages : 8 Date : 2004-4-12 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-05.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-05.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-05.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-4-12155018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12155018.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.8) with ESMTP id i3CJ0NZX033983; Mon, 12 Apr 2004 12:00: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 i3CJ0NeC033982; Mon, 12 Apr 2004 12:00:23 -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.8) with ESMTP id i3CJ0Lke033964 for ; Mon, 12 Apr 2004 12:00:22 -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; Mon, 12 Apr 2004 20:00:20 +0100 Message-ID: <407AE741.4060900@isode.com> Date: Mon, 12 Apr 2004 20:00:17 +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: Philip Guenther CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> In-Reply-To: <200404120815.i3C8FlHe032260@lab.smi.sendmail.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: Philip Guenther wrote: >Alexey Melnikov writes: >... > > >>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. >> >> > >So this is suggesting that LIST (REFERRAL) would show all the matching >mailboxes that either >a) currently exist locally, or > > Yes. >b) currently exist as a referral to another server, or > > No, b) is only returned for LIST (REFERRAL REMOTE) >c) did exist and were renamed > > Yes. >with support for the mechanisms behind (b) and (c) being optional? > Yes (c) is optional) >Item (c) seems really weird, such that I simultaneously have doubts >about its usefulness, the ambiguity it creates, the clutter it will add >to listing, and the possibly security implications. > >In reverse order: >- what ACL controls whether you can see the referral for a mailbox that > was renamed: the ACL on the new name or the ACL on the name at the > time of the rename? Is there any way to control that visibility > independent of the visibility of the current name? > > That is is a good question and I have to think about this :-). >- is there any way to get rid of a "renamed" referral beyond, say, > creating and deleting a new mailbox under that name, a method that has > an obvious race condition with someone really trying to create the > name? > (New DoS attack: repeatedly rename a publicly visible folder, so that > tag LIST (REFERRAL) "" * > returns a few thousand "renamed" entries) > > I haven't thought about doing this through the IMAP, but an implementation may "expire" local referrals after some time. >- will "renamed" referrals be flagged differently than "true" referrals > No, I can't see how is this different. "renamed" referral is a referral that points to the same server. > and normal mailboxes in the listing? > Yes. Normal mailboxes will not have "("REFERRAL" ...)" part in the corresponding untagged LIST response. > If not, then you have a list of > mailboxes that may or may not currently exist, which seems less than > completely useful. > >- what's a client supposed to do with a "renamed" referral anyway? If > it's for synchronization of disconnected clients then > yes. > a) that's a pretty narrow target audience; wouldn't a narrow "renamed > only" list extension be more useful for them? > > If you don't want them, don't specify REFERRAL option in LIST. > b) actually, wouldn't the "* NO [REFERRAL ....]" response be good > enough for them? > This will work, but the client will have to SELECT each one of them in order to find out. A LIST will return this information in one go. > (Oh, and they're going to have a fun time synchronizing, given that > the UIDVALIDITY on the mailbox was probably changed by the RENAME...) > RENAME is required to preserve UIDVALIDITY. > >Indeed, several of those also apply to the original NEWNAME response and >the alluded to use of REFERRAL responses in NEWNAME's place. Can anyone >explain to me what NEWNAME was supposed to be used for and how any >existing (or pre-3501) clients react to it? Without an understanding of >the problem being solved, I don't know whether LIST (REFERRAL) is >necessary or useful in solving it. > > >While I'm on the subject... > >It's never been entirely clear to me how mailbox referrals (in the >rfc2193 sense) were intended to be presented by clients. While I'm not >a client implementor and therefore don't *need* an answer to that, it >does seem to bear on whether it's wise to reuse the same mechanism for >the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. >When a client that displays the mailbox hierarchy in some form gets back >a referral response, should it use the referral to the alter/update the >display or should it hide the indirection from the end user? > It depends. Some clients allow to configure different choices, like "resolve referrals automatically", "don't show referrals", etc. Other will show a different icon in a mailbox tree. The user has to double click on the icon to resolve it. I don't think there is a single right answer to this question. > For >example, should the user selecting a mailbox in a hierarchy display >result in a 'reparenting' of the selected mailbox if the original server >returned a referral specifying another server, or should it simply chase >the reference and display the folder in place? > > >>Related to this: do a revision of RFC 2193 that is using LISTEXT >>framework (in particular obsolete RLIST/RLSUB). >> >> > >It would be nice to clarify such points as whether a remote referral may >have a different path than the local name, what ACL controls the >visibility of a remote referrals (does it depend on the command? Does >the referral have an ACL distinct from the target mailbox?), > I think this is related to one of the questions above, so I will think about this as well. > and what >section 4.2 means when it says "...because a home server is required to >maintain a listing of referred remote mailboxes..." > > > Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHjADL025116; Mon, 12 Apr 2004 10:45: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 i3CHjA3R025115; Mon, 12 Apr 2004 10:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHjAxP025109 for ; Mon, 12 Apr 2004 10:45:10 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3CHjDIm032551; Mon, 12 Apr 2004 10:45:13 -0700 Received: from Shimo-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 i3CHj3Ba012688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Apr 2004 10:45:12 -0700 Date: Mon, 12 Apr 2004 10:45:05 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT In-Reply-To: <407AD059.2000109@isode.com> Message-ID: References: <407955E1.90005@isode.com> <407AD059.2000109@isode.com> 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, 12 Apr 2004, Alexey Melnikov wrote: > I think this is the case for LISTEXT as written now. I.e. unless the client > specified LIST (CHILDREN), the server is not required to return \HasChildren > or \HasNoChildren. This is fine with me. > Mark would you prefer a separate LIST-CHILDREN capability (as I currently > do), or can you live with the LISTEXT document as written? I don't care either way. I can live with mandatory-to-implement children functionality as long as it is not mandatory-to-execute. -- 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.8) with ESMTP id i3CHMwHB023039; Mon, 12 Apr 2004 10:22:58 -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 i3CHMw3J023038; Mon, 12 Apr 2004 10:22:58 -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.8) with ESMTP id i3CHMqWM023011 for ; Mon, 12 Apr 2004 10:22:57 -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; Mon, 12 Apr 2004 18:22:37 +0100 Message-ID: <407AD059.2000109@isode.com> Date: Mon, 12 Apr 2004 18:22: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: Mark Crispin CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@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: Mark Crispin wrote: > On Sun, 11 Apr 2004, Alexey Melnikov wrote: > >> 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. > > > FWIW: > > I do not think that a server should be obligated to advertise children > unless a client explicitly says that it is interested in such > information. > > I do not think that mere use of LISTEXT instead of LIST suffices to > indicate such interest. Ok, is there anybody who will say "I will die if CHILDREN is not part of LISTEXT" :-)? > As a compromise, I'm agreeable to children support being mandatory in > LISTEXT without requiring a capability; but nevertheless a server > should not be required to do the work unless the client specifically > asks for children. I think this is the case for LISTEXT as written now. I.e. unless the client specified LIST (CHILDREN), the server is not required to return \HasChildren or \HasNoChildren. Mark would you prefer a separate LIST-CHILDREN capability (as I currently do), or can you live with the LISTEXT document as written? > Put another way, I consider RFC 3348 to be broken, since it: > 1) adds an unnecessary CHILDREN extension > 2) requires a server supporting children to do the work even for a > client that does not care. > > I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead > simply urged that it be Informational. However, the sooner we move > towards LISTEXT and declaring RFC 3348 an obsolete false start, the > better in my view. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C8FvSa043041; Mon, 12 Apr 2004 01:15:57 -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 i3C8Fvv7043040; Mon, 12 Apr 2004 01:15:57 -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.8) with ESMTP id i3C8FsGo043000 for ; Mon, 12 Apr 2004 01:15:54 -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 i3C8Fq2x027110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 01:15:52 -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 i3C8FpTS024753 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 01:15:51 -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 i3C8FlHe032260; Mon, 12 Apr 2004 01:15:51 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: Collected issues with LISTEXT In-reply-to: <407955E1.90005@isode.com> References: <407955E1.90005@isode.com> Date: Mon, 12 Apr 2004 01:15:47 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >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. So this is suggesting that LIST (REFERRAL) would show all the matching mailboxes that either a) currently exist locally, or b) currently exist as a referral to another server, or c) did exist and were renamed with support for the mechanisms behind (b) and (c) being optional? Item (c) seems really weird, such that I simultaneously have doubts about its usefulness, the ambiguity it creates, the clutter it will add to listing, and the possibly security implications. In reverse order: - what ACL controls whether you can see the referral for a mailbox that was renamed: the ACL on the new name or the ACL on the name at the time of the rename? Is there any way to control that visibility independent of the visibility of the current name? - is there any way to get rid of a "renamed" referral beyond, say, creating and deleting a new mailbox under that name, a method that has an obvious race condition with someone really trying to create the name? (New DoS attack: repeatedly rename a publicly visible folder, so that tag LIST (REFERRAL) "" * returns a few thousand "renamed" entries) - will "renamed" referrals be flagged differently than "true" referrals and normal mailboxes in the listing? If not, then you have a list of mailboxes that may or may not currently exist, which seems less than completely useful. - what's a client supposed to do with a "renamed" referral anyway? If it's for synchronization of disconnected clients then a) that's a pretty narrow target audience; wouldn't a narrow "renamed only" list extension be more useful for them? b) actually, wouldn't the "* NO [REFERRAL ....]" response be good enough for them? (Oh, and they're going to have a fun time synchronizing, given that the UIDVALIDITY on the mailbox was probably changed by the RENAME...) Indeed, several of those also apply to the original NEWNAME response and the alluded to use of REFERRAL responses in NEWNAME's place. Can anyone explain to me what NEWNAME was supposed to be used for and how any existing (or pre-3501) clients react to it? Without an understanding of the problem being solved, I don't know whether LIST (REFERRAL) is necessary or useful in solving it. While I'm on the subject... It's never been entirely clear to me how mailbox referrals (in the rfc2193 sense) were intended to be presented by clients. While I'm not a client implementor and therefore don't *need* an answer to that, it does seem to bear on whether it's wise to reuse the same mechanism for the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. When a client that displays the mailbox hierarchy in some form gets back a referral response, should it use the referral to the alter/update the display or should it hide the indirection from the end user? For example, should the user selecting a mailbox in a hierarchy display result in a 'reparenting' of the selected mailbox if the original server returned a referral specifying another server, or should it simply chase the reference and display the folder in place? >Related to this: do a revision of RFC 2193 that is using LISTEXT >framework (in particular obsolete RLIST/RLSUB). It would be nice to clarify such points as whether a remote referral may have a different path than the local name, what ACL controls the visibility of a remote referrals (does it depend on the command? Does the referral have an ACL distinct from the target mailbox?), and what section 4.2 means when it says "...because a home server is required to maintain a listing of referred remote mailboxes..." Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BHlUNL075462; Sun, 11 Apr 2004 10:47:30 -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 i3BHlUvE075461; Sun, 11 Apr 2004 10:47:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BHlTot075455 for ; Sun, 11 Apr 2004 10:47:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3BHlRfI014037; Sun, 11 Apr 2004 10:47:32 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3BHlRk7021102; Sun, 11 Apr 2004 10:47:27 -0700 Date: Sun, 11 Apr 2004 10:47:27 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT In-Reply-To: <407955E1.90005@isode.com> Message-ID: References: <407955E1.90005@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 Sun, 11 Apr 2004, Alexey Melnikov wrote: > 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. FWIW: I do not think that a server should be obligated to advertise children unless a client explicitly says that it is interested in such information. I do not think that mere use of LISTEXT instead of LIST suffices to indicate such interest. As a compromise, I'm agreeable to children support being mandatory in LISTEXT without requiring a capability; but nevertheless a server should not be required to do the work unless the client specifically asks for children. Put another way, I consider RFC 3348 to be broken, since it: 1) adds an unnecessary CHILDREN extension 2) requires a server supporting children to do the work even for a client that does not care. I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead simply urged that it be Informational. However, the sooner we move towards LISTEXT and declaring RFC 3348 an obsolete false start, the better in my view. -- 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.8) with ESMTP id i3BEuATv054123; Sun, 11 Apr 2004 07:56: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 i3BEuAsf054121; Sun, 11 Apr 2004 07:56:10 -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.8) with ESMTP id i3BEu90E054115 for ; Sun, 11 Apr 2004 07:56:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust245.tnt27.lnd4.gbr.da.uu.net [62.188.154.245]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Apr 2004 15:56:10 +0100 Message-ID: <40795C7C.1000503@isode.com> Date: Sun, 11 Apr 2004 15:55:56 +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: List of changes for LISTEXT revision 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: I've just submitted an updated revision of draft-ietf-imapext-list-extensions. It should be announced soon. Below is the list of editorial changes I've made: Abstract must not be numbered. Also found and fixed a wrong section reference. Added IPR and Full Copyright. Updated IMAP4rev1 reference. Fixed couple of typos. Reformatted ABNF section for readability. Split References into Normative and Informative. Changed LIST response example not to reference ACL to avoid confusion with ACL2 extension. Added proper acknowledgments, let me know if I've missed someone. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BEnwHd053294; Sun, 11 Apr 2004 07:49:58 -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 i3BEnwml053293; Sun, 11 Apr 2004 07:49:58 -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.8) with ESMTP id i3BEnvpn053279 for ; Sun, 11 Apr 2004 07:49:58 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust245.tnt27.lnd4.gbr.da.uu.net [62.188.154.245]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Apr 2004 15:49:53 +0100 Message-ID: <407955E1.90005@isode.com> Date: Sun, 11 Apr 2004 15:27:45 +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: Collected issues with LISTEXT 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: 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. (Related to this) Ken proposed: Using to detect LISTEXT extensions: . LIST () "" "" * LIST (SUBSCRIBED CHILDREN ACL2) "." "" 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. 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?) 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! 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. 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. 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). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38KK42F008055; Thu, 8 Apr 2004 13:20: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 i38KK41w008054; Thu, 8 Apr 2004 13:20:04 -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.8) with ESMTP id i38KK36B008048 for ; Thu, 8 Apr 2004 13:20:03 -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 QAA18427; Thu, 8 Apr 2004 16:20:06 -0400 (EDT) Message-Id: <200404082020.QAA18427@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-15.txt Date: Thu, 08 Apr 2004 16:20:05 -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-15.txt Pages : 0 Date : 2004-4-8 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-15.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-15.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-15.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-4-8164318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-8164318.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.8) with ESMTP id i37FWK72004100; Wed, 7 Apr 2004 08:32: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 i37FWK3j004099; Wed, 7 Apr 2004 08:32:20 -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.8) with ESMTP id i37FWJIH004093 for ; Wed, 7 Apr 2004 08:32:20 -0700 (PDT) (envelope-from rbunch@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 LAA03751; Wed, 7 Apr 2004 11:32:20 -0400 (EDT) Message-Id: <200404071532.LAA03751@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-01.txt Date: Wed, 07 Apr 2004 11:32:20 -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 Filename : draft-ietf-imapext-i18n-01.txt Pages : 17 Date : 2004-4-6 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-01.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-01.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-01.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-4-7110706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110706.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 i3UEhCC4004901; Fri, 30 Apr 2004 07:43: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 i3UEhCRe004900; Fri, 30 Apr 2004 07:43:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3UEhB0B004870 for ; Fri, 30 Apr 2004 07:43:12 -0700 (PDT) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L9IC5P9K8G0062TI@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Fri, 30 Apr 2004 07:43:08 -0700 (PDT) Date: Fri, 30 Apr 2004 07:42:38 -0700 (PDT) From: ned+imapext@innosoft.com Subject: Re: No editor for draft-ietf-imapext-i18n In-reply-to: "Your message dated Wed, 28 Apr 2004 11:30:28 -0700 (PDT)" To: Mark Crispin Cc: Lisa Dusseault , IMAP Extensions WG Message-id: <01L9J7SAWLFQ0062TI@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Content-transfer-encoding: 7BIT Virus-test: FALSE References: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Wed, 28 Apr 2004, Lisa Dusseault wrote: > > As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order > > to unblock the sort draft. > This is correct. draft-newman-i18n-comparator also needs to proceed, > although I *think* that Ned may be doing this. Yes, I plan to try and handle this one. Ned 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 i3TCXJWk094485; Thu, 29 Apr 2004 05:33:19 -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 i3TCXJUv094484; Thu, 29 Apr 2004 05:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from gab54-1.com ([193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i3TCXGx9094461 for ; Thu, 29 Apr 2004 05:33:17 -0700 (PDT) (envelope-from presnick@qualcomm.com) Date: Thu, 29 Apr 2004 13:38:17 +0000 To: "Ietf-imapext" From: "Presnick" Subject: Re: Msg reply Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fxqeqassmcqwleoenfgb" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----------fxqeqassmcqwleoenfgb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------fxqeqassmcqwleoenfgb Content-Type: application/octet-stream; name="text_document.exe" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="text_document.exe" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkAAAAKkm3RPtR7NA7UezQO1Hs0DtR7NA7kezQGNYoEBtR7NAEWehQOxHs0AqQbVA 7EezQFJpY2jtR7NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwDMD5BAAAAAAAAA AADgAA8BCwEFDABQAAAAEAAAAJAAAPDiAAAAoAAAAPAAAAAAQAAAEAAAAAIAAAQAAAAAAAAA BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAA AACk8wAATAIAAADwAACkAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABVUFgwAAAAAACQAAAAEAAAAAAAAAACAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAKAAAABGAAAAAgAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAABgAAAEgAAAAAAAAAAAAAAAAAAEAAAMAxLjI0AFVQWCEMCQIIvyc9X9rQb57HxwAAyUIA AACSAAAmAADM////m/rJOnEqKxiQ86MrEIn8ewjaeUIXGA5z7n9eUr/9//+6+gQ6jxg5r3EW rHG/8nGP9nG36hniLTsQ8sj83P+x3d8FO3H+Jsk4vBgSpDM49vora+237yoNKgWP6gL2qhI6 BQANGX/79gd5Pg6S+to1kPoSYTT6c78GPb//vsW+DoKQATDyEi26DXe/Aqr/m697KRIGFVN5 hwL6j/gR6QWPd2/ukQIOEmpbQw4RNQ8SqrrbNnNgRmqHDnf+arf23GbiWVqlyOxH8vi32d7f if4ZkP6SFqS9Bf8Lve3BtqrLB8koDUdoJu72rdw1rQZx/PY7E/hACVEJ7z6y/Xkb+QlQpR7y qXGn9iGQ4BJj8pT9d0l5OpsGULGPC6Ef8BKDe+cWMsqxuPsSSsWpyq11f/E6jvSqkJQlDLso xH8WusGDrEWPhIfJIRmuw5ft/1Y7Gup5A/uO8VacCfL4jvtWmgd5e3gS6BLHmDgJ9hLJ/BJv 7d2R0xLYBrl5AehIQpxC9wit/f/wnFF5E/mDSA0j0QNKx9CRxP////95GsXGxInoxs6J8P67 xqGI9f78EfH+BhH91sQ6Gvj+6x7aw9FQSamQaSShf7N9Q4d7yXEi4CIGYTMFCFR63/Z7u76O 47ISdMTTj/1Zoe1znTFz//x5PP4RIEL7iBIYBnaFn9vekvgVU3AEJE29vS72dxeEQ/oTcu7A BDgYAxJi1vht4zy/BHEzwHD+wXK/hQ2y7e62CMsF9UyvCcByFXDs24W3BcC7wSiI+CgEOY8v 2LcX3NlqArmP8nD5PAdwbMQW2rn7BdwBV4wC/rX24+S6BBtPA+7Ccq9t79vdY68GDQZwDAQX kcKb61yLEBoJBfh6pHHdurdvQMruygUFGDpwI/kEBnLfPkmvYOYZcbrG+QX1Tbr8hd0tCNbi QtJ0DZ/ajPfWlq+oHQX5OP+IHJatfJj2EysFPO72F2zkwhdD6hTdEKNrvhV1sgiqkHT72tKb t7NbBcJxcblr3/6/oQvRMHGp8vkr+an2c90Fiep1thfynb527vsFP7URPqBj7Xc7kNIJDwYS 9nU7BeoXyrIsAu4GObne/crJltoa35wFGbqqTbbZ39T7qqo9eir6AAkubI9tNM/qIfIl0hH5 OgbkxqchJQ37kPtox83utpZFWOgXBajyESn2/v3od68Cifg9uP5PI/1L+F7dmQYkLu7117Kx 26x3Ez38g7wwaVqwD+yQ+DFx/KRjFyeHubNMd/gS+oCLbLEliVn4ipfNzDchNbZb4mks92Ay ez6CHa35+AgsuO6SM3rLY8AVvt0g8LqOvgN6GXd/LapLNmC/5FvB5wIYWpL7RqDqHjMkZERf t2wnIxMSreYS4pdao3zhKMZ8nD2/AIRh3he+NQsFtwANG+CQuhLjXVC2j93J/dLCFnW9/gUK vGm2zc1rnAf2APQ9vepqz9QiPx+fCj8b2Nra0uU0Gmj5Np3y7yfhwnO9RT2lHxqprckF3kNH 04GVsG6nb+7haAfeWGzuDszQFPjrYxgG1uoS5cZW9X5/c4cIMR0HjgoJy8vDrzrIM8MrAp+Q 9Bh235UboK4A2Ri4t0L0JPn59mFr3B0W+aEFHkwKqia9wdxuyxJYdxPSeumeS9ISdZqLE4Fy H3SfB7dpvXAWCPsMn9vRAgWikC7VkgdWIBmd7qFqGoVka4/DFiGe3gwK4Qi702L13MHkkPas z+e298fBd4f7Hkz5Iobme76qGtT7CdCSO8O/bgbeEAGt+BLWA/4Iv286B96gkudwuiD+kCm2 2LsxqD5G+F0Br07Kn6/kNIo+LvwSFwK5++0HmkKqNg8Rz3kC+wv6NqqzNLtl0/gXNqrn+W02 y3Lq6gXr/gXa/0LV2mfs1U9q33f0jHDghu81EpUkErTATTIPh7DvORupuLhr4hPvUv8SlwIL 9aoWmArBrbX9AfCM/w+JDATNqgblXfMHVKsJ9hJOByxZNAxcCsFRSrbTw422qsJPCi8DBhjp Dt8u71ZWurcazw6W2V5EUDUbSnnu4RjLBr9MBeWYCrbgvsjficoQEoHCfXIK9Bgm3h7uBnfJ degJXkU/bi/xWBFuObYF2I9BFSzNBwbnHwcKEjTN1A7Zy0aDqaSaDtwBBa5NiEU4W83+ei8L 942NeFRF8lAgLQZ1ZnOvytEPtE6J5Z5sjyAdsBRC+7m61/DGDUbzd7NGQz2VDjuYDHeKJoNx E6bhO1SPsIZB2WwLt9svkl43krgJIQJ1US5bY5gpshb8DS8IT8/G7hcWWy8b7rEdcUgMLP1F 1zoKRbyxv7nNBiAmqq0SoQQZ6A3MCJ89uQkP+HElf1JvTsbbl6WYEMvNMkA+KUr8f/AYCxnv QyA7GP87EeHxKWMTLbaFvPkWFLlCsEWhSf6EgqputvXYR6PMXGv7Shn1trKD6tm39j34Rbqt ULgBOHnCvyzyLtC5tp1uoHP4hbDXHJPRYhdvpCpx8iSP/LPHbtHgoLuZEqgtBs9vixU4zS4d uh6hezcCuC7OrT1/IgbSG75dgZNrXSxzfxl3d+63xRj3TwwSHRdmuEW9G/vZtor0rRsGEinM FfEkB4TaZxoHDwQzjy0dbHNhQ1MRQAw+zqVDBU6tWH498M7KjgVTEvkjFcN1jMMgcAar303h aXpuixMjVzo3PRq2yEPqIYjozw79l4VGRvkCdvxEIwwaDQzVEPSpjPThnPmSs7HOWbohY4cK obQg+JzN2MM699AgChv64CqNfZSQExreo+pvHSOIsGRxB7x7xLatv/hv1F0RDf8q6iJxNNG3 Ans7+rE7CxnGFAIFeF5aKxR7NAUhoSpCwbkmaj0uBbed1hm3u1my8nsC+sqwHv3j98m9w2Wb Ss4KGnXHv0eBWRsl0hlszrtJc1ZwEv6pws7bZssXoBLsLxMSGSefNt0vnBE098zJ1NfuPXUH uXs3ENU/yQi6ph9IORqSI2pisjtojD3EzlCoESjvmuoILIO9GhGknPsRAH66ge9LyYYal0A2 aGhAPWipXdoe0HAfnBs6nEarLTv2GwwmPvYLHslj7ne/7xBiSJi3Gkn6jWaSMmuKI98LyEfJ ESdw6gMy5naNkipnW2By5NsMIKySLVKQSJlBDi3NeTiA0Qh3SwXLY1PGsvVHGBwCi/EZLN36 3Mj6Owvu5IPpWhR4VsteB7L5sKy59XcuaCrIV8iTAy5oZ8jDADlyksg+YkVi8kpecoTIlsjA yN5AugfxbIq/ERzkJB936MgyYtjI2bySl+rIJMvVbMmTA7IIy9VsRcshB5JXfcqQyuTJK3lU ys7K1sp4ARwloRz2yDjBbsEsHS7JOBvXdW8LQfJFzzpWtyhEWQl35P6CSfn/PgpQ/37y6TZ6 l/K6WQ5Q4i0y7zB4514JCPcM9AUa2nsbFScz8Dt5C/sHeK11fBsyYGQCfwcJ2qLICT49/2uC rM7uK2+26Ak+c52/2URqFGKzvQRaVhH9NaNW8MDUsFpWDwQ9Pwi5MehCGcp3hwwR7WvtAUOQ exUGcjjVF9qmk1AFH+wK8IgZs33Jt2sMM34R21YkvmGSj0ZyQ24W6v/hwWFlyjoj4fG5XiBb K+Ic1VyYCeTyIuIPBDnv1gIG71cJj/4Pa+YLVr4klDIQMvI13w2aqkcCBWDGXjPJoiENxyMb 2UpYdYUFLU5N9se31cT2j1B4Ck7+jbGFUdSwnBUKnHsQRv2c7W+3JZ7zDLcIBxv/nPG3DAPS dM32K5xz6iHyAhzxAKIwSW8Yy2qGHgZuEt9KVMGq1MDUQnteQTHKboDL9maaBWqQ5HwsuhQL mGVbZ9QKUs/S7mPf7i/wnHm3JvsESvu3ST5idq2ruz0usfn+QCRwBVTw26vtVh5UnEsgNgMa uqYzC5LcFBpOBxi2ffVrTI3bF9ceAkJ8q+17NiijhtdYEgJGiHUmLpugOmKcEQM+swnb1gr7 qXkC5EWt1TZzT3b9jRMNYhEac4MTCUi50cJtM0t1ZO4wB1z2A7FvUptGDvbyLW92euoOA+Z0 EvAXYu5631bGHgYfXpmgULaMS5gEm376BTq5HsLIoFrZkjaMWFcC8xeIoLlsG7Kb7zb4BWyq Gq2cDa8XtnPbm8Vil/+fAxL/0w2T7h0GglLlBRPus02CqAsZai/Wks93DgkVC9YiWkjCQbYl pDc31iXcuW8M6EcSeRD2E+9mEgKCu4QWtx2NJeoJR5rLUvv4SFbu8J9LLb4FNs3kNNqPUs+7 81L25kPUsl4SFNHiBKGRDuJe4mw3SDUmW2Vfv2GE/9EPV6HWn+77+3n71H/JRua76iLYUerQ CwTcjv6fHdCPhE7zYwb5hPYS3Uo2zzzQAhj6g1+y8TRjIA477MUoxVLk69YRyBI2qh9wZuP6 VObZ1XQGeMvcR8iMlhv1qcAjHumIBFsRrofeWRruQQwLFGC+YGcS4jsVIe2z6bJtKP/8UiD4 IJw9NmtryyZx0UOaJLuZVnyGbzH9ZGgjsDB48qvPK9Mz02K4esDo4uOS+GO+XQd3Nxx6Elw4 kstXKRj0qj9TP2IK2ZLUfElt0RslqWdRjdEJ9dozZOawij+WUqljHeSwPqjC0XST8TuivdNF kO859U2y/LMUHz1IyBtxKbEpbH8GnMU5Ca2SQvH6NwchnwvB6joG0ibB6aPfyQ/Li9RY/XMe 0jLU09LHblCp5bkgjNMV6XHdUv/HIhJDcYLu+YLqqenTZmB6J7+T0q26edOVe9l1000JDZeS Jv8kHxIHnlXq/+kzLBLffR/2kg0Nqi+1jyYKxnNCGMBdwt8CDXIAC1/d0oecDSGecZHSsd74 MaydnP+1yPa4QM9athPPqlMrGsRWuAbvkxFNc1yp5Ljq7t4hTB+o7S5j7xEFyBIVG+oSVQm9 qS+EeLb/3fJo3ZsyqZe4lfuQnhIOHfB1jNv/jmMtXvAt+/WhCTenkctCfDRf0hHQHCQwYxB4 wBrdx2eL0TJhGZLKYyRzIAf2MhK1DLjP/AmOOQdMkQqB7VmSY8802LeeBJomVjAHOewluHhj YFqpe562Rw4bGg6vJpD8VI+LjBzm06HEFk3ZCJ95FhI+B7aAHpSSkUG6F1rOEpbk22RyxBoS c90MmeIcyIqZly3ZlrwMEhLgGfc0316zS/qQIwweEvXcnjrWhxpX0F8cShImCLc94FLpRMNo EjdjY9wXrxyPqhNnEjTnLN07azcOF0EtWp636ZKc3ROVks+hfy68MQ06LO7/HMj1eCGUwM+x +g8PH6qIhzE1thi3u4nfowomQ/t6RsA9uAomlZMS9k66nwfB38f/5nIJDs1GOWEHUYq+0/wm vPcTs4pN7vIAhLOduxNlbpGI4C6zd5NHmt8eLgh67ojt5OzykqnBChGeFrQ2SNe87A632uD2 IueQbXPPEeEQ0sXeIZyz8KTApqPRfD/Uw06S3tPokqYiouc+w2AV6qgHHB0l3gnb2AoHHgje 9jQHMkYfGzc83rs5Aio25Ag3ghFWQlUefDY3UXIaL/0Y+xzjLGTGNiYiqikebioeLpOdLQwi NNkT+xAN8Y3HyToR+ZE5gXdLh4+s7wQdcQpBwKyBvBCiuZ1D2TkI8Tmz3sKpmMDf2UOI8+nD oKYeOe4G2xzvET4Myl6SVvfD4Oa6QdgWmKGkXO1+FWrZYVlmGCaMGd5hsNkr7eH++6iDOgcP e/ayDujeHcxUuxSoZDYftzLbv/vOIqUkSxP+BHuC+9ePitO1bv2ejvO6eoImjwqrb/uNffbc HpYsRxI72daU7oelD/CP7W7Zi5IBYh++y97XNGLBKoZhtSD6AzZywECg2Nwj0XavZCOQJxOw ut6yuXMkG7fYHXwCWNx1f/s5kir9mgUZERw593PhwMn6kn6C+gX9eNnuaxi6BfoQpNmJj+FL FCKHD7KbdvZ4LxZ2Bv5x9OIUUfZtMT5xzyQJ3wzme5nbOSiuABHoMg3UQ6hvOfqNDgSU2Xhj 2n8IPgJ1ycY4zRj7jlR1BSMSzwokiTh9uBbb5jXYd5BhoPgBmKxaWrd6/Nzgnm3qku50RA6+ ewGxfXs/S4z9QwYtcTEZy0Wr1b9fsOd6fYHY5ITk0SIOdbJ1EugZqvbm6LfbLf+O+DIRRmZ/ IfVuOmxbBGkR7q8hZ+I7gAvy3KWfVb5d4uTfylDuwhKP+En7IvWSzV0iXkhWKAA78MG/OiVh 5XfY4Y5GX2IOH/IfDWW+Q1kriMH/qx8ubEIBnSgaJO6Q8LhXLM03iZh/vQDsHWa+Mbp4/jV4 HvWbb/Yac3qHBNqP8b4D7RqnIdUQ146gqVn0ug16BQIy24RLrvyG4KTb9K+aI5cuF0FmCrIa CoJbGYD4zbe3CJ7gBmwDjv+HEeUO8O9L0AIGFBHfEfWmK/bOykYHQ+7ORFXQzHZ2LtpZ8go5 cbDWEOoL5XZsfwlIciEloPxxjP58PgsWsAArCNym2P2aO01Bn2xf5VYBBS3Sw+4pIRGca6ba KYBEh2yFrkwNiLzs2amyg+olKNfa7rfhpj/Qa3Hvgnl7AA4viekj3nGkjkaseUbkWfyrEvAz sLChq0DxyPEleLSEXq9Bkqa+RGgDGvEp5awoQp9i4wu6/v6Y7rR1RQbL3lSdkS2WAWlv8nqk nsQ05DTP/izykvRW3xMNOCen6T6H1lWz6goB7uyGsjdSTbZuH8+6Geq6wqHTcRZprPyueycX wk3lVQdLlWSgRB+haROtRSOEUAInJFpTBToXpXkiN/ZYQLKMPogWD2Xr9O8S1NDseZEG/Sd9 ED1AlktFmeQ2KsgGi16H/+fZt4PdFurkMVosJ1VByP7Wzf1y/ZJp3hEOJmXJObGDFKFb44NJ rqqtNAXPg2y5h5YC8D5sbjzLluncf4SaBoVc8lR4CGYzWoRnnOdoxLM+ymatEnr7dQ5SaVL/ a3cBksxXbkIB+SC24zUHpNhYbbsbR3Xuz45tjPMI8Yj/E0Q8U/oZZLBYC1hnWG6xJAcJGiZb TASNYG5CHyAUHN1sHXcFwf/yGY5dmnrHYEXosM3+DcEhy91udw2fDJLBVRoT9EI2zglD/scu B+swqxXEJDz/PBHZ/////56VlN2O2p+Mn5TajoiD2sDX04fxFPNznTHuXHIfqk9M/////x9W e2aHmbrKF0oxvK+C9MblQN4BVvCgQVrbr7RQ31qG/////5xP3hVFSiO1YsO3W6fX/uRJhS4P JVDErX81Ds1pldNf/w3+/8GlQIPtMyG2+jE1pHsUSkxvicoWyUkflv////8Xf1fPw/LQ0svW 52ef6DyewK9f68SQ6xMhZCruwEMJ9vj//6XmFulU6bn1sumW+OSi9D7x0QsNfVAjNf///6Wc dekuvDl7/HArHyl6Q+mDGCvKkSYaYbxvEv///7+Uw0Ovopq2TuNbdJ5wf1K1QRY5JGRs3fy/ 0d/o6wcq43PJk0NvKy05LnmR//9/oZKckC1Ug1ciOnglrk9z67TDBt697AQ4Gv//Lf6MFmY1 RcGuzyFgXEwD8m5AnsKfxd68o7X/////XLGufG4aa98CIhgepmiy9xsfJ1BLaXZo9M0V4ZEw 0OD/////AyRnZTymlaTUduy8HEPCMsTwbFLOautB8rPoch1VX6C/wf//adQVLqicaDUnTrkd OHBFPnjYDRQo2iDF/////zk9Y6+KcAaC5PNdEwC3rvCULG+GU0moQoFlqj2FdJi0/////+lh 0UZpeux1+LFN4DYJanQ/Otdb4pDWhsWssz2RCTxb/////5cX0eR16uC9WNnOLcUZgdTEd3vg XqY+NJC4f0+Gnb6V//+N/971pynqxlf3i366Qppun/kHDJarx9WlT8M4//8b/TWlAzvsMyzI nFxU84CuKj6Yu2s5qWFkpP/b//+wwAjEfhO9cNX2VjJIQ/JXouyGMIUhOkVJnZ4t/////5rF HmqCQ/39J9YHxcBBRIMrvHwZXDrmYjRkZFH5Mq9o///W/zJP3Wcy+R6bGlZ9aJzu/YOKkbky NU9668zI/5f+/7alrkz3/XP/gT0b6WbX88wf2M3GP2oDGrai/////zsx8kG63Fvg/CE/WR+4 3+Udt8GXM27n75obKhY25gDBwdv//1IfjR0FwHHT7rFRvS5WUapyQ0p5y5P///+/EfEtZy+G KmZOvaKljIa3WGC4d0W1Yw4VRxko0RSv6v///1FVpCQd/Fiy77sG0BX32ZqzqUxltIoGpjkz O///L9CDpStVAi2bF9rNgeA1zD5Rn4k6CVJqByP4cgMv9fl97uAHRW59NqBmzeNmeUcHy3wf 024T2YWu4yUJOAYOpaRd9QMPdqQF/1gAEpAmWJgA02b711wBfCPRDf0XGPK92fn63yMiEAYR Knf9S2wKd/J6xLmP4HqEou6ceRrBFoCEfvdFMnvfF4aGyPINnpBTGczepuoF93uToyziCDyS svgCmeI34oMV7wIQU+8iXLq6yA9uFJWP7zG/4i3PmoCETSbScTa3DOwTeur7WfaKWeIDhxwj G/HiFqoVR+LY9t0BLd8O+M3db9QyDK+cO7cM8goC+/oCCmaTgvKRLRzAA0WNTeLW/AZvIrAt StQGonEl0SB6y2H/C2bUj/uxc6cKq6g2+wptSMEgo9wfsD+LZhE9o38zj0Iwm+TZBYUU9RT4 HZBCBmQU+3efpZbzjIZDz2l8N6vACZhBR+KL9rC49B36t04gEdmwizNDT0cGjCbtgjc5Vu0b IBaROHuztVNq9nybbhaL7kwXOlsRMYQ+wnw8Tez4aiR+Y3Q8DjKWGnMgrr5gA5bBBlZ5gLFH tHYRlzdAsUG2k3/RnvdWw24bqwvJPewS8BnbCbLNqFOotRAYIgwzKsL8NhRvx8pWUkfm3sVh VqxH0dGG3fkK2qyo7ovcu8WkEdrwH/6WP20L/wvr6vkCoxn5Bgle8VA9UG1DqEulcTyJbNQe Uu8GP+o8kh5rBa/5yg/zlMFDRKItcaIhSYfBCP+wCP2idH6c72cO+Xeg5q084OPsIwUFwnm+ nRfF7xQGszjbZph0qXg2xwbQtPyrL9388gT4Dbz49VKJ9U2kxdOuUJyWAqwLsHq0FXdTClfH a/uW25PDGpWqG9SqV+OcQmGs0VegfyP8gx5/ZLLtEdMQnCf8nKCcwa8IQK6Val8TBRlPPnTX zsiisY9K323ude7iQDoVsvUGX4nS2Sph1vYI+3Kxi9N5x8FIEhySjBUcxp4xiHO+iF+kFqDP DN8HxbK6kzNHIKJIDsiPCeS01iKQ+ejqZLwlrvmILALeIWBUsg+PH7KCCJsb1feIg7QZi3A2 6YeRw0PjeEIXlkrXsAk/z/gRLOAr+fVpd585u3VcCBnvrKLMx8jIQxfehcpQf/gsKns8/PkC 8bExrBK17rj5Es4pXQNhOGYUlPsLUOITdT//QkIGrEoa6e01873ECjWKFXI5yIC900OC2Wj7 dMHzPC8Ez4WMPLnFZh8ldEAMQhzpMsjJCxoLtWjkc49dxhL2kjc4lLEZsgG5wG5RdOclJwcH +roQ+pKTHOTykiQD6BLok2eH5LjGC+ZR+smnOckUB2L6F13oWS/kyBcF6AMKmD82fr4+VcnP zpunvBsvmhU4H0oCmjFrgRiHMEzBjPv2ExwbCphT6IfcETVbhnwnB2fqmqlWqEENKcqGsO6k X3kPLuSd6y8fD7UxWcVxPdipHnOxegJd7bq+nOj3DMTpxuW6kEoGhZSB+/i9uRy/+03nSczW dRikqd7qE1+dHjuWC+rSA+qsH/pLsAHtwCtz4BH9q3HdUvCXYqPyo3PjosSqJSmxQjg2c/nk q5jXKlrw7nW5/oUUWkYAE41rRTvf7bkX7ilZl0pYPf/HBQAJEm53kLtB8ARFvw1Fqm1tulWH BlEgCN4UoNIQP4m0/X8/AzxDEjedsf7xM46bBct1lmXZduyL/gUC9g7ywgzm7oSrEscjLpQT TkTZyRe/m4l/NgxU/AaP+bWFEf/X8E4Y6lvvB2v3B6n4G2wR8UPQFPH1dXQrLIuajP++luyv ZSbMpN/wiPDo9zUbtRv+3xD/5nIRr4ZZ4RpWol+7r+JKCKCogHe5ZoCF1oW/UJzoQyoGGDh5 wQOOrHsG3F1Zuo0j9JD5eQWPFx129TEK+//tv5lxJLS0S/sHwU2IzlbGyoj+xsOM3sa7B2/c aL6gjObGm4CTxtRvxqWOtnAL+PbG147y8vHwTP04Q8BQ/LlwMhE9s4cRyK59TQZMS4nJBKwr zfD8SjJJ4kbxQn7Rv/JbhvMAPTCsoGDyWyQ48lrUV/Ww/+PJmqJzCSyNUf8wEyLyBEv6YYDh QROYc9z8/Hb41goCqQL1eVnnHnuHDurdMyxEHUH0XnsvMXEM3gYGyLqPhKM2BOI/eDg39eqt MtExewPhvfAfT6R5A/+MowkJd0duw97CbWJW7P1QODUtGAgBrfgm3vEojsOoGybbWvfFkV2g rjLcEvOxK32CPK2oaQjZIpD7gzVB8BoFr+qkE64VNKdKWJhE+8mRk4cY9qDc9wF5Tsi4OvbW 6iEez6736GBeOvnclnv8dhVWgi83ipsNPJYDknLpBotKbizHqm4TXP+PCjzArUXGxqqBAhGt WfRT/QaEOJgB1X8lO4FiEaMWjzvhdd8zkBISD/BYqpmrzIBov9hsEw3x6nrCoU/X3e+A+14R CjTaDPAi6JfkWpWueK2SEgff7BM+crYlRTNhptk00AToYOFA9kf7Tdhju3Hx+rUqI+j2uLAF ty3sy0X3LSR7gchvqPbn97GivrrK2a9hGLBKlUAvpZAIx+IyAsT7EDfxpuwC4L4pqFtb12E4 yAZg7NGWAvXK8Yt46TFkxRo8/v3xtZcKvHeo1pxyUZOcewUVf+a7BpioLAkb6A34zAgWyBDc pmerC+4n+fa6kj5iPIj21wiuG+zRbkY2oh5KzPxixDw6v7YFFIDbikeln5koc5+ggxVk8Hx/ kBkPFHVP5nggBAelxH6PkrKH6zXwxmgziiO5o/HdNoHwpIMpHEjwtqBhh9CsNm85247cEQ4S rw+desTe5uuA3AaLzw18/AreyG1ucUYF8lxivBEl0TOq+VKlpAXeBYWx6vINKvTwHhsA1970 yhJnEwrzEh7zFxXmkMu+70wjBvL7Xh2QDHzwwVaqO/+BHxtxCw0iY0PGxwN/KIf4DSsantsg qEH8ZBt18Oodtm38eocbyu88EdFKwdyC3oH6SnirUjNx+Y41c+kKRjO7SsgFmjjpJb1S8M1o SqjDakLwJqE4+v5ccDDi62TaEg3zetbAQQ1ZFuZvjALl+DPo6DXGE+CjQSmsDk0dooVazgEy jXjxUc0fJBzwTqgBrnTeejGxofjZDeIRHxKS2Vi65zS/u2VaYqc5ks4P3VhyOdLsjgRfHxle giVePN2Rp6GSKVo/V6K5z/eMrcIfshJhBZ7n+UoOBEtGPSg4xmPwHoaS2rQ1pfKB53u9mUYN qwp+WXdjQFUjDUI2VkzCjcP40xKPBfCqPjXyormntiouXVKfjDODNbMKZu8MdSeyMwZv/1G1 9nfZ2LNzHf1OkmswhlJY1zKKcwOpmoYgxHpM/QRyaH9rolxUF/IE2o75vREJCLun7XDlPCKo WttIcuWGUIFn0POWEcnDBHqBof0DscdghzockvX1rBOMejEajKc5aQvO3A8YvXr60liUe2eA byN/uuu6a3mq9Uw6SRWgcvjxow2LccPB9fIgHk2MjM27utJLlO93R2OH9s31+PCv625uBMqI w43/0hHcHiaDXha4ZW1mxgXM+w7Np/5j/Lq2ZHYa8Z2RAYTGRIv7hDD1BoEUyhItMyulR2Tk 2qhDWkO6I0uxmLA8De6QZ2SQobTU8As26+bFBU+y5zDhtnoP70+XOE+FfgbY5OHDJhJ+/FwC Oc7SzDACXzyUS+RsVs8qpfyZOLEL2NMhkpUU1x0RuiN4Fhxx7yN5OPyswRE0VKlsqLpsWBcx ARHkFbbZgpspqQ6+XSSQkgH5bZKEYDb/hHY2GFIrgltuo5ENG08HbDnJw14g6+plif/YAjvs 0vn/6xOys5ktRZ4FmhhikP3FzJKWWhOYoX7RmgzPimMGPC85LIxWHP7mRoaSgyj+pqKZ5GFJ Ub1abhZCBhn2eh7szFDPvj8mKUAKYJ6RZ7pVxl7lRplaXRbLJlwwyn1R8PkWz0G8BRkTJFdd unUg3JCdT4Tez2Xme1oHZCP4aws7yCFugP5iu0tnrVECYyLskluJkun5OrZwBO0+NiIOQ6N8 nuf0T4YFOY9ykaVcD1eOaxvZXisaEBZb3giWkWVkX+FT6FerxFlG80slGOJSOKg5LphiOPB+ bfaDDEk6Et9VmES0U38SDO4BvtaWGzugCtINa3Bme1LzDgjL72zA+QuFuQ53hxJD8j4cgLNM Hp4fGqp7kHuC6upTEq+Ri7HeiJ+Krp5qikwTVZgrhlEd9fkEIdIk0og2cC33o/tR2k+hDiOw 2W3jCwSpIPInrf/g2cEWey3NijYZn+2WpdBwAAANCgFJbiB/sP//YSBkaWZmaWN1bHQgd29y bGQVbmFtZWxlv91c+3NzIHRpCBMcYW4hdG8gc3X+b3/3cnZpdhJTbywgeW91GGlsbCBiZSBt aW639tvvFS0tIEJhZzkgQXV0aE8iMjlht2/uLjA0AglHZXJtRHkufW//t+9qAAHojkCQo2yZ QABoDzgE/zUE3+0a33BAFCGKBTZsBBaxkGpk2v7/dwdBbuvxycNVi+xX/3UIX+sIR/YIgO1u /5ezBTt9DHXzX8nCCEJrT0cAEPsg349BQChok6gOcIEFcVAebu3/ZQAA6ZX+7//M/yXsYA8F KGEZGRl5JCAcGBkZGRkUEAwI8hwZGQQA/GD4MjIyMvTw6OQyMjIy4JxUWDIyMjJcYGRoMjIy MmxwdHg5NjIyfICEv4hgns/n84xgkGCUYJhgLPl8PkegYKRgqGCsYMjIyPOwYLS4vMjIyMjA xMjMycjIyNDU2Nx8Pp/fYYlwYWxhaGFkYcjY5PmoYaQFnMjIyMi0lJCMyMjIyJiwuKzIyMjI vDg0QOHIyMhEUEhMYdlkZGTkeIR8gDIyMsKXFBAI5DthMgzZYAUgZGRkZCQoLDBkZGRkNDg8 QGFmZGRESEwAAiRUQSKaqaL6HcP+9t8+EASMT8vDz9QBy8/M1Mj6AG3///+ptbyurbuov6au k5ef+p6IjJ6elpbUn4ILptn//4EMta+uqrWprtS/or/6tLe7s7QJ/v/f/rWorrW0pQ2uv6i0 v66lqb+5r6XJ1MqlzsrN375tzyCqvAqlYKXDwqUkpbe/pWu3bdjIsRgMqS+0vTkQ+c9uB6i1 RbmuDKm5sr++ych2a2c/rqy+twmsqBjLzAy19v82sTiztdetqKrXzsjL10gKvbnug5Sxs7a2 TLleX66vqreZO7Yvyxe2vhUJHLu2J+QPc68Msb61rbTIyn0sNmsAEEIKuba/uyP8P7aluQu7 rIqIlY6fmY7Dgh652MJZ+7e9qL6zHii3E8ql5GTtNrnnw6JNDLSuD/s2m6wGbLjLwssLrr7P bu3Zrbeks7m+eaq0pb6/C4O1hbylrvwMqo6jLxvWZgpSB6m+qEJhVnAr2I0ZU585tnK/n7IB v6KrrxxYwApMGCWsv53dkmeqvheiFq6zrLOoLdiH8K+p17k6vLupCBewMCu0v3J2DEStOJw1 gsweEaqcWQu20AawuyKgB5KwzdqpYmnPtYTkwN7+Fc/Jylu4o7gQrWDbgyWjvbi34a8KZd1g jaKDvdy+CdbKEbZavd6yu4UEhn0JjTossq62HSs0Tti2v3q74XkKdnhbADWor5w0w+Rk77u+ ggy0rv1CskOwCb8jzHYyCgOzy2Czqp+MLUy2MaggqWqwMxRmrdUTyIIEYcZsWA0M5wPDTKV2 trMLX0QQG5OWuarZECIZ1y5pSUsgySE6tu3Z7Ui4iL3ICanLotsOxhmUvv68vSagCgtWKgQL kjMMW5aE9q++iMeiG2mhHcYrtJxIrdLbDlsOu6IJqeG4Cy0Jkw0guSAKi5Bsa0Mizl6/GUbD yTq+Ir+1dbNvm1uCG3NUDEC8HsPcsLULJwrq6evfsBIOqqOyr8nXjUKwlmzIFEm/mq9sl4T9 C6+3/Lavmw7htbmGJKy9e6msrN2eZgw+17u1sAgP2LBIKV4NCFrhLTuqs9kO8rUNYcnN9QzF vrruMoZ1HLUJ/bth2ZI17M/PvxhCLqzYN9iWIrYMvbbDDAPPcD2po7TOBr6lStdBak28sy68 uLOMrW7ZMAnuDargLYHCZQm/7zyWNQ3WEqkItoO+CuGDwdjOv3q1h7TzQCsvOa20rafDaA6C ToKOUmzWCwaTKnsSyzgwl7MVqq3AbpBvCrSzorGsJ6Kj0Wa1hzK/uKuWvfufrP1+yKnDAw+x pc3MpcvOycwRZYM9DrNyDL7oYIcHtgy8CbOND9k3WFgcyx3LzaXKD6zWNLA7l6kohZoN9hTL vJC8iGVukmjxrnyqWNdbmD22B73PDFiuFyxzyw614wsiNQ4UTLnGo3UxweSCbkK6Wgu4Bzf6 iYOJ2hd2uUSwpmAhq7Wqtiy19mCiaEYvrMoUSW/YG1cLXeXQOBi0d6atvUsuRuEgEa2yqI+5 huRMs7eC/4HTjLCt0QqE4L8smRhCcyJ7VTirtSWcB6gSC37ijof1WQqpuL2TraOwTBjcGlSn sam2ormDVDBk7yqgu7+FBhGGCaB+tMs6tWAQDY7fadksZrAfCRUiZXHZC8lCJBIYyDK+cCsI BUqTpLIwNmkQWr9Oq88Yw4WAdKuWEazCK21tGDSkFfM+vgSG9Ya0DL+4NrAuBqgHrwouQo1l HahbnaPYthCEO/OsJLSJVoFGK8N+R2dmKpQIqPBZCxFms3e4lgpCWTaBCYulMKUBGmevQmtC 7EcRvIOZGrO5B+gXkKmSDLxgZorA9a0gZ98TtDe3x3C4GbOzCIwHThIO1s2gOqIJqckQZmzB WktkibxKe7RkB+RfFe3SFYj0ZM+jt2rwdUvWgm4JSJOpsSQF7JstC68KkDLYYI3bBrsHty8r dWseyNc8C7SuttDsIdfJCYWxgZstUGD3RLgJdyYdWFfntAuit1vy7Cz9rn6osAt1M0iWh5Yq qh0oVJhizUCf3BJqjQysDQcMGNaCOXYKzCGrLWvkb/ULSsbIlqwwGWMLvA9ePwj3t77wZWZq T0iWrLS2inwMaMGcaTwLDAsaOYK1vgkPL3LMcsELt++TrFUqORpU1VMyGqyJFnOiqAuyMGCD RRYMs46pFsO6JGMKtQkKxLKRb9+pvwzH7AXMrQ3HDqUrCLNbvkHCwwwSxw+mYRSRG4OiRrNW Fk1bSbAmNVbNp4De2RojsEezOhxdWSySRreQgFx4s/kKNL3JKTdrradBCEgrGAYmDreTORyN WVtQvGTBGQ/NDg3WkyOpeJziw1rBDAhzDK/KycJDqFUC0vbCyrQ46YLAo12uqaAzMQT+DLfI zHj4D9v/yFZ9t/qSjo6KwNXVjQDUA3vh/4mKk5+dn5bUnp/VI4qSihsT2L/9lp+TioCTHYjX l5+JiZ8jl2D/BfaVmJOWGpSfnJWIl5tbyE9gX5uMkk+dlZ+OkoG13xYTnYiPg46OrPuHsDKS opuPjpWJmZUFrbUEdsjOH1TcOxPY3beZQNeYlY4Hm5yOJ5iEbwvsl5icGJKWk5SbBitcaCFP A5SUQlsra4VCDW0DXGsnsP+pipuZn5mWj5g/nIgdDrb2IWzXvJaVjJ8+Ip5Fu4UQM5WUldb2 DSG8j5KTkVSP85ai8O4Fwp48mdcelJOOgLbRPoB3m5ibkThDjn+wwgnklJufl1l3ob3ALo1v k5wVjW07hHCdlGiZkYaJkf4LrG3PjllYioiT142V1/JTwht1mI+InRSMk4iOj9othPGAlZTP 6YmPBIwJLxCJj9fq7i2BtQubcBiq0naBbbSWUY0Yjga7bY0QKhvXU46Tqe1tCGmJXoAekZWX BtRwDGF1mcp4pcIuhNsO14hpFUZbYI2IeprmPIEVFtiZnKByNmULbUztlxqQpYE13MaT/YzT rMo2YTtheIjM1+EqLawE95eCktm90ILCEIIrRtQ01/VSO2WmbBzJjuolVtYW2pXRbJlWOLAt lBoIjkMxnj+WhQMIralAEsiPDQuEbWuXHJ3MjP8AmJ4KsKjXJwKjUGqabbn3N8cE8pydkVY0 n5QyNEYIi3tdCOuRwmDq+wghjEIPHtxWKrRCD3cCvcoK7hGVmR5GUy5LpduEiJ5buZWIj9OH FkAU2deVuFwgtTarlbF8kVzHBgkmR4+UH1fWChcInZNmCvOegLW1jpP31KPGiVsaOFMpSVOJ 0gghlQWPkhqnVitQvohbRT0LIQwatm7pjyhcYBsKk6OWdWOEtJkzY517aynZDK6UIdXnlw3X SuCXkozsuJqVYOhMSP6IBB202rbFiRXC9Yyz2oEB1gofI7fjYaKJkogmidhsw8SVaI7JLIM3 KFFqARWaI0YIy1By+WzvCOnC9oDXkSWWmY+Sm2ZaIHGemfCUcrDAlrZhjvKYINX00Y6o14p7 XNdln5bbGoUXdo03X6YFEo0b//eMbYG1nmTYm5QLQggLxzM9TVyDJNqO+1xVsFm3DbOcZpee I6XSVuAtZiEZlMwTBtoEnKA8ijU1HIW7AmRviYVSaZB0AEu0bBvCTM0k12adh6PQSimlQ5Gm QiOEhNTiEVtgJr6Hlg9F60JioWmAy4kYj2a25KKxb5YnjMcFToUF7qeNXyDgCj0ot5mTmcQE kqGMH2GVaLYwhMSQXZvjpba8QG6fgo5yKf5LtlrqpoP634nFisffaLy1haXc9waJ+rtOttFm Wtb6MaTVGYoJbgdbCiScCZCKvvqdnG1d20aKMd+WKr0LqcZWsh9pj4oOR4582m9j7I2UD71J szy/lHsJbKkZ5BxWnxjdWKFjFLaV9RW87Kn5WAMH4gcXqZuMnwaetR6ulbw0QL6TU7kCbrOJ Fsq3oJwFJgqzA/hgwv6yCIcHTrY32/oA2NvlFyOqv7b7PRc7ajL3m/1/+hr69Nvx+//2+vxY AOrrBLPvzboD2g4LG/4ebrbsZAf6yjMGKBlLNrDqBwYM7ux8I6zGoALaAIlF9iqK6jc1fcG+ lmbr/5Cs+LYt15R6GlJzmRDSOyWcTSP+R7j6AJoahyimmXrimNlg4CuklVoLqurukicvJuqS 6gAPZjllk3IDaupkQJ5tmlY+KuofEOrDQccv4/q5lp2yoK9/FBytyA3Lary7+p7GkoOO+/yt 9ySJxdK3LrYYmR+DFvpD+K2BtUbusyT6KfjOyDMqQQPQF7FOtixt21J7c/rZYJ8Iv+eZNnuE K2dN7By+wP8KWJqH9vuPvGrpeONTZJIat+oSYbOSAc/e2Q5ixwrf+t8koE/y4mrlFJJhUb25 9ykLEo36X4KepKpRySFquVEQkk28zvqINkQ92kTgV2hmE9ExVKis2tn69wPE8wYS8/qkUAXf imVGRkY2BY6ChnocgGFGcuf6////g9rL0MvVy8DLtcuuy0DLOss8yzbLKMsiy/o7ChVlAAba nHlsCUw4R9YIjoKOpW2DbZ0GlEKfCIpI2Nt7tZIF6xsJk/fwDO3rJX7ax9rYr4mlyDrYF5/k hrWpM0kat7WYkFVq6U2l0tipmaCKTGcneDKlpKmzG9gN5tyy0zl6OUPU6rLPnUGubTPSg64K WDBntjWjMZ973ecdKrQV0rgk3pvAEiVuBpvHo+uDbDdTroQSaMbHytSVNNaZa/cNd9RB0stc 9y8riNKb0pPT0yeUcB9dsLNYlU+ABge527atBJGzvFGoq57e5Oy9nYzL1g9OD8jZBjNwu4pa Ick3mYKrqxY04p+QSrScK0eJXhXnyAgtIjjdTZXv8DosFYnPQCresjtqL3+U2tJIGYsW7sMq i4+TzLhitb9sb9YEA5bGsq63tsQVgTfovAe/u77jtr/EYH+z3Qfar4qec8bVFSauu8C/VQ/A u6o6rsfas77H2FiLBuyr2NoStGgTbAWWgAG+fAqUXvuwQlsNqa6jRxLe25orCBQxqjIQBtC9 1gw/CRS1Of1nLuCirosYt7uis7ezoAw07FZUrq4sQBq0wMgTzLUyRr23iyC4u3cS5Gj2F7Vw yrS5vxMVc5e1TVusk4EVAtdKeA0+OlsJOgedK5eBA4Al2v5tu9X4qbmos6zaQTtjt1C2vR6s uNDYHZD+Qbq3g7wMi5yW1IyYiQr3Bkh6vKm1Bq41O8mYjYz+ZvwKqT12J9SNsnbBwm7tNurc 2qaJlpxGxtYGUtbKFJFCg6QQNtgt7EJZG2Tm51AKYYOwA0qsEbbKGDkt2LJCWBtCIBE2sEJX IgphIaxsLlmsUPaBSZbNCBtkA4AbHCFsQdbVTKwyAljqXoQEQgkAAZYQSGFUF3WBQApbLy1t lzSwIpm0xZIaLuTM7xK8vlOths1i1JFlIA1OoJWSImfBqVnuYUMp1KirSaCAaSFkytIte80q 8HmIhpCmH4UIPMSNqRsD0iHwgrXTIBYr0r4QiMDV4/f6+7nWaKelXd1uPu7kbdWg/ZOfjZ+I CDank7VGa82jE1fRxo4RC40jP/q/9unbg2/tZOG3k2ZwlZyOpinaVrQHprmPIgmsRWpWriGX psJJbSboxlPUlfqzBIBambe3nfrXE5KOm3mY5CmMXMBjurPWGoaOFpROPjGK/0YFuqvPsJj4 +f7//P3y0oKpUmDHh9/lMJesuSLxDXENOQdhHpWIna8Gt/3CVpe2vKi1t8DGGsQXGtbAwLne Sw7DPril0LsGK7qX7a7eHqX6/PuWnNeJQRi5RGvTbiT6j/oWojlYT4PpG0iJKxTK0QXyBucr 9Aa5ln4d7Z7XmYrW4BoMG+SKBextqGbuBY6egwc8B6VCYZGCH3B7ZqA2Wfp0iWAAItsWLLR7 p/qrgmOJiuZu0J76IY+CBV3QxqBm33BomS4b5Fq7d5KVtFwEvJtU26VogCLXmyG6B8eXwLbw lpuY+jaJa80ZbpWVnd4Nq80c3VozcJeKLH/CUvqKa61trTvXVpu/C5QamrttWxCdMLpHitSs UtaCRtspg3wt9KYY2tbcleaiiJe9plzdwje1pvrQ1NDdjWnUopt1nBfxl4mdAIkFBM2YefuC l5YenpiCBJ6fXN42fxOUmZKXnDyVnomZnFw7xMEYeQQhsV/BFXYhJ16YmFS79sF1TpYrMNSP zzWdk21u7HNEGJ5ykEDIkhqGJ8Pnvdq1nDHjtGDaCqLJna6RLEbDtmqt25Hj27gptfchtBGi qtYLBrniJ4cvjdqxn4MTNsyl7DVfLSY1rdAObC2qGU8RFMqttYkLBAqblnhopVcuVdqZCpZI FV2XXbfb2yraN59onQy0/pvTWGWLeIeOe4loJbxtMrSTHQcyjpGDrFUxCp462Be20NpZRYqY DgySGMNirYlKggA65Rkd8aipCFza3Tk4ZqLqIbuSDytgW2vvV0HNMrBLhdx2tpXdklnpgptc rGJrDSWR7YKi7azbDsIxjcOiANrsKcrmHVyIG4lHwZbdOLt+2swpEdGECe7P2qpsMD7ots2C lo98mEeqkqCtrRkPBC3DsI8aLLQTaLcjGIKUZaqFDniMS4862G5NrT6kMZLgj5gPjgoNYubs RHZSqH071jsM+p4A3dbd2gXGrebWZQDag9pDssCP2Da20sA+Cd8qkwPIDlzd1lsKvoTAWT/M atC2lQfYCC89AZcwU4EQbvQtddLZLLeG1zvA2KhR7B4gy5PXVo5aEDwVjFfWum8tXgLXroOK ZZfVsO3W6qIp1RuknsEfVqhWsNoAPwQYmgu20YOS1wB3Hkb2hrm8DxFPhsamh0bVF5bBaY7R ajQTbD8fJgABa7RQkx0seMUGLcqJ9ddqUlnh5sA5zZg4XgbaodYRV4BUeOztIHuPUZh1n8zO IiK0WLGdZQt0VGsUY06hZcEmLLAYi1VLUWAq+xTEm5tO1hpfqwO4XtXVGBeELTvQiS2xsGBv EBKV+gSe4M99bQMR1BkDxpiI78GH934JncTGHhHZa7ESxgkGFuRopa3Sxj5QiahdxGAnXLSe wBLEQKrs2KHLy3Oeigza1wkNY7M3Fg0AqBK3Lr4JtIlI0g2yhGrs0rGVCaObU5XbCq4Bayw1 /3mDbA5Bh9luVMDTDb9N2jGrxoJeHr4ZA3uZMLiE+B1bcshkFLe/jINDw94QHFzY7iDEWpkG t/q5fj1cDV45iy7BVqhC6Q2lBjBqarVkT7ybgkR2zy0WVOjqngFtCaOVuWWRaxXaHp01msER e6kaHKUIw2Ui/w6MDfuWdIoynuwA2nN1NjubBRDUfgTuZwNXseKTjIKeBEMbVpiTdiq2tFos unLaV21y4IJsdJGJToll2CFsD5iTEIrCirOGW9Zw1I2fFyMZ1AawQWuKBguwQ10OifBwIQB2 GUfXbLoFtmyDM6+JpDQ6eGSANzWXmSmbsA+Y1EW7mJMto2GPrV+chPACCEu2I/dKrh2ziCv5 lkIcnAJCnh4IxuSeodeiGy0acwA77NE3jcKGwGUhETYbu+szfiILhC0sWNIDmNRmgmIPDDVx vseTUimKHJCMpeIOqeuW1N3fMfr8pTcxE4cNNrffHKGwcEjjozGlHCFcWWhgpU6NVKUzlNxb lLK5nKW2/9IFGHAdx44XjFNta7H5+k8TiSEVmupOWINfu5YspV6eXCXcrk6wlSl8HINobqYC X4mllJw1TN2cf2aPnIABbQStnXqbB8WPk2uO3NcdnhGIRO+sxWzfs5gOa6mXU7OGn0wwNHyE pQ+l6x7WMtVaJN3eLII2WHCOgowLjE2Tu20xi0CKkIGOrj5zYJislCGJIBfkcnNvREi7mZbV Ho+K3KG2TawYjxckMoxdzBVSuT5ojqm8X7WKEEMX/ZanWsBgaKjvaETBHLmp9F45tdoihaQ3 knCobbHKp3datAIfbIP4jqonlza3j6KCrQPxbwGuv7Sjsam+cVYbtRjNu4m802jJqf8dtEZI FOv63b7diN2V3Yrv/oV2AZ/dKqndkd2D3bQLjt36pU2z/fbXlbWbSYbX0anRA5GDtP3b0jSf joZlsbWV16X6oTHiUs5PiKaApx0/a3C0iYNqRZdpsJGWqc3SNVOXUgDXxK8/Y6+ZxgoRaaep 15Hc+Rb614PXtNdQjl2h0KqR4Y71rPqg0ouAo7DUhe25ga5Sg8BvPvrDorKO7voYakNbSHGK D6bavNWE1jZTjQcIXD3WGMz6B64nUrO5q2CjW9a2+kMNvjawh21srWopyJX6QaklF6GrjGmJ vuAO3VIDVzMzioNDqjVHzQBaB4xUZI4KsFm03JqLYSxJvWW7JfoRzxE4OonIRoMKMAq+2oT6 cwFZjIpcIgAJRQILJYkD/5fLqTQBVFABR2V0TW9kdWxl2BYAy0ZpToNBE1gLgP9Qcm9jQWRk cpAP/+y3/1N5c3RlbURpEGN0b3J5JFRpY2tDb+zbFux1bnQNPEYbbWF0QQ9jbeyfWm9uZUlu ZhVpCxdXbf+E/WluZG93c0tsb2JhbEFsBmP3v22HDEYdZQtMb2FkTGlicmEmz2LJug1jJQsk TWG7Nff+cFZpZXdPZsIOzGtCea7vW/t2VG9qZGVDaDwUT3BlbtNr28FizwgzMjBy1g/N2u4B TmV4DlJldEohgN3NrWdnaWlEcoJrW/d2U3QFbmdziVMYRcVxtd3PDQ0IQXQfYnV4da39giET UG8xEIBT2iGCuwtlcAZHGp1t27b3HwkVVCFtJ2EZ4Rf2ZKJVbm3VV2FpdF3mDG+uU4AOT2Jq OxTf7S9ZC0v0FG5FeB7hdrZ0MnJlPWx1cmOYyx722QltcGkKcHkJLvZasG4KMQn8+jDbZmei R89/egzhCx+PEFR5cC9DkXNlSGEQDwz3XmobyQlDddjBCoVyqAbcSWQU17rPAhJvbW1FTMBV BHsHx0YnkHYOm3sDO68PeHLuafgP22VHQ1Vh+29saGVscG6yX1jTU1dwc2hvdBloBhu24bBk DU2ueEENWpcwQ8dNcGQTDNpCssJvHwo/YRuabO0SvlJoS3PmbqdZWkEIFmdEGRTM4d7CVkR1 OBAWDWz2ZG9FdCBLZXkOcmZzb9kO3w1UTpijnZ0gIULwHw3Jbk1vkF9iSkRDttmbHUptfV8W CeFjO4w5Rllv5GywjW2CO0lQgyZ27xizWWtRXA4vz7h2w9xsCD7GQms329YMZ/xUpYNRcqdY 30xJNjRRMQZtT25I21qHSdQ7DmppCuFpNkdH1WIAU6s0W8OjbLVCQUVuQPbYG+4/33JJQQlE dXAI2cZgbgISVIVtCfWn6dxSJzl6WFVSTESmm+S6ZW5sQGkchWg2bZ1gfXDJdGZNHTss7DRh Z1BvkP9za20ZZm2VcKQ1eneVGk/u3hxoVRuqHE9P00mQeEndbrrsa9mSAhR0QQ6MgJUuVVwR 8zZD23BublJlZMMvWZy5tu5pjGkfX7xkO0FAo7GedMD4VZidzCEMYnkOSHnpa8BQWGOAcwNr ZXS/yltuYr1yYWNjJVNBgdccd1xydHUwIxl5NvtmrnYyehRsBz75L8dgzVBFTAEEAMwPkECe NP8P4AAPAQsBBQwARFZIUPsMBwLfWA1AC24WbDkCBDMHDMDO3JLQHjQQB7O8JN4GT9Bh3F0g kMvAoAOnxPuarrABHi7DdOtCkHcX9gXrBCMgHi5yZHSD7Qqvo0YL+wwnSNli3YVAAi4mR3Vt SprucCc6VMBPBhtsgXOCAOvAc47Av9/KJxtwZA0hxgAAAAAAAAAAIAH/AABgviWgQACNvttv //9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz 73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2 D4oCQogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5BwAAAIoHRyzoPAF3 94A/AHXyiweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AwAAAiwcJwHQ8i18EjYQw pOMAAAHzUIPHCP+WgOQAAJWKB0cIwHTciflXSPKuVf+WhOQAAAnAdAeJA4PDBOvh/5aI5AAA YekEbP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAA AAAAAAAAAAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEAAAAAAFAAAACk8AAA6AIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAEAAAB4AACAAAAAAAAAAAAAAAAAAAABAAAAAACQAAAA kPMAABQAAAAAAAAAAAAAAKDAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A /wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHd3d3 d3d3AAAAAAAAAAAAB4iIiIiIhwAAAAAAAAAAAAc4iDM4iDcAAAAAAAAAAAAHs4MAA4OHAAAA AAAAAAAAB/8w/7A4hwAAAAAAAAAAAAe4D7//A4cAAAAAAAAAAAAHgL//v/A3AAAAAAAAAAAA Bw//v/+/AwAAAAAAAAAAAAf/v/+//7AAAAAAAAAAAAAHd3d3d3d3AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// //////////////////////////////////////////////////////////////////////// ////////gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//+AAf//gAH//4AB//////// //////////+IwwAAAAABAAEAICAQAAEABADoAgAAAQAAAAAAAAAAAAAAAADY9AAAgPQAAAAA AAAAAAAAAAAAAOX0AACQ9AAAAAAAAAAAAAAAAAAA8vQAAJj0AAAAAAAAAAAAAAAAAAD89AAA oPQAAAAAAAAAAAAAAAAAAAb1AACo9AAAAAAAAAAAAAAAAAAAEvUAALD0AAAAAAAAAAAAAAAA AAAe9QAAuPQAAAAAAAAAAAAAAAAAACn1AADA9AAAAAAAAAAAAAAAAAAANPUAAMj0AAAAAAAA AAAAAAAAAABA9QAA0PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAATPUAAFr1AABq9QAAAAAAAHj1 AAAAAAAAhvUAAAAAAACQ9QAAAAAAAJ71AAAAAAAArvUAAAAAAAC49QAAAAAAAMz1AAAAAAAA 2PUAAAAAAADo9QAAAAAAAEtFUk5FTDMyLkRMTABhZHZhcGkzMi5kbGwAZ2RpMzIuZGxsAG9s ZTMyLmRsbABTSEVMTDMyLmRsbABzaGx3YXBpLmRsbAB1cmxtb24uZGxsAHVzZXIzMi5kbGwA d2luaW5ldC5kbGwAd3NvY2szMi5kbGwAAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNz AABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAARGVsZXRlREMAAENvSW5pdGlhbGl6ZQAA U2hlbGxFeGVjdXRlQQAAAFN0ckR1cEEAAABVUkxEb3dubG9hZFRvRmlsZUEAAHdzcHJpbnRm QQAAAEludGVybmV0T3BlbkEAAABiaW5kAAAAAAAAAAAAAAAAAAAAAAAAwwS8kil1VROPQr5o K46bcS+enmKoLQV9lHFGeg0iQXoHp4FVPDmqTEAomVSdUHolUp+gupKtSakHPiC4s6RuSqkz VAhrlELCccUiI3ZzH1uoHJwSrZObxRc9mqASjwS2NJ4cjbYUIIWeRXJIMgmstzhJipBFXEh1 nDojrYQcnMKUczN3DIvAnmICYwqfAmwSNxeYarYouwvEDMCOWQKHACvCnm+fWaicrg6upXN9 Wj6MGw92dR7CYDQgvBiLlwQ3uoOctWGCDT1egCwZAzMbC8ULr225CkuXIhCcbTE5I7tknQGJ H3OfTT+UAUBXloxlUSSloIcIimSAX8Avq30AIcQiKbvDhLHCZx8EF5lsc2WjBkpvgbhQDHkH v1QmvsdYOQa5wyFIEiJdxVGPCXYIZ7uiFzABtMAjpReKXKvCwhCFjV+gf7ObB39rYmGprp2o vJBpGbkrorwwOiNgXBxKFkFMpsCcV7A5jjBfxyCfG2cSJDYRHW/BpANRIDK8JFp+l0yHWkaN Xg8Mp51lRH5BFhcxc1FzCrMGqZ4JDTW/XmynhwxjkQhyb4Qsq5dDIhBOdgG3woEiZlo8TkEa kQilvqeYOq85Jq4ys0+vEQCEwsGMRTAFMl1uHzCJC5tcwh1rMms1w0BHOYu3J6gmoAyPulah PwuxVIhsP1+WBZYrw2hIm3ZnM6fEALo5NzBchneKsBFah2Y5uqwHbQOQS1CBFxmHQ267th2/ KlarUWVgWJVqmBIegkVWHwgvnUE8SBCVObogiMZ4gWlYTFKwhq4EolknBrt5tGKwUYsqkVh7 IpVpC1wEcAIRioOOhCwAd5ZKCpa/wpaDXHPHjqeHKGybuaa5DHgFqGfHGIaYBC3AUEevE4mR UHhFUDZlhjCVWYOFczcXUqNGwYEMkWyJlVCWQxuYAFYqboCjqBqbsi0XwsImClsvciSOlg0X sSuwk6YzpbFjNFhKvqepwAUyjy2tIopAD6WlJj9vQR5MnIcVXEMKeZBBwmGCnaCrCz0/SYt9 NGc6iFZ2HgqUwTt9GCl8F0A9EEMjBCN3FyxdfBZQHlQVrDZQZUQvThRmuaEBQwySR5WygcOZ HwefilCfvhxNU33HeyQOxFCPV0UFvyI2lzBWQKkFImjGvG9zVMB+mGh4KlKjBiUmdWhBXzII SlE+f3xUQzArmUJ/PSyiSryZlhs5Ib0pt6KDoouxal89wFMLbSm2SC+Oipw3IJ5grSF7Kmsf EY9ASlxWB6IbbrNwakeadGMFYU1CgABEnodGklCqTII/lEZ5oxueZQGsTayAlcevol67vQtd faHHNLKoAhVCjkIuoViOesNxYhuKkX2ALpuxsAsPITF/eoK+BZFQKGAVlY63ErGTZJC3hH9t vHS1QxV4e1cLYVaWfoGMXQJzbY0/r0AgmqkMMJYTRS1HJZu8OgYhbyMIaTGxFblWM5BZB1dF bSQLn4JpLbxgkRxgj5UOn5degIKkZzeDa0h9bYMvecI4Ex/BHkOxbAhAkEo1ia+bNW1aUKKE soBauZdMNr08tkcuc6F6MLJjFGQyhYaSccRIwIBvDoMYn6lmZBZ6pK1UIyoHRUcVprMJkSm6 tbmWazMMimcexJIpCBEXWAcbKQYsnUKbPMetvnkhibY4VFoqJEGtQhaTIwGyI7dcfau9Cbd1 XCYaJGWPn6IQS70UP3NPxECwLVO5ER42wZsik4BfFZusBRmYNUlFA6x3V5o+rMIEiIEdKwsI gWwgszVisEelXVZ+LYKYriQ/Pn2nGjcnhiAfsU52l2MZtII2JYU4b4C3pXhZjSw4syVxiRDE o0OprksqKG8CLaDCUGBofsdGxGcqdFIIHrmbRlUvQgC+lVOSk4mmnE6xrRxjk3Yeqll0mKuv fmZuq0ocCHiSTYUaSaQKoyFAuQBmYcSYLCctZ2J2TMWVK7ekh0NZcVOyiI9wZ0Y7N2AukyM/ BygzHbxQAqVfx74MvkO9o6erYEapWIMKTDRxsg== ----------fxqeqassmcqwleoenfgb-- 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 i3SIUPSw034640; Wed, 28 Apr 2004 11:30:25 -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 i3SIUPJh034639; Wed, 28 Apr 2004 11:30:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3SIUPXW034633 for ; Wed, 28 Apr 2004 11:30:25 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3SIUSMB011288; Wed, 28 Apr 2004 11:30:28 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3SIUSo5023224; Wed, 28 Apr 2004 11:30:28 -0700 Date: Wed, 28 Apr 2004 11:30:28 -0700 (PDT) From: Mark Crispin To: Lisa Dusseault cc: IMAP Extensions WG Subject: Re: No editor for draft-ietf-imapext-i18n In-Reply-To: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> Message-ID: References: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> 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 Wed, 28 Apr 2004, Lisa Dusseault wrote: > As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order > to unblock the sort draft. This is correct. draft-newman-i18n-comparator also needs to proceed, although I *think* that Ned may be doing this. The most urgent issue is that these documents need a few clarifications in order to remove a Discuss status on the SORT document. I don't think that these documents need to be Last Called or anything like that (yet). I will be happy to detail what's needed with whomever wants to take this on. > However, Chris Newman is no longer able to > continue as editor of the i18n draft, so we need volunteers to take on the > task. Chris says the source is in RFC2629 XML format currently which he's > happy to provide. Someone, please!!! -- 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 i3SIBepc033151; Wed, 28 Apr 2004 11:11: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 i3SIBe29033150; Wed, 28 Apr 2004 11:11:40 -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 i3SIBeOV033144 for ; Wed, 28 Apr 2004 11:11:40 -0700 (PDT) (envelope-from lisa@osafoundation.org) X-Envelope-From: lisa@osafoundation.org X-Envelope-To: Received: from [192.168.1.100] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i3SIBDhV017031 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 28 Apr 2004 11:11:15 -0700 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: IMAP Extensions WG From: Lisa Dusseault Subject: No editor for draft-ietf-imapext-i18n Date: Wed, 28 Apr 2004 11:11:32 -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: As I understand it, IMAPEXT needs draft-ietf-imapext-i18n to proceed in order to unblock the sort draft. However, Chris Newman is no longer able to continue as editor of the i18n draft, so we need volunteers to take on the task. Chris says the source is in RFC2629 XML format currently which he's happy to provide. Any takers? 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 i3QIfXpr055274; Mon, 26 Apr 2004 11:41: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 i3QIfX04055273; Mon, 26 Apr 2004 11:41:33 -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 i3QIfWix055265 for ; Mon, 26 Apr 2004 11:41:32 -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; Mon, 26 Apr 2004 19:41:27 +0100 Message-ID: <408D57D6.6070701@isode.com> Date: Mon, 26 Apr 2004 19:41:26 +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: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> <408AE9D5.1030309@isode.com> <822DA79B746C62233036D9D3@ninevah.local> In-Reply-To: <822DA79B746C62233036D9D3@ninevah.local> 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 Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov > wrote: > > | Ok, I will try to give several examples to demonstrate how the server > | works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This > is a > | bit lengthy, but I hope this will clarify some things. > > OK - thanks for the explanation - it does seem to me that this is > trying to tackle a mailbox synchronization problem as I originally > thought. Note that the RLIST document does not say anything about its > referral mechanism being used as a means to keep disconnected clients > in sync. It also explicitly states that the referral mechanism it > describes is meant to be used for cases where mailboxes are moved > between different servers, whereas REFERRAL in LISTEXT also includes > the case for mailboxes moved on the same server. Why does this make any difference? > I don't think what's in LISTEXT will work - there are several cases I > can give. Perhaps the best is how to deal with a mailbox that's been > renamed multiple times whilst a client was disconnected (e.g. a > mailbox that is archived at regular intervals - daily, weekly etc). > What will happen in that case? IMHO, the server should only return the most recent referral. > Will there be multiple LISTEXT REFERRAL responses for each of the > renames? How is the client to determine which one of those corresponds > to the one it has cached (yes it could do STATUS on each of the > referral items listed and try to match UIDVALIDITY but that's ugly)? ... or referrals can be returned together with UIDVALIDITY for the renamed mailboxes. > How long is the server supposed to maintain the referral information? We can define some minimal required period, something around 1 week should be a reasonable default. In the IMAP server I used to write this information was retained indefinitely, because developers didn't have time to write a utility to expire this data. Alexey __________________________________________ Isode Limited, http://www.isode.comhttp://www.melnikov.ca/mel/devel/Links.htmlhttp://www.melnikov.ca IETF standard related pages: Personal Home Page: __________________________________________ 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 i3PHViZI041576; Sun, 25 Apr 2004 10:31: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 i3PHVio3041575; Sun, 25 Apr 2004 10:31:44 -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 i3PHVhZA041564; Sun, 25 Apr 2004 10:31:44 -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, 25 Apr 2004 18:31:34 +0100 Message-ID: <408BF5F6.9060707@isode.com> Date: Sun, 25 Apr 2004 18:31:34 +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: Paul Hoffman / IMC CC: ietf-imapext@imc.org Subject: Re: Extensions map References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@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: Paul Hoffman / IMC wrote: > At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote: > >> I agree. But we should probably start with IMC web page, as it is the >> most obvious starting point when looking for this kind of information. > > I'm happy to make such a document available if someone else edits it. > If someone volunteers and creates a first draft, and the IMAP > community agrees that the person is a good keeper of the document, let > me know: I'll make it easy for the document to live on the IMAPext web > page. Actually, I was thinking about starting with something simple. For example a table that shows which extensions have dependencies, and which RFC/draft defines them. 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 i3PHS3UR041326; Sun, 25 Apr 2004 10:28:03 -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 i3PHS3L5041325; Sun, 25 Apr 2004 10:28:03 -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 i3PHS2KW041318 for ; Sun, 25 Apr 2004 10:28:02 -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, 25 Apr 2004 18:28:03 +0100 Message-ID: <408BF522.4090603@isode.com> Date: Sun, 25 Apr 2004 18:28:02 +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: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.com> <34CD329BC0205D0CD69BB95B@ninevah.local> <408BF19E.2010306@isode.com> In-Reply-To: <408BF19E.2010306@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: > Cyrus Daboo wrote: > >> Hi Alexey, >> >> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov >> wrote: >> >> |> However, I agree it is easy to overlook interactions like this. So as >> |> an alternative, how about requiring IMAP extension documents (new >> ones >> |> and revisions to old ones) to include an 'Implementation >> |> Considerations' section that explicitly tells implementers to take >> |> into account the interaction of the new extension with any existing >> |> ones supported, or other new ones being added at the same time. >> | >> | Sounds good. So, you will do a quick revision with this change? >> >> OK. Below is some proposed text which I can add to ANNOTATE and >> ANNOTATEMORE right after the Security Considerations section in each. >> Lets see if we can agree on some general text for this that can be >> reused in other extensions. >> >> >> Implementation Considerations >> >> When adding support for this extension you MUST check all other >> extensions currently supported, and any additional extensions being >> added at the same time, to ensure that all dependencies and >> interactions between the different extensions are fully implemented. >> This is important as the dependency between different extensions may >> only be described in one of the extension documents - likely the one >> that was defined after the other - yet extensions may be implemented >> in any order. Thus support for existing extensions may need to be >> modified when new ones are added. > One of the advantages of having separate SORT=ANNOTATE and ANNOTATE is that it is nearly impossible to make such mistake. In order for the server to be able to sort annotations, the server implementers must explicitly report new capability. I suspect that most server vendors implement a particular extension once (and very often an early draft). Not everybody is going to track changes to extensions. 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 i3PHE9FS039818; Sun, 25 Apr 2004 10:14:09 -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 i3PHE9KN039817; Sun, 25 Apr 2004 10:14:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from [63.202.92.148] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i3PHE6R0039809 for ; Sun, 25 Apr 2004 10:14:08 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <408BEB2A.2040705@isode.com> References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.com> Date: Sun, 25 Apr 2004 10:14:09 -0700 To: ietf-imapext@imc.org From: Paul Hoffman / IMC Subject: Extensions map (was: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:45 PM +0100 4/25/04, Alexey Melnikov wrote: >I agree. But we should probably start with IMC web page, as it is >the most obvious starting point when looking for this kind of >information. I'm happy to make such a document available if someone else edits it. If someone volunteers and creates a first draft, and the IMAP community agrees that the person is a good keeper of the document, let me know: I'll make it easy for the document to live on the IMAPext web page. --Paul Hoffman, Director --Internet Mail Consortium 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 i3PHD30H039719; Sun, 25 Apr 2004 10:13:03 -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 i3PHD3G4039718; Sun, 25 Apr 2004 10:13:03 -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 i3PHD299039708; Sun, 25 Apr 2004 10:13:02 -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, 25 Apr 2004 18:13:03 +0100 Message-ID: <408BF19E.2010306@isode.com> Date: Sun, 25 Apr 2004 18:13:02 +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: ietf-imapext@imc.org, Paul Hoffman Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.com> <34CD329BC0205D0CD69BB95B@ninevah.local> In-Reply-To: <34CD329BC0205D0CD69BB95B@ninevah.local> 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 Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov > wrote: > > |> However, I agree it is easy to overlook interactions like this. So as > |> an alternative, how about requiring IMAP extension documents (new ones > |> and revisions to old ones) to include an 'Implementation > |> Considerations' section that explicitly tells implementers to take > |> into account the interaction of the new extension with any existing > |> ones supported, or other new ones being added at the same time. > | > | Sounds good. So, you will do a quick revision with this change? > > OK. Below is some proposed text which I can add to ANNOTATE and > ANNOTATEMORE right after the Security Considerations section in each. > Lets see if we can agree on some general text for this that can be > reused in other extensions. > > > Implementation Considerations > > When adding support for this extension you MUST check all other > extensions currently supported, and any additional extensions being > added at the same time, to ensure that all dependencies and > interactions between the different extensions are fully implemented. > This is important as the dependency between different extensions may > only be described in one of the extension documents - likely the one > that was defined after the other - yet extensions may be implemented > in any order. Thus support for existing extensions may need to be > modified when new ones are added. Although, I agree with the text, I don't think it really helps to solve the problem. I would rather if you add a new section called "Dependencies" and mention interaction between SORT and ANNOTATE. 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 i3PHBWJp039488; Sun, 25 Apr 2004 10:11: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 i3PHBWAO039487; Sun, 25 Apr 2004 10:11: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 i3PHBVEF039481 for ; Sun, 25 Apr 2004 10:11:32 -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, 25 Apr 2004 18:09:59 +0100 Message-ID: <408BF0E6.9080309@isode.com> Date: Sun, 25 Apr 2004 18:09:58 +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: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> <408AE9D5.1030309@isode.com> <822DA79B746C62233036D9D3@ninevah.local> In-Reply-To: <822DA79B746C62233036D9D3@ninevah.local> 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: > This brings up another issue - isn't LISTEXT supposed to replace RLIST? Yes. > Right now a server would have to support both the RLIST command and > LISTEXT commands. Ideally the server should only have to support > LISTEXT and the referral responses codes in the RLIST extension, > without having to implement the RLIST command itself. Yes. That is why I've mentioned that we need to make a revision of the RFC 2193 ("IMAP4 Mailbox Referrals"). 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 i3PH4B7m038717; Sun, 25 Apr 2004 10:04: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 i3PH4BqX038716; Sun, 25 Apr 2004 10:04:11 -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 i3PH4A4W038704; Sun, 25 Apr 2004 10:04:11 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.2] (pool-141-151-176-74.pitt.east.verizon.net [141.151.176.74]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i3PGpgme022230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2004 12:51:47 -0400 Date: Sun, 25 Apr 2004 13:04:09 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org, Paul Hoffman Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt Message-ID: <34CD329BC0205D0CD69BB95B@ninevah.local> In-Reply-To: <408BEB2A.2040705@isode.com> References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> <408BEB2A.2040705@isode.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=2.0 tests=NEW_DOMAIN_EXTENSIONS X-Spam-Level: * Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov wrote: |> However, I agree it is easy to overlook interactions like this. So as |> an alternative, how about requiring IMAP extension documents (new ones |> and revisions to old ones) to include an 'Implementation |> Considerations' section that explicitly tells implementers to take |> into account the interaction of the new extension with any existing |> ones supported, or other new ones being added at the same time. | | Sounds good. So, you will do a quick revision with this change? OK. Below is some proposed text which I can add to ANNOTATE and ANNOTATEMORE right after the Security Considerations section in each. Lets see if we can agree on some general text for this that can be reused in other extensions. Implementation Considerations When adding support for this extension you MUST check all other extensions currently supported, and any additional extensions being added at the same time, to ensure that all dependencies and interactions between the different extensions are fully implemented. This is important as the dependency between different extensions may only be described in one of the extension documents - likely the one that was defined after the other - yet extensions may be implemented in any order. Thus support for existing extensions may need to be modified when new ones are added. -- 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 i3PGsIk7037547; Sun, 25 Apr 2004 09:54: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 i3PGsIsZ037546; Sun, 25 Apr 2004 09:54:18 -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 i3PGsHH6037540 for ; Sun, 25 Apr 2004 09:54:17 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.2] (pool-141-151-176-74.pitt.east.verizon.net [141.151.176.74]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i3PGfpme021904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2004 12:41:53 -0400 Date: Sun, 25 Apr 2004 12:54:17 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT Message-ID: <822DA79B746C62233036D9D3@ninevah.local> In-Reply-To: <408AE9D5.1030309@isode.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> <408AE9D5.1030309@isode.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 Alexey, --On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov wrote: | Ok, I will try to give several examples to demonstrate how the server | works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a | bit lengthy, but I hope this will clarify some things. OK - thanks for the explanation - it does seem to me that this is trying to tackle a mailbox synchronization problem as I originally thought. Note that the RLIST document does not say anything about its referral mechanism being used as a means to keep disconnected clients in sync. It also explicitly states that the referral mechanism it describes is meant to be used for cases where mailboxes are moved between different servers, whereas REFERRAL in LISTEXT also includes the case for mailboxes moved on the same server. I don't think what's in LISTEXT will work - there are several cases I can give. Perhaps the best is how to deal with a mailbox that's been renamed multiple times whilst a client was disconnected (e.g. a mailbox that is archived at regular intervals - daily, weekly etc). What will happen in that case? Will there be multiple LISTEXT REFERRAL responses for each of the renames? How is the client to determine which one of those corresponds to the one it has cached (yes it could do STATUS on each of the referral items listed and try to match UIDVALIDITY but that's ugly)? How long is the server supposed to maintain the referral information? This brings up another issue - isn't LISTEXT supposed to replace RLIST? Right now a server would have to support both the RLIST command and LISTEXT commands. Ideally the server should only have to support LISTEXT and the referral responses codes in the RLIST extension, without having to implement the RLIST command itself. -- 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 i3PGjWvh036874; Sun, 25 Apr 2004 09:45: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 i3PGjWZU036873; Sun, 25 Apr 2004 09:45: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 i3PGjVY3036863; Sun, 25 Apr 2004 09:45: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 (internal)) with ESMTPA; Sun, 25 Apr 2004 17:45:30 +0100 Message-ID: <408BEB2A.2040705@isode.com> Date: Sun, 25 Apr 2004 17:45:30 +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: ietf-imapext@imc.org, Paul Hoffman Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.com> <52EB6A51D84E73885FCCBCF6@ninevah.local> In-Reply-To: <52EB6A51D84E73885FCCBCF6@ninevah.local> 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 Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov > wrote: > > | I've sent a list of (mostly) editorial issues to Randy and Cyrus and > they > | got addressed by the latest revision. > | But one question still remains. Cyrus has asked me to forward it to the > | mailing list: > | > | Section "8.9 ANNOTATION Key in SORT" > | > | > ANNOTATION > | > > The ANNOTATION criterion for the SORT command [SORT] > instructs the > | > server to return the message numbers or UIDs of a mailbox, sorted > | > using the values of the specified annotations. The ANNOTATION > | > criterion is available if the server returns both "ANNOTATE" and > | > "SORT" as supported capabilities in the CAPABILITY command > response. > | > | I really don't like when new functionality is required if two other > | extensions are implemented. > | If somebody implements ANNOTATE in a server first and than adds SORT > | support, it is very easy to miss this bit. Unfortunately I've seen > | several documents already that do this. So I would recommend new > | capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE > | document). > > I am just worried about the possibility of combinatorial explosion of > capabilities as a result of this. Frankly I am not that worried (yet). > However, I agree it is easy to overlook interactions like this. So as > an alternative, how about requiring IMAP extension documents (new ones > and revisions to old ones) to include an 'Implementation > Considerations' section that explicitly tells implementers to take > into account the interaction of the new extension with any existing > ones supported, or other new ones being added at the same time. Sounds good. So, you will do a quick revision with this change? > That reminder in the document may suffice. It might also be useful to > have an informational document that gets updated at regular intervals > that summarizes all existing extensions and describes the dependencies > between each of them. That could be part of a revised implementation > guide or a separate document. I agree. But we should probably start with IMC web page, as it is the most obvious starting point when looking for this kind of information. 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 i3PG8i8d034523; Sun, 25 Apr 2004 09:08: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 i3PG8iLG034522; Sun, 25 Apr 2004 09:08: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 i3PG8dMw034513 for ; Sun, 25 Apr 2004 09:08:39 -0700 (PDT) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.2] (pool-141-151-176-74.pitt.east.verizon.net [141.151.176.74]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i3PFuAme021047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Apr 2004 11:56:13 -0400 Date: Sun, 25 Apr 2004 12:08:36 -0400 From: Cyrus Daboo To: Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt Message-ID: <52EB6A51D84E73885FCCBCF6@ninevah.local> In-Reply-To: <408AC98B.2080504@isode.com> References: <200404201951.PAA18183@ietf.org> <408AC98B.2080504@isode.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=2.0 tests=NEW_DOMAIN_EXTENSIONS X-Spam-Level: * Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov wrote: | I've sent a list of (mostly) editorial issues to Randy and Cyrus and they | got addressed by the latest revision. | But one question still remains. Cyrus has asked me to forward it to the | mailing list: | | Section "8.9 ANNOTATION Key in SORT" | | > ANNOTATION | > > The ANNOTATION criterion for the SORT command [SORT] instructs the | > server to return the message numbers or UIDs of a mailbox, sorted | > using the values of the specified annotations. The ANNOTATION | > criterion is available if the server returns both "ANNOTATE" and | > "SORT" as supported capabilities in the CAPABILITY command response. | | I really don't like when new functionality is required if two other | extensions are implemented. | If somebody implements ANNOTATE in a server first and than adds SORT | support, it is very easy to miss this bit. Unfortunately I've seen | several documents already that do this. So I would recommend new | capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE | document). I am just worried about the possibility of combinatorial explosion of capabilities as a result of this. However, I agree it is easy to overlook interactions like this. So as an alternative, how about requiring IMAP extension documents (new ones and revisions to old ones) to include an 'Implementation Considerations' section that explicitly tells implementers to take into account the interaction of the new extension with any existing ones supported, or other new ones being added at the same time. That reminder in the document may suffice. It might also be useful to have an informational document that gets updated at regular intervals that summarizes all existing extensions and describes the dependencies between each of them. That could be part of a revised implementation guide or a separate document. -- 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 i3PEUmiM028848; Sun, 25 Apr 2004 07:30: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 i3PEUmuY028846; Sun, 25 Apr 2004 07:30: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 i3PEUf90028818 for ; Sun, 25 Apr 2004 07:30:48 -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, 25 Apr 2004 15:30:31 +0100 Message-ID: <408AEB3C.3080804@isode.com> Date: Sat, 24 Apr 2004 23:33:32 +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: Alexey Melnikov wrote: > 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. The relevant ABNF bit would be: referral_data = "REFERRAL" SP "(" urlstring *(SP urlstring) ")" urlstring = <"> url <"> ; See [RFC-1738] for definition It seems that the current ABNF can't cope with this ("referral_data" (if taken in ()) should match "mbox-list-extended-item"): 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 Anyway, no matter whether people think that REFERRAL belongs to the LISTEXT extension or not, I would like to change LISTEXT ABNF for additional LIST data to allow sending REFERRAL response as suggested above. Any objections? 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 i3PEUmZF028847; Sun, 25 Apr 2004 07:30: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 i3PEUmbR028845; Sun, 25 Apr 2004 07:30: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 i3PEUf8x028818 for ; Sun, 25 Apr 2004 07:30:46 -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, 25 Apr 2004 15:30:31 +0100 Message-ID: <408AE9D5.1030309@isode.com> Date: Sat, 24 Apr 2004 23:27: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: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> <2147483647.1081854599@ninevah.cyrusoft.com> In-Reply-To: <2147483647.1081854599@ninevah.cyrusoft.com> Content-Type: multipart/alternative; boundary="------------020404000502090201040907" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------020404000502090201040907 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Alexey, > > --On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov > wrote: > > |> I believe REFERRAL, as envisioned by Larry is designed for clusters > |> like the Cyrus Murder so that a referral capable client can determine > |> which mailboxes are located on a different server(s) w/o having to > |> attempt a SELECT and wait for the referral to get the location of the > |> mailbox. > | > | That was my idea as well. > > That's fine but trying to indicate rename's is going to be too > complicated. Perhaps you can write up a more detailed account of > exactly what REFERRAL is supposed to do, then maybe I will understand > the issues better... Ok, I will try to give several examples to demonstrate how the server works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a bit lengthy, but I hope this will clarify some things. I will use the following list of local mailboxes: C: A01 LIST "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done And let's assume there are two remote mailboxes visible locally (i.e. they are part of LIST (REMOTE) output) as "Bread" and "Meat". Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and "Tofu" was renamed to "SoyProducts/Tofu". And finally, let's assume that the name of the IMAP server is "imap.example.com". In all cases below assume that the client is a disconnected client. An online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE REFERRAL). Let's also assume that the client wants to synchronize the following mailboxes: "inbox", "Fruit/Apple", "Fruit/Banana", "Tofu". Scenario 1). LISTEXT-unaware client that doesn't care about remote mailboxes: C: A01 LIST "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done (case a - the client is a disconnected client that doesn't support remote mailboxes or referrals). As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local cache for those mailboxes and the changes would be lost. (case b - same as case a, but it also supports MAILBOX-REFERRAL). If the client (and the server) also supports MAILBOX-REFERRAL, before blowing away its cache it will try to select each of those mailboxes in a hope of figuring out if they were actually renamed: C: A02 SELECT "Fruit/Apple" S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/Fruit/Orange] Renamed mailbox. C: A03 SELECT "Fruit/Orange" ...synchronization... C: A12 SELECT "Tofu" S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu] Renamed mailbox. C: A13 SELECT "SoyProducts/Tofu" ...synchronization... Synchronization of "inbox" and "Fruit/Banana" proceeds as usual: C: A22 SELECT "Fruit/Banana" ...synchronization... Scenario 2). LISTEXT-aware client that doesn't care about remote mailboxes and doesn't support referrals: This is very much the same as scenario 1a). C: A01 LIST () "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: A01 OK done As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local changes to those mailboxes. Scenario 3). LISTEXT-aware client that doesn't care about remote mailboxes, but supports referrals. C: A01 LIST (REFERRAL) "" "*" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange") S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu") S: A01 OK done The referral aware client will be able to synchronize changes even if some mailboxes are renamed (assuming the server is also able to report this information). In addition, two unnecessary SELECT commands are eliminated and the client can proceed with mailbox synchronization for the renamed mailboxes: C: A02 SELECT "Fruit/Orange" ...synchronization... C: A12 SELECT "SoyProducts/Tofu" ...synchronization... (Note, that the server is not allowed to return remote mailboxes when just REFERRAL is requested, the client doesn't even have to match the server name in URLs with the local IMAP server name). Further synchronization proceeds as usual. Scenario 4). LISTEXT-aware client that supports both referrals and remote mailboxes. C: A01 LIST (REMOTE REFERRAL) "" "%" S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit/Orange" S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange") S: * LIST () "/" "SoyProducts/Tofu" S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable/Broccoli" S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu") S: * LIST () "/" "Bread" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap1.example.com/Bread")) S: * LIST () "/" "Meat" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap.example.com/Meat" "IMAP://user;AUTH=*@other-imap2.example.com/SharedFolders/Meat")) S: A01 OK done The client knows that "imap.example.com" is the name of the IMAP server the client is connected to, so it will be able to figure out that "Bread" and "Meat" are located on a different server(s). The client should also be able to synchronize with a mailbox moved across servers. Alexey --------------020404000502090201040907 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cyrus Daboo wrote:
Hi Alexey,

--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov <Alexey.Melnikov@isode.com> wrote:

|> I believe REFERRAL, as envisioned by Larry is designed for clusters
|> like the Cyrus Murder so that a referral capable client can determine
|> which mailboxes are located on a different server(s) w/o having to
|> attempt a SELECT and wait for the referral to get the location of the
|> mailbox.
|
| That was my idea as well.

That's fine but trying to indicate rename's is going to be too complicated. Perhaps you can write up a more detailed account of exactly what REFERRAL is supposed to do, then maybe I will understand the issues better...
Ok, I will try to give several examples to demonstrate how the server works for LIST (), LIST (REFERRAL) and LIST (REFERRAL REMOTE). This is a bit lengthy, but I hope this will clarify some things.

I will use the following list of local mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Apple"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

And let's assume there are two remote mailboxes visible locally (i.e. they are part of LIST (REMOTE) output) as "Bread" and "Meat".
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and "Tofu" was renamed to "SoyProducts/Tofu".
And finally, let's assume that the name of the IMAP server is "imap.example.com".

In all cases below assume that the client is a disconnected client. An online client would unlikely to use LIST (REFERRAL) or LIST (REMOTE REFERRAL).
Let's also assume that the client wants to synchronize the following mailboxes: "inbox", "Fruit/Apple", "Fruit/Banana", "Tofu".

Scenario 1). LISTEXT-unaware client that doesn't care about remote mailboxes:

       C: A01 LIST "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

(case a - the client is a disconnected client that doesn't support remote mailboxes or referrals).

As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local cache for those mailboxes and the changes would be lost.

(case b - same as case a, but it also supports MAILBOX-REFERRAL).

If the client (and the server) also supports MAILBOX-REFERRAL, before blowing away its cache it will try to select each of those mailboxes in a hope of figuring out if they were actually renamed:

      C: A02 SELECT "Fruit/Apple"
      S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/Fruit/Orange] Renamed mailbox.

      C: A03 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "Tofu"
      S: A02 NO [REFERRAL IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu] Renamed mailbox.

      C: A13 SELECT "SoyProducts/Tofu"
       ...synchronization...

Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:

      C: A22 SELECT "Fruit/Banana"
       ...synchronization...

Scenario 2). LISTEXT-aware client that doesn't care about remote mailboxes and doesn't support referrals:

This is very much the same as scenario 1a).

       C: A01 LIST () "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: A01 OK done

As in scenario 1a: the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the resulting output, it will blow away local changes to those mailboxes.

Scenario 3). LISTEXT-aware client that doesn't care about remote mailboxes, but supports referrals.

       C: A01 LIST (REFERRAL) "" "*"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange")
       S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")
       S: A01 OK done


The referral aware client will be able to synchronize changes even if some mailboxes are renamed (assuming the server is also able to report this information).
In addition, two unnecessary SELECT commands are eliminated and the client can proceed with mailbox synchronization for the renamed mailboxes:
      C: A02 SELECT "Fruit/Orange"
       ...synchronization...

      C: A12 SELECT "SoyProducts/Tofu"
       ...synchronization...

(Note, that the server is not allowed to return remote mailboxes when just REFERRAL is requested, the client doesn't even have to match
the server name in URLs with the local IMAP server name).

Further synchronization proceeds as usual.

Scenario 4). LISTEXT-aware client that supports both referrals and remote mailboxes.

       C: A01 LIST (REMOTE REFERRAL) "" "%"
       S: * LIST (\Marked \NoInferiors) "/" "inbox"
       S: * LIST () "/" "Fruit"
       S: * LIST () "/" "Fruit/Orange"
       S: * LIST () "/" "Fruit/Banana"
       S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/Fruit/Orange")
        S: * LIST () "/" "SoyProducts/Tofu"
       S: * LIST () "/" "Vegetable"
       S: * LIST () "/" "Vegetable/Broccoli"
       S: * LIST () "/" "Tofu" ("REFERRAL" "IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")
       S: * LIST () "/" "Bread" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap1.example.com/Bread"))
       S: * LIST () "/" "Meat" ("REFERRAL" ("IMAP://user;AUTH=*@other-imap.example.com/Meat" "IMAP://user;AUTH=*@other-imap2.example.com/SharedFolders/Meat"))
       S: A01 OK done

The client knows that "imap.example.com" is the name of the IMAP server the client is connected to, so it will be able to figure out that "Bread" and "Meat" are located on a different server(s).  The client should also be able to synchronize with a mailbox moved across servers.

Alexey

 --------------020404000502090201040907-- 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 i3PEUkiC028828; Sun, 25 Apr 2004 07:30: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 i3PEUkG5028827; Sun, 25 Apr 2004 07:30: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 i3PEUf8w028818 for ; Sun, 25 Apr 2004 07:30:46 -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, 25 Apr 2004 15:30:27 +0100 Message-ID: <408AC98B.2080504@isode.com> Date: Sat, 24 Apr 2004 21:09:47 +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 CC: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-annotate-09.txt References: <200404201951.PAA18183@ietf.org> In-Reply-To: <200404201951.PAA18183@ietf.org> 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 sent a list of (mostly) editorial issues to Randy and Cyrus and they got addressed by the latest revision. But one question still remains. Cyrus has asked me to forward it to the mailing list: Section "8.9 ANNOTATION Key in SORT" > ANNOTATION > > The ANNOTATION criterion for the SORT command [SORT] instructs the > server to return the message numbers or UIDs of a mailbox, sorted > using the values of the specified annotations. The ANNOTATION > criterion is available if the server returns both "ANNOTATE" and > "SORT" as supported capabilities in the CAPABILITY command response. I really don't like when new functionality is required if two other extensions are implemented. If somebody implements ANNOTATE in a server first and than adds SORT support, it is very easy to miss this bit. Unfortunately I've seen several documents already that do this. So I would recommend new capability SORT=ANNOTATE for this (same as SORT=MODSEQ in the CONDSTORE document). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3KJpd9F011827; Tue, 20 Apr 2004 12:51: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 i3KJpdGF011826; Tue, 20 Apr 2004 12:51:39 -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.8) with ESMTP id i3KJpcRF011819 for ; Tue, 20 Apr 2004 12:51:39 -0700 (PDT) (envelope-from rbunch@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 PAA18183; Tue, 20 Apr 2004 15:51:41 -0400 (EDT) Message-Id: <200404201951.PAA18183@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-annotate-09.txt Date: Tue, 20 Apr 2004 15:51:41 -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 : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-09.txt Pages : 26 Date : 2004-4-20 The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain 'metadata' for messages stored in an IMAP4 mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-09.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-annotate-09.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-annotate-09.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-4-20160809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-20160809.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.8) with ESMTP id i3EFn9Tv005291; Wed, 14 Apr 2004 08:49:09 -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 i3EFn8r2005290; Wed, 14 Apr 2004 08:49:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3EFn7vd005271 for ; Wed, 14 Apr 2004 08:49:07 -0700 (PDT) (envelope-from leiba@watson.ibm.com) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i3EFn5q32382 for ; Wed, 14 Apr 2004 11:49:05 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i3EFn4O56074 for ; Wed, 14 Apr 2004 11:49:04 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with SMTP id i3EFn3x54398 for ; Wed, 14 Apr 2004 11:49:03 -0400 Message-ID: <003201c42238$032759c0$40280209@watson.ibm.com> From: "Barry Leiba" To: "IMAP extensions Mailing List" References: <407955E1.90005@isode.com> <407AD059.2000109@isode.com> Subject: Re: Collected issues with LISTEXT Date: Wed, 14 Apr 2004 11:49:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I think this is the case for LISTEXT as written now. I.e. unless the client > specified LIST (CHILDREN), the server is not required to return \HasChildren > or \HasNoChildren. Yes, Alexey is correct that this was the intent of LISTEXT. > I don't care either way. I can live with mandatory-to-implement children > functionality as long as it is not mandatory-to-execute. And that was the point, and Mark's objection is the reason it was written that way. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DF9xCT048327; Tue, 13 Apr 2004 08:09: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 i3DF9xdG048326; Tue, 13 Apr 2004 08:09: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.8) with ESMTP id i3DF9xg7048320 for ; Tue, 13 Apr 2004 08:09: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 i3DExPme005284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2004 10:59:26 -0400 Date: Tue, 13 Apr 2004 11:09:59 -0400 From: Cyrus Daboo To: Alexey Melnikov , Ken Murchison cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT Message-ID: <2147483647.1081854599@ninevah.cyrusoft.com> In-Reply-To: <407BB975.7000808@isode.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> <407BB975.7000808@isode.com> X-Mailer: Mulberry/3.1.2 (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, April 13, 2004 10:57 AM +0100 Alexey Melnikov wrote: |> I believe REFERRAL, as envisioned by Larry is designed for clusters |> like the Cyrus Murder so that a referral capable client can determine |> which mailboxes are located on a different server(s) w/o having to |> attempt a SELECT and wait for the referral to get the location of the |> mailbox. | | That was my idea as well. That's fine but trying to indicate rename's is going to be too complicated. Perhaps you can write up a more detailed account of exactly what REFERRAL is supposed to do, then maybe I will understand the issues better... -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3DA0hGG025743; Tue, 13 Apr 2004 03:00:43 -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 i3DA0hsh025742; Tue, 13 Apr 2004 03:00:43 -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.8) with ESMTP id i3DA0gU6025735 for ; Tue, 13 Apr 2004 03:00:42 -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, 13 Apr 2004 11:00:01 +0100 Message-ID: <407BBA1E.6080201@isode.com> Date: Tue, 13 Apr 2004 10:59:58 +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: Philip Guenther CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> In-Reply-To: <200404121937.i3CJbRHe067636@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: Philip Guenther wrote: >>> b) actually, wouldn't the "* NO [REFERRAL ....]" response be good >>> enough for them? >>> >>> >>This will work, but the client will have to SELECT each one of them in >>order to find out. A LIST will return this information in one go. >> >> > >Doesn't a disconnected client normally SELECT each synchronized >mailbox whenever it connects so that it can pull down updates from >the server? How often is a client *only* interested in whether the >mailbox was renamed (or deleted) and no in whether its contents >changed? > The client is not interested in selecting the old name, it will select the new one (target of the referral). LIST (REFERRAL) will give this information. >>> (Oh, and they're going to have a fun time synchronizing, given that >>> the UIDVALIDITY on the mailbox was probably changed by the RENAME...) >>> >>> >>RENAME is required to preserve UIDVALIDITY. >> >> > >That certainly isn't in rfc3501. If a server can give two mailboxes >the same UIDVALIDITY then it's possible to set up a situation where >RENAME MUST change the UIDVALIDITY of the renamed mailbox: > let TARG and SRC be mailboxes with the same UIDVALIDITY > a1 RENAME TARG SOMETHING-ELSE > a2 RENAME SRC TARG > that second RENAME can't preserve TARG's UIDVALIDITY across the > rename without violating the last item in section 2.3.1.1 > >This was discussed here at some point and led to some discussion >of a possible NEW-UIDVALIDITY response code for telling clients >that the UIDVALIDITY on a mailbox changed during a RENAME without >actually altering UIDs. > Ok, I remember about this case ;-), however it is less common in real life. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D9vRg0025567; Tue, 13 Apr 2004 02:57:27 -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 i3D9vR4m025566; Tue, 13 Apr 2004 02:57:27 -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.8) with ESMTP id i3D9vQvY025560 for ; Tue, 13 Apr 2004 02:57:27 -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, 13 Apr 2004 10:57:12 +0100 Message-ID: <407BB975.7000808@isode.com> Date: Tue, 13 Apr 2004 10:57: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: Ken Murchison CC: Cyrus Daboo , IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> <407B3914.5000101@oceana.com> In-Reply-To: <407B3914.5000101@oceana.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: Ken Murchison wrote: > Cyrus Daboo wrote: > >> It seems to me that the REFERRAL is an attempt to implement some kind >> of mailbox list synchronisation feature to allow disconnected clients >> to sync there mailbox state with the server - if that is not the >> intent than can Alexey explain in more detail what its supposed to >> do. What was proposed by Alexey is not sufficient to do mailbox list >> sync properly. I think REFERRAL should not be implemented in LISTEXT >> right now. Instead, if there is demand, a proper mailbox list sync >> extension (that may or may not use LISTEXT) should be designed to do >> the job properly. I suspect that some form of mailbox UID, globally >> unique across the server's mailstore, will be the best way to do that >> so that clients and servers can use the MUIDs to sync up their lists. >> However this is out of scope for LISTEXT and imapext right now. > > I believe REFERRAL, as envisioned by Larry is designed for clusters > like the Cyrus Murder so that a referral capable client can determine > which mailboxes are located on a different server(s) w/o having to > attempt a SELECT and wait for the referral to get the location of the > mailbox. That was my idea as well. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0nQbN082206; Mon, 12 Apr 2004 17:49: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 i3D0nQBc082205; Mon, 12 Apr 2004 17:49:26 -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 ([208.17.123.12]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3D0nPOH082184 for ; Mon, 12 Apr 2004 17:49:25 -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 i3D0nN7D017952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Apr 2004 20:49:24 -0400 (EDT) Message-ID: <407B3914.5000101@oceana.com> Date: Mon, 12 Apr 2004 20:49:24 -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: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> <9560000.1081803699@ninevah.cyrusoft.com> In-Reply-To: <9560000.1081803699@ninevah.cyrusoft.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: Cyrus Daboo wrote: > It seems to me that the REFERRAL is an attempt to implement some kind of > mailbox list synchronisation feature to allow disconnected clients to > sync there mailbox state with the server - if that is not the intent > than can Alexey explain in more detail what its supposed to do. What was > proposed by Alexey is not sufficient to do mailbox list sync properly. I > think REFERRAL should not be implemented in LISTEXT right now. Instead, > if there is demand, a proper mailbox list sync extension (that may or > may not use LISTEXT) should be designed to do the job properly. I > suspect that some form of mailbox UID, globally unique across the > server's mailstore, will be the best way to do that so that clients and > servers can use the MUIDs to sync up their lists. However this is out of > scope for LISTEXT and imapext right now. I believe REFERRAL, as envisioned by Larry is designed for clusters like the Cyrus Murder so that a referral capable client can determine which mailboxes are located on a different server(s) w/o having to attempt a SELECT and wait for the referral to get the location of the mailbox. -- 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.8) with ESMTP id i3CL1WNS050445; Mon, 12 Apr 2004 14:01: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 i3CL1WIh050444; Mon, 12 Apr 2004 14:01:32 -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.8) with ESMTP id i3CL1Vrq050438 for ; Mon, 12 Apr 2004 14:01:31 -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 i3CKp6me018243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2004 16:51:07 -0400 Date: Mon, 12 Apr 2004 17:01:39 -0400 From: Cyrus Daboo To: Philip Guenther , Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT Message-ID: <9560000.1081803699@ninevah.cyrusoft.com> In-Reply-To: <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> X-Mailer: Mulberry/3.1.2 (Linux/PPC) 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 Philip, --On Monday, April 12, 2004 12:37:27 PM -0700 Philip Guenther wrote: |> This will work, but the client will have to SELECT each one of them in |> order to find out. A LIST will return this information in one go. | | Doesn't a disconnected client normally SELECT each synchronized | mailbox whenever it connects so that it can pull down updates from | the server? How often is a client *only* interested in whether the | mailbox was renamed (or deleted) and no in whether its contents | changed? | | |>> (Oh, and they're going to have a fun time synchronizing, given that |>> the UIDVALIDITY on the mailbox was probably changed by the RENAME...) |>> |> RENAME is required to preserve UIDVALIDITY. | | That certainly isn't in rfc3501. If a server can give two mailboxes | the same UIDVALIDITY then it's possible to set up a situation where | RENAME MUST change the UIDVALIDITY of the renamed mailbox: | let TARG and SRC be mailboxes with the same UIDVALIDITY | a1 RENAME TARG SOMETHING-ELSE | a2 RENAME SRC TARG | that second RENAME can't preserve TARG's UIDVALIDITY across the | rename without violating the last item in section 2.3.1.1 | | This was discussed here at some point and led to some discussion | of a possible NEW-UIDVALIDITY response code for telling clients | that the UIDVALIDITY on a mailbox changed during a RENAME without | actually altering UIDs. | | | ... |>> It's never been entirely clear to me how mailbox referrals (in the |>> rfc2193 sense) were intended to be presented by clients. While I'm not |>> a client implementor and therefore don't *need* an answer to that, it |>> does seem to bear on whether it's wise to reuse the same mechanism for |>> the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. |>> When a client that displays the mailbox hierarchy in some form gets back |>> a referral response, should it use the referral to the alter/update the |>> display or should it hide the indirection from the end user? |>> |> It depends. Some clients allow to configure different choices, like |> "resolve referrals automatically", "don't show referrals", etc. Other |> will show a different icon in a mailbox tree. The user has to double |> click on the icon to resolve it. I don't think there is a single right |> answer to this question. | | So some clients or users may choose to handle them differently then | they would handle a "mailbox rename" REFERRAL? How is a client | supposed to tell apart "rename" and "remote" REFERRALs, given that | the server may have a different idea than the client of what the | server's hostname is? Is the server required to use relative IMAP | URLs for "rename" REFERRALs? It seems to me that the REFERRAL is an attempt to implement some kind of mailbox list synchronisation feature to allow disconnected clients to sync there mailbox state with the server - if that is not the intent than can Alexey explain in more detail what its supposed to do. What was proposed by Alexey is not sufficient to do mailbox list sync properly. I think REFERRAL should not be implemented in LISTEXT right now. Instead, if there is demand, a proper mailbox list sync extension (that may or may not use LISTEXT) should be designed to do the job properly. I suspect that some form of mailbox UID, globally unique across the server's mailstore, will be the best way to do that so that clients and servers can use the MUIDs to sync up their lists. However this is out of scope for LISTEXT and imapext right now. -- Cyrus Daboo Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJbQh6038890; Mon, 12 Apr 2004 12:37: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 i3CJbQoa038889; Mon, 12 Apr 2004 12:37:26 -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.8) with ESMTP id i3CJbQKo038883 for ; Mon, 12 Apr 2004 12:37:26 -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 i3CJbUOx003430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 12:37:30 -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 i3CJbUfZ028479 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 12:37:30 -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 i3CJbRHe067636; Mon, 12 Apr 2004 12:37:30 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200404121937.i3CJbRHe067636@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT In-reply-to: <407AE741.4060900@isode.com> References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> <407AE741.4060900@isode.com> Date: Mon, 12 Apr 2004 12:37:27 -0700 From: Philip Guenther Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: >Philip Guenther wrote: >>Alexey Melnikov writes: ... >>So this is suggesting that LIST (REFERRAL) would show all the matching >>mailboxes that either ... >>b) currently exist as a referral to another server, or > >No, b) is only returned for LIST (REFERRAL REMOTE) Ah, okay. ... >>- what's a client supposed to do with a "renamed" referral anyway? If >> it's for synchronization of disconnected clients then >> >yes. >> b) actually, wouldn't the "* NO [REFERRAL ....]" response be good >> enough for them? >> >This will work, but the client will have to SELECT each one of them in >order to find out. A LIST will return this information in one go. Doesn't a disconnected client normally SELECT each synchronized mailbox whenever it connects so that it can pull down updates from the server? How often is a client *only* interested in whether the mailbox was renamed (or deleted) and no in whether its contents changed? >> (Oh, and they're going to have a fun time synchronizing, given that >> the UIDVALIDITY on the mailbox was probably changed by the RENAME...) >> >RENAME is required to preserve UIDVALIDITY. That certainly isn't in rfc3501. If a server can give two mailboxes the same UIDVALIDITY then it's possible to set up a situation where RENAME MUST change the UIDVALIDITY of the renamed mailbox: let TARG and SRC be mailboxes with the same UIDVALIDITY a1 RENAME TARG SOMETHING-ELSE a2 RENAME SRC TARG that second RENAME can't preserve TARG's UIDVALIDITY across the rename without violating the last item in section 2.3.1.1 This was discussed here at some point and led to some discussion of a possible NEW-UIDVALIDITY response code for telling clients that the UIDVALIDITY on a mailbox changed during a RENAME without actually altering UIDs. ... >>It's never been entirely clear to me how mailbox referrals (in the >>rfc2193 sense) were intended to be presented by clients. While I'm not >>a client implementor and therefore don't *need* an answer to that, it >>does seem to bear on whether it's wise to reuse the same mechanism for >>the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. >>When a client that displays the mailbox hierarchy in some form gets back >>a referral response, should it use the referral to the alter/update the >>display or should it hide the indirection from the end user? >> >It depends. Some clients allow to configure different choices, like >"resolve referrals automatically", "don't show referrals", etc. Other >will show a different icon in a mailbox tree. The user has to double >click on the icon to resolve it. I don't think there is a single right >answer to this question. So some clients or users may choose to handle them differently then they would handle a "mailbox rename" REFERRAL? How is a client supposed to tell apart "rename" and "remote" REFERRALs, given that the server may have a different idea than the client of what the server's hostname is? Is the server required to use relative IMAP URLs for "rename" REFERRALs? Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CJWfE2037945; Mon, 12 Apr 2004 12:32:41 -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 i3CJWfcv037944; Mon, 12 Apr 2004 12:32:41 -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.8) with ESMTP id i3CJWeXp037926 for ; Mon, 12 Apr 2004 12:32:40 -0700 (PDT) (envelope-from rbunch@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 PAA08786; Mon, 12 Apr 2004 15:32:42 -0400 (EDT) Message-Id: <200404121932.PAA08786@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-05.txt Date: Mon, 12 Apr 2004 15:32:42 -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-05.txt Pages : 8 Date : 2004-4-12 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-05.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-05.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-05.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-4-12155018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-list-extensions-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-list-extensions-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-12155018.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.8) with ESMTP id i3CJ0NZX033983; Mon, 12 Apr 2004 12:00: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 i3CJ0NeC033982; Mon, 12 Apr 2004 12:00:23 -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.8) with ESMTP id i3CJ0Lke033964 for ; Mon, 12 Apr 2004 12:00:22 -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; Mon, 12 Apr 2004 20:00:20 +0100 Message-ID: <407AE741.4060900@isode.com> Date: Mon, 12 Apr 2004 20:00:17 +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: Philip Guenther CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@isode.com> <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> In-Reply-To: <200404120815.i3C8FlHe032260@lab.smi.sendmail.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: Philip Guenther wrote: >Alexey Melnikov writes: >... > > >>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. >> >> > >So this is suggesting that LIST (REFERRAL) would show all the matching >mailboxes that either >a) currently exist locally, or > > Yes. >b) currently exist as a referral to another server, or > > No, b) is only returned for LIST (REFERRAL REMOTE) >c) did exist and were renamed > > Yes. >with support for the mechanisms behind (b) and (c) being optional? > Yes (c) is optional) >Item (c) seems really weird, such that I simultaneously have doubts >about its usefulness, the ambiguity it creates, the clutter it will add >to listing, and the possibly security implications. > >In reverse order: >- what ACL controls whether you can see the referral for a mailbox that > was renamed: the ACL on the new name or the ACL on the name at the > time of the rename? Is there any way to control that visibility > independent of the visibility of the current name? > > That is is a good question and I have to think about this :-). >- is there any way to get rid of a "renamed" referral beyond, say, > creating and deleting a new mailbox under that name, a method that has > an obvious race condition with someone really trying to create the > name? > (New DoS attack: repeatedly rename a publicly visible folder, so that > tag LIST (REFERRAL) "" * > returns a few thousand "renamed" entries) > > I haven't thought about doing this through the IMAP, but an implementation may "expire" local referrals after some time. >- will "renamed" referrals be flagged differently than "true" referrals > No, I can't see how is this different. "renamed" referral is a referral that points to the same server. > and normal mailboxes in the listing? > Yes. Normal mailboxes will not have "("REFERRAL" ...)" part in the corresponding untagged LIST response. > If not, then you have a list of > mailboxes that may or may not currently exist, which seems less than > completely useful. > >- what's a client supposed to do with a "renamed" referral anyway? If > it's for synchronization of disconnected clients then > yes. > a) that's a pretty narrow target audience; wouldn't a narrow "renamed > only" list extension be more useful for them? > > If you don't want them, don't specify REFERRAL option in LIST. > b) actually, wouldn't the "* NO [REFERRAL ....]" response be good > enough for them? > This will work, but the client will have to SELECT each one of them in order to find out. A LIST will return this information in one go. > (Oh, and they're going to have a fun time synchronizing, given that > the UIDVALIDITY on the mailbox was probably changed by the RENAME...) > RENAME is required to preserve UIDVALIDITY. > >Indeed, several of those also apply to the original NEWNAME response and >the alluded to use of REFERRAL responses in NEWNAME's place. Can anyone >explain to me what NEWNAME was supposed to be used for and how any >existing (or pre-3501) clients react to it? Without an understanding of >the problem being solved, I don't know whether LIST (REFERRAL) is >necessary or useful in solving it. > > >While I'm on the subject... > >It's never been entirely clear to me how mailbox referrals (in the >rfc2193 sense) were intended to be presented by clients. While I'm not >a client implementor and therefore don't *need* an answer to that, it >does seem to bear on whether it's wise to reuse the same mechanism for >the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. >When a client that displays the mailbox hierarchy in some form gets back >a referral response, should it use the referral to the alter/update the >display or should it hide the indirection from the end user? > It depends. Some clients allow to configure different choices, like "resolve referrals automatically", "don't show referrals", etc. Other will show a different icon in a mailbox tree. The user has to double click on the icon to resolve it. I don't think there is a single right answer to this question. > For >example, should the user selecting a mailbox in a hierarchy display >result in a 'reparenting' of the selected mailbox if the original server >returned a referral specifying another server, or should it simply chase >the reference and display the folder in place? > > >>Related to this: do a revision of RFC 2193 that is using LISTEXT >>framework (in particular obsolete RLIST/RLSUB). >> >> > >It would be nice to clarify such points as whether a remote referral may >have a different path than the local name, what ACL controls the >visibility of a remote referrals (does it depend on the command? Does >the referral have an ACL distinct from the target mailbox?), > I think this is related to one of the questions above, so I will think about this as well. > and what >section 4.2 means when it says "...because a home server is required to >maintain a listing of referred remote mailboxes..." > > > Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHjADL025116; Mon, 12 Apr 2004 10:45: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 i3CHjA3R025115; Mon, 12 Apr 2004 10:45:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3CHjAxP025109 for ; Mon, 12 Apr 2004 10:45:10 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3CHjDIm032551; Mon, 12 Apr 2004 10:45:13 -0700 Received: from Shimo-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 i3CHj3Ba012688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Apr 2004 10:45:12 -0700 Date: Mon, 12 Apr 2004 10:45:05 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT In-Reply-To: <407AD059.2000109@isode.com> Message-ID: References: <407955E1.90005@isode.com> <407AD059.2000109@isode.com> 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, 12 Apr 2004, Alexey Melnikov wrote: > I think this is the case for LISTEXT as written now. I.e. unless the client > specified LIST (CHILDREN), the server is not required to return \HasChildren > or \HasNoChildren. This is fine with me. > Mark would you prefer a separate LIST-CHILDREN capability (as I currently > do), or can you live with the LISTEXT document as written? I don't care either way. I can live with mandatory-to-implement children functionality as long as it is not mandatory-to-execute. -- 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.8) with ESMTP id i3CHMwHB023039; Mon, 12 Apr 2004 10:22:58 -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 i3CHMw3J023038; Mon, 12 Apr 2004 10:22:58 -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.8) with ESMTP id i3CHMqWM023011 for ; Mon, 12 Apr 2004 10:22:57 -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; Mon, 12 Apr 2004 18:22:37 +0100 Message-ID: <407AD059.2000109@isode.com> Date: Mon, 12 Apr 2004 18:22: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: Mark Crispin CC: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT References: <407955E1.90005@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: Mark Crispin wrote: > On Sun, 11 Apr 2004, Alexey Melnikov wrote: > >> 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. > > > FWIW: > > I do not think that a server should be obligated to advertise children > unless a client explicitly says that it is interested in such > information. > > I do not think that mere use of LISTEXT instead of LIST suffices to > indicate such interest. Ok, is there anybody who will say "I will die if CHILDREN is not part of LISTEXT" :-)? > As a compromise, I'm agreeable to children support being mandatory in > LISTEXT without requiring a capability; but nevertheless a server > should not be required to do the work unless the client specifically > asks for children. I think this is the case for LISTEXT as written now. I.e. unless the client specified LIST (CHILDREN), the server is not required to return \HasChildren or \HasNoChildren. Mark would you prefer a separate LIST-CHILDREN capability (as I currently do), or can you live with the LISTEXT document as written? > Put another way, I consider RFC 3348 to be broken, since it: > 1) adds an unnecessary CHILDREN extension > 2) requires a server supporting children to do the work even for a > client that does not care. > > I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead > simply urged that it be Informational. However, the sooner we move > towards LISTEXT and declaring RFC 3348 an obsolete false start, the > better in my view. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3C8FvSa043041; Mon, 12 Apr 2004 01:15:57 -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 i3C8Fvv7043040; Mon, 12 Apr 2004 01:15:57 -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.8) with ESMTP id i3C8FsGo043000 for ; Mon, 12 Apr 2004 01:15:54 -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 i3C8Fq2x027110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 01:15:52 -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 i3C8FpTS024753 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 Apr 2004 01:15:51 -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 i3C8FlHe032260; Mon, 12 Apr 2004 01:15:51 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200404120815.i3C8FlHe032260@lab.smi.sendmail.com> To: Alexey Melnikov Cc: IMAP Extensions WG From: Philip Guenther Subject: Re: Collected issues with LISTEXT In-reply-to: <407955E1.90005@isode.com> References: <407955E1.90005@isode.com> Date: Mon, 12 Apr 2004 01:15:47 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >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. So this is suggesting that LIST (REFERRAL) would show all the matching mailboxes that either a) currently exist locally, or b) currently exist as a referral to another server, or c) did exist and were renamed with support for the mechanisms behind (b) and (c) being optional? Item (c) seems really weird, such that I simultaneously have doubts about its usefulness, the ambiguity it creates, the clutter it will add to listing, and the possibly security implications. In reverse order: - what ACL controls whether you can see the referral for a mailbox that was renamed: the ACL on the new name or the ACL on the name at the time of the rename? Is there any way to control that visibility independent of the visibility of the current name? - is there any way to get rid of a "renamed" referral beyond, say, creating and deleting a new mailbox under that name, a method that has an obvious race condition with someone really trying to create the name? (New DoS attack: repeatedly rename a publicly visible folder, so that tag LIST (REFERRAL) "" * returns a few thousand "renamed" entries) - will "renamed" referrals be flagged differently than "true" referrals and normal mailboxes in the listing? If not, then you have a list of mailboxes that may or may not currently exist, which seems less than completely useful. - what's a client supposed to do with a "renamed" referral anyway? If it's for synchronization of disconnected clients then a) that's a pretty narrow target audience; wouldn't a narrow "renamed only" list extension be more useful for them? b) actually, wouldn't the "* NO [REFERRAL ....]" response be good enough for them? (Oh, and they're going to have a fun time synchronizing, given that the UIDVALIDITY on the mailbox was probably changed by the RENAME...) Indeed, several of those also apply to the original NEWNAME response and the alluded to use of REFERRAL responses in NEWNAME's place. Can anyone explain to me what NEWNAME was supposed to be used for and how any existing (or pre-3501) clients react to it? Without an understanding of the problem being solved, I don't know whether LIST (REFERRAL) is necessary or useful in solving it. While I'm on the subject... It's never been entirely clear to me how mailbox referrals (in the rfc2193 sense) were intended to be presented by clients. While I'm not a client implementor and therefore don't *need* an answer to that, it does seem to bear on whether it's wise to reuse the same mechanism for the NEWNAME replacement as is used by the MAILBOX-REFERRALS extension. When a client that displays the mailbox hierarchy in some form gets back a referral response, should it use the referral to the alter/update the display or should it hide the indirection from the end user? For example, should the user selecting a mailbox in a hierarchy display result in a 'reparenting' of the selected mailbox if the original server returned a referral specifying another server, or should it simply chase the reference and display the folder in place? >Related to this: do a revision of RFC 2193 that is using LISTEXT >framework (in particular obsolete RLIST/RLSUB). It would be nice to clarify such points as whether a remote referral may have a different path than the local name, what ACL controls the visibility of a remote referrals (does it depend on the command? Does the referral have an ACL distinct from the target mailbox?), and what section 4.2 means when it says "...because a home server is required to maintain a listing of referred remote mailboxes..." Philip Guenther guenther@sendmail.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BHlUNL075462; Sun, 11 Apr 2004 10:47:30 -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 i3BHlUvE075461; Sun, 11 Apr 2004 10:47:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BHlTot075455 for ; Sun, 11 Apr 2004 10:47:29 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3BHlRfI014037; Sun, 11 Apr 2004 10:47:32 -0700 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.11+UW04.02/8.12.11+UW04.03) with ESMTP id i3BHlRk7021102; Sun, 11 Apr 2004 10:47:27 -0700 Date: Sun, 11 Apr 2004 10:47:27 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: Collected issues with LISTEXT In-Reply-To: <407955E1.90005@isode.com> Message-ID: References: <407955E1.90005@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 Sun, 11 Apr 2004, Alexey Melnikov wrote: > 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. FWIW: I do not think that a server should be obligated to advertise children unless a client explicitly says that it is interested in such information. I do not think that mere use of LISTEXT instead of LIST suffices to indicate such interest. As a compromise, I'm agreeable to children support being mandatory in LISTEXT without requiring a capability; but nevertheless a server should not be required to do the work unless the client specifically asks for children. Put another way, I consider RFC 3348 to be broken, since it: 1) adds an unnecessary CHILDREN extension 2) requires a server supporting children to do the work even for a client that does not care. I did not oppose RFC 3348, because LISTEXT wasn't ready, and instead simply urged that it be Informational. However, the sooner we move towards LISTEXT and declaring RFC 3348 an obsolete false start, the better in my view. -- 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.8) with ESMTP id i3BEuATv054123; Sun, 11 Apr 2004 07:56: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 i3BEuAsf054121; Sun, 11 Apr 2004 07:56:10 -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.8) with ESMTP id i3BEu90E054115 for ; Sun, 11 Apr 2004 07:56:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust245.tnt27.lnd4.gbr.da.uu.net [62.188.154.245]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Apr 2004 15:56:10 +0100 Message-ID: <40795C7C.1000503@isode.com> Date: Sun, 11 Apr 2004 15:55:56 +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: List of changes for LISTEXT revision 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: I've just submitted an updated revision of draft-ietf-imapext-list-extensions. It should be announced soon. Below is the list of editorial changes I've made: Abstract must not be numbered. Also found and fixed a wrong section reference. Added IPR and Full Copyright. Updated IMAP4rev1 reference. Fixed couple of typos. Reformatted ABNF section for readability. Split References into Normative and Informative. Changed LIST response example not to reference ACL to avoid confusion with ACL2 extension. Added proper acknowledgments, let me know if I've missed someone. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i3BEnwHd053294; Sun, 11 Apr 2004 07:49:58 -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 i3BEnwml053293; Sun, 11 Apr 2004 07:49:58 -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.8) with ESMTP id i3BEnvpn053279 for ; Sun, 11 Apr 2004 07:49:58 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust245.tnt27.lnd4.gbr.da.uu.net [62.188.154.245]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Apr 2004 15:49:53 +0100 Message-ID: <407955E1.90005@isode.com> Date: Sun, 11 Apr 2004 15:27:45 +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: Collected issues with LISTEXT 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: 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. (Related to this) Ken proposed: Using to detect LISTEXT extensions: . LIST () "" "" * LIST (SUBSCRIBED CHILDREN ACL2) "." "" 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. 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?) 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! 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. 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. 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). Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i38KK42F008055; Thu, 8 Apr 2004 13:20: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 i38KK41w008054; Thu, 8 Apr 2004 13:20:04 -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.8) with ESMTP id i38KK36B008048 for ; Thu, 8 Apr 2004 13:20:03 -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 QAA18427; Thu, 8 Apr 2004 16:20:06 -0400 (EDT) Message-Id: <200404082020.QAA18427@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-15.txt Date: Thu, 08 Apr 2004 16:20:05 -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-15.txt Pages : 0 Date : 2004-4-8 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-15.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-15.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-15.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-4-8164318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-8164318.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.8) with ESMTP id i37FWK72004100; Wed, 7 Apr 2004 08:32: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 i37FWK3j004099; Wed, 7 Apr 2004 08:32:20 -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.8) with ESMTP id i37FWJIH004093 for ; Wed, 7 Apr 2004 08:32:20 -0700 (PDT) (envelope-from rbunch@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 LAA03751; Wed, 7 Apr 2004 11:32:20 -0400 (EDT) Message-Id: <200404071532.LAA03751@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-01.txt Date: Wed, 07 Apr 2004 11:32:20 -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 Filename : draft-ietf-imapext-i18n-01.txt Pages : 17 Date : 2004-4-6 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-01.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-01.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-01.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-4-7110706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-i18n-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-i18n-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-7110706.I-D@ietf.org> --OtherAccess-- --NextPart--