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 <ietf-imapext@imc.org>; 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)" <Pine.LNX.4.60.0404281125170.17501@shiva0.cac.washington.edu>
To: Mark Crispin <mrc@cac.washington.edu>
Cc: Lisa Dusseault <lisa@osafoundation.org>, IMAP Extensions WG <ietf-imapext@imc.org>
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> <Pine.LNX.4.60.0404281125170.17501@shiva0.cac.washington.edu>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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" <ietf-imapext@imc.org>
From: "Presnick" <presnick@qualcomm.com>
Subject: Re: Msg reply
Message-ID: <odwgfslsytnrcubvbvb@imc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------fxqeqassmcqwleoenfgb"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

----------fxqeqassmcqwleoenfgb
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
  

<br>
</body></html>

----------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 <ietf-imapext@imc.org>; 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 <mrc@CAC.Washington.EDU>
To: Lisa Dusseault <lisa@osafoundation.org>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: No editor for draft-ietf-imapext-i18n
In-Reply-To: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org>
Message-ID: <Pine.LNX.4.60.0404281125170.17501@shiva0.cac.washington.edu>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; Wed, 28 Apr 2004 11:11:40 -0700 (PDT) (envelope-from lisa@osafoundation.org)
X-Envelope-From: lisa@osafoundation.org
X-Envelope-To: <ietf-imapext@imc.org>
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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>
From: Lisa Dusseault <lisa@osafoundation.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
> <Alexey.Melnikov@isode.com> 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 <Alexey.Melnikov@isode.com>
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 <phoffman@imc.org>
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> <p06100506bcb1a1e2ee94@[63.202.92.148]>
In-Reply-To: <p06100506bcb1a1e2ee94@[63.202.92.148]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Hi Alexey,
>>
>> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
>> <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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: <p06100506bcb1a1e2ee94@[63.202.92.148]>
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 <phoffman@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: ietf-imapext@imc.org, Paul Hoffman <phoffman@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>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
> <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: ietf-imapext@imc.org, Paul Hoffman <phoffman@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Alexey,

--On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
<Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Alexey,

--On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
<Alexey.Melnikov@isode.com> 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: ietf-imapext@imc.org, Paul Hoffman <phoffman@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>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
> <Alexey.Melnikov@isode.com> 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 <entry-name> <attribute-name>
> |  > >   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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Alexey,

--On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
<Alexey.Melnikov@isode.com> 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 <entry-name> <attribute-name>
|  > >   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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <url> 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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 
> <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
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Cyrus Daboo wrote:<br>
<blockquote type="cite"
 cite="mid2147483647.1081854599@ninevah.cyrusoft.com">Hi Alexey, <br>
  <br>
--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov <a
 class="moz-txt-link-rfc2396E" href="mailto:Alexey.Melnikov@isode.com">&lt;Alexey.Melnikov@isode.com&gt;</a>
wrote: <br>
  <br>
|&gt; I believe REFERRAL, as envisioned by Larry is designed for
clusters <br>
|&gt; like the Cyrus Murder so that a referral capable client can
determine <br>
|&gt; which mailboxes are located on a different server(s) w/o having
to <br>
|&gt; attempt a SELECT and wait for the referral to get the location of
the <br>
|&gt; mailbox. <br>
| <br>
| That was my idea as well. <br>
  <br>
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...
</blockquote>
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.<br>
<br>
I will use the following list of local mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
And let's assume there are two remote mailboxes visible locally (i.e.
they are part of LIST (REMOTE) output) as "Bread" and "Meat".<br>
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and
"Tofu" was renamed to "SoyProducts/Tofu".<br>
And finally, let's assume that the name of the IMAP server is
"imap.example.com".<br>
<br>
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).<br>
<font color="#000000">Let's also assume that the client </font><font
 color="#000000">wants to
synchronize the following mailboxes: "inbox", "Fruit/Apple",
"Fruit/Banana", "Tofu".<br>
</font><br>
Scenario 1). LISTEXT-unaware client that doesn't care about remote
mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
(case a - the client is a disconnected client that doesn't support
remote mailboxes or referrals).<br>
<br>
As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the
resulting output, <b>it will blow away local cache for those </b><b>mailboxes
and the changes would be lost</b><b>.<br>
<br>
</b>(case b - same as case a, but it also supports MAILBOX-REFERRAL).<br>
<br>
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:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/Fruit/Orange">IMAP://user;AUTH=*@imap.example.com/Fruit/Orange</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A03 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A13 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A22 SELECT "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Scenario 2). LISTEXT-aware client that doesn't care about remote
mailboxes and doesn't support referrals:<br>
<br>
This is very much the same as scenario 1a).<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST () "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
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.<b><br>
</b><br>
Scenario 3). LISTEXT-aware client that doesn't care about remote
mailboxes, but supports referrals.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REFERRAL) "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/Fruit/Orange">IMAP://user;AUTH=*@imap.example.com/Fruit/Orange</a>")<br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")</a><br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<br>
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).<br>
In addition, two unnecessary SELECT commands are eliminated and the
client can proceed with mailbox synchronization for the renamed
mailboxes:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
(Note, that the server is not allowed to return remote mailboxes
when just REFERRAL is requested, the client doesn't even have to match<br>
the server name in URLs with the local IMAP server name).<br>
<br>
Further synchronization proceeds as usual.<br>
<br>
Scenario 4). LISTEXT-aware client that supports both referrals and
remote
mailboxes.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REMOTE REFERRAL) "" "%"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/Fruit/Orange">IMAP://user;AUTH=*@imap.example.com/Fruit/Orange</a>")<br>
</b>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")</a><br>
</b><font color="#33cc00">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Bread" ("REFERRAL"
(</font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@other-imap1.example.com/Bread"</a></b><font
 color="#33cc00">))<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Meat" ("REFERRAL" (</font><b>"<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@other-imap.example.com/Meat"</a></b><font
 color="#33cc00"> </font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@other-imap2.example.com/SharedFolders/Meat"</a></b><font
 color="#33cc00">))<br>
</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<font color="#000000">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).&nbsp; The
client should also be able to </font><font color="#000000">synchronize
with a mailbox moved across
servers.<br>
<br>
Alexey<br>
</font><b><font color="#33cc00"><br>
</font></b>
</body>
</html>

--------------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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <entry-name> <attribute-name>
 > >   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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>; Wed, 14 Apr 2004 11:49:03 -0400
Message-ID: <003201c42238$032759c0$40280209@watson.ibm.com>
From: "Barry Leiba" <leiba@watson.ibm.com>
To: "IMAP extensions Mailing List" <ietf-imapext@imc.org>
References: <407955E1.90005@isode.com> <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu> <407AD059.2000109@isode.com> <Pine.WNT.4.60.0404121044120.2828@Shimo-Tomobiki.Panda.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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>, Ken Murchison <ken@oceana.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

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...

-- 
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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <guenther@sendmail.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ken@oceana.com>
CC: Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <ken@oceana.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Philip Guenther <guenther@sendmail.com>, Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Philip,

--On Monday, April 12, 2004 12:37:27 PM -0700 Philip Guenther 
<guenther@sendmail.com> 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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
Cc: IMAP Extensions WG <ietf-imapext@imc.org>
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 <guenther@sendmail.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Alexey Melnikov <Alexey.Melnikov@isode.com> writes:
>Philip Guenther wrote:
>>Alexey Melnikov <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <guenther+imap@sendmail.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Philip Guenther wrote:

>Alexey Melnikov <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <MRC@CAC.Washington.EDU>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: Collected issues with LISTEXT
In-Reply-To: <407AD059.2000109@isode.com>
Message-ID: <Pine.WNT.4.60.0404121044120.2828@Shimo-Tomobiki.Panda.COM>
References: <407955E1.90005@isode.com> <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu> <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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <mrc@cac.washington.edu>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: Collected issues with LISTEXT
References: <407955E1.90005@isode.com> <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu>
In-Reply-To: <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
Cc: IMAP Extensions WG <ietf-imapext@imc.org>
From: Philip Guenther <guenther+imap@sendmail.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Alexey Melnikov <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <mrc@CAC.Washington.EDU>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: Collected issues with LISTEXT
In-Reply-To: <407955E1.90005@isode.com>
Message-ID: <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <LIST () "" ""> 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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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)" <Pine.LNX.4.60.0404281125170.17501@shiva0.cac.washington.edu>
To: Mark Crispin <mrc@cac.washington.edu>
Cc: Lisa Dusseault <lisa@osafoundation.org>, IMAP Extensions WG <ietf-imapext@imc.org>
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> <Pine.LNX.4.60.0404281125170.17501@shiva0.cac.washington.edu>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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" <ietf-imapext@imc.org>
From: "Presnick" <presnick@qualcomm.com>
Subject: Re: Msg reply
Message-ID: <odwgfslsytnrcubvbvb@imc.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------fxqeqassmcqwleoenfgb"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

----------fxqeqassmcqwleoenfgb
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
  

<br>
</body></html>

----------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 <ietf-imapext@imc.org>; 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 <mrc@CAC.Washington.EDU>
To: Lisa Dusseault <lisa@osafoundation.org>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: No editor for draft-ietf-imapext-i18n
In-Reply-To: <7A508AA2-993F-11D8-B566-000A95B2BB72@osafoundation.org>
Message-ID: <Pine.LNX.4.60.0404281125170.17501@shiva0.cac.washington.edu>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; Wed, 28 Apr 2004 11:11:40 -0700 (PDT) (envelope-from lisa@osafoundation.org)
X-Envelope-From: lisa@osafoundation.org
X-Envelope-To: <ietf-imapext@imc.org>
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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>
From: Lisa Dusseault <lisa@osafoundation.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
> <Alexey.Melnikov@isode.com> 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 <Alexey.Melnikov@isode.com>
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 <phoffman@imc.org>
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> <p06100506bcb1a1e2ee94@[63.202.92.148]>
In-Reply-To: <p06100506bcb1a1e2ee94@[63.202.92.148]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Hi Alexey,
>>
>> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
>> <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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: <p06100506bcb1a1e2ee94@[63.202.92.148]>
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 <phoffman@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: ietf-imapext@imc.org, Paul Hoffman <phoffman@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>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
> <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: ietf-imapext@imc.org, Paul Hoffman <phoffman@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Alexey,

--On Sunday, April 25, 2004 5:45 PM +0100 Alexey Melnikov 
<Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Alexey,

--On Saturday, April 24, 2004 11:27 PM +0100 Alexey Melnikov 
<Alexey.Melnikov@isode.com> 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: ietf-imapext@imc.org, Paul Hoffman <phoffman@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>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
> <Alexey.Melnikov@isode.com> 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 <entry-name> <attribute-name>
> |  > >   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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Alexey,

--On Saturday, April 24, 2004 9:09 PM +0100 Alexey Melnikov 
<Alexey.Melnikov@isode.com> 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 <entry-name> <attribute-name>
|  > >   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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <url> 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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 
> <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
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
Cyrus Daboo wrote:<br>
<blockquote type="cite"
 cite="mid2147483647.1081854599@ninevah.cyrusoft.com">Hi Alexey, <br>
  <br>
--On Tuesday, April 13, 2004 10:57 AM +0100 Alexey Melnikov <a
 class="moz-txt-link-rfc2396E" href="mailto:Alexey.Melnikov@isode.com">&lt;Alexey.Melnikov@isode.com&gt;</a>
wrote: <br>
  <br>
|&gt; I believe REFERRAL, as envisioned by Larry is designed for
clusters <br>
|&gt; like the Cyrus Murder so that a referral capable client can
determine <br>
|&gt; which mailboxes are located on a different server(s) w/o having
to <br>
|&gt; attempt a SELECT and wait for the referral to get the location of
the <br>
|&gt; mailbox. <br>
| <br>
| That was my idea as well. <br>
  <br>
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...
</blockquote>
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.<br>
<br>
I will use the following list of local mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
And let's assume there are two remote mailboxes visible locally (i.e.
they are part of LIST (REMOTE) output) as "Bread" and "Meat".<br>
Let's also assume that "Fruit/Apple" was renamed to "Fruit/Orange" and
"Tofu" was renamed to "SoyProducts/Tofu".<br>
And finally, let's assume that the name of the IMAP server is
"imap.example.com".<br>
<br>
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).<br>
<font color="#000000">Let's also assume that the client </font><font
 color="#000000">wants to
synchronize the following mailboxes: "inbox", "Fruit/Apple",
"Fruit/Banana", "Tofu".<br>
</font><br>
Scenario 1). LISTEXT-unaware client that doesn't care about remote
mailboxes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
(case a - the client is a disconnected client that doesn't support
remote mailboxes or referrals).<br>
<br>
As the client doesn't see mailboxes "Fruit/Apple" and "Tofu" in the
resulting output, <b>it will blow away local cache for those </b><b>mailboxes
and the changes would be lost</b><b>.<br>
<br>
</b>(case b - same as case a, but it also supports MAILBOX-REFERRAL).<br>
<br>
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:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Apple"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/Fruit/Orange">IMAP://user;AUTH=*@imap.example.com/Fruit/Orange</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A03 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A02 NO [REFERRAL
<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu</a>]
Renamed mailbox.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A13 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Synchronization of "inbox" and "Fruit/Banana" proceeds as usual:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A22 SELECT "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
Scenario 2). LISTEXT-aware client that doesn't care about remote
mailboxes and doesn't support referrals:<br>
<br>
This is very much the same as scenario 1a).<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST () "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
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.<b><br>
</b><br>
Scenario 3). LISTEXT-aware client that doesn't care about remote
mailboxes, but supports referrals.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REFERRAL) "" "*"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/Fruit/Orange">IMAP://user;AUTH=*@imap.example.com/Fruit/Orange</a>")<br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")</a><br>
</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<br>
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).<br>
In addition, two unnecessary SELECT commands are eliminated and the
client can proceed with mailbox synchronization for the renamed
mailboxes:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A02 SELECT "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A12 SELECT "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...synchronization...<br>
<br>
(Note, that the server is not allowed to return remote mailboxes
when just REFERRAL is requested, the client doesn't even have to match<br>
the server name in URLs with the local IMAP server name).<br>
<br>
Further synchronization proceeds as usual.<br>
<br>
Scenario 4). LISTEXT-aware client that supports both referrals and
remote
mailboxes.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; C: A01 LIST (REMOTE REFERRAL) "" "%"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST (\Marked \NoInferiors) "/" "inbox"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Orange"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Banana"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Fruit/Apple" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/Fruit/Orange">IMAP://user;AUTH=*@imap.example.com/Fruit/Orange</a>")<br>
</b>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "SoyProducts/Tofu"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable"<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Vegetable/Broccoli"<br>
<b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Tofu" ("REFERRAL" "<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu")</a><br>
</b><font color="#33cc00">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Bread" ("REFERRAL"
(</font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@other-imap1.example.com/Bread"</a></b><font
 color="#33cc00">))<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: * LIST () "/" "Meat" ("REFERRAL" (</font><b>"<a
 class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@other-imap.example.com/Meat"</a></b><font
 color="#33cc00"> </font><b>"<a class="moz-txt-link-abbreviated"
 href="mailto:IMAP://user;AUTH=*@imap.example.com/SoyProducts/Tofu">IMAP://user;AUTH=*@other-imap2.example.com/SharedFolders/Meat"</a></b><font
 color="#33cc00">))<br>
</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S: A01 OK done<br>
<br>
<font color="#000000">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).&nbsp; The
client should also be able to </font><font color="#000000">synchronize
with a mailbox moved across
servers.<br>
<br>
Alexey<br>
</font><b><font color="#33cc00"><br>
</font></b>
</body>
</html>

--------------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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <entry-name> <attribute-name>
 > >   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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>; 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 <ietf-imapext@imc.org>; Wed, 14 Apr 2004 11:49:03 -0400
Message-ID: <003201c42238$032759c0$40280209@watson.ibm.com>
From: "Barry Leiba" <leiba@watson.ibm.com>
To: "IMAP extensions Mailing List" <ietf-imapext@imc.org>
References: <407955E1.90005@isode.com> <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu> <407AD059.2000109@isode.com> <Pine.WNT.4.60.0404121044120.2828@Shimo-Tomobiki.Panda.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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>, Ken Murchison <ken@oceana.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

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...

-- 
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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <guenther@sendmail.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ken@oceana.com>
CC: Cyrus Daboo <daboo@cyrusoft.com>, IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <ken@oceana.com>
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 <daboo@cyrusoft.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <daboo@cyrusoft.com>
To: Philip Guenther <guenther@sendmail.com>, Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Hi Philip,

--On Monday, April 12, 2004 12:37:27 PM -0700 Philip Guenther 
<guenther@sendmail.com> 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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
Cc: IMAP Extensions WG <ietf-imapext@imc.org>
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 <guenther@sendmail.com>
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Alexey Melnikov <Alexey.Melnikov@isode.com> writes:
>Philip Guenther wrote:
>>Alexey Melnikov <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <guenther+imap@sendmail.com>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Philip Guenther wrote:

>Alexey Melnikov <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <MRC@CAC.Washington.EDU>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: Collected issues with LISTEXT
In-Reply-To: <407AD059.2000109@isode.com>
Message-ID: <Pine.WNT.4.60.0404121044120.2828@Shimo-Tomobiki.Panda.COM>
References: <407955E1.90005@isode.com> <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu> <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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <mrc@cac.washington.edu>
CC: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: Collected issues with LISTEXT
References: <407955E1.90005@isode.com> <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu>
In-Reply-To: <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
Cc: IMAP Extensions WG <ietf-imapext@imc.org>
From: Philip Guenther <guenther+imap@sendmail.com>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=unsubscribe>

Alexey Melnikov <Alexey.Melnikov@isode.com> 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 <ietf-imapext@imc.org>; 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 <mrc@CAC.Washington.EDU>
To: Alexey Melnikov <Alexey.Melnikov@isode.com>
cc: IMAP Extensions WG <ietf-imapext@imc.org>
Subject: Re: Collected issues with LISTEXT
In-Reply-To: <407955E1.90005@isode.com>
Message-ID: <Pine.LNX.4.60.0404111041080.20967@shiva1.cac.washington.edu>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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 <Alexey.Melnikov@isode.com>
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 <ietf-imapext@imc.org>
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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <LIST () "" ""> 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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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 <ietf-imapext@imc.org>; 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: <http://www.imc.org/ietf-imapext/mail-archive/>
List-ID: <ietf-imapext.imc.org>
List-Unsubscribe: <mailto:ietf-imapext-request@imc.org?body=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--