Received: from cnri by ietf.org id aa10707; 1 Apr 97 3:58 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa04736; 1 Apr 97 3:58 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id XAA07412 for imap-out; Mon, 31 Mar 1997 23:53:57 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from admin.diego.netmanage.com (admin.diego.netmanage.com [156.27.60.10]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id XAA07408 for ; Mon, 31 Mar 1997 23:53:54 -0800 Received: by admin.diego.netmanage.com (SMI-8.6/SMI-SVR4) id XAA06719; Mon, 31 Mar 1997 23:52:39 -0800 From: Syd Logan Message-Id: <970331235238.ZM6717@admin.diego.netmanage.com> Date: Mon, 31 Mar 1997 23:52:38 -0800 In-Reply-To: "Vickus Claasen - Min - x830" "Where can I get a IMAP server for NT ??" (Apr 1, 7:48am) References: <19970401061013547.AAA170@p133.iscorltd.co.za> X-Mailer: Z-Mail (4.0b.820 20aug96) To: vickusc@iscorltd.co.za, imap@cac.washington.edu Subject: Re: Where can I get a IMAP server for NT ?? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Try http://www.imap.org/products/servers.html -- Syd Logan Senior Software Engineer, Z-Mail for Unix NetManage, Inc. http://www.users.cts.com/crash/s/slogan My PGP public key is available at: http://www-swiss.ai.mit.edu/~bal/pks-toplev.html - search for "Syd Logan"   Received: from cnri by ietf.org id aa08917; 1 Apr 97 1:35 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa02610; 1 Apr 97 1:35 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id VAA05785 for imap-out; Mon, 31 Mar 1997 21:49:23 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailman.iscorltd.co.za (mailman.iscorltd.co.za [139.53.1.16]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA05781 for ; Mon, 31 Mar 1997 21:49:15 -0800 Received: from p133.iscorltd.co.za ([139.53.21.176]) by mailman.iscorltd.co.za (Netscape Mail Server v2.02) with SMTP id AAA170 for ; Tue, 1 Apr 1997 08:10:13 +0200 Comments: Authenticated sender is From: Vickus Claasen - Min - x830 Organization: Iscor To: imap@cac.washington.edu Date: Tue, 1 Apr 1997 07:48:14 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Where can I get a IMAP server for NT ?? Reply-to: vickusc@iscorltd.co.za X-Confirm-Reading-To: vickusc@iscorltd.co.za X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Win32 (v2.52) Message-ID: <19970401061013547.AAA170@p133.iscorltd.co.za> I'd like to test IMAP on NT 4.0.... Has Netscape got such a product ?? (ie a IMAP server for NT ??) Regards Vic -------------------------------------------- Vickus Classen Tel +27 832646244 eMail : vickusc@iscorltd.co.za PO Box 30504,Sunnyside,0132,South Africa --------------------------------------------   Received: from cnri by ietf.org id aa09665; 1 Apr 97 2:30 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa03346; 1 Apr 97 2:30 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id WAA06578 for imap-out; Mon, 31 Mar 1997 22:47:54 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from linda.fdata.se (linda.fdata.se [159.72.248.10]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA06568 for ; Mon, 31 Mar 1997 22:47:49 -0800 Received: from gwpo.wmail ([164.9.248.224]) by linda.fdata.se (8.8.4/8.8.4) with SMTP id IAA08913 for ; Tue, 1 Apr 1997 08:46:13 +0200 (MET DST) Received: by gwpo.wmail with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC3E79.688801C0@gwpo.wmail>; Tue, 1 Apr 1997 08:48:02 +0200 Message-ID: From: "Hagero, Per" To: "imap@cac.washington.edu" , Vickus Claasen - Min - x830 Cc: "'Steve.Mcdaniel@isocor.ie'" , "'paul.webster@isocor.ie'" Subject: RE: Where can I get a IMAP server for NT ?? Date: Tue, 1 Apr 1997 08:45:18 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ! ISOCOR has a product that features IMAP4. It was voted the best=20 internet product award at EMA 96. ISOCOR has at least one South=20 African reseller, but I=B4v copied my reply to two people at the ISOCOR=20 office in UK. Best Regards Per H=E4ger=F6 Senior Consultant WM-data ---------- From: Vickus Claasen - Min - x830[SMTP:vickusc@IscorLtd.CO.ZA] Sent: den 1 april 1997 08:14 To: imap@cac.washington.edu Subject: Where can I get a IMAP server for NT ?? I'd like to test IMAP on NT 4.0.... Has Netscape got such a product ?? (ie a IMAP server for NT ??) Regards Vic -------------------------------------------- Vickus Classen Tel +27 832646244 eMail : vickusc@iscorltd.co.za PO Box 30504,Sunnyside,0132,South Africa --------------------------------------------   Received: from cnri by ietf.org id aa11295; 1 Apr 97 4:40 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa05334; 1 Apr 97 4:40 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id AAA08069 for imap-out; Tue, 1 Apr 1997 00:39:25 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from nqus02.aditi.com (nqus02.aditi.com [207.77.61.2]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id AAA08065 for ; Tue, 1 Apr 1997 00:39:22 -0800 Received: by nqus02.aditi.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC3E34.A39EDC10@nqus02.aditi.com>; Tue, 1 Apr 1997 00:35:46 -0800 Message-ID: From: Amit Seth To: "'imap@cac.washington.edu'" Subject: Need help with IMAP programming. Date: Tue, 1 Apr 1997 00:28:24 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I have started learning details of IMAP recently and am interested in developing IMAP client / server. I am familiar with MFC and winsock programming. Need some help in details of IMAP client / server development. Possibly some site where I can pick up some sample code. Thanks! Regards / Amit Amit Seth http://www.aditi.com/custdesk http://www.geocities.com/SiliconValley/Heights/5633/index.html   Received: from cnri by ietf.org id aa16103; 1 Apr 97 10:16 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa11125; 1 Apr 97 10:16 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id GAA12274 for imap-out; Tue, 1 Apr 1997 06:18:31 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from socrates.nca.asu.edu (socrates.ed.asu.edu [129.219.88.66]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id GAA12270 for ; Tue, 1 Apr 1997 06:18:28 -0800 Received: (qmail 29557 invoked from network); 1 Apr 1997 14:18:23 -0000 Received: from kirk.nca.asu.edu (129.219.88.141) by socrates.nca.asu.edu with SMTP; 1 Apr 1997 14:18:23 -0000 Date: Tue, 1 Apr 1997 07:14:20 -0700 () From: "C. R. Oldham" To: Vickus Claasen - Min - x830 cc: imap@cac.washington.edu Subject: Re: Where can I get a IMAP server for NT ?? In-Reply-To: <19970401061013547.AAA170@p133.iscorltd.co.za> Message-ID: X-X-Sender: cro@socrates.nca.asu.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Apr 1997, Vickus Claasen - Min - x830 wrote: > I'd like to test IMAP on NT 4.0.... > > Has Netscape got such a product ?? (ie a IMAP server for NT ??) I don't know, but Digital has their Altavista Mail Server. See http://altavista.digital.com/ -- | Charles R. (C. R.) Oldham | NCA Commission on Schools | | cro@nca.asu.edu | Arizona St. Univ., PO Box 873011 | | V:602/965-8700 F:602/965-9423 |________ Tempe, AZ 85287-3011_ | | "I like it!"--Citizen G'Kar, Babylon 5 | #include X_>|   Received: from cnri by ietf.org id aa21911; 1 Apr 97 13:02 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa14552; 1 Apr 97 13:02 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id JAA15947 for imap-out; Tue, 1 Apr 1997 09:15:48 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id JAA15943 for ; Tue, 1 Apr 1997 09:15:45 -0800 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Tue, 1 Apr 1997 09:15:29 -0800 Message-ID: <0A684133865BCF118F0E08002BE7ADACE1AFB4@DABONE> From: "Mike Gahrns (Exchange)" Cc: IMAP Discusson List Subject: RE: proxyauth Date: Tue, 1 Apr 1997 09:15:19 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain > > Does that make it any easier, or is it still a problem? > > It's still a problem. Standards shouldn't have rarely-used features > because they cause interoperability problems. > > I won't object to PROXYAUTH under the conditions that: > > (a) you drop the second argument. > > and > > (b) you mention that if the authentication mechanism supports proxy > auth > directly (e.g. KERBEROS V4), that should be the preferred method for > interoperability. > > > The problem of creating users and/or locating users in the server's > filesystem is an issue for a different extension. > I concur with Chris. The second argument should be dropped. Pointing out b) in the draft is probably a good idea as well.   Received: from cnri by ietf.org id aa21976; 1 Apr 97 13:04 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa14598; 1 Apr 97 13:04 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id JAA15920 for imap-out; Tue, 1 Apr 1997 09:15:06 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA15914 for ; Tue, 1 Apr 1997 09:15:02 -0800 Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA02149 for ; Tue, 1 Apr 1997 09:15:00 -0800 (PST) Received: from rain ([205.217.228.39]) by judge.mcom.com (Netscape Mail Server v2.02) with SMTP id AAA25616; Tue, 1 Apr 1997 09:14:57 -0800 Message-ID: <33414121.ABD@netscape.com> Date: Tue, 01 Apr 1997 09:08:49 -0800 From: Ted Chen Organization: Netscape Communications Corporation X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: vickusc@iscorltd.co.za CC: imap@cac.washington.edu Subject: Re: Where can I get a IMAP server for NT ?? References: <19970401061013547.AAA170@p133.iscorltd.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vickus Claasen - Min - x830 wrote: > > I'd like to test IMAP on NT 4.0.... > > Has Netscape got such a product ?? (ie a IMAP server for NT ??) > > Regards > Vic > -------------------------------------------- > Vickus Classen > Tel +27 832646244 > eMail : vickusc@iscorltd.co.za > PO Box 30504,Sunnyside,0132,South Africa > -------------------------------------------- Yes, Netscape Mail Server 2.02 on NT supports IMAP4. -- Ted   Received: from cnri by ietf.org id aa22204; 1 Apr 97 13:11 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa14761; 1 Apr 97 13:11 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id JAA03314 for imap-out; Tue, 1 Apr 1997 09:09:16 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailhost1.cac.washington.edu (mailhost1.cac.washington.edu [140.142.32.2]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA03307 for ; Tue, 1 Apr 1997 09:09:13 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id JAA17656; Tue, 1 Apr 1997 09:09:08 -0800 Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST) From: Mark Crispin Subject: re: muddied answers before... re: EXISTS and EXPUNGE To: Jack De Winter cc: imap@cac.washington.edu In-Reply-To: <3.0.32.19970331231815.00753f08@lacroix.wildbear.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 31 Mar 1997 23:18:17 -0500, Jack De Winter wrote: > So what happens in the case of 2 EXPUNGEd messages and 1 EXISTS? I > guess I am asking you to better define 'current'. "Current" means "at the time that that response is issued". Each response must be processed sequentially. * 40 EXISTS current: 40 * 23 EXPUNGE current: 39 * 34 EXPUNGE current: 38 * 39 EXISTS current: 39 Means that at the start, there were 40 messages; messages 23 and 35 were expunged (remember the decrement rule); then 1 new message appeared.   Received: from cnri by ietf.org id aa22627; 1 Apr 97 13:25 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa15077; 1 Apr 97 13:25 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id JAA03993 for imap-out; Tue, 1 Apr 1997 09:32:48 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA03986 for ; Tue, 1 Apr 1997 09:32:44 -0800 Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0b2) with SMTP id AAA1573; Tue, 1 Apr 1997 09:32:41 -0800 Date: Tue, 1 Apr 1997 09:32:41 -0800 (PST) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: Where can I get a IMAP server for NT ?? To: vickusc@iscorltd.co.za cc: imap@cac.washington.edu In-Reply-To: <19970401061013547.AAA170@p133.iscorltd.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > Has Netscape got such a product ?? (ie a IMAP server for NT ??) Yes. http://home.netscape.com/comprod/server_central/index.html   Received: from cnri by ietf.org id aa24722; 1 Apr 97 14:12 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa16106; 1 Apr 97 14:12 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id KAA04982 for imap-out; Tue, 1 Apr 1997 10:06:40 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA04978; Tue, 1 Apr 1997 10:06:32 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Tue, 1 Apr 1997 13:05:32 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Tue, 1 Apr 1997 13:05:31 -0500 Message-Id: <3.0.32.19970401130322.00755ddc@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Apr 1997 13:03:23 -0500 To: Mark Crispin From: Jack De Winter Subject: re: muddied answers before... re: EXISTS and EXPUNGE Cc: imap@cac.washington.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >> So what happens in the case of 2 EXPUNGEd messages and 1 EXISTS? I >> guess I am asking you to better define 'current'. > >"Current" means "at the time that that response is issued". Each response >must be processed sequentially. > > * 40 EXISTS current: 40 > * 23 EXPUNGE current: 39 > * 34 EXPUNGE current: 38 > * 39 EXISTS current: 39 > >Means that at the start, there were 40 messages; messages 23 and 35 were >expunged (remember the decrement rule); then 1 new message appeared. Fair enough... (its what I thought, but wanted to make sure). So, to sum up, if we get an expunge, we delete the 'count' by 1 and issue an EXPUNGE and if we get an append, we increase the 'count' by 1 and issue an EXISTS with the new value. I guess this kind of method forgoes the collapsing of any elements. Do a lot of servers and clients deal with collapsing of elements? (i.e. issuing only the final EXISTS in the above case) regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa25971; 1 Apr 97 15:13 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa17270; 1 Apr 97 15:13 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id LAA06734 for imap-out; Tue, 1 Apr 1997 11:13:49 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.50.81]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA06730 for ; Tue, 1 Apr 1997 11:13:46 -0800 Received: from joelk (joelk.qualcomm.com [129.46.166.243]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with SMTP id LAA01716; Tue, 1 Apr 1997 11:08:47 -0800 (PST) Message-Id: <3.0.1.32.19970401110948.00a257d0@happy.qualcomm.com> X-Sender: joelk@happy.qualcomm.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 01 Apr 1997 11:09:48 -0800 To: "Hagero, Per" From: Joel King Subject: RE: Where can I get a IMAP server for NT ?? Cc: imap@cac.washington.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 08:45 AM 4/1/97 +0200, Hagero, Per wrote: >Hi ! > >ISOCOR has a product that features IMAP4. It was voted the best=20 >internet product award at EMA 96. ISOCOR has at least one South=20 >African reseller, but I=B4v copied my reply to two people at the ISOCOR=20 >office in UK. > You can download a beta version of Eudora Worldmail Server that includes an IMAP server. See: http://www.eudora.com/worldmail/ This is actually a rebranded version of the ISOCOR server. Joel King   Received: from cnri by ietf.org id aa26942; 1 Apr 97 16:06 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa18233; 1 Apr 97 16:06 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id LAA20235 for imap-out; Tue, 1 Apr 1997 11:56:57 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA20230 for ; Tue, 1 Apr 1997 11:56:53 -0800 Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0b2) with SMTP id AAA5150; Tue, 1 Apr 1997 11:56:47 -0800 Date: Tue, 1 Apr 1997 11:56:46 -0800 (PST) From: Mike Macgirvin Reply-To: Mike Macgirvin Subject: Re: proxyauth To: John Gardiner Myers cc: imap@cac.washington.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > The primary argument for the proposed proxyauth IMAP extension seems > to be that Kerberos is the only authentication system which currently > supports the separate authentication and authorization ID feature of > SASL. It is argued that it is better to support this across all SASL > mechanisms using an IMAP extension than to individually fix each SASL > mechanism which lacks the feature. Close, but I'd like to emphasize "across all *authentication* mechanisms". There are authentication mechanisms even in IMAP which are not SASL mechanisms. The LOGIN command and pre-authentication, for example. Some vendors are currently creating alternate SASL methods and it is totally unclear whether they intend to include a proxy mechansim (which has never been specified as being a part of SASL) into their mechanisms. I doubt it. This implies that to be a part of SASL such a proxy mechanism needs to be considerably more than "fixing" individual methods -- part of the SASL definition itself. If you choose to go this route, I'll let you figure out how to subsume LOGIN and PREAUTH. (Currently guestimated 99.99% of the real world cases). > There is work in progress within the ACAP WG to define PLAINTEXT, > ANONYMOUS, and EXTERNAL SASL mechanisms which have this feature. I take it "EXTERNAL" is in essence the IMAP notion of "PREAUTH"? Anyway, the lack of SASL (*and other*) mechanisms is a part of this, but there is also an issue that the mechanism could in some ways be the equivalent of Unix's "su". It is a much better design choice for this type of mechanism to be isolated and minimal so that its proper functioning and security can be verified. It could be considered a flaw to have 'n' implementations each operating under slightly different circumstances. This is a recipe for a CERT advisory. > I'm uncomfortable with the system-dependent folder path being part of > the proposed extension. I've gotten _that_ message loud and clear. > The path should either be an > implementation-dependent extension, or this should be encoded in the > userid, which is an implementation-dependent string anyway. Gak. This coming from somebody who argues about layering violations? I would have overloaded the name and been done with it except it violates my aesthetics. How can I write a draft such that: A server which implements ``PROXYAUTH'' MUST implement the userid arg. It MAY accept or reject additional arguments, which are not defined for the purposes of proxy authentication. I just want to make sure that the definition of proxyauth does not *forbid* additional implementation-defined arguments. That's it. Can anybody suggest alternate wording for this? > I argue that this extension will only suffice to fix the IMAP > protocol, and work will be needed to add this feature to POP3, LDAP, > ACAP, and every other protocol which uses SASL. Best to just fix the > deficient mechanisms and get it over with. You've missed the point - proxyauth does not define an authentication mechanism. It is independant of SASL. I appreciate that it might touch peripherally on the kinds of things that SASL claims to do (it slices, it dices, but it doesn't do the Watusi); but the separation of "assuming an identity without requiring authentication" from the "authentication handshake mechanism" is intentional. I'd like to see all these protocols report quota information also, but that doesn't mean that just because all these protocols utilize SASL that it is SASL's job to do this.   Received: from cnri by ietf.org id aa28039; 1 Apr 97 17:00 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa19267; 1 Apr 97 17:00 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id MAA09636 for imap-out; Tue, 1 Apr 1997 12:55:26 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from istn.thenet.net (istn.thenet.net [206.64.182.43]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA09631 for ; Tue, 1 Apr 1997 12:55:19 -0800 Received: from Connect2 Message Router by istn.thenet.net via Connect2-SMTP 4.30.b4; Tue, 1 Apr 1997 15:49:23 -0500 Message-ID: In-Reply-To: <9D2B502F01B40F00@istn.thenet.net> Date: Tue, 1 Apr 1997 15:52:00 -0500 From: Marc Michels X-Confirm-Reading-To: Disposition-Notification-To: Organization: ISTN Inc., Miami To: Joel King , "Hagero, Per" Cc: imap@cac.washington.edu Subject: RE: Where can I get a IMAP server for NT ?? Importance: Normal MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-disposition: inline Content-transfer-encoding: quoted-printable X-Mailer: Connect2-SMTP 4.30.b4 MHS/SMF to SMTP Gateway =3D=3D=3D=3D=3D Original Message from JOELK@ISMTP (Joel King) {joelk@Qualco= mm.COM} at = 4/01/97 2:09 pm >At 08:45 AM 4/1/97 +0200, Hagero, Per wrote: >>Hi ! >> >>ISOCOR has a product that features IMAP4. It was voted the best >>internet product award at EMA 96. ISOCOR has at least one South >>African reseller, but I=DDv copied my reply to two people at the ISOCOR >>office in UK. >> > >You can download a beta version of Eudora Worldmail Server that includes >an IMAP server. See: > > http://www.eudora.com/worldmail/ > >This is actually a rebranded version of the ISOCOR server. > > >Joel King > =3D=3D=3D=3D=3D Comments by MARC@ISTN (Marc Michels) at 4/01/97 3:48 pm Try InterChange from Infinite Technologies. Their server is a released = product, and it works! You can get a 30 day eval from: http://www.lauenstein.com or from http://www.ihub.com Have fun! Marc Michels Director ---------------------------------------------------------------------------= - ISTN Inc. Communication Services & High Performance Messaging Solutions -> mailto:marc@lauenstein.com -> visit our web site: http://www.lauenstein.com -> Phone: (305) 944 9611 -> Fax: (305) 944 3512 = ---------------------------------------------------------------------------= -   Received: from cnri by ietf.org id aa00042; 1 Apr 97 18:08 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa20775; 1 Apr 97 18:08 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id OAA23933 for imap-out; Tue, 1 Apr 1997 14:08:07 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA23926; Tue, 1 Apr 1997 14:07:58 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Tue, 1 Apr 1997 17:06:56 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Tue, 1 Apr 1997 17:06:56 -0500 Message-Id: <3.0.32.19970401170443.007542d8@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Apr 1997 17:04:44 -0500 To: Mark Crispin From: Jack De Winter Subject: double check regarding server responses... Cc: imap@cac.washington.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Just want to check a couple of points. Now, most of this deals with things that I remember being talked about on the list or at the last IETF meeting, but cannot find anything to back up my position. 1) during a FETCH, STORE, or SEARCH, the spec says an EXPUNGE cannot be done 1a) I had thought there was discussion about making this any command? If not, is it possible to do a: C: a01 STORE 1:2 +FLAGS (\Deleted) S: * EXISTS 33 S: * FETCH 32 (\Seen) S: * FETCH 2 (\Deleted) S: ... S: a01 OK STORE completed 1b) I had thought there was talk about adding COPY to the list of commands? 2) I remember someone stating that they wanted some of the commands to be accepted in lower case as well. Is this something we are working towards? (Personally, we have coded all of the strings as is, in upper case for all commands, modifiers, etc.). 3) Someone had expressed concern that the mandated search CHARSETs should be US-ASCII and ISO-XXXX-1 (Latin 1). Is this still in progress? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa00242; 1 Apr 97 18:11 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa20880; 1 Apr 97 18:11 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA25987; Tue, 1 Apr 1997 14:58:53 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA22364 for ; Tue, 1 Apr 1997 14:58:38 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA03299 for ; Tue, 1 Apr 1997 14:58:35 -0800 Received: from mailhost1.cac.washington.edu (mailhost1.cac.washington.edu [140.142.32.2]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA14645 for ; Tue, 1 Apr 1997 14:58:33 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA28407; Tue, 1 Apr 1997 14:58:26 -0800 Message-Id: Date: Tue, 1 Apr 1997 14:49:19 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Jack De Winter Cc: imap@cac.washington.edu Subject: re: double check regarding server responses... In-Reply-To: <3.0.32.19970401174203.00764c64@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Every response has immediate effect. That means any subsequent response is affected by previous responses. > i.e. EXPUNGE 5, then EXISTS 10, then EXPUNGE 10, then EXISTS 10 would > get translated to EXISTS 10, EXISTS 11, with and EXPUNGE for 5 and 10 > to follow? * 5 EXPUNGE * 10 EXISTS * 10 EXPUNGE * 10 EXISTS is not equivalent to * 10 EXISTS * 11 EXISTS * 5 EXPUNGE * 10 EXPUNGE Take out a piece of paper, starting with 8 messages, and work out, one by one what each of these does. Hint: in the first case you end up with 10 messages, and in the second case you end up with 9 messages. This is specifically stated in RFC 2060 section 7.4.1. Please look for answers to pedagogical questions in the document before sending them to the mailing list.   Received: from cnri by ietf.org id aa00381; 1 Apr 97 18:18 EST Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa21037; 1 Apr 97 18:18 EST Received: (from daemon@localhost) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id OAA24374 for imap-out; Tue, 1 Apr 1997 14:25:43 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA24367; Tue, 1 Apr 1997 14:25:39 -0800 Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.100.202]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA25600; Tue, 1 Apr 1997 14:25:38 -0800 Date: Tue, 1 Apr 1997 14:25:35 -0800 (PST) From: David L Miller Reply-To: David L Miller To: c-client@cac.washington.edu, imap@cac.washington.edu Subject: IMAP and C-Client lists being automated Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We are in the process of moving the c-client@cac.washington.edu and imap@cac.washington.edu mailing lists from the current manually maintained lists to our campus ListProc server. You DO NOT need to do anything, all current subscriptions will be moved without any intervention needed on your part. You should see a welcome message from ListProc@U.Washington.EDU shortly with further information about the ListProc system. There will be a slight change in the headers on messages from the lists, but we have made every effort to minimize the differences. Messages to the lists can still be sent to the same addresses, {imap|c-client}@CAC.Washington.EDU. For those who prefer a digested form, daily digests will now be available. See the ListProc documentation for details. Requests sent to imap-request and c-client-request will be directed to listproc@u.washington.edu. If you need human assistance, please contact dlm@cac.washington.edu or mrc@cac.washington.edu. We apologize if this causes any inconvenience or confusion! -- David L. Miller | When ideas fail, words come in Software Engineer, Pine Development Team | very handy. -- Goethe Box 354841, University of Washington | 4545 15th Ave NE, Seattle WA 98105, USA | Phone: (206)685-6240 FAX: (206)685-4045 |   Received: from cnri by ietf.org id aa00390; 1 Apr 97 18:18 EST Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa21047; 1 Apr 97 18:18 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA49014; Tue, 1 Apr 1997 15:04:53 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA21516 for ; Tue, 1 Apr 1997 15:04:32 -0800 Received: from mailhost1.cac.washington.edu (mailhost1.cac.washington.edu [140.142.32.2]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA10417 for ; Tue, 1 Apr 1997 15:04:27 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA28592 for ; Tue, 1 Apr 1997 15:04:26 -0800 Message-Id: Date: Tue, 1 Apr 1997 14:34:36 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: IMAP Interest List Subject: change to IMAP mailing list MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN The imap mailing list has changed to LISTPROC. I am no longer directly involved in the loop of maintaining the mail list. The service host has also changed to u.washington.edu; that is, the new addresses are: imap@u.washington.edu to post imap-request@u.washington.edu or listproc@u.washington.edu to make subscription changes however the old imap@cac.washington.edu address will continue to work. You all should have received a message informing you of your new subscription status. Please don't send subscription change requests to my personal mailbox (mrc@cac.washington.edu) any more.   Received: from cnri by ietf.org id aa00456; 1 Apr 97 18:22 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa21119; 1 Apr 97 18:22 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id OAA12748 for imap-out; Tue, 1 Apr 1997 14:33:19 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA12738 for ; Tue, 1 Apr 1997 14:33:14 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA25842; Tue, 1 Apr 1997 14:33:06 -0800 Date: Tue, 1 Apr 1997 14:11:19 -0800 (PST) From: Mark Crispin Subject: re: double check regarding server responses... To: Jack De Winter cc: imap@cac.washington.edu In-Reply-To: <3.0.32.19970401170443.007542d8@lacroix.wildbear.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 01 Apr 1997 17:04:44 -0500, Jack De Winter wrote: > 1) during a FETCH, STORE, or SEARCH, the spec says an EXPUNGE cannot be done > 1a) I had thought there was discussion about making this any command? There is no way this can be done and still allow multiple commands to be in progress. > If not, is it possible to do a: > C: a01 STORE 1:2 +FLAGS (\Deleted) > S: * EXISTS 33 > S: * FETCH 32 (\Seen) > S: * FETCH 2 (\Deleted) > S: ... > S: a01 OK STORE completed This scenario is permitted. It means: There are 33 messages in the mailbox. Message 32's flag list is now (\Seen) Message 2's flag list is now (\Deleted) There should have been an untagged FETCH response for message 1, though. > 1b) I had thought there was talk about adding COPY to the list of commands? No. COPY is (the only sequence number command that is) safe to allow EXPUNGE, because you can't cascade it (since you want to wait to see if the COPY worked before issuing another one). Thus, this scenario is valid: C: A001 COPY 2,4,6,8 Fred S: * 3 EXPUNGE S: A001 OK COPY completed Note that the messages added to Fred are messages 2,4,6,8 at the start of the COPY command, or messages 2,3,5,7 at the end of the COPY command. In other words, the EXPUNGE can't take place until AFTER the messages from the COPY command are identified (because of the "no expunge while no commands in progress" rule). Otherwise you have an ambiguity. Now, consider this scenario: C: A001 COPY 2,4,6,8 Fred S: * 4 EXPUNGE S: A001 NO COPY rejected, because some requested message(s) were expunged Since message 4 was requested in the COPY, but was expunged before copying started, the entire COPY had to be rejected because of the "COPY must do everything requested or nothing at all" rule. The scenario: C: A001 COPY 2,4,6,8 Fred S: * 4 EXPUNGE S: A001 OK COPY completed means that message 4 was copied *before* it was expunged. I don't recommend doing this, though; I'm aware that some clients have problems with this scenario and there is some talk about banning it. > 2) I remember someone stating that they wanted some of the commands to be > accepted in lower case as well. All commands are case-independent, and have been since the beginning of IMAP. If your server doesn't accept lowercase or mixed case commands, it is broken. Refer to the top paragraph of page 65 of RFC-2060. > 3) Someone had expressed concern that the mandated search CHARSETs should > be US-ASCII and ISO-XXXX-1 (Latin 1). Is this still in progress? The only mandated search charset is US-ASCII. ISO-8859-1 is not mandated, and it never will be now that the Internet is moving towards UTF-8. The best way to stop IMAP from advancing would be to get it sidetracked on 8859.   Received: from cnri by ietf.org id aa00470; 1 Apr 97 18:22 EST Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa21132; 1 Apr 97 18:22 EST Received: (from daemon@localhost) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) id OAA14156 for imap-out; Tue, 1 Apr 1997 14:46:00 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA14147; Tue, 1 Apr 1997 14:45:48 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Tue, 1 Apr 1997 17:44:18 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Tue, 1 Apr 1997 17:44:17 -0500 Message-Id: <3.0.32.19970401174203.00764c64@lacroix.wildbear.on.ca> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 01 Apr 1997 17:42:04 -0500 To: Mark Crispin From: Jack De Winter Subject: re: double check regarding server responses... Cc: imap@cac.washington.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:11 PM 4/1/97 -0800, Mark Crispin wrote: >On Tue, 01 Apr 1997 17:04:44 -0500, Jack De Winter wrote: >> 1) during a FETCH, STORE, or SEARCH, the spec says an EXPUNGE cannot be done >> 1a) I had thought there was discussion about making this any command? > >There is no way this can be done and still allow multiple commands to be in >progress. My apologies here... just realized I meant to say response, not command. >> If not, is it possible to do a: >> C: a01 STORE 1:2 +FLAGS (\Deleted) >> S: * EXISTS 33 >> S: * FETCH 32 (\Seen) >> S: * FETCH 2 (\Deleted) >> S: ... >> S: a01 OK STORE completed > >This scenario is permitted. It means: > There are 33 messages in the mailbox. > Message 32's flag list is now (\Seen) > Message 2's flag list is now (\Deleted) >There should have been an untagged FETCH response for message 1, though. Ah, so from 1a, only the EXPUNGE response itself is explicitly not allowed to happen, but everything else is. Thanks. How about the case where the EXPUNGE would cause a dependancy on an EXISTS or a FETCH? In that case, do you proceed as if the EXPUNGE was not there, and alter the message numbers accordingly? i.e. EXPUNGE 5, then EXISTS 10, then EXPUNGE 10, then EXISTS 10 would get translated to EXISTS 10, EXISTS 11, with and EXPUNGE for 5 and 10 to follow? >> 1b) I had thought there was talk about adding COPY to the list of commands? > >No. COPY is (the only sequence number command that is) safe to allow EXPUNGE, >because you can't cascade it (since you want to wait to see if the COPY worked >before issuing another one). Thus, this scenario is valid: > C: A001 COPY 2,4,6,8 Fred > S: * 3 EXPUNGE > S: A001 OK COPY completed >Note that the messages added to Fred are messages 2,4,6,8 at the start of the >COPY command, or messages 2,3,5,7 at the end of the COPY command. In other >words, the EXPUNGE can't take place until AFTER the messages from the COPY >command are identified (because of the "no expunge while no commands in >progress" rule). Otherwise you have an ambiguity. > >Now, consider this scenario: > C: A001 COPY 2,4,6,8 Fred > S: * 4 EXPUNGE > S: A001 NO COPY rejected, because some requested message(s) were > expunged >Since message 4 was requested in the COPY, but was expunged before copying >started, the entire COPY had to be rejected because of the "COPY must do >everything requested or nothing at all" rule. > >The scenario: > C: A001 COPY 2,4,6,8 Fred > S: * 4 EXPUNGE > S: A001 OK COPY completed >means that message 4 was copied *before* it was expunged. I don't recommend >doing this, though; I'm aware that some clients have problems with this >scenario and there is some talk about banning it. Good examples... very good. Any chance of getting these into something like the BCP? >> 2) I remember someone stating that they wanted some of the commands to be >> accepted in lower case as well. > >All commands are case-independent, and have been since the beginning of IMAP. >If your server doesn't accept lowercase or mixed case commands, it is broken. > >Refer to the top paragraph of page 65 of RFC-2060. whoops... >> 3) Someone had expressed concern that the mandated search CHARSETs should >> be US-ASCII and ISO-XXXX-1 (Latin 1). Is this still in progress? > >The only mandated search charset is US-ASCII. ISO-8859-1 is not mandated, and >it never will be now that the Internet is moving towards UTF-8. The best way >to stop IMAP from advancing would be to get it sidetracked on 8859. fair enough... and thanks for the clarifications.... regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa00511; 1 Apr 97 18:23 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa21151; 1 Apr 97 18:23 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA21100; Tue, 1 Apr 1997 15:15:52 -0800 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA42274 for ; Tue, 1 Apr 1997 15:15:14 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA21370 for ; Tue, 1 Apr 1997 15:15:11 -0800 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA25966 for ; Tue, 1 Apr 1997 15:15:06 -0800 Received: from RAYCH by doggate.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id HY5HP5NJ; Tue, 1 Apr 1997 15:14:54 -0800 Message-Id: <199704012315.PAA25966@mx1.cac.washington.edu> Date: Tue, 1 Apr 1997 15:14:28 -0800 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Raymond Cheng To: schaefer@nbn.com, "Larry Osterman (Exchange)" MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Cc: imap@cac.washington.edu MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Re: EXISTS responses MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook Express 4.71.0613.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0613.0 X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On March 31, Bart Schaefer wrote: [...] >If that's true, then we have a good argument that servers must >keep the message data around. But if that were the case, I think we'd >have seen it quoted here before, in refutation of the "NIL FETCH >Response" >alternative. No, the way I see it, an unreported EXPUNGE means the server must interpret message sequence numbers from the client with the unreported EXPUNGE's in mind. It does not necessarily mean that the expunged messages still exist. ...Cheng ----- Email: raych@microsoft.com Microsoft Outlook Express Developer My opinions are mine, all MINE!   Received: from cnri by ietf.org id aa02113; 1 Apr 97 19:23 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa22314; 1 Apr 97 19:23 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA24093; Tue, 1 Apr 1997 16:16:17 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA50198 for ; Tue, 1 Apr 1997 16:15:43 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA03126 for ; Tue, 1 Apr 1997 16:15:38 -0800 Received: from po7.andrew.cmu.edu (PO7.ANDREW.CMU.EDU [128.2.10.107]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA16520 for ; Tue, 1 Apr 1997 16:15:34 -0800 Received: (from postman@localhost) by po7.andrew.cmu.edu (8.8.2/8.8.2) id TAA20640 for imap@cac.washington.edu; Tue, 1 Apr 1997 19:15:18 -0500 Received: via switchmail; Tue, 1 Apr 1997 19:15:07 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 1 Apr 1997 19:12:46 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 1 Apr 1997 19:12:41 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 1 Apr 1997 19:12:41 -0500 (EST) Message-Id: Date: Tue, 1 Apr 1997 19:12:41 -0500 (EST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: proxyauth In-Reply-To: References: X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Mike Macgirvin writes: > Close, but I'd like to emphasize "across all *authentication* mechanisms". > There are authentication mechanisms even in IMAP which are not SASL > mechanisms. The LOGIN command and pre-authentication, for example. Both of these are legacy facilities. ACAP is defining PLAINTEXT and EXTERNAL SASL mechanisms to provide the same functionality within SASL and with the ability to support proxies. > Some vendors are currently creating alternate SASL methods and it is > totally unclear whether they intend to include a proxy mechansim > (which has never been specified as being a part of SASL) into their > mechanisms. I doubt it. This implies that to be a part of SASL such > a proxy mechanism needs to be considerably more than "fixing" > individual methods -- part of the SASL definition itself. The proxy feature has been in SASL since the beginning, though its existence wasn't as emphasised in earlier documents as it has been in later ones. The current SASL draft makes an explicit reference to the proxying use of a separate authorization identity. > If you > choose to go this route, I'll let you figure out how to subsume LOGIN and > PREAUTH. (Currently guestimated 99.99% of the real world cases). If you're talking installed base, most of it can't support a proxyauth extension anyway, since the bulk of the deployed servers irrevocably give up the ability to become another user before going to the AUTHENTICATED state. Since doing a proxy connection requires new development on both the server and the client, subsuming LOGIN and PREAUTH with different syntax is not a big issue. > I take it "EXTERNAL" is in essence the IMAP notion of "PREAUTH"? Pretty much. Client gives the authorization identity and server says "yup" or "nope", using a presumed external authentication context. > but there is also an issue that the mechanism could in some ways be > the equivalent of Unix's "su". It is a much better design choice for > this type of mechanism to be isolated and minimal so that its proper > functioning and security can be verified. Which is why I propose a system with a minimal number of states. You've got a state where you can't make requests other than to negotiate a privilege level, and you've got a state where you can access data but have shed the authority needed to change privilege levels. The proper functioning and security of the privilege determining code can is minimal and can be verified. The ability for an attacker to set up one of a potentially large number of initial server states before executing code which mucks with privilege levels makes proper verification of security difficult. > It could be considered a > flaw to have 'n' implementations each operating under slightly > different circumstances. This is a recipe for a CERT advisory. In the SASL API's I've written, the mechanism calls out to an application-defined function to answer the question of whether a given authentication identity may use a given authorization identity. > How can I write a draft such that: > > A server which implements ``PROXYAUTH'' MUST implement the userid arg. It MAY > accept or reject additional arguments, which are not defined for the purposes > of proxy authentication. I'm not sure I sufficiently understand the case where you need the second argument. I suspect that it would only ever be used by a client that was written specifically to talk to your particular server implementation and none other. In that case, a private extension makes the most sense to me. A separate command would be the cleanest way to specify this extension. > I just want to make sure that the definition of proxyauth does not *forbid* > additional implementation-defined arguments. That's it. Can anybody suggest > alternate wording for this? Extensions, including private ones, can modify anything that doesn't break peers that don't understand the extension. So if you say nothing about additional arguments in the proxyauth extension that does not forbid some other extension from defining additional arguments. > > I argue that this extension will only suffice to fix the IMAP > > protocol, and work will be needed to add this feature to POP3, LDAP, > > ACAP, and every other protocol which uses SASL. Best to just fix the > > deficient mechanisms and get it over with. > > You've missed the point - proxyauth does not define an authentication > mechanism. It is independant of SASL. I get the point, but believe it's the wrong approach. Making it be independent of SASL leaves the same problem unresolved in other protocols. > I appreciate that it might touch > peripherally on the kinds of things that SASL claims to do (it slices, it > dices, but it doesn't do the Watusi); but the separation of "assuming an > identity without requiring authentication" from the "authentication handshake > mechanism" is intentional. I'd like to see all these protocols report quota > information also, but that doesn't mean that just because all these protocols > utilize SASL that it is SASL's job to do this. Determining quota information is a problem that is independent of authentication. Assuming an identity is directly part of the authentication problem, and is quite rightly SASL's job. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from cnri by ietf.org id aa06229; 1 Apr 97 21:19 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa24088; 1 Apr 97 21:19 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA29614; Tue, 1 Apr 1997 18:11:27 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA22286 for ; Tue, 1 Apr 1997 18:11:00 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA13299 for ; Tue, 1 Apr 1997 18:10:58 -0800 Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA18907 for ; Tue, 1 Apr 1997 18:10:55 -0800 Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0b2) with SMTP id AAA9865; Tue, 1 Apr 1997 18:10:52 -0800 Message-Id: Date: Tue, 1 Apr 1997 18:10:52 -0800 (PST) Reply-To: Mike Macgirvin Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mike Macgirvin To: John Gardiner Myers Cc: imap@cac.washington.edu Subject: Re: proxyauth In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: "Mike Macgirvin" X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN > Both of these are legacy facilities. ACAP is defining PLAINTEXT and > EXTERNAL SASL mechanisms to provide the same functionality within SASL > and with the ability to support proxies. Are these defined in a public place? I am unable to obtain any reference. Right now we have legacy login to support. Probably will for some time to come judging from what I saw at MailConnect. > The current SASL draft makes an explicit reference to > the proxying use of a separate authorization identity. But only provides implementation reference for Kerberos (perhaps gssapi, the description is pretty terse). > If you're talking installed base, most of it can't support a proxyauth > extension anyway, since the bulk of the deployed servers irrevocably > give up the ability to become another user before going to the > AUTHENTICATED state. Not necessarily so. Yes, I know that this mechanism is common based on unix setuid(), but it's not universal. > In the SASL API's I've written, the mechanism calls out to an > application-defined function to answer the question of whether a given > authentication identity may use a given authorization identity. But the calling context can vary in 'n' dimensions up to the number of supported authenticators, and this is generally in crypto API code that developers generally will be wiring in without fully understanding all the nuances, and that may be difficult to debug because the important information may be encrypted along the way. Contrast that to the proxyauth mechanism which has two input states - a person with privilege or not; and two output states, a changed identity or not. As I've said in a past message somewhere, I'm not writing off SASL, but just because somebody tells me it slices and dices doesn't mean I'm gonna' blindly accept that it will do the Watusi. My customers don't need a slicer or dicer.   Received: from cnri by ietf.org id aa25597; 2 Apr 97 11:31 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa13042; 2 Apr 97 11:31 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id IAA28813; Wed, 2 Apr 1997 08:19:01 -0800 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA28804 for ; Wed, 2 Apr 1997 08:18:36 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA26742 for ; Wed, 2 Apr 1997 08:18:35 -0800 Received: from exinis1-1.morgan.com (exinis.ms.com [204.254.197.6]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA11927 for ; Wed, 2 Apr 1997 08:18:27 -0800 Received: (from mail@localhost) by exinis1-1.morgan.com (8.8.5/fw v1.22) id LAA09708 for ; Wed, 2 Apr 1997 11:18:22 -0500 (EST) Received: from samail1.morgan.com(144.14.9.149) by exinis1-1.morgan.com via smap (V1.3) id sma009589; Wed Apr 2 11:18:05 1997 Received: from cheers.morgan.com (cheers.morgan.com [144.14.15.178]) by samail1.morgan.com (8.8.5/hub v1.44) with ESMTP id LAA01670 for ; Wed, 2 Apr 1997 11:18:04 -0500 (EST) Received: (foad@localhost) by cheers.morgan.com (8.7.5/sendmail.cf.client v1.05) id LAA24455 for imap@cac.washington.edu; Wed, 2 Apr 1997 11:18:03 -0500 (EST) Message-Id: <199704021618.LAA24455@cheers.morgan.com> Date: Wed, 2 Apr 1997 11:18:03 -0500 (EST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Nick Foad To: imap@cac.washington.edu Subject: SEARCH SENTxxx & Y2K X-Sun-Charset: US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hi, and apologies if this came up before, the SEARCH SENTxxx compares "date" specified against the rfc822 Date: field, and whilst the IMAP "date-year" is a four-digit field, RFC822 clearly states that "date" contains a "2DIGIT" year. I can see these commands causing confusion and problems in year 2000+. i guess these SEARCH commands should be obsoleted ??? Nick.   Received: from cnri by ietf.org id aa26533; 2 Apr 97 12:10 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa13840; 2 Apr 97 12:10 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id IAA23845; Wed, 2 Apr 1997 08:58:24 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA17080 for ; Wed, 2 Apr 1997 08:57:51 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA06271 for ; Wed, 2 Apr 1997 08:57:47 -0800 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA02171 for ; Wed, 2 Apr 1997 08:57:45 -0800 Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.2/8.8.2/MOON) with ESMTP id IAA07118; Wed, 2 Apr 1997 08:57:36 -0800 (PST) Received: (from schaefer@localhost) by candle.brasslantern.com (8.7.6/8.7.3) id IAA07385; Wed, 2 Apr 1997 08:55:50 -0800 Message-Id: <970402085550.ZM7384@candle.brasslantern.com> Date: Wed, 2 Apr 1997 08:55:50 -0800 Reply-To: schaefer@nbn.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bart Schaefer To: Nick Foad , imap@cac.washington.edu Subject: Re: SEARCH SENTxxx & Y2K In-Reply-To: Nick Foad "SEARCH SENTxxx & Y2K" (Apr 2, 11:18am) References: <199704021618.LAA24455@cheers.morgan.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.820 20aug96) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Apr 2, 11:18am, Nick Foad wrote: } Subject: SEARCH SENTxxx & Y2K } } the SEARCH SENTxxx compares "date" specified against the } rfc822 Date: field, and whilst the IMAP "date-year" is a } four-digit field, RFC822 clearly states that "date" contains } a "2DIGIT" year. I can see these commands causing confusion and } problems in year 2000+. This is an April Fools gag, a day late, right? RFC822 2-digit years were obsoleted years ago by RFC1123, section 5.2.14. Although the presence of the header in the message is still as defined by 822, no Internet software should still be generating 2-digit years in the contents of the header. See also draft-ietf-drums-msg-fmt-01.txt for interpretation of any 2-digit years that may remain. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern   Received: from cnri by ietf.org id aa07163; 2 Apr 97 19:42 EST Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa22799; 2 Apr 97 19:42 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA20678; Wed, 2 Apr 1997 16:32:43 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA31360 for ; Wed, 2 Apr 1997 16:32:10 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA28015 for ; Wed, 2 Apr 1997 16:32:08 -0800 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA14424; Wed, 2 Apr 1997 16:32:04 -0800 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <211QS3QD>; Wed, 2 Apr 1997 16:31:51 -0800 Message-Id: <0A684133865BCF118F0E08002BE7ADACE1AFCF@DABONE> Date: Wed, 2 Apr 1997 16:31:20 -0800 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: Mark Crispin , "'Jack De Winter'"@u.washington.edu Cc: imap@cac.washington.edu Subject: RE: double check regarding server responses... MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN > >> 1b) I had thought there was talk about adding COPY to the list of > commands? > > > >No. COPY is (the only sequence number command that is) safe to allow > EXPUNGE, > >because you can't cascade it (since you want to wait to see if the > COPY > worked > >before issuing another one). Thus, this scenario is valid: > > C: A001 COPY 2,4,6,8 Fred > > S: * 3 EXPUNGE > > S: A001 OK COPY completed > >Note that the messages added to Fred are messages 2,4,6,8 at the > start of the > >COPY command, or messages 2,3,5,7 at the end of the COPY command. In > other > >words, the EXPUNGE can't take place until AFTER the messages from the > COPY > >command are identified (because of the "no expunge while no commands > in > >progress" rule). Otherwise you have an ambiguity. > > > >Now, consider this scenario: > > C: A001 COPY 2,4,6,8 Fred > > S: * 4 EXPUNGE > > S: A001 NO COPY rejected, because some requested message(s) were > > expunged > >Since message 4 was requested in the COPY, but was expunged before > copying > >started, the entire COPY had to be rejected because of the "COPY must > do > >everything requested or nothing at all" rule. > > > >The scenario: > > C: A001 COPY 2,4,6,8 Fred > > S: * 4 EXPUNGE > > S: A001 OK COPY completed > >means that message 4 was copied *before* it was expunged. I don't > recommend > >doing this, though; I'm aware that some clients have problems with > this > >scenario and there is some talk about banning it. > > Good examples... very good. Any chance of getting these into > something like > the BCP? I agree that this was an excellent example put together by Mark Crispin. Thanks Mark! Since it is related to the 'what to do with expunged messages on multi-accessed mailboxes' discussion I agree it would be nice to add to the practice draft I have been working on. I will submit another version of this on thursday and will send a pointer to it when it appears.   Received: from cnri by ietf.org id aa07245; 2 Apr 97 19:46 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa22859; 2 Apr 97 19:46 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA20306; Wed, 2 Apr 1997 16:39:11 -0800 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA19248 for ; Wed, 2 Apr 1997 16:38:34 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA23731 for ; Wed, 2 Apr 1997 16:38:31 -0800 Received: from mailhost1.cac.washington.edu (mailhost1.cac.washington.edu [140.142.32.2]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA25618; Wed, 2 Apr 1997 16:38:26 -0800 Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.100.202]) by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA00500; Wed, 2 Apr 1997 16:38:25 -0800 Message-Id: Date: Wed, 2 Apr 1997 16:38:22 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: David L Miller To: imap@cac.washington.edu, c-client@cac.washington.edu Subject: ListProc hint MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Several people have already stumbled across problems sending ListProc commands (e.g. unsubscribe, set) from an address other than what they subscribed from, so here's a little hint. Most commands will accept an addition of "for
" to make it apply to another address, e.g. if I subscribed to the IMAP list as foo@bar.com and want to change to getting daily digests, I could send the following to listproc@u.washington.edu: set imap digest for foo@bar.com The ListProc server would then send a confirmation message to foo@bar.com. The cookie in that confirmation message must then be returned within 7 days for the change to take effect. Hope that helps! -- David L. Miller | Wise men make proverbs, but fools Software Engineer, Pine Development Team | repeat them. -- Samuel Palmer Box 354841, University of Washington | 4545 15th Ave NE, Seattle WA 98105, USA | Phone: (206)685-6240 FAX: (206)685-4045 |   Received: from cnri by ietf.org id aa08397; 2 Apr 97 20:57 EST Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa23904; 2 Apr 97 20:57 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA19312; Wed, 2 Apr 1997 17:46:27 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA28836 for ; Wed, 2 Apr 1997 17:45:37 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA02726 for ; Wed, 2 Apr 1997 17:19:56 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA15659 for ; Wed, 2 Apr 1997 17:19:52 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Wed, 2 Apr 1997 20:19:05 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Wed, 2 Apr 1997 20:19:04 -0500 Message-Id: <3.0.32.19970402201622.00d3deb4@lacroix.wildbear.on.ca> Date: Wed, 02 Apr 1997 20:16:24 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: imap@cac.washington.edu Subject: current state of namespaces? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Just talking to a friend who was trying to find information on IMAP namespaces, and I hae some messages from this list, but nothing else. Has their been any work done on a spec and if so, what state is it in? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa06994; 3 Apr 97 13:04 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa15426; 3 Apr 97 13:04 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id JAA20117; Thu, 3 Apr 1997 09:57:20 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA46218 for ; Thu, 3 Apr 1997 09:55:42 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA06608 for ; Thu, 3 Apr 1997 09:55:41 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA11873 for ; Thu, 3 Apr 1997 09:55:36 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Thu, 3 Apr 1997 12:54:51 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Thu, 3 Apr 1997 12:54:50 -0500 Message-Id: <3.0.32.19970403125152.00e6c8b4@lacroix.wildbear.on.ca> Date: Thu, 03 Apr 1997 12:51:53 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: imap@cac.washington.edu Subject: IMAP append and implementations... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Wanted to get some feedback from people on how they do Append. The reason I am asking is because in our implementation, we get the entire file before requesting the append lock for our mail store. I was just taking a long look at the mail store, and there is one case (during a really long COPY operation) where the message could be rejected due to a locked mail store after the entire message has been sent. So, is this a good thing to do? Any ideas? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa17976; 3 Apr 97 18:12 EST Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa22537; 3 Apr 97 18:12 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA51088; Thu, 3 Apr 1997 15:08:58 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA04606 for ; Thu, 3 Apr 1997 15:08:10 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA20397 for ; Thu, 3 Apr 1997 15:08:04 -0800 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA20417 for ; Thu, 3 Apr 1997 15:08:02 -0800 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <211QTD4X>; Thu, 3 Apr 1997 15:07:51 -0800 Message-Id: <0A684133865BCF118F0E08002BE7ADACE1AFE8@DABONE> Date: Thu, 3 Apr 1997 15:07:44 -0800 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: "imap@CAC.Washington.EDU" , "'Jack De Winter'"@u.washington.edu Subject: RE: current state of namespaces? MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I am also interested in the status of this. The latest I heard was that the issue was brought up at the last UW IMAP meeting a rough proposal was hashed out. I think a group was going to crank out a draft. A bunch of the same people will probably be the IETF meeting next week. Perhaps we can firm up a proposal there. I will be at the IETF meeting, and will be willing to help write up the name space draft, if no one else has the time to get the draft out. -mikega > ---------- > From: Jack De Winter[SMTP:jack@Wildbear.ON.CA] > Sent: Wednesday, April 02, 1997 5:16 PM > To: imap@CAC.Washington.EDU > Subject: current state of namespaces? > > Just talking to a friend who was trying to find > information on IMAP namespaces, and I hae some > messages from this list, but nothing else. Has > their been any work done on a spec and if so, what > state is it in? > > regards, > Jack > ------------------------------------------------- > Jack De Winter - Wildbear Consulting, Inc. > (519) 576-3873 http://www.wildbear.on.ca/ > > Author of SLMail for 95 & NT (http://www.seattlelab.com/) >   Received: from cnri by ietf.org id aa26539; 3 Apr 97 22:23 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa26537; 3 Apr 97 22:23 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id TAA06615; Thu, 3 Apr 1997 19:18:46 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA25764 for ; Thu, 3 Apr 1997 19:17:17 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA04110 for ; Thu, 3 Apr 1997 19:17:15 -0800 Received: from gpu.utcc.utoronto.ca (gpu.utcc.utoronto.ca [128.100.102.1]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id TAA14324 for ; Thu, 3 Apr 1997 19:17:12 -0800 Received: from localhost by gpu.utcc.utoronto.ca with SMTP id <336531>; Thu, 3 Apr 1997 22:17:08 -0500 Message-Id: Date: Thu, 3 Apr 1997 22:17:03 -0500 Reply-To: alex.nishri@utoronto.ca Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Alex Nishri To: imap@cac.washington.edu Subject: email address for a sub-sub-folders? In-Reply-To: <8nCt7xK00iWn01UWE0@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: nishri@gpu.utcc X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN We have an application where we will be adding support for mail delivery to an imap sub-sub-folder. For a subfolder the acceptable email address syntax appears to be userid+folder@hostname. What is it for a folder (eg folder2) of a folder (eg folder1): userid+folder1+folder2@hostname ? userid+folder1.folder2@hostname ? Is this covered in an rfc?   Received: from cnri by ietf.org id aa27976; 3 Apr 97 22:30 EST Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa26632; 3 Apr 97 22:30 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id TAA37076; Thu, 3 Apr 1997 19:24:59 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA25652 for ; Thu, 3 Apr 1997 19:24:23 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA13360 for ; Thu, 3 Apr 1997 19:24:21 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA14433 for ; Thu, 3 Apr 1997 19:24:15 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Thu, 3 Apr 1997 22:22:06 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Thu, 3 Apr 1997 22:22:04 -0500 Message-Id: <3.0.32.19970403221957.00dc4d50@lacroix.wildbear.on.ca> Date: Thu, 03 Apr 1997 22:19:58 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: alex.nishri@utoronto.ca, imap@cac.washington.edu Subject: Re: email address for a sub-sub-folders? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN At 10:17 PM 4/3/97 -0500, Alex Nishri wrote: >We have an application where we will be adding support for mail delivery >to an imap sub-sub-folder. For a subfolder the acceptable email address >syntax appears to be userid+folder@hostname. What is it for a folder >(eg folder2) of a folder (eg folder1): userid+folder1+folder2@hostname ? >userid+folder1.folder2@hostname ? > >Is this covered in an rfc? Its kind of implementation dependant... standards that are used are userid+folder+folder+drop and userid+folder.folder.drop as I understand them. Most of us also require that the ACLs for the drop are set to the 'p' right is enable.d regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa20056; 4 Apr 97 13:37 EST Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa15150; 4 Apr 97 13:37 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA24588; Fri, 4 Apr 1997 10:31:51 -0800 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA44870 for ; Fri, 4 Apr 1997 10:30:41 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA25223 for ; Fri, 4 Apr 1997 10:30:40 -0800 Received: from mailhost1.cac.washington.edu (mailhost1.cac.washington.edu [140.142.32.2]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA09498 for ; Fri, 4 Apr 1997 10:30:38 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA15405 for ; Fri, 4 Apr 1997 10:30:37 -0800 Message-Id: Date: Fri, 4 Apr 1997 10:20:33 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: IMAP Interest List Subject: text searching MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN The BODY and TEXT criteria for SEARCH were designed in 1985, before MIME existed. As a result, they are (implicitly) specified to do a free-text search of the entire RFC 822 message text (TEXT) or the text after the message header (body) without regard for MIME. This is what c-client still implements. To preserve this behavior, RFC-2060 requires MIME decoding only if a CHARSET argument was specified and was not US-ASCII. RFC-2060 also says that search "MAY exclude non-TEXT and non-MESSSAGE" body parts from searching. I don't know if we can do this without resetting the standards clock, but I would like to change it as follows: If CHARSET is not specified, then the 1985 behavior (free text search) MUST be done. If CHARSET is specified, then MIME decoding, skipping of binary texts, and coercion of all texts to UTF-8 MUST be done. This includes US-ASCII. The purpose of this is to eliminate server behavior ambiguity.   Received: from cnri by ietf.org id aa24681; 4 Apr 97 14:37 EST Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa16405; 4 Apr 97 14:37 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA54052; Fri, 4 Apr 1997 11:30:49 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA42652 for ; Fri, 4 Apr 1997 11:30:09 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA16501 for ; Fri, 4 Apr 1997 11:30:08 -0800 Received: from prowler.isocor.com (prowler.isocor.com [198.6.228.65]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA29845; Fri, 4 Apr 1997 11:30:04 -0800 Received: from erik.isocor.com (198.6.228.71) by prowler.isocor.com (NPlex 1.3.112); 4 Apr 1997 11:29:42 -0800 Message-Id: Date: Fri, 4 Apr 1997 11:31:25 -0800 (Pacific Standard Time) Reply-To: erik.forsberg@isocor.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Erik Forsberg To: Mark Crispin Cc: IMAP Interest List Subject: Re: text searching In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1b2 Build (6) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Fri, 4 Apr 1997 10:20:33 -0800 Mark Crispin wrote: > The BODY and TEXT criteria for SEARCH were designed in 1985, before MIME > existed. As a result, they are (implicitly) specified to do a free-text > search of the entire RFC 822 message text (TEXT) or the text after the message > header (body) without regard for MIME. This is what c-client still > implements. > > To preserve this behavior, RFC-2060 requires MIME decoding only if a CHARSET > argument was specified and was not US-ASCII. RFC-2060 also says that search > "MAY exclude non-TEXT and non-MESSSAGE" body parts from searching. > > I don't know if we can do this without resetting the standards clock, but I > would like to change it as follows: > > If CHARSET is not specified, then the 1985 behavior (free text search) MUST be > done. I would not be happy with the above change. If it read ... (free text search) MAY be done, that would make it acceptable. > If CHARSET is specified, then MIME decoding, skipping of binary texts, and > coercion of all texts to UTF-8 MUST be done. This includes US-ASCII. This is also not good. The standard shoudl say NOTHING about internal implementation. I do not at all convert all text to UTF-8 but I still support case-insensitive searches for all iso-8859 character sets. There is no reason for the spec to make my implementation invalid. > > The purpose of this is to eliminate server behavior ambiguity. > ---------------------- Erik Forsberg erik.forsberg@isocor.com   Received: from cnri by ietf.org id aa24784; 4 Apr 97 14:43 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa16564; 4 Apr 97 14:43 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA20302; Fri, 4 Apr 1997 11:37:18 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA36862 for ; Fri, 4 Apr 1997 11:36:32 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA17210 for ; Fri, 4 Apr 1997 11:36:28 -0800 Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA29988 for ; Fri, 4 Apr 1997 11:36:24 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA10968; Fri, 4 Apr 1997 11:36:22 -0800 Message-Id: Date: Fri, 4 Apr 1997 11:31:07 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: erik.forsberg@isocor.com Cc: IMAP Interest List Subject: Re: text searching In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Fri, 4 Apr 1997 11:31:25 -0800 (Pacific Standard Time), Erik Forsberg wrote: > I would not be happy with the above change. If it read ... > (free text search) MAY be done, that would make it acceptable. The problem is that with the status quo, we have an inconsistancy, which is also not good. We should make the protocol as unambiguous as possible. > > If CHARSET is specified, then MIME decoding, skipping of binary texts, and > > coercion of all texts to UTF-8 MUST be done. This includes US-ASCII. > This is also not good. The standard shoudl say NOTHING about > internal implementation. I do not at all convert all text to UTF-8 but > I still support case-insensitive searches for all iso-8859 character > sets. There is no reason for the spec to make my implementation invalid. I believe that the European practice of only supporting ISO-8859 should be strongly discouraged, on the grounds that this is not internationalization. We should think of 8859 solely in terms of "compatibility with the past". Unicode is coming, and the sooner this fact is recognized the better.   Received: from cnri by ietf.org id aa29260; 4 Apr 97 17:08 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa19472; 4 Apr 97 17:08 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA15287; Fri, 4 Apr 1997 14:03:00 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA51104 for ; Fri, 4 Apr 1997 14:02:26 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA02173 for ; Fri, 4 Apr 1997 14:02:24 -0800 Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA14761 for ; Fri, 4 Apr 1997 14:02:21 -0800 Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.100.202]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA14589; Fri, 4 Apr 1997 14:02:15 -0800 Message-Id: Date: Fri, 4 Apr 1997 14:02:12 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: David L Miller To: Jack De Winter Cc: alex.nishri@utoronto.ca, imap@cac.washington.edu Subject: Re: email address for a sub-sub-folders? In-Reply-To: <3.0.32.19970403221957.00dc4d50@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 3 Apr 1997, Jack De Winter wrote: > At 10:17 PM 4/3/97 -0500, Alex Nishri wrote: > >We have an application where we will be adding support for mail delivery > >to an imap sub-sub-folder. For a subfolder the acceptable email address > >syntax appears to be userid+folder@hostname. What is it for a folder > >(eg folder2) of a folder (eg folder1): userid+folder1+folder2@hostname ? > >userid+folder1.folder2@hostname ? > > > >Is this covered in an rfc? > > Its kind of implementation dependant... standards that are used are > userid+folder+folder+drop and userid+folder.folder.drop as I understand > them. Most of us also require that the ACLs for the drop are set to > the 'p' right is enable.d This is highly dependent on the delivery agent and does not really have anything to do with IMAP at all. Another form, used by tmail, is userid+dir/dir/folder@hostname I have also seen addresses of the form userid=folder@hostname (Qmail?) I have never seen an RFC or draft on this, but I'm sure it would be useful... -- David L. Miller | If I were two-faced, would I be Software Engineer, Pine Development Team | wearing this one? -- Abraham Box 354841, University of Washington | Lincoln 4545 15th Ave NE, Seattle WA 98105, USA | Phone: (206)685-6240 FAX: (206)685-4045 |   Received: from cnri by ietf.org id aa02338; 4 Apr 97 19:40 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa22306; 4 Apr 97 19:40 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA21403; Fri, 4 Apr 1997 16:36:08 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA46506 for ; Fri, 4 Apr 1997 16:35:31 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA03634 for ; Fri, 4 Apr 1997 16:35:30 -0800 Received: from memlinc.CS.Berkeley.EDU (memlinc.CS.Berkeley.EDU [128.32.42.128]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA07161 for ; Fri, 4 Apr 1997 16:35:27 -0800 Received: from localhost (jefleung@localhost) by memlinc.CS.Berkeley.EDU (8.6.10/8.6.9) with SMTP id QAA16017 for ; Fri, 4 Apr 1997 16:35:26 -0800 Message-Id: Date: Fri, 4 Apr 1997 16:35:26 -0800 (PST) Reply-To: Jeff!?! Leung Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jeff!?! Leung To: IMAP Mailing List Subject: Newbie Implementation questions MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Authentication-Warning: memlinc.CS.Berkeley.EDU: jefleung owned process doing -bs X-Sender: jefleung@memlinc.CS.Berkeley.EDU X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hello all. My group is implementing an IMAP server, and I had the following questions... 1. Is there a standard or suggested way to determine Mailbox flags for a FLAGS response? Is this solely an implementation decision? I would figure that directories are \Noselect, any mailbox changed since last select would be \Marked (otherwise \Unmarked), but I don't know how I would figure out \Noinferiors, unless I am using it to guarantee that the server is only minimal/basic conformance (in which case, LIST does not consider hierarchy?). 2. Same question, but for permanent flags. Is this a client dependent thing, or is it determined when the server starts up (admin's decision) 3. For LIST commands, how do we determine the hierarchy delimiter? For newsgroups, it's ".", and for folders it's typically "/". I would think that I could keep track of valid namespaces and store their respective delimiters with them, and after reading in a leading "#" for LIST's reference argument , I could compare the namespace to the namespace's delimiter. OK, that's it for now. Thanks! -- Jeff.   Received: from cnri by ietf.org id aa13788; 5 Apr 97 0:37 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa01700; 5 Apr 97 0:37 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id VAA29783; Fri, 4 Apr 1997 21:32:26 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA37014 for ; Fri, 4 Apr 1997 21:31:29 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA20739 for ; Fri, 4 Apr 1997 21:31:27 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA22775 for ; Fri, 4 Apr 1997 21:31:19 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Sat, 5 Apr 1997 00:30:21 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Sat, 5 Apr 1997 00:30:20 -0500 Message-Id: <3.0.32.19970405002745.00733794@lacroix.wildbear.on.ca> Date: Sat, 05 Apr 1997 00:27:46 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: imap@cac.washington.edu Subject: regarding time zone for the SEARCH modifiers... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN just out of curiousity, are the date SEARCH modifiers, such as SENTBEFORE, assume to operate on the server time or the universal time? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa29056; 5 Apr 97 19:15 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa16480; 5 Apr 97 19:15 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA06787; Sat, 5 Apr 1997 16:11:36 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA39872 for ; Sat, 5 Apr 1997 16:08:52 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA03130 for ; Sat, 5 Apr 1997 16:08:51 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA24668 for ; Sat, 5 Apr 1997 16:08:45 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Sat, 5 Apr 1997 19:07:51 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Sat, 5 Apr 1997 19:07:50 -0500 Message-Id: <3.0.32.19970405190456.00d913ac@lacroix.wildbear.on.ca> Date: Sat, 05 Apr 1997 19:04:58 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: imap@cac.washington.edu Subject: regarding SEARCH modifiers... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I was wondering if it was on purpose that there is not AND modifier for the SEARCH command? We have an OR and a NOT modifier, and I can see some cases where an AND modifier might be useful. I assume that under these cases, you would simply get the client to submit 2 searches, and have the client merge the results? Is there a more efficient way to do a search for effectively: if ANSWERED and not RECENT or RECENT and not SEEN? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa29426; 5 Apr 97 19:49 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa16894; 5 Apr 97 19:49 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA07674; Sat, 5 Apr 1997 16:46:08 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA51310 for ; Sat, 5 Apr 1997 16:44:23 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA13334 for ; Sat, 5 Apr 1997 16:44:21 -0800 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA06490 for ; Sat, 5 Apr 1997 16:44:19 -0800 Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.2/8.8.2/MOON) with ESMTP id QAA16211; Sat, 5 Apr 1997 16:44:14 -0800 (PST) Received: (from schaefer@localhost) by candle.brasslantern.com (8.7.6/8.7.3) id QAA09156; Sat, 5 Apr 1997 16:49:36 -0800 Message-Id: <970405164935.ZM9155@candle.brasslantern.com> Date: Sat, 5 Apr 1997 16:49:35 -0800 Reply-To: schaefer@nbn.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bart Schaefer To: Jack De Winter , imap@cac.washington.edu Subject: Re: regarding SEARCH modifiers... In-Reply-To: "Jack De Winter" "regarding SEARCH modifiers..." (Apr 5, 7:04pm) References: <3.0.32.19970405190456.00d913ac@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.820 20aug96) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Apr 5, 7:04pm, Jack De Winter wrote: } Subject: regarding SEARCH modifiers... } } I was wondering if it was on purpose that there is not AND modifier AND is automatic; all you have to do is submit multiple keys. See the second paragraph in 6.4.4 (second on p. 38). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern   Received: from cnri by ietf.org id aa08228; 5 Apr 97 23:22 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa00475; 5 Apr 97 23:22 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id UAA00559; Sat, 5 Apr 1997 20:18:02 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id UAA20610 for ; Sat, 5 Apr 1997 20:17:16 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id UAA13695 for ; Sat, 5 Apr 1997 20:17:14 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id UAA08929 for ; Sat, 5 Apr 1997 20:17:09 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Sat, 5 Apr 1997 23:16:45 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Sat, 5 Apr 1997 23:16:45 -0500 Message-Id: <3.0.32.19970405231346.00db0554@lacroix.wildbear.on.ca> Date: Sat, 05 Apr 1997 23:13:48 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: schaefer@nbn.com, imap@cac.washington.edu Subject: Re: regarding SEARCH modifiers... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN At 04:49 PM 4/5/97 -0800, Bart Schaefer wrote: >On Apr 5, 7:04pm, Jack De Winter wrote: >} Subject: regarding SEARCH modifiers... >} >} I was wondering if it was on purpose that there is not AND modifier > >AND is automatic; all you have to do is submit multiple keys. See the >second paragraph in 6.4.4 (second on p. 38). Got that one... but what happens if you want to do the equivalent of ( a AND b ) OR ( c AND d )? There is no way to express that cleanly due to the OR operand's construction... if there was an AND, the statement would be: OR AND a b AND c d regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa08813; 6 Apr 97 0:05 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa01096; 6 Apr 97 0:05 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id VAA13651; Sat, 5 Apr 1997 21:00:58 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA46420 for ; Sat, 5 Apr 1997 21:00:37 -0800 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA15497 for ; Sat, 5 Apr 1997 21:00:35 -0800 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA09422 for ; Sat, 5 Apr 1997 21:00:31 -0800 Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.2/8.8.2/MOON) with ESMTP id VAA24553; Sat, 5 Apr 1997 21:00:12 -0800 (PST) Received: (from schaefer@localhost) by candle.brasslantern.com (8.7.6/8.7.3) id VAA09689; Sat, 5 Apr 1997 21:05:34 -0800 Message-Id: <970405210533.ZM9688@candle.brasslantern.com> Date: Sat, 5 Apr 1997 21:05:33 -0800 Reply-To: schaefer@nbn.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bart Schaefer To: Jack De Winter , imap@cac.washington.edu Subject: Re: regarding SEARCH modifiers... In-Reply-To: "Jack De Winter" "Re: regarding SEARCH modifiers..." (Apr 5, 11:13pm) References: <3.0.32.19970405231346.00db0554@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.820 20aug96) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Apr 5, 11:13pm, Jack De Winter wrote: } Subject: Re: regarding SEARCH modifiers... } } At 04:49 PM 4/5/97 -0800, Bart Schaefer wrote: } >On Apr 5, 7:04pm, Jack De Winter wrote: } >} Subject: regarding SEARCH modifiers... } >} } >} I was wondering if it was on purpose that there is not AND modifier } > } >AND is automatic; all you have to do is submit multiple keys. See the } >second paragraph in 6.4.4 (second on p. 38). } } Got that one... but what happens if you want to do the equivalent of } ( a AND b ) OR ( c AND d )? 1 SEARCH OR ((subject a) (to b)) ((subject c) (cc d)) I just discovered that parenthesized lists can't have any excess white space, at least in so far as the UWash server is concerned; the above works, but 2 SEARCH OR ( ( subject a ) ( to b ) ) ( ( subject c ) ( cc d ) ) produces a BAD response. Is that really how it's supposed to work, Mark? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern   Received: from cnri by ietf.org id aa09179; 6 Apr 97 0:38 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa01640; 6 Apr 97 0:38 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id VAA02816; Sat, 5 Apr 1997 21:34:11 -0800 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA27732 for ; Sat, 5 Apr 1997 21:33:04 -0800 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA16772 for ; Sat, 5 Apr 1997 21:33:03 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id VAA28442 for ; Sat, 5 Apr 1997 21:33:00 -0800 Received: from Ikkoku-Kan.Panda.COM (sean@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id VAA01972; Sat, 5 Apr 1997 21:32:57 -0800 (PST) Received: from localhost (scott@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id VAA23577; Sat, 5 Apr 1997 21:32:52 -0800 (PST) Message-Id: Date: Sat, 5 Apr 1997 21:28:51 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: schaefer@nbn.com Cc: Jack De Winter , imap@cac.washington.edu Subject: Re: regarding SEARCH modifiers... In-Reply-To: <970405210533.ZM9688@candle.brasslantern.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Sat, 5 Apr 1997 21:05:33 -0800, Bart Schaefer wrote: > } Got that one... but what happens if you want to do the equivalent of > } ( a AND b ) OR ( c AND d )? > > 1 SEARCH OR ((subject a) (to b)) ((subject c) (cc d)) or just simply 1 SEARCH OR (subject a to b) (subject c cc d) If you want multiple words, you must use quotes 1 SEARCH OR (subject "paris trip" to "Fred Foobar") (subject c cc d) > I just discovered that parenthesized lists can't have any excess white > space, at least in so far as the UWash server is concerned; the above > works, but > > 2 SEARCH OR ( ( subject a ) ( to b ) ) ( ( subject c ) ( cc d ) ) > > produces a BAD response. Is that really how it's supposed to work, Mark? Yes, that's how it's supposed to work. Read the spec carefully. There is no free insertion of spaces anywhere in IMAP. Every character, including space, is significant in the protocol. In other words, if the spec calls for a SPACE at a particular point, there must be one (and only one) space at that point. If the spec does not call for a SPACE, there must not be any space at that point.   Received: from cnri by ietf.org id aa27625; 6 Apr 97 20:08 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa16294; 6 Apr 97 20:08 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA05694; Sun, 6 Apr 1997 17:04:45 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA20118 for ; Sun, 6 Apr 1997 17:04:03 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA12945 for ; Sun, 6 Apr 1997 17:04:01 -0700 Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA22678 for ; Sun, 6 Apr 1997 17:03:59 -0700 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA01163; Sun, 6 Apr 1997 17:03:20 -0700 Received: from mcm-nitro by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA11509; Sun, 6 Apr 1997 17:03:18 -0700 Received: from gentilly (awe182-33.AWE.Sun.COM) by mcm-nitro.eng.sun.com (PMDF V5.1-7 #22763) with SMTP id <0E88QUN1A008UQ@mcm-nitro.eng.sun.com>; Sun, 6 Apr 1997 17:04:00 -0700 (PDT) Message-Id: Date: Sun, 06 Apr 1997 17:00:35 -0700 (PDT) Reply-To: William Yeager Sender: IMAP-owner@u.washington.edu Precedence: bulk From: William Yeager To: schaefer@nbn.com Cc: Jack De Winter , imap@cac.washington.edu Subject: Re: regarding SEARCH modifiers... In-Reply-To: Your message with ID <970405210533.ZM9688@candle.brasslantern.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN A00168 SEARCH ALL OR (ALL FROM SHIEH) (ALL OR (ALL FROM CSG) (ALL OR (ALL FROM DWARREN) (ALL OR (ALL FROM VINCENT.RYAN) (ALL OR (ALL FROM SRIVASTAVA) (ALL OR (ALL FROM CATHYWU) (ALL OR (ALL FROM MHOY) (ALL OR (ALL FROM MSTURM) (ALL OR (ALL FROM SOFYAN) (ALL OR (ALL FROM MARTIN.FUJITANI@) (ALL OR (ALL FROM JAC) (ALL OR (ALL FROM CLIN) (ALL OR (ALL FROM "TODD MACKEY") (ALL OR (ALL FROM ELLIS) (ALL OR (ALL FROM KMAC) (ALL FROM JGEROMEL))))))))))))))) * SEARCH 3 16 25 29 30 32 35 52 54 61 75 77 80 83 86 107 130 140 154 155 177 187 189 196 201 203 212 220 224 227 233 236 297 315 335 336 355 356 360 382 384 A00168 OK SEARCH completed That is an example of a nested OR that works fine. A00245 SEARCH ALL FROM YEAGER NOT (ALL TO YEAGER) NOT (ALL CC YEAGER) * SEARCH 76 334 354 369 373 374 375 376 393 396 A00245 OK SEARCH completed The above is "from yeager AND NOT (to yeager OR cc yeager)" The simple application of De Morgan's laws is all that is required to do complete logical searches with NOT, OR and AND. Bill   Received: from cnri by ietf.org id aa23175; 7 Apr 97 15:38 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa17784; 7 Apr 97 15:38 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA09664; Mon, 7 Apr 1997 12:31:41 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA46498 for ; Mon, 7 Apr 1997 12:30:46 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA25900 for ; Mon, 7 Apr 1997 12:30:44 -0700 Received: from po7.andrew.cmu.edu (PO7.ANDREW.CMU.EDU [128.2.10.107]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA10364 for ; Mon, 7 Apr 1997 12:30:41 -0700 Received: (from postman@localhost) by po7.andrew.cmu.edu (8.8.2/8.8.2) id PAA16976 for imap@cac.washington.edu; Mon, 7 Apr 1997 15:30:36 -0400 Received: via switchmail; Mon, 7 Apr 1997 15:30:34 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 7 Apr 1997 15:29:13 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 7 Apr 1997 15:29:11 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 7 Apr 1997 15:29:09 -0400 (EDT) Message-Id: Date: Mon, 7 Apr 1997 15:29:09 -0400 (EDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: text searching In-Reply-To: References: X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN The Cyrus server treats the lack of a CHARSET specifier the same as if it got a "CHARSET us-ascii" specifier. So I would object to Mark's proposed change. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from cnri by ietf.org id aa23246; 7 Apr 97 15:45 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa17917; 7 Apr 97 15:45 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA47052; Mon, 7 Apr 1997 12:40:18 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA45568 for ; Mon, 7 Apr 1997 12:38:28 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA26712 for ; Mon, 7 Apr 1997 12:38:23 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA29066 for ; Mon, 7 Apr 1997 12:38:20 -0700 Received: from Ikkoku-Kan.Panda.COM (hgm@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id MAA03380; Mon, 7 Apr 1997 12:38:17 -0700 (PDT) Received: from localhost (helfa@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id MAA29775; Mon, 7 Apr 1997 12:38:13 -0700 (PDT) Message-Id: Date: Mon, 7 Apr 1997 12:35:01 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: John Gardiner Myers Cc: imap@cac.washington.edu Subject: Re: text searching In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Mon, 7 Apr 1997 15:29:09 -0400 (EDT), John Gardiner Myers wrote: > The Cyrus server treats the lack of a CHARSET specifier the same as if > it got a "CHARSET us-ascii" specifier. So I would object to Mark's > proposed change. I am aware of this. The problem is that this conflicts with the IMAP2 definition of SEARCH. The result is that the client does not know which form of search the server will do if charset is absent or if it's US-ASCII. Only a non-US-ASCII search is guaranteed to have a certain behavior. We really need to move towards One True Way of doing things instead of letting religious issues cause there to be "every server does its own thing." That message is coming in loud and clear from the client guys. I agree that the Cyrus style of search is better, and we should all move to that style. I'll be implementing that shortly. But I'm concerned about the past compatibility issues.   Received: from cnri by ietf.org id aa23409; 7 Apr 97 15:54 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa18114; 7 Apr 97 15:54 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA10350; Mon, 7 Apr 1997 12:49:22 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA26078 for ; Mon, 7 Apr 1997 12:49:04 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA11687 for ; Mon, 7 Apr 1997 12:49:02 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA10708 for ; Mon, 7 Apr 1997 12:48:58 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <2N3CJKGA>; Mon, 7 Apr 1997 12:48:44 -0700 Message-Id: Date: Mon, 7 Apr 1997 12:48:36 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Vladimir Vulovic (Exchange)" To: imap@cac.washington.edu Subject: rename questions MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN (Question #1) *** Should # RENAME foo foo/bar where "foo" mailbox exists and "foo/bar" mailbox does not exist, succeed? (Question #2) *** Does the following paragraph from RFC (6.3.5. RENAME Command): "Renaming INBOX is permitted, and has special behavior. It moves all messages in INBOX to a new mailbox with the given name, leaving INBOX empty. If the server implementation supports inferior hierarchical names of INBOX, these are unaffected by a rename of INBOX." means that RENAME for INBOX is never hiearchical? I.e. that # RENAME INBOX foo leaves "INBOX/bar" intact instead of renaming it into "foo/bar"? (Question #3) *** Should rename of an INBOX change UIDVALIDITY of an INBOX? Questions (1) and (2) assume "/" is a hierarchy delimiter: Thanks, Vladimir   Received: from cnri by ietf.org id aa24840; 8 Apr 97 14:40 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa18986; 8 Apr 97 14:40 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA16132; Tue, 8 Apr 1997 11:35:21 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA51032 for ; Tue, 8 Apr 1997 11:34:37 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA10828 for ; Tue, 8 Apr 1997 11:34:35 -0700 Received: from po6.andrew.cmu.edu (PO6.ANDREW.CMU.EDU [128.2.10.106]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA23880 for ; Tue, 8 Apr 1997 11:34:32 -0700 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.8.2/8.8.2) id OAA11058 for imap@cac.washington.edu; Tue, 8 Apr 1997 14:34:23 -0400 Received: via switchmail; Tue, 8 Apr 1997 14:34:15 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 8 Apr 1997 14:15:19 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 8 Apr 1997 14:15:17 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 8 Apr 1997 14:15:14 -0400 (EDT) Message-Id: Date: Tue, 8 Apr 1997 14:15:14 -0400 (EDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: text searching In-Reply-To: References: X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I think in this case you're overly worried. The semantics of the IMAP2 definition of SEARCH which are not in the semantics of SEARCH CHARSET US-ASCII are simply not useful. Mandating implementation of non-useful semantics is pointless. IMAP2 is ancient history. We need to concentrate on looking forward, not backwards. -- _.John Gardiner Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up   Received: from cnri by ietf.org id aa05085; 9 Apr 97 23:36 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa00745; 9 Apr 97 23:36 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id UAA02955; Wed, 9 Apr 1997 20:32:28 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id UAA47530 for ; Wed, 9 Apr 1997 20:29:52 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id UAA18045 for ; Wed, 9 Apr 1997 20:29:51 -0700 Received: from rainier.tpdinc.com (rainier.tpdinc.com [206.136.148.3]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id UAA02675 for ; Wed, 9 Apr 1997 20:29:48 -0700 Received: from orcas.tpdinc.com by rainier.tpdinc.com (8.7.5/TPD-Sendmail-2.0-072396) id UAA28126; Wed, 9 Apr 1997 20:30:02 -0700 (PDT) Message-Id: Date: Wed, 9 Apr 1997 20:32:18 -0700 (Pacific Daylight Time) Reply-To: Nick Silberstein Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Nick Silberstein To: imap@cac.washington.edu Subject: Recurring error with UW IMAPd & Solaris 2.5 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-X-Sender: nick@rainier.tpdinc.com X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hello all, I've been having a recurring problem with UW's IMAP daemon & assorted clients I've been trying to use in conjunction with it. The connection seems to inexplicably die quite frequently; Pine, for example, complains: [MAIL FOLDER "INBOX" CLOSED DUE TO ACCESS ERROR]. This problem generally occurs when there has been a short period of inactivity; ie, no operations have been processed by the server, such as retrieving or expunging messages. This period of time is much less than the 60*3 compiled in time-out (I assume this is in seconds, 3 minutes?); it is also not consistent; sometimes it will happen a second after opening a mailbox, othertimes not for a minute. It also occurs sometimes directly after receiving new mail, which would seem to indicate a locking problem, but doesn't explain the former error. Is this a known/confirmed problem with the UW imapd & Solaris, or is it something I am doing wrong? It's making working with imap rather difficult. :( Configuration: Server ------ Solaris 2.5, UW IMAP daemon (IMAP4rev1 v10.171) No rcfile in use. Compiled with 'make gso' (gcc solaris), run from inetd Client ------ Linux - Pine 3.96 WinNT - PC-Pine 3.96, Outlook Express, several others, all with same results. I'd greatly appreciate any help anyone could offer; I would be surprised if I have been the first person to experience this problem, but was unable to locate any references to it, both in IMAP documentation & in archives of this and Pine's mailing lists. Thanks very much, Nick Silberstein   Received: from cnri by ietf.org id aa14291; 11 Apr 97 9:59 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa10470; 11 Apr 97 9:59 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id GAA08963; Fri, 11 Apr 1997 06:53:54 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id GAA41842 for ; Fri, 11 Apr 1997 06:49:35 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id GAA09674 for ; Fri, 11 Apr 1997 06:49:34 -0700 Received: from usr10.primenet.com (root@usr10.primenet.com [206.165.5.110]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id GAA07428 for ; Fri, 11 Apr 1997 06:49:27 -0700 Received: from primenet.com (root@mailhost02.primenet.com [206.165.5.53]) by usr10.primenet.com (8.8.5/8.8.5) with ESMTP id GAA16028 for ; Fri, 11 Apr 1997 06:49:26 -0700 (MST) Received: from usr06.primenet.com (kdh@usr06.primenet.com [206.165.5.106]) by primenet.com (8.8.5/8.8.5) with SMTP id GAA09656 for ; Fri, 11 Apr 1997 06:49:24 -0700 (MST) Message-Id: Date: Fri, 11 Apr 1997 06:49:25 -0700 (MST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Kathleen Daily-Herrman To: imap@cac.washington.edu Subject: "imap create argument missing"? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: kdh@usr06.primenet.com X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hi.. I'm trying to set up pcpine on my local pc for remote access to another system. It works fine and I can see and manipulate my inbox and all my folders. However, when I try to create a message and send... it gives me either a message that it I have an "imap create argument missing. I've tried very hard to get the syntax correct with the following folders below but something is missing. The path to the folders is not correct because when i send the message it it tries to find the sent-mail folder and can't find it. Does anyone know where I can find IMAP create arguments? I've tried looking through the site http://www.imap.org but I can't seem to find what I need. default-fcc = {my.mailhost.com}mail/sent-mail default-saved-msg-folder = {my.mailhost.com}mail/saved-messages postponed-folder = {my.mailhost.com}mail/postponed-msgs thx. Kathleen   Received: from cnri by ietf.org id aa14886; 11 Apr 97 10:36 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa11150; 11 Apr 97 10:36 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id HAA29066; Fri, 11 Apr 1997 07:22:50 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA37046 for ; Fri, 11 Apr 1997 07:22:08 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA22462 for ; Fri, 11 Apr 1997 07:22:07 -0700 Received: from usr07.primenet.com (root@usr07.primenet.com [206.165.5.107]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA20450 for ; Fri, 11 Apr 1997 07:22:04 -0700 Received: from primenet.com (root@mailhost02.primenet.com [206.165.5.53]) by usr07.primenet.com (8.8.5/8.8.5) with ESMTP id HAA03696 for ; Fri, 11 Apr 1997 07:22:02 -0700 (MST) Received: from usr08.primenet.com (kdh@usr08.primenet.com [206.165.5.108]) by primenet.com (8.8.5/8.8.5) with SMTP id HAA16688 for ; Fri, 11 Apr 1997 07:22:00 -0700 (MST) Message-Id: Date: Fri, 11 Apr 1997 07:22:00 -0700 (MST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Kathleen Daily-Herrman To: imap@cac.washington.edu Subject: sorry MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: kdh@usr08.primenet.com X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I'm directing my question to appropriate list.. please disregard my question about the "imap" create errors. I apologize for any inconvenience Kathleen   Received: from cnri by ietf.org id aa16118; 11 Apr 97 12:00 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa12951; 11 Apr 97 12:00 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id IAA44876; Fri, 11 Apr 1997 08:56:47 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA28804 for ; Fri, 11 Apr 1997 08:55:26 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA29584 for ; Fri, 11 Apr 1997 08:39:47 -0700 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA22034 for ; Fri, 11 Apr 1997 08:39:41 -0700 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 11 Apr 1997 11:38:21 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 11 Apr 1997 11:38:20 -0400 Message-Id: <3.0.32.19970411113507.00dd45b0@lacroix.wildbear.on.ca> Date: Fri, 11 Apr 1997 11:35:08 -0400 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: imap@cac.washington.edu Subject: again: regarding time zone for the SEARCH modifiers... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN >>From imap-owner@u.washington.edu Sat Apr 05 00:32:34 1997 >Date: Sat, 05 Apr 1997 00:27:46 -0500 >Sender: IMAP-owner@u.washington.edu >From: "Jack De Winter" >To: imap@cac.washington.edu >Subject: regarding time zone for the SEARCH modifiers... >X-Sender: "Jack De Winter" >X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN > >just out of curiousity, are the date SEARCH modifiers, such >as SENTBEFORE, assume to operate on the server time or the >universal time? Sent this out before, and no response. The big part of this is that if we are doing it in UTC, and I want to search on any message that I have received into my mailstore, I can only do it with respect to midnight UTC, not midnight local time. Is that really useful? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa17949; 11 Apr 97 13:22 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa14700; 11 Apr 97 13:22 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA08817; Fri, 11 Apr 1997 10:18:19 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA20332 for ; Fri, 11 Apr 1997 10:17:14 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA00742 for ; Fri, 11 Apr 1997 10:17:12 -0700 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA24708 for ; Fri, 11 Apr 1997 10:17:09 -0700 Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.2/8.8.2/MOON) with ESMTP id KAA07328; Fri, 11 Apr 1997 10:17:06 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.7.6/8.7.3) id KAA04248; Fri, 11 Apr 1997 10:22:42 -0700 Message-Id: <970411102242.ZM4247@candle.brasslantern.com> Date: Fri, 11 Apr 1997 10:22:42 -0700 Reply-To: schaefer@nbn.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bart Schaefer To: Jack De Winter , imap@cac.washington.edu Subject: Re: again: regarding time zone for the SEARCH modifiers... In-Reply-To: "Jack De Winter" "again: regarding time zone for the SEARCH modifiers..." (Apr 11, 11:35am) References: <3.0.32.19970411113507.00dd45b0@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.820 20aug96) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Apr 11, 11:35am, Jack De Winter wrote: } Subject: again: regarding time zone for the SEARCH modifiers... } } >just out of curiousity, are the date SEARCH modifiers, such } >as SENTBEFORE, assume to operate on the server time or the } >universal time? } } Sent this out before, and no response. The big part of this is that } if we are doing it in UTC, and I want to search on any message that } I have received into my mailstore, I can only do it with respect to } midnight UTC, not midnight local time. Is that really useful? The spec doesn't say whether any timezone conversions are ever done. The implication is that time and timezone are ignored. Thus: Searches on internal date use the server's local time. Searches on sent date use the *sender's* local time (the value from the Date: header). It would actually be far *more* useful to specify that everything was normalized to universal time; then clients would at least know how to adjust for the user's local time zone. What puzzles me is why SENTBEFORE et.al. take only a and not a . You're right about this making searches ambiguous; if I want to implement more accurate searching in my client, I have to get messages covering at least one extra date from the server, then prune out on the client those that don't actually fit the criteria. The best world would both specify universal time and permit SEARCHes to specify at least a time and optionally a timezone. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern   Received: from cnri by ietf.org id aa22327; 11 Apr 97 18:47 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa21699; 11 Apr 97 18:47 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA26271; Fri, 11 Apr 1997 15:43:42 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA48626 for ; Fri, 11 Apr 1997 15:42:30 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA00674 for ; Fri, 11 Apr 1997 15:42:28 -0700 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA19759 for ; Fri, 11 Apr 1997 15:42:22 -0700 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 11 Apr 1997 18:42:21 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 11 Apr 1997 18:42:20 -0400 Message-Id: <3.0.32.19970411183907.006cde30@lacroix.wildbear.on.ca> Date: Fri, 11 Apr 1997 18:39:08 -0400 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: schaefer@nbn.com, imap@cac.washington.edu Subject: Re: again: regarding time zone for the SEARCH modifiers... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN >The spec doesn't say whether any timezone conversions are ever done. >The implication is that time and timezone are ignored. Thus: > > Searches on internal date use the server's local time. > > Searches on sent date use the *sender's* local time (the > value from the Date: header). > >It would actually be far *more* useful to specify that everything was >normalized to universal time; then clients would at least know how to >adjust for the user's local time zone. My problem is that the server and the client may be in different zones, so that the above behaviour is not always predicatable. Take the IETF meeting in Memphis, -1 from where my server was. Granted, it is only an hour's difference, but a client in Memphis accessing a server in Kitchener would have to know the time zone at the server end, and there currently is no such way to find this. >What puzzles me is why SENTBEFORE et.al. take only a and not a >. You're right about this making searches ambiguous; if I >want to implement more accurate searching in my client, I have to get >messages covering at least one extra date from the server, then prune >out on the client those that don't actually fit the criteria. > >The best world would both specify universal time and permit SEARCHes to >specify at least a time and optionally a timezone. I would rather see this proceed as usual, but allow for an optional time zone specifier. Granted, I can go very easily between local and universal time, but also allowing for something to find out what time zone the server is in would be useful. Extensions perhaps? If needed, I will write something up for this, but would like to see how many vendors out there think that the extension would be used a lot. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa22657; 11 Apr 97 19:17 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa22219; 11 Apr 97 19:17 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA27811; Fri, 11 Apr 1997 16:14:12 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA20808 for ; Fri, 11 Apr 1997 16:13:46 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA03448 for ; Fri, 11 Apr 1997 16:13:44 -0700 Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA03253 for ; Fri, 11 Apr 1997 16:13:41 -0700 Received: from mv-mcquilwp.mv.unisys.com ([192.59.248.79]) by bbmail1.unisys.com (8.8.5/8.6.12) with SMTP id XAA17209 for ; Fri, 11 Apr 1997 23:13:13 GMT Message-Id: <334EC570.5D5C@mpa15ab.mv.unisys.com> Date: Fri, 11 Apr 1997 16:12:48 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bill McQuillan To: imap@cac.washington.edu Subject: Re: again: regarding time zone for the SEARCH modifiers... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN >>It would actually be far *more* useful to specify that everything was >>normalized to universal time; then clients would at least know how to >>adjust for the user's local time zone. > >My problem is that the server and the client may be in different zones, >so that the above behaviour is not always predicatable. Take the IETF >meeting in Memphis, -1 from where my server was. Granted, it is only an >hour's difference, but a client in Memphis accessing a server in Kitchener >would have to know the time zone at the server end, and there currently is >no such way to find this. Actually, if the SEARCH was always done in UTC *and* a time was allowed in the argument the UA could synthesize any timezone that it desired. The server's timezone would be irrelevant. Perhaps if no time is given, the server should use its own timezone as the best guess at the client's timezone. Bill McQuillan   Received: from cnri by ietf.org id aa22890; 11 Apr 97 19:38 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa22506; 11 Apr 97 19:38 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA09015; Fri, 11 Apr 1997 16:35:29 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA04524 for ; Fri, 11 Apr 1997 16:34:55 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA08849 for ; Fri, 11 Apr 1997 16:34:53 -0700 Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id QAA03728 for ; Fri, 11 Apr 1997 16:34:51 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id QAA15935 for ; Fri, 11 Apr 1997 16:34:50 -0700 Message-Id: Date: Fri, 11 Apr 1997 16:19:05 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: IMAP Interest List Subject: Re: again: regarding time zone for the SEARCH modifiers... In-Reply-To: <334EC570.5D5C@mpa15ab.mv.unisys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN My take on this issue: I don't think that it is very useful to overengineer the date searching. My implementation uses the date "as the user sees it" without regard to timezone; that is, the internal dates are searched in the server's timezone, and the Date: headers are searched in the composer's timezone. In other words: Date: Fri, 31 Dec 1999 13:23:45 -0800 and Date: Sat, 1 Jan 2000 08:23:45 +0900 are considered to be different days, even though they refer to the same time. Similarly, internal dates of 1-Jan-2000 08:23:45 +0900 and 31-Dec-1999 13:23:45 -0800 are also considered to be different days. This is less likely to be a problem since it is highly unlikely that a server would have multiple timezones except for summer time (at least in the USA, that doesn't cause a date ambiguity since the transition happens at 0200). It was done this way because the claim was, once upon a time, that users would be confused by a "31 Dec 1999" message coming up on a "SEARCH ON 1-JAN-2000" because that message happened to be in a timezone west of Greenwich (which happens to be all of the Americas). However, if the general concensus is that times should be compared absolutely according to UTC for searching, it wouldn't be hard for me to change it. My sort already does absolute time comparisons.   Received: from cnri by ietf.org id aa23698; 11 Apr 97 20:45 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa23483; 11 Apr 97 20:45 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA11874; Fri, 11 Apr 1997 17:42:25 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA48502 for ; Fri, 11 Apr 1997 17:42:00 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA22194 for ; Fri, 11 Apr 1997 17:41:58 -0700 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA05127; Fri, 11 Apr 1997 17:41:54 -0700 Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.2/8.8.2/MOON) with ESMTP id RAA02314; Fri, 11 Apr 1997 17:41:55 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.7.6/8.7.3) id RAA05209; Fri, 11 Apr 1997 17:47:32 -0700 Message-Id: <970411174732.ZM5208@candle.brasslantern.com> Date: Fri, 11 Apr 1997 17:47:32 -0700 Reply-To: schaefer@nbn.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bart Schaefer To: Mark Crispin , IMAP Interest List Subject: Re: again: regarding time zone for the SEARCH modifiers... In-Reply-To: Mark Crispin "Re: again: regarding time zone for the SEARCH modifiers..." (Apr 11, 4:19pm) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.820 20aug96) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Apr 11, 4:19pm, Mark Crispin wrote: > Subject: Re: again: regarding time zone for the SEARCH modifiers... > > However, if the general concensus is that times should be compared absolutely > according to UTC for searching, it wouldn't be hard for me to change it. My > sort already does absolute time comparisons. There are two issues here: 1. If times should be compared absolutely according to UTC, the spec needs to say so. Can this be changed? 2. In order for the above to be useful, the client needs to be able to say with more accuracy than a day what times it is interested in (because the conversion will sometimes cause a messge to "change days"). Can the spec be changed to permit in SEARCH commands? If the answer to (2) is "no", then I think the behavior Mark described (use the server local and sender local dates, ignore times) is less confusing and should be explicitly specified if at all possible.   Received: from cnri by ietf.org id aa23737; 11 Apr 97 20:49 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa23550; 11 Apr 97 20:49 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA01871; Fri, 11 Apr 1997 17:46:12 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA20832 for ; Fri, 11 Apr 1997 17:45:42 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA14409 for ; Fri, 11 Apr 1997 17:45:40 -0700 Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA22438 for ; Fri, 11 Apr 1997 17:45:39 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA17606; Fri, 11 Apr 1997 17:45:36 -0700 Message-Id: Date: Fri, 11 Apr 1997 17:43:38 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: schaefer@nbn.com Cc: IMAP Interest List Subject: Re: again: regarding time zone for the SEARCH modifiers... In-Reply-To: <970411174732.ZM5208@candle.brasslantern.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Fri, 11 Apr 1997 17:47:32 -0700, Bart Schaefer wrote: > 1. If times should be compared absolutely according to UTC, the spec needs > to say so. Can this be changed? It can't be changed without resetting the standards timer. It could, however, be clarified. > 2. In order for the above to be useful, the client needs to be able to say > with more accuracy than a day what times it is interested in (because > the conversion will sometimes cause a messge to "change days"). Can > the spec be changed to permit in SEARCH commands? Ditto. > If the answer to (2) is "no", then I think the behavior Mark described (use > the server local and sender local dates, ignore times) is less confusing and > should be explicitly specified if at all possible. >From the point of view of my server, this would be a clarification and OK. But it depends upon what others think. It's not very important to me, but it seems to be important to some people.   Received: from cnri by ietf.org id aa24304; 11 Apr 97 21:42 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa24258; 11 Apr 97 21:42 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA08880; Fri, 11 Apr 1997 18:39:19 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA30836 for ; Fri, 11 Apr 1997 18:38:49 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA25723 for ; Fri, 11 Apr 1997 18:38:47 -0700 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA23196; Fri, 11 Apr 1997 18:38:38 -0700 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 11 Apr 1997 21:38:21 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 11 Apr 1997 21:38:19 -0400 Message-Id: <3.0.32.19970411213502.006d0804@lacroix.wildbear.on.ca> Date: Fri, 11 Apr 1997 21:35:05 -0400 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: Mark Crispin , schaefer@nbn.com Cc: IMAP Interest List Subject: Re: again: regarding time zone for the SEARCH modifiers... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN At 05:43 PM 4/11/97 -0700, Mark Crispin wrote: >On Fri, 11 Apr 1997 17:47:32 -0700, Bart Schaefer wrote: >> 1. If times should be compared absolutely according to UTC, the spec needs >> to say so. Can this be changed? > >It can't be changed without resetting the standards timer. It could, however, >be clarified. > >> 2. In order for the above to be useful, the client needs to be able to say >> with more accuracy than a day what times it is interested in (because >> the conversion will sometimes cause a messge to "change days"). Can >> the spec be changed to permit in SEARCH commands? > >Ditto. > >> If the answer to (2) is "no", then I think the behavior Mark described (use >> the server local and sender local dates, ignore times) is less confusing and >> should be explicitly specified if at all possible. > >>From the point of view of my server, this would be a clarification and OK. >But it depends upon what others think. It's not very important to me, but it >seems to be important to some people. I guess part of it from my POV is just getting the standards a bit clearer, and hence, some kind of clarification on the effective time zones in the Internal Date bassed search and the Header Date based search would help. As for going beyond that, I think that I would be willing to write an extension to accept full date-time constructs for a search, and have it ready in short order. (After I get something finished and sent his way for approval, for another RFC based thingy...) regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa16000; 12 Apr 97 17:34 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa15528; 12 Apr 97 17:34 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA07740; Sat, 12 Apr 1997 14:30:38 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA45098 for ; Sat, 12 Apr 1997 14:28:36 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA29143 for ; Sat, 12 Apr 1997 14:28:35 -0700 Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA07844 for ; Sat, 12 Apr 1997 14:28:33 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHMDJIUWCA99EAA4@INNOSOFT.COM> for imap@cac.washington.edu; Sat, 12 Apr 1997 14:28:29 PDT Message-Id: Date: Sat, 12 Apr 1997 14:29:52 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: "Vladimir Vulovic (Exchange)" Cc: imap@cac.washington.edu Subject: Re: rename questions In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Mon, 7 Apr 1997, Vladimir Vulovic (Exchange) wrote: > (Question #1) *** > > Should > > # RENAME foo foo/bar > > where "foo" mailbox exists and "foo/bar" mailbox does not exist, > succeed? I would say yes. The spec is not clear. > (Question #2) *** > > Does the following paragraph from RFC (6.3.5. RENAME Command): > > "Renaming INBOX is permitted, and has special behavior. It moves > all messages in INBOX to a new mailbox with the given name, > leaving INBOX empty. If the server implementation supports > inferior hierarchical names of INBOX, these are unaffected by a > rename of INBOX." > > means that RENAME for INBOX is never hiearchical? I.e. that > > # RENAME INBOX foo > > leaves "INBOX/bar" intact instead of renaming it into "foo/bar"? That was the intent of that line. > (Question #3) *** > > Should rename of an INBOX change UIDVALIDITY of an INBOX? I don't think it really matters as long as UIDs are used consistantly with the decision (e.g. can't reset UIDNEXT unless UIDVALIDITY is also reset).   Received: from cnri by ietf.org id aa16113; 12 Apr 97 17:44 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa15660; 12 Apr 97 17:44 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA28488; Sat, 12 Apr 1997 14:40:59 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA20802 for ; Sat, 12 Apr 1997 14:40:09 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA08756 for ; Sat, 12 Apr 1997 14:40:08 -0700 Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA20677 for ; Sat, 12 Apr 1997 14:40:06 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHMDWNT7BO99EAA4@INNOSOFT.COM> for IMAP@cac.washington.edu; Sat, 12 Apr 1997 14:39:04 PDT Message-Id: Date: Sat, 12 Apr 1997 14:40:28 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: IMAP Interest List Subject: Re: again: regarding time zone for the SEARCH modifiers... In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I think it was a rather serious mistake to not use date-time in the SEARCH modifiers. Failure to fully qualify such things always results in this sort of problem. I'm embarassed I didn't catch this before RFC 2060 was published. Now it's too late to fix properly. Now we're left with a choice between: (1) Something which may be what the user wants (if user is in same timezone as server), but is unpredictable. (2) Something which probably isn't what the user wants, but is predictable. For the sake of interoperability, I'm leaning towards (2). Unpredictable results in a protocol is a design error.   Received: from cnri by ietf.org id aa16273; 12 Apr 97 17:57 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa15818; 12 Apr 97 17:57 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA28995; Sat, 12 Apr 1997 14:53:48 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA51008 for ; Sat, 12 Apr 1997 14:53:14 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA09339 for ; Sat, 12 Apr 1997 14:53:13 -0700 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA20841 for ; Sat, 12 Apr 1997 14:53:08 -0700 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Sat, 12 Apr 1997 17:53:22 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Sat, 12 Apr 1997 17:53:21 -0400 Message-Id: <3.0.32.19970412174945.00daed50@lacroix.wildbear.on.ca> Date: Sat, 12 Apr 1997 17:49:46 -0400 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: IMAP@cac.washington.edu Subject: questioning FETCH subcommands... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Okay, I have been racking my brain on these for a while, but: 1) are BODY and BODYSTRUCTURE the exact same, except for the heading? I have been told yes and no, and the grammar for both of these has "SPACE body" after the subcommand name. Now, if they are both there, why? The main body of the document says that BODY uses the non-extensible form of BODYSTRUCTURE, yet the grammar is the same. 2) On the MIME subpart, do we have any resolution? The spec does say that if it is not multipart, then "only have a part 1". 3) If the RFC commands (except for RFC822.SIZE) all have counterparts in the other commands (i.e. RFC822 is BODY[]) why do we have them there at all? trying to keep interoperable, regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa00114; 13 Apr 97 4:42 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa05055; 13 Apr 97 4:42 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id BAA13684; Sun, 13 Apr 1997 01:39:13 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA41948 for ; Sun, 13 Apr 1997 01:38:43 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA03683 for ; Sun, 13 Apr 1997 01:38:41 -0700 Received: from prowler.isocor.com (prowler.isocor.com [198.6.228.65]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA28708 for ; Sun, 13 Apr 1997 01:38:39 -0700 Received: from win.efca.com (198.6.231.35) by prowler.isocor.com (NPlex 1.3.125); 13 Apr 1997 02:39:08 -0700 Message-Id: Date: Sun, 13 Apr 1997 01:38:36 -0700 (Pacific Daylight Time) Reply-To: erik.forsberg@isocor.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Erik Forsberg To: Chris Newman Cc: imap@cac.washington.edu, "Vladimir Vulovic (Exchange)" Subject: Re: rename questions In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1 Build (11) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Sat, 12 Apr 1997 14:29:52 -0700 Chris Newman wrote: > On Mon, 7 Apr 1997, Vladimir Vulovic (Exchange) wrote: > > (Question #1) *** > > > > Should > > > > # RENAME foo foo/bar > > > > where "foo" mailbox exists and "foo/bar" mailbox does not exist, > > succeed? > > I would say yes. The spec is not clear. > That should not be taken for granted. My server disallows that because it does generate an internal consistency problem. Not even the UNIX file system (at least BSD which I just tested) does not allow such a RENAME ---------------------- Erik Forsberg erik.forsberg@isocor.com   Received: from cnri by ietf.org id aa01496; 13 Apr 97 6:51 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa06721; 13 Apr 97 6:51 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id DAA14909; Sun, 13 Apr 1997 03:48:28 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id DAA43688 for ; Sun, 13 Apr 1997 03:47:49 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id DAA11574 for ; Sun, 13 Apr 1997 03:47:47 -0700 Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id DAA17450 for ; Sun, 13 Apr 1997 03:47:45 -0700 Received: from mail.pak.net ([203.135.1.2]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id DAA18347 for ; Sun, 13 Apr 1997 03:47:14 -0700 (PDT) Received: by khi.pak.net (1.65/waf) via UUCP; Sun, 13 Apr 97 15:45:03 GMT+5 for IMAP@cac.washington.edu Received: by scn.khi.pak.net (Mini-Host for Windows v1.51; WinUUCP) with UUCP; Sun, 13 Apr 1997 15:42:35 -0500 (GMT) Message-Id: <1997Apr13.154235@scn.khi.pak.net> Date: Sun, 13 Apr 1997 15:42:35 -0500 (GMT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Adnan Waheed To: IMAP@cac.washington.edu Subject: Request for Information : How to get Start on IMAP In-Reply-To: <3.0.32.19970412174945.00daed50@lacroix.wildbear.on.ca>; from "Jack De Winter" at Apr 12, 97 4:49 X-Mailer: Mini-Host for Windows v1.51; Data Manager X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Dear IMAP Users! This is an oppourtunity to thank you for providing innovative communication trends in IT industry aroud the globe via IMAP. I would to developed a sample IMAP client and a Server for Windows NT. Please guide us what sources/ steps do i take in order to get Start developing IMAP centric application. I have gone through with the sample IMAP toolkit along with the relevent RFC's as such. I am very mew in IMAP, and will be looking forward for a kind response for the same. Regards --- Adnan Waheed (adnan@scn.khi.pak.net) CatCuss Communications www.catcuss.com ... Sun, 13 Apr 97 15:35 -0500 GMT   Received: from cnri by ietf.org id aa26188; 14 Apr 97 8:27 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa08700; 14 Apr 97 8:27 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id FAA29086; Mon, 14 Apr 1997 05:22:12 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA19238 for ; Mon, 14 Apr 1997 05:17:47 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA17105 for ; Mon, 14 Apr 1997 05:17:44 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA05946 for ; Mon, 14 Apr 1997 05:17:42 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id IAA13808 for ; Mon, 14 Apr 1997 08:07:52 -0400 Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id IAA26887 for ; Mon, 14 Apr 1997 08:17:40 -0400 Message-Id: Date: Mon, 14 Apr 1997 08:16:07 -0400 (Eastern Daylight Time) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Barry Leiba To: IMAP Subject: Re: questioning FETCH subcommands... In-Reply-To: <3.0.32.19970412174945.00daed50@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: leibax@watson.ibm.com X-Mailer: Simeon for Win32 Version 4.1.1 Build (11) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Sat, 12 Apr 97 17:49:46 -0400 Jack De Winter wrote: > 1) are BODY and BODYSTRUCTURE the exact same, except for the > heading? I have been told yes and no, and the grammar for > both of these has "SPACE body" after the subcommand name. > Now, if they are both there, why? The main body of the > document says that BODY uses the non-extensible form of > BODYSTRUCTURE, yet the grammar is the same. The grammar is not the same, though I think the grammar is awkwardly specified. But look at the grammar for "body_ext_1part" and "body_ext_mpart". The idea is that these items can be returned by FETCH BODYSTRUCTURE, but not by FETCH BODY. > 3) If the RFC commands (except for RFC822.SIZE) all have counterparts > in the other commands (i.e. RFC822 is BODY[]) why do we have them > there at all? History. I'd love to see them go away. Perhaps the spec should deprecate them but still recommend support of them for older clients. Perhaps, too, we should have a "body[size]" to replace "rfc822.size". Barry Leiba, Multimedia Messaging (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba   Received: from cnri by ietf.org id aa02996; 14 Apr 97 13:24 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa15642; 14 Apr 97 13:24 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA42536; Mon, 14 Apr 1997 10:19:05 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA51860 for ; Mon, 14 Apr 1997 10:17:34 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA02427 for ; Mon, 14 Apr 1997 10:17:32 -0700 Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA11495 for ; Mon, 14 Apr 1997 10:17:30 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHOXBR0KJ499F70S@INNOSOFT.COM> for imap@cac.washington.edu; Mon, 14 Apr 1997 10:16:27 PDT Message-Id: Date: Mon, 14 Apr 1997 10:17:52 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: Erik Forsberg Cc: IMAP Discusson List Subject: Re: rename questions In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Sun, 13 Apr 1997, Erik Forsberg wrote: > wrote: > > On Mon, 7 Apr 1997, Vladimir Vulovic (Exchange) wrote: > > > Should > > > > > > # RENAME foo foo/bar > > > > > > where "foo" mailbox exists and "foo/bar" mailbox does not exist, > > > succeed? > > > > I would say yes. The spec is not clear. > > > That should not be taken for granted. My server disallows that because > it does generate an internal consistency problem. Not even the UNIX file > system (at least BSD which I just tested) does not allow such a RENAME It's a general principle that a server should only respond NO under the following conditions: (a) The spec says you have to say NO. (b) There is no reasonable action the server can take to honor the request. I said yes, because I believe that the command has a clear interpretation which the server can follow (on unix it'd be equivalent to: mv foo foo.tmp ; mkdir foo ; mv foo.tmp foo/bar). Of course, this is another of those edge conditions which are sufficiently rare that it's probably not a big deal one way or the other.   Received: from cnri by ietf.org id aa04643; 14 Apr 97 14:29 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa17067; 14 Apr 97 14:29 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA08041; Mon, 14 Apr 1997 11:24:58 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA48544 for ; Mon, 14 Apr 1997 11:23:59 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA10259 for ; Mon, 14 Apr 1997 11:23:58 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA26484 for ; Mon, 14 Apr 1997 11:23:56 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <2R1T2GS8>; Mon, 14 Apr 1997 11:24:03 -0700 Message-Id: Date: Mon, 14 Apr 1997 11:24:01 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mark Pustilnik (Exchange)" To: 'IMAP Discusson List' Subject: SEARCH HEADER question MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Here is a question that I hope someone can help me with. The definition of SEARCH HEADER, as quoted from RFC 2060, is the following: HEADER Messages that have a header with the specified field-name (as defined in [RFC-822]) and that contain the specified string in the [RFC-822] field-body. RFC-822 explains field-name and field-body as follows: Once a field has been unfolded, it may be viewed as being com- posed of a field-name followed by a colon (":"), followed by a field-body, and terminated by a carriage-return/line-feed. My interpretation of all this is that when the client sends A001 SEARCH HEADER "From:" "From:" the search should come up empty. This is how my implementation of search currently works. However, I doubt whether this behavior is correct, because both the UW server and the Cyrus server will match all messages in the mailbox that have a From: header. I am inclined to dismiss this as a bug, except the current behavior provides one useful feature: one can say A001 SEARCH NOT HEADER "Foo:" "Foo:" and get back a list of all messages that do not have the "Foo:" header.   Received: from cnri by ietf.org id aa05982; 14 Apr 97 15:03 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa17815; 14 Apr 97 15:03 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA09641; Mon, 14 Apr 1997 11:58:56 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA05508 for ; Mon, 14 Apr 1997 11:58:22 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA14044 for ; Mon, 14 Apr 1997 11:58:19 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (mace@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA14491 for ; Mon, 14 Apr 1997 11:58:15 -0700 Received: from Ikkoku-Kan.Panda.COM (lum@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id LAA16356; Mon, 14 Apr 1997 11:58:09 -0700 (PDT) Received: from localhost (linus@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id LAA27810; Mon, 14 Apr 1997 11:58:03 -0700 (PDT) Message-Id: Date: Mon, 14 Apr 1997 11:53:11 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: "Mark Pustilnik (Exchange)" Cc: 'IMAP Discusson List' Subject: re: SEARCH HEADER question In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Mon, 14 Apr 1997 11:24:01 -0700, Mark Pustilnik (Exchange) wrote: > My interpretation of all this is that when the client sends > A001 SEARCH HEADER "From:" "From:" > the search should come up empty. > > This is how my implementation of search currently works. However, I > doubt whether this behavior is correct, because both the UW server and > the Cyrus server will match all messages in the mailbox that have a > From: header. > > I am inclined to dismiss this as a bug, except the current behavior > provides one useful feature: one can say > A001 SEARCH NOT HEADER "Foo:" "Foo:" > and get back a list of all messages that do not have the "Foo:" header. Your message confused me, since A001 SEARCH HEADER "From:" "From:" will always come up empty on my server, and A001 SEARCH NOT HEADER "From:" "From:" will always come up non-empty. This is because "From:" will never match any field-name. Now, when you substitute this with: A001 SEARCH HEADER "From" "From:" and A001 SEARCH NOT HEADER "Foo" "Foo:" then what you say makes sense. I agree, this seems to be a bug in Cyrus and my server. I implement this by doing a subset header fetch, and then searching through the resulting text. But your message contains an interesting argument for declaring this a feature and clarifying the spec to agree.   Received: from cnri by ietf.org id aa06308; 14 Apr 97 15:16 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa18109; 14 Apr 97 15:16 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA51908; Mon, 14 Apr 1997 12:11:41 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA44634 for ; Mon, 14 Apr 1997 12:09:21 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA15272 for ; Mon, 14 Apr 1997 12:09:19 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA27651 for ; Mon, 14 Apr 1997 12:09:15 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <2R1T2H8Z>; Mon, 14 Apr 1997 12:09:03 -0700 Message-Id: Date: Mon, 14 Apr 1997 12:09:00 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mark Pustilnik (Exchange)" To: "Mark Pustilnik (Exchange)" , 'Mark Crispin' Cc: 'IMAP Discusson List' Subject: RE: SEARCH HEADER question MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN My apologies, there is a typo in the example command below. The command should say A001 SEARCH HEADER FROM "From:" instead of A001 SEARCH HEADER "From:" "From:" As to the last point made about possibly making the existing bug into a feature, my feeling is against it. Doing so would introduce a semantic difference between SEARCH FROM "Foo" and SEARCH HEADER FROM "Foo" > ---------- > From: Mark Crispin[SMTP:MRC@Panda.COM] > Sent: Monday, April 14, 1997 11:53 AM > To: Mark Pustilnik (Exchange) > Cc: 'IMAP Discusson List' > Subject: re: SEARCH HEADER question > > On Mon, 14 Apr 1997 11:24:01 -0700, Mark Pustilnik (Exchange) wrote: > > My interpretation of all this is that when the client sends > > A001 SEARCH HEADER "From:" "From:" > > the search should come up empty. > > > > This is how my implementation of search currently works. However, I > > doubt whether this behavior is correct, because both the UW server > and > > the Cyrus server will match all messages in the mailbox that have a > > From: header. > > > > I am inclined to dismiss this as a bug, except the current behavior > > provides one useful feature: one can say > > A001 SEARCH NOT HEADER "Foo:" "Foo:" > > and get back a list of all messages that do not have the "Foo:" > header. > > Your message confused me, since > A001 SEARCH HEADER "From:" "From:" > will always come up empty on my server, and > A001 SEARCH NOT HEADER "From:" "From:" > will always come up non-empty. This is because "From:" will never > match any > field-name. > > Now, when you substitute this with: > A001 SEARCH HEADER "From" "From:" > and > A001 SEARCH NOT HEADER "Foo" "Foo:" > then what you say makes sense. > > I agree, this seems to be a bug in Cyrus and my server. I implement > this by > doing a subset header fetch, and then searching through the resulting > text. > But your message contains an interesting argument for declaring this a > feature > and clarifying the spec to agree. >   Received: from cnri by ietf.org id aa09941; 14 Apr 97 17:44 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa21213; 14 Apr 97 17:44 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA25194; Mon, 14 Apr 1997 14:40:16 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA41936 for ; Mon, 14 Apr 1997 14:39:29 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA04452 for ; Mon, 14 Apr 1997 14:39:28 -0700 Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA01705 for ; Mon, 14 Apr 1997 14:39:26 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHP6IKUNSM99F9D5@INNOSOFT.COM> for imap@cac.washington.edu; Mon, 14 Apr 1997 14:39:16 PDT Message-Id: Date: Mon, 14 Apr 1997 14:40:40 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: "Mark Pustilnik (Exchange)" Cc: 'IMAP Discusson List' Subject: Re: SEARCH HEADER question In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Mon, 14 Apr 1997, Mark Pustilnik (Exchange) wrote: > I am inclined to dismiss this as a bug, except the current behavior I am also inclined to dismiss this as a bug. > provides one useful feature: one can say > A001 SEARCH NOT HEADER "Foo:" "Foo:" > and get back a list of all messages that do not have the "Foo:" header. Shouldn't A001 SEARCH NOT HEADER "Foo" "" get the same results under either semantics? Unfortunately, both c-client and Cyrus seem to get this wrong -- c-client incorrectly responds with BAD to this perfectly legal syntax, and Cyrus assumes a match against "" is always true, even if the header doesn't exist.   Received: from cnri by ietf.org id aa23583; 15 Apr 97 2:43 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa03738; 15 Apr 97 2:43 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id XAA06475; Mon, 14 Apr 1997 23:37:42 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA42660 for ; Mon, 14 Apr 1997 23:37:02 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA19866 for ; Mon, 14 Apr 1997 23:37:00 -0700 Received: from dns.nhl.nl (dns.nhl.nl [141.252.1.3]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id XAA28561 for ; Mon, 14 Apr 1997 23:36:57 -0700 Received: from mailserv.tem.nhl.nl by dns.nhl.nl id aa29225; 15 Apr 97 8:37 CETDST Received: from rc1016-bosscha.tem.nhl.nl by mailserv.tem.nhl.nl id aa19362; 15 Apr 97 8:36 CETDST Message-Id: Date: Tue, 15 Apr 1997 08:36:56 +0200 (Romance Daylight Time) Reply-To: f.j.bosscha@tem.nhl.nl Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Freerk J. Bosscha" To: imap@cac.washington.edu Subject: Corrupt folders in SCO 3.2.5 and Imap MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: bosscha@tem.nhl.nl X-Mailer: Simeon for Win32 Version 4.1 Build (3) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I have got the following two questions/problems. 1. Since the time I have upgraded to the IMAP4rev1 server quit a number of users had trouble with there mailbox. I think the problem might be the message from the Mail System Internal Data. We are using SCO-UNIX 3.2.5 with MMDF. Does anyone else found these problems. 2. Watching the memory consument from imap, I saw that he allocates memory as big as the size of the mail-box. When the mail-box is small, there is no problem. But on our university, quit a lot of students send there word-documents as attachment to the teachers, so the mailboxes can grow. Is there a possibility to solve this problem, other then buying RAM. ---------------------- Freerk J. Bosscha Noordelijke Hogeschool Leeuwarden The Netherlands phone : xx-31-(0)58 2961 435 fax : xx-31-(0)58 2961 466 e-mail: f.j.bosscha@tem.nhl.nl url : hppt://www.tem.nhl.nl/~bosscha   Received: from cnri by ietf.org id aa28574; 15 Apr 97 9:18 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa10077; 15 Apr 97 9:18 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id GAA14217; Tue, 15 Apr 1997 06:12:03 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id GAA49296 for ; Tue, 15 Apr 1997 06:10:49 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id GAA04514 for ; Tue, 15 Apr 1997 06:10:47 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id GAA16951 for ; Tue, 15 Apr 1997 06:10:45 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id JAA15148 for ; Tue, 15 Apr 1997 09:00:56 -0400 Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id JAA22168 for ; Tue, 15 Apr 1997 09:10:43 -0400 Message-Id: Date: Tue, 15 Apr 1997 09:09:21 -0400 (Eastern Daylight Time) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Barry Leiba To: 'IMAP Discusson List' Subject: Re: SEARCH HEADER question In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1 Build (11) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Mon, 14 Apr 97 14:40:40 -0700 Chris Newman wrote: > I am also inclined to dismiss this as a bug. I agree. > > provides one useful feature: one can say > > A001 SEARCH NOT HEADER "Foo:" "Foo:" > > and get back a list of all messages that do not have the "Foo:" header. I agree with what I think Chris thinks: that this is bad. My server has this bug also, because the code for "SEARCH HEADER xxx yyy" is exactly the same as the code for "FETCH BODY[HEADER.FIELDS (xxx)]" with a filter for "Does it contain 'yyy'?" on the back end. It would not be hard to fix this, though, and I'm inclined to do so (but I'll wait for the dust to settle on this discussion first). > Shouldn't > > A001 SEARCH NOT HEADER "Foo" "" > > get the same results under either semantics? This works correctly on my server, selecting only those messages that have a "Foo:" header record. This is because I extract the header record(s) in question, and then say "If I got something *and* it contains the search string, then say yes." I should point out that the current behaviour makes it impossible to search for all messages, say, that have a subject containing the word "subject". That, alone, is reason enough to "fix" it. Don't others agree? Let's clarify the spec so that it explicitly states what it seems to say anyway: that SEARCH HEADER should search only the *body* of the header records, not the tags, and that searching for "" (as above) should match exactly all messages that *have* the header record in question. Barry Leiba, Multimedia Messaging (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba   Received: from cnri by ietf.org id aa12548; 15 Apr 97 18:00 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa21425; 15 Apr 97 18:00 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA09105; Tue, 15 Apr 1997 14:56:22 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA48228 for ; Tue, 15 Apr 1997 14:53:47 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA09087 for ; Tue, 15 Apr 1997 14:53:39 -0700 Received: from prowler.isocor.com (prowler.isocor.com [198.6.228.65]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA29756 for ; Tue, 15 Apr 1997 14:53:35 -0700 Received: from erik.isocor.com (198.6.228.71) by prowler.isocor.com (NPlex 1.3.125); 15 Apr 1997 15:54:28 -0700 Message-Id: Date: Tue, 15 Apr 1997 14:54:38 -0700 (Pacific Daylight Time) Reply-To: erik.forsberg@isocor.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Erik Forsberg To: Barry Leiba Cc: 'IMAP Discusson List' Subject: Re: SEARCH HEADER question In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1 Build (11) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Just to add my 2 cents; I agree with the conclusions by Barry below; I believe my server always did the correct thing (according to this interpreation which I completeky agree with) On Tue, 15 Apr 1997 09:09:21 -0400 Barry Leiba wrote: > On Mon, 14 Apr 97 14:40:40 -0700 Chris Newman > wrote: > > I am also inclined to dismiss this as a bug. > > I agree. > > > > provides one useful feature: one can say > > > A001 SEARCH NOT HEADER "Foo:" "Foo:" > > > and get back a list of all messages that do not have the "Foo:" header. > > I agree with what I think Chris thinks: that this is bad. My server has > this bug also, because the code for "SEARCH HEADER xxx yyy" is exactly the > same as the code for "FETCH BODY[HEADER.FIELDS (xxx)]" with a filter for > "Does it contain 'yyy'?" on the back end. It would not be hard to fix > this, though, and I'm inclined to do so (but I'll wait for the dust to > settle on this discussion first). > > > Shouldn't > > > > A001 SEARCH NOT HEADER "Foo" "" > > > > get the same results under either semantics? > > This works correctly on my server, selecting only those messages that have > a "Foo:" header record. This is because I extract the header record(s) in > question, and then say "If I got something *and* it contains the search > string, then say yes." > > I should point out that the current behaviour makes it impossible to search > for all messages, say, that have a subject containing the word "subject". > That, alone, is reason enough to "fix" it. Don't others agree? > > Let's clarify the spec so that it explicitly states what it seems to say > anyway: that SEARCH HEADER should search only the *body* of the header > records, not the tags, and that searching for "" (as above) should match > exactly all messages that *have* the header record in question. > > Barry Leiba, Multimedia Messaging (leiba@watson.ibm.com) > http://www.research.ibm.com/people/l/leiba > ---------------------- Erik Forsberg erik.forsberg@isocor.com   Received: from cnri by ietf.org id aa15224; 16 Apr 97 15:04 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa18612; 16 Apr 97 15:04 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA54968; Wed, 16 Apr 1997 11:57:26 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA28898 for ; Wed, 16 Apr 1997 11:55:43 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA15127 for ; Wed, 16 Apr 1997 11:55:42 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA09540 for ; Wed, 16 Apr 1997 11:55:40 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <292ACG6D>; Wed, 16 Apr 1997 11:55:29 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACE1B055@DABONE> Date: Wed, 16 Apr 1997 11:55:11 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: 'IMAP Mailing List' Subject: FW: I-D ACTION:draft-gahrns-imap-practice-01.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN A second copy of the multi-Accessed mailbox practice draft that many of you contributed to is now available. I suspect there will be need for very little further discussion on this. The changes in this draft from the previous draft where consensus on desired behavior was reached, are: 1) Minor grammatical changes suggested by Mark Keasling 2) Added the example that Mark Crispin contributed to the list regarding COPY of expunged messages, that many people thought would be worthwhile to add Please let me know of any errors. Sorry for the delay in this reaching the list, but the IETF had stopped accepting submissions of drafts prior to the recent IETF mtg in Memphis. thx, -mikega > ---------- > From: Internet-Drafts@ietf.org[SMTP:Internet-Drafts@ietf.org] > Reply To: Internet-Drafts@ietf.org > Sent: Wednesday, April 16, 1997 7:34 AM > To: IETF-Announce@ietf.org > Subject: I-D ACTION:draft-gahrns-imap-practice-01.txt > > > A Revised Internet-Draft is available from the on-line > Internet-Drafts > directories. > > > Title : IMAP4 Multi-Accessed Mailbox Practice > > Author(s) : M. Gahrns > Filename : draft-gahrns-imap-practice-01.txt > Pages : 12 > Date : 04/14/1997 > > IMAP4[rfc2060] is rich client/server protocol that allows a client to > access and manipulate electronic mail messages on a server. Within the > > protocol framework, it is possible to have differing results for > particular > client/server interactions. If a protocol does not allow for this, it > is > often unduly restrictive. > > For example, when multiple clients are accessing a mailbox and one > attempts to delete the mailbox, an IMAP4 server may choose to > implement > a solution based upon server architectural constraints or > individual preference. > > With this flexibility comes greater client responsibility. It is not > sufficient for a client to be written based upon the behavior of > a particular IMAP server. Rather the client must be based upon > the behavior allowed by the protocol. > > By documenting common IMAP4 server practice for the case of > simultaneous > client access to a mailbox, we hope to ensure the widest amount of > inter-operation between IMAP4 clients and servers. > > > Internet-Drafts are 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-gahrns-imap-practice-01.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-practice-01.tx > t > > Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-gahrns-imap-practice-01.txt". > > NOTE: The mail server at ds.internic.net 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. >   Received: from cnri by ietf.org id aa18863; 16 Apr 97 16:30 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa21441; 16 Apr 97 16:30 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA03218; Wed, 16 Apr 1997 13:26:34 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA18974 for ; Wed, 16 Apr 1997 13:26:07 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA24799 for ; Wed, 16 Apr 1997 13:26:04 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA25319 for ; Wed, 16 Apr 1997 13:26:02 -0700 Received: from Ikkoku-Kan.Panda.COM (murphy@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id NAA21376; Wed, 16 Apr 1997 13:25:57 -0700 (PDT) Received: from localhost (mtk@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id NAA07447; Wed, 16 Apr 1997 13:25:53 -0700 (PDT) Message-Id: Date: Wed, 16 Apr 1997 13:15:16 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Paul Falstad Cc: IMAP Interest List Subject: re: nested encoding In-Reply-To: <9704161258.ZM15087@hanoi.software.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN RFC 2045, page 17, states the prohibition on nested encodings. This prohibition has been in all previous MIME specifications. I should know; I was the primary instigator of this prohibition in the MIME working group. So, a message/rfc822 may *NOT* be encoded with BASE64 or QUOTED-PRINTABLE, and any mail program which writes such a body part is broken by definition.   Received: from cnri by ietf.org id aa22565; 16 Apr 97 17:47 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa23433; 16 Apr 97 17:47 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA08351; Wed, 16 Apr 1997 14:43:49 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA54130 for ; Wed, 16 Apr 1997 14:43:30 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA16640 for ; Wed, 16 Apr 1997 14:43:26 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA13772 for ; Wed, 16 Apr 1997 14:43:23 -0700 Received: from Ikkoku-Kan.Panda.COM (phillip@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id OAA21460; Wed, 16 Apr 1997 14:43:19 -0700 (PDT) Received: from localhost (ph18@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id OAA08144; Wed, 16 Apr 1997 14:43:14 -0700 (PDT) Message-Id: Date: Wed, 16 Apr 1997 14:36:00 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: andy@hsl.meitca.com Cc: IMAP Interest List Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Wed, 16 Apr 1997 17:20:17 -0500, Andrew McCown wrote: > I have a draft for that extension that should be hitting the list within > the next few days - just need to clean up a couple of things in it. A few requirements: 1) Use RFC-1766 language tags, not some other mechanism. 2) Default language MUST be English, and English support is required. 3) Do not use charsets (and in particular do not use the text_mime2 option for resp_text); use regular (not modified) UTF-7 (RFC-1642) instead. I want to consider abolishing text_mime2 from resp_text, and perhaps allowing resp_text to be CHAR8s (with a requirement that they be UTF-8) instead of CHARs. Unlike mailbox names, there is no compatibility reason why resp_text must be 7bit, particularly if it's only triggered by a LANGUAGE extension.   Received: from cnri by ietf.org id aa17967; 17 Apr 97 1:49 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa02836; 17 Apr 97 1:49 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id WAA18346; Wed, 16 Apr 1997 22:45:14 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA17142 for ; Wed, 16 Apr 1997 22:44:27 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA27679 for ; Wed, 16 Apr 1997 22:44:26 -0700 Received: from mailhost1.cac.washington.edu (mailhost1.cac.washington.edu [140.142.32.2]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA22390 for ; Wed, 16 Apr 1997 22:44:24 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id WAA04487 for ; Wed, 16 Apr 1997 22:44:23 -0700 Message-Id: Date: Wed, 16 Apr 1997 22:30:12 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: IMAP Interest List Subject: Bad practice: STATUS command on currently selected mailbox MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Some client implementors seem to believe that it is reasonable to issue a STATUS command on the currently selected mailbox. Don't do this. If your client does this, please fix it not to do so. It's completely unnecessary to do so. You can get all that information from the selected mailbox via FETCH commands and/or your cache. It's non-interoperable with RFC-1730 and IMAP2, neither of which had the STATUS command. More importantly, it can cause extra work and unexpected results in some servers. In the c-client server, doing a STATUS command on the selected mailbox opens that mailbox for a second time, readonly. As such, it causes all the work of parsing the mailbox (which for flat-file formats can be expensive). In some formats, since STATUS is readonly, it can actually cause a *suppression* of new mail checking. More evil, on certain operating systems, opening a file twice in the same process causes any lock on that process to be discarded; this is a design flaw in SVR4's implementation of fcntl(). The process is never made aware of this, and the result can be corrupted mailboxes. It is possible that, in a future version of the c-client server, that I may make a special check for STATUS on the currently selected mailbox and return a "NO Client bug detected -- STATUS on selected mbx -- report to client vendor" error, perhaps with some ALERTs, as a defensive measure against such bad client behavior.   Received: from cnri by ietf.org id aa19177; 17 Apr 97 2:32 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa03453; 17 Apr 97 2:32 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id XAA26078; Wed, 16 Apr 1997 23:28:16 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA19184 for ; Wed, 16 Apr 1997 23:27:39 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA00515 for ; Wed, 16 Apr 1997 23:27:38 -0700 Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA23075 for ; Wed, 16 Apr 1997 23:27:36 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id XAA13497 for ; Wed, 16 Apr 1997 23:27:35 -0700 Message-Id: Date: Wed, 16 Apr 1997 23:20:08 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: IMAP Interest List Subject: Bad Practice: issuing STATUS command for all mailboxes returned by LIST * MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I have received reports of client behavior which is even worse than doing a001 LIST "" * That behavior is to do a STATUS command on every mailbox that was returned by that LIST. This can be an extremely costly operation on the server (it uncovered a memory leak on my server that caused some imapds to reach sizes of 250MB!), particularly if the server has to read the entire mailbox to determine the number of messages. Remember: 1) Use %, not *, when doing an initial top-level LIST 2) Only use STATUS at user request. There is a reason why STATUS information is not part of LIST.   Received: from cnri by ietf.org id aa27938; 17 Apr 97 8:42 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa09285; 17 Apr 97 8:43 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id FAA04411; Thu, 17 Apr 1997 05:35:23 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA54164 for ; Thu, 17 Apr 1997 05:34:18 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA25862 for ; Thu, 17 Apr 1997 05:34:17 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA27399 for ; Thu, 17 Apr 1997 05:34:15 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id IAA10426 for ; Thu, 17 Apr 1997 08:24:27 -0400 Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id IAA20649 for ; Thu, 17 Apr 1997 08:34:13 -0400 Message-Id: Date: Thu, 17 Apr 1997 08:32:47 -0400 (Eastern Daylight Time) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Barry Leiba To: IMAP Interest List Subject: Re: Bad practice: STATUS command on currently selected mailbox In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1 Build (11) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I agree that doing STATUS on *all* mailboxes is a bad thing; I thought about doing it in my client (when the client uses a proprietary protocol to communicate with our server, it gets the message count in each folder and displays it with the folder icon, so I wanted to do the same thing when the client was using IMAP) but rejected it for exactly the reasons that Mark states. I also agree that there's no good reason to do STATUS on the selected mailbox, and that clients should be encouraged not to do that - they should already know all that information from having done the SELECT and from having kept track of what's been happening to the mailbox since. But I must take exception to the idea that it's a terrible client bug. IMO it's a *server* bug if it's an expensive operation. In my server, for instance, STATUS on a mailbox does indeed cause that mailbox to be opened. But STATUS on the *selected* mailbox just instantly returns the information that I have saved away in the session's data structure. It takes no time at all. I can't imagine why anyone would write a server that wouldn't handle this simple special case and why anyone would so vehemently rave about it so. > It is possible that, in a future version of the c-client server, that I may > make a special check for STATUS on the currently selected mailbox and > return a "NO Client bug detected -- STATUS on selected mbx -- report to > client vendor" error, perhaps with some ALERTs, as a defensive measure > against such bad client behavior. Why don't you just fix your server instead, rather than demanding that clients bow to your particular server's aberrant behaviour? Barry Leiba, Multimedia Messaging (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba   Received: from cnri by ietf.org id aa04169; 17 Apr 97 10:31 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa11588; 17 Apr 97 10:31 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id HAA10512; Thu, 17 Apr 1997 07:26:24 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA26820 for ; Thu, 17 Apr 1997 07:24:55 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA09064 for ; Thu, 17 Apr 1997 07:24:54 -0700 Received: from mystery.milleredp.com (mystery.milleredp.com [205.184.29.2]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA12219 for ; Thu, 17 Apr 1997 07:24:51 -0700 Received: from tombstone (tombstone.milleredp.com [205.184.29.4]) by mystery.milleredp.com (8.7.4/8.7.3) with SMTP id GAA03356 for ; Thu, 17 Apr 1997 06:36:39 -0700 Message-Id: <199704171336.GAA03356@mystery.milleredp.com> Date: Thu, 17 Apr 1997 07:24:16 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: John Edward Miller To: IMAP@cac.washington.edu Subject: Re: Bad practice: STATUS command on currently selected mailbox In-Reply-To: ; from "jem" at Thu Apr 17 07:24:16 1997 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET="US-ASCII" X-Mailer: Siren Mail (Windows Version 3.1.0 (Windows 95/NT)) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN > Some client implementors seem to believe that it is reasonable to issue a > STATUS command on the currently selected mailbox. > > It's non-interoperable with RFC-1730 and IMAP2, neither of which had the > STATUS command. Necessary? Perhaps not. Reasonable? I think so. I'd also hesitate to argue that, at this time, it makes sense to build clients that are backward compatible. Servers, okay, but clients, no. > More importantly, it can cause extra work and unexpected results in some > servers. > > In the c-client server, doing a STATUS command... I hate to say 'change the server', but I don't think this kind of behavior should be prohibited based on the current capabilities of one product.   Received: from cnri by ietf.org id aa17265; 17 Apr 97 12:57 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa15310; 17 Apr 97 12:57 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id JAA22852; Thu, 17 Apr 1997 09:52:07 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA19008 for ; Thu, 17 Apr 1997 09:51:18 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA24666 for ; Thu, 17 Apr 1997 09:51:16 -0700 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id JAA02540; Thu, 17 Apr 1997 09:51:06 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHT3ARJ7I499FMH9@INNOSOFT.COM>; Thu, 17 Apr 1997 09:50:38 PDT Message-Id: Date: Thu, 17 Apr 1997 09:52:03 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: andy@hsl.meitca.com, Mark Crispin Cc: IMAP Interest List Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Wed, 16 Apr 1997, Mark Crispin wrote: > 3) Do not use charsets (and in particular do not use the text_mime2 option for > resp_text); use regular (not modified) UTF-7 (RFC-1642) instead. 4) Make sure your reference is the correct reference for Unicode 2.0 rather than 1.1. Unicode 1.1 and 2.0 are incompatible so we need to make sure we use the right reference. I believe the correct reference is ISO 10646:1993 including amendments 1-7. > I want to consider abolishing text_mime2 from resp_text, and perhaps allowing > resp_text to be CHAR8s (with a requirement that they be UTF-8) instead of > CHARs. Unlike mailbox names, there is no compatibility reason why resp_text > must be 7bit, particularly if it's only triggered by a LANGUAGE extension. That sounds like the right way to do it to me. The client's LANGUAGE command would cause UTF-8 to appear in response codes. Otherwise response codes would be restricted to US-ASCII. I'd be reluctant to see two variants of UTF-7 used in IMAP, so I prefer using UTF-8 in this context.   Received: from cnri by ietf.org id aa18977; 17 Apr 97 13:17 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa15785; 17 Apr 97 13:17 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA20160; Thu, 17 Apr 1997 10:12:36 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA25884 for ; Thu, 17 Apr 1997 10:12:04 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA10048 for ; Thu, 17 Apr 1997 10:12:02 -0700 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA16431 for ; Thu, 17 Apr 1997 10:12:00 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHT41DI7FK99FCQB@INNOSOFT.COM> for imap@cac.washington.edu; Thu, 17 Apr 1997 10:11:18 PDT Message-Id: Date: Thu, 17 Apr 1997 10:12:43 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: IMAP Discusson List Subject: IMAP URLs MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN So, I'm going to have to do *yet another* revision on the IMAP URL document. These are the changes which been required or hinted at before the IMAP URL document will be allowed to move to proposed standard: (1) Remove the password field. I'm tempted to just use the password field to identify the AUTH mechanism -- e.g. . Or I can just leave it ";" as it is now. Comments? (2) Change the way relative URLs are resolved with respect to parameters like ;UID= and ;SECTION=. The problem here is that apparently no servers do anything special for parameters when resolving relative URLs. So the new URL specification (draft-fielding-url-syntax-04.txt) changes the rules for resolving relative URLs with parameters. The proposal is to use: This would fix URL resolving with UID & SECTION so it would work with current web browsers, and use the syntax in rather than RFC 1808. (3) The proposed process language for URLs currently has text which recommends the use of hex-encoded UTF-8 in new URL schemes. This language has caused controversy and might be removed. The current IMAP URL spec contains some weasel wording in section 9 on this topic. I could take the next step and REQUIRE conversion between IMAP's modified UTF-7 and URL hex-encoded UTF-8 (were I to do this, I'd probably put a code snippet in an appendix). Comments? I suspect these changes are signficant enough that another last call is merited, so there won't be an IMAP URL standard for a bit longer. So is anyone implementing IMAP URLs?   Received: from cnri by ietf.org id aa23819; 17 Apr 97 15:07 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa18272; 17 Apr 97 15:07 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA27152; Thu, 17 Apr 1997 12:03:36 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA20088 for ; Thu, 17 Apr 1997 12:01:57 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA29838 for ; Thu, 17 Apr 1997 12:01:54 -0700 Received: from prowler.isocor.com (prowler.isocor.com [198.6.228.65]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA19460; Thu, 17 Apr 1997 12:01:49 -0700 Received: from erik.isocor.com (198.6.228.71) by prowler.isocor.com (NPlex 1.3.125); 17 Apr 1997 13:03:06 -0700 Message-Id: Date: Thu, 17 Apr 1997 12:02:41 -0700 (Pacific Daylight Time) Reply-To: erik.forsberg@isocor.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Erik Forsberg To: Mark Crispin Cc: IMAP Interest List , andy@hsl.meitca.com Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1 Build (14) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Couldnt we also make the text in resp_text be optional ? It seems really silly forcing a server to transmit noise words when there is nothing useful to say. On Wed, 16 Apr 1997 14:36:00 -0700 Mark Crispin wrote: > On Wed, 16 Apr 1997 17:20:17 -0500, Andrew McCown wrote: > > I have a draft for that extension that should be hitting the list within > > the next few days - just need to clean up a couple of things in it. > > A few requirements: > > 1) Use RFC-1766 language tags, not some other mechanism. > > 2) Default language MUST be English, and English support is required. > > 3) Do not use charsets (and in particular do not use the text_mime2 option for > resp_text); use regular (not modified) UTF-7 (RFC-1642) instead. > > I want to consider abolishing text_mime2 from resp_text, and perhaps allowing > resp_text to be CHAR8s (with a requirement that they be UTF-8) instead of > CHARs. Unlike mailbox names, there is no compatibility reason why resp_text > must be 7bit, particularly if it's only triggered by a LANGUAGE extension. > ---------------------- Erik Forsberg erik.forsberg@isocor.com   Received: from cnri by ietf.org id aa24602; 17 Apr 97 15:30 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa18809; 17 Apr 97 15:30 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA28594; Thu, 17 Apr 1997 12:27:08 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA41868 for ; Thu, 17 Apr 1997 12:26:26 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA06076 for ; Thu, 17 Apr 1997 12:26:26 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA06662; Thu, 17 Apr 1997 12:26:20 -0700 Received: from POPDOG by doggate.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 292AC94D; Thu, 17 Apr 1997 12:26:14 -0700 Received: from RAYCH.dns.microsoft.com by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 20SJ0K3W; Thu, 17 Apr 1997 12:26:06 -0700 Message-Id: <199704171926.MAA06662@mx2.cac.washington.edu> Date: Thu, 17 Apr 1997 19:26:23 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Raymond Cheng To: Mark Crispin , IMAP Interest List Subject: Re: Bad Practice: issuing STATUS command for all mailboxes returned by LIST * MIME-Version: 1.0 Content-Type: text/plain; boundary="----=_NextPart_000_01BC4B21.ECD33580"; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook Express 4.71.0710.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.0710.0 X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Out of curiousity, what does a client do if it wants to be able to show = the unread mail in each folder? It seems to me that this is what the = STATUS command is used for. It's true that STATUS may be extremely = costly on the server, but what other recourse is there for a client that = wants to provide this information? And what if STATUS is not expensive on other servers? Why should a = client be prohibited from sending a STATUS for every mailbox on that = server? I do not intend to limit the usage of the STATUS command because of its = (possible) expense. If this were the case, then clients should also = refrain from sending the RFC822.SIZE command except on "user demand". ...Cheng ----- Email: raych@microsoft.com Microsoft Outlook Express Developer My opinions are mine, all MINE! ---- From: Mark Crispin To: IMAP Interest List Date: Wednesday, April 16, 1997 11:36 PM Subject: Bad Practice: issuing STATUS command for all mailboxes returned = by LIST * >I have received reports of client behavior which is even worse than >doing > a001 LIST "" * > >That behavior is to do a STATUS command on every mailbox that was >returned by >that LIST. This can be an extremely costly operation on the server (it >uncovered a memory leak on my server that caused some imapds to reach >sizes of >250MB!), particularly if the server has to read the entire mailbox to >determine the number of messages. > >Remember: > >1) Use %, not *, when doing an initial top-level LIST > >2) Only use STATUS at user request. There is a reason why STATUS >information > is not part of LIST. >   Received: from cnri by ietf.org id aa24622; 17 Apr 97 15:31 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa18825; 17 Apr 97 15:31 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA02325; Thu, 17 Apr 1997 12:28:08 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA02488 for ; Thu, 17 Apr 1997 12:26:31 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA02490 for ; Thu, 17 Apr 1997 12:26:29 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA20039; Thu, 17 Apr 1997 12:26:25 -0700 Received: from POPDOG by doggate.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 292AC94L; Thu, 17 Apr 1997 12:26:19 -0700 Received: from RAYCH.dns.microsoft.com by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 20SJ0K3Y; Thu, 17 Apr 1997 12:26:07 -0700 Message-Id: <199704171926.MAA20039@mx1.cac.washington.edu> Date: Thu, 17 Apr 1997 19:19:37 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Raymond Cheng To: "erik.forsberg@isocor.com" , Mark Crispin Cc: IMAP Interest List , "andy@hsl.meitca.com" Subject: Re: Internationalized Server Response Text? MIME-Version: 1.0 Content-Type: text/plain; boundary="----=_NextPart_000_01BC4B29.89902980"; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook Express 4.71.0710.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.0710.0 X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I think it's too late to change this. ...Cheng ----- Email: raych@microsoft.com Microsoft Outlook Express Developer My opinions are mine, all MINE! ---- From: Erik Forsberg To: Mark Crispin Cc: IMAP Interest List ; andy@hsl.meitca.com = Date: Thursday, April 17, 1997 12:17 PM Subject: re: Internationalized Server Response Text? >Couldnt we also make the text in resp_text be optional ? >It seems really silly forcing a server to transmit noise words >when there is nothing useful to say. [...]   Received: from cnri by ietf.org id aa25135; 17 Apr 97 15:46 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa19120; 17 Apr 97 15:46 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA02941; Thu, 17 Apr 1997 12:42:36 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA41972 for ; Thu, 17 Apr 1997 12:42:02 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA15664 for ; Thu, 17 Apr 1997 12:41:51 -0700 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA20419 for ; Thu, 17 Apr 1997 12:41:46 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHT99IRBEO99E9T7@INNOSOFT.COM> for IMAP@cac.washington.edu; Thu, 17 Apr 1997 12:41:26 PDT Message-Id: Date: Thu, 17 Apr 1997 12:42:50 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: Erik Forsberg Cc: IMAP Interest List Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997, Erik Forsberg wrote: > Couldnt we also make the text in resp_text be optional ? > It seems really silly forcing a server to transmit noise words > when there is nothing useful to say. It's not worth risking incompatibility to save 2 octets, IMHO.   Received: from cnri by ietf.org id aa25998; 17 Apr 97 16:03 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa19433; 17 Apr 97 16:03 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA00371; Thu, 17 Apr 1997 12:59:28 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA45224 for ; Thu, 17 Apr 1997 12:58:51 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA29242 for ; Thu, 17 Apr 1997 12:58:47 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id MAA07342 for ; Thu, 17 Apr 1997 12:58:44 -0700 Received: from Ikkoku-Kan.Panda.COM (brit@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id MAA24164; Thu, 17 Apr 1997 12:58:40 -0700 (PDT) Received: from localhost (bjj@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id MAA12093; Thu, 17 Apr 1997 12:58:34 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 11:39:59 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Barry Leiba Cc: IMAP Interest List Subject: Re: Bad practice: STATUS command on currently selected mailbox In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997 08:32:47 -0400 (Eastern Daylight Time), Barry Leiba wrote: > But I must take exception to the idea that it's a terrible client bug. IMO > it's a *server* bug if it's an expensive operation. In my server, for > instance, STATUS on a mailbox does indeed cause that mailbox to be opened. > But STATUS on the *selected* mailbox just instantly returns the information > that I have saved away in the session's data structure. It takes no time > at all. I can't imagine why anyone would write a server that wouldn't > handle this simple special case and why anyone would so vehemently rave > about it so. It may be very easy for you, particularly if you don't have to worry about many different mailbox formats, hard links, multiple namespaces, and proxying. There is a blindness behind the attitude of "it is easy for me, it must be easy for you so you must be an idiot to complain about it." Some environments can render extremely difficult something that is trivial or a non-issue in other environments. If you're unable to recognize this, you're as guilty as your predecessors at IBM who thought that "all the world is S/360". > Why don't you just fix your server instead, rather than demanding that > clients bow to your particular server's aberrant behaviour? This rewards bad client behavior, and worse, it prevents the broken clients from being fixed.   Received: from cnri by ietf.org id aa26982; 17 Apr 97 16:14 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa19692; 17 Apr 97 16:14 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA04753; Thu, 17 Apr 1997 13:10:20 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA48326 for ; Thu, 17 Apr 1997 13:09:38 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA07025 for ; Thu, 17 Apr 1997 13:09:36 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA07639 for ; Thu, 17 Apr 1997 13:09:32 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id PAA11682 for ; Thu, 17 Apr 1997 15:59:44 -0400 Received: from mars.watson.ibm.com (mars.watson.ibm.com [9.2.2.58]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id QAA23379 for ; Thu, 17 Apr 1997 16:09:30 -0400 Message-Id: Date: Thu, 17 Apr 1997 16:08:03 -0400 (Eastern Daylight Time) Reply-To: Barry Leiba Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Barry Leiba To: IMAP Interest List Subject: Re: Bad practice: STATUS command on currently selected mailbox In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1 Build (11) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 97 11:39:59 -0700 Mark Crispin wrote: > It may be very easy for you, particularly if you don't have to worry about > many different mailbox formats, hard links, multiple namespaces, and proxying. So what do you do when a client has barry.inbox selected and tries to do a STATUS on leiba.inbox, not knowing that it's really the same, hard-linked file? It seems to me that you have to deal with this issue whether or not the clients are "fixed". > There is a blindness behind the attitude of "it is easy for me, it must be > easy for you so you must be an idiot to complain about it." Some There is also a blindness behind the attitude of "it is hard for me, so I should make everyone adhere to my rules." You *could* fix your server to save, in a memory block, the STATUS information for the currently selected mailbox. For me, this falls out of the way I've designed the data structures anyway. For you, perhaps it will take some work. It's not impossible, nor is it particularly hard (modulo issues of determining whether the requested mailbox is the same as the selected one, which, as I said above, you have to deal with anyway). > you're as guilty as your predecessors at IBM who thought that "all the > world is S/360". A very good cop-out, and one that I've heard too often. I could as well make a banal comment about how people in acadaemia are detached from reality. It would be equally lame... and, despite how my tone comes across, I respect you too much to say that. Really. > This rewards bad client behavior, and worse, it prevents the broken clients > from being fixed. It's still a question of whether they're "broken". I agree with you that a well written client shouldn't need to do that. But it's legal, according to the spec. Now, if you want to change the spec to say "a client MUST NOT send a STATUS command for the currently selected mailbox, and a server MAY respond BAD (or NO) to such a request", then I'd agree that the client that did that is broken. And hey, I might even support such a change to the spec. :-) Barry Leiba, Multimedia Messaging (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba   Received: from cnri by ietf.org id aa27007; 17 Apr 97 16:14 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa19703; 17 Apr 97 16:14 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA04861; Thu, 17 Apr 1997 13:11:12 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA49894 for ; Thu, 17 Apr 1997 13:10:41 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA00760 for ; Thu, 17 Apr 1997 13:10:39 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA21149 for ; Thu, 17 Apr 1997 13:10:36 -0700 Received: from Ikkoku-Kan.Panda.COM (clam@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id NAA24196; Thu, 17 Apr 1997 13:10:33 -0700 (PDT) Received: from localhost (chince@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id NAA12157; Thu, 17 Apr 1997 13:10:29 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 13:08:57 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Chris Newman Cc: andy@hsl.meitca.com, IMAP Interest List Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997 09:52:03 -0700 (PDT), Chris Newman wrote: > > I want to consider abolishing text_mime2 from resp_text > That sounds like the right way to do it to me. Do you think that we can abolish text_mime2 as a protocol simplification without resetting the clock? We don't need to change the 7-bit nature of resp_text, since the LANGUAGE extension could relax that. I agree that it'd be best to go with UTF-8.   Received: from cnri by ietf.org id aa27409; 17 Apr 97 16:32 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa20038; 17 Apr 97 16:32 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA02245; Thu, 17 Apr 1997 13:28:51 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA54086 for ; Thu, 17 Apr 1997 13:28:19 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA02720 for ; Thu, 17 Apr 1997 13:28:18 -0700 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA08143; Thu, 17 Apr 1997 13:28:13 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHTAV81F0Q99E9T7@INNOSOFT.COM>; Thu, 17 Apr 1997 13:27:10 PDT Message-Id: Date: Thu, 17 Apr 1997 13:28:34 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: Mark Crispin Cc: andy@hsl.meitca.com, IMAP Interest List Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997, Mark Crispin wrote: > On Thu, 17 Apr 1997 09:52:03 -0700 (PDT), Chris Newman wrote: > > > I want to consider abolishing text_mime2 from resp_text > > That sounds like the right way to do it to me. > > Do you think that we can abolish text_mime2 as a protocol simplification > without resetting the clock? We don't need to change the 7-bit nature of > resp_text, since the LANGUAGE extension could relax that. I agree that it'd > be best to go with UTF-8. Not only would it be legal to delete text_mime2 on the move to draft standard, but the rules would require it be done in the absence of two interoperable implementations.   Received: from cnri by ietf.org id aa28958; 17 Apr 97 17:24 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa21280; 17 Apr 97 17:24 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA08532; Thu, 17 Apr 1997 14:19:55 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA54112 for ; Thu, 17 Apr 1997 14:18:55 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA08305 for ; Thu, 17 Apr 1997 14:18:51 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA09669 for ; Thu, 17 Apr 1997 14:18:49 -0700 Received: from Ikkoku-Kan.Panda.COM (dmt@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id OAA24246; Thu, 17 Apr 1997 14:18:45 -0700 (PDT) Received: from localhost (dlg@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id OAA12365; Thu, 17 Apr 1997 14:18:42 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 14:01:37 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Raymond Cheng Cc: IMAP Interest List Subject: Re: Bad Practice: issuing STATUS command for all mailboxes returned by LIST * In-Reply-To: <199704171926.MAA06662@mx2.cac.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997 19:26:23 -0700, Raymond Cheng wrote: > Out of curiousity, what does a client do if it wants to be able to show the > unread mail in each folder? It seems to me that this is what the STATUS > command is used for. It's true that STATUS may be extremely costly on the > server, but what other recourse is there for a client that wants to provide > this information? The recourse is to address the user desire in some other way. Part of this is to think of "what would I do if I didn't have a GUI, or if I was on a slow link". For example, instead of "showing the unread mail in each folder", you may have a command that says "find the next folder with unread mail". This command would not blindly get STATUS for all the folders in the list; rather, it would stop when it finds one that has a non-zero unread count. > And what if STATUS is not expensive on other servers? Why should a client be > prohibited from sending a STATUS for every mailbox on that server? The problem is that you can't guarantee that you'll always be talking to an ideal server. It also gives an excellent way by which a server can cause your client to look bad compared to other clients. I know of site managers that used the bad behavior of an older beta of one of your competitors' client as an excuse to ban that client from the entire organization. This may not even be deliberate. Your client will be stillborn in the radio IP arena. RTTs are very expensive. You'll spend a couple of seconds per transaction just doing the turnaround. > I do not intend to limit the usage of the STATUS command because of its > (possible) expense. If this were the case, then clients should also refrain > from sending the RFC822.SIZE command except on "user demand". The fact that RFC822.SIZE is part of the "FAST" and "FULL" fetch items should suggest to you that IMAP was designed and implemented on servers where this was fast. Furthermore, there is an aggregate way of fetching RFC822.SIZE for all messages in a single command. Now, in STATUS, there is no aggregation. You have to do an RTT for each single mailbox. It obviously could have been in LIST and it wasn't. This should suggest something to reasonable people.   Received: from cnri by ietf.org id aa02857; 17 Apr 97 21:17 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa25679; 17 Apr 97 21:17 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA43636; Thu, 17 Apr 1997 18:13:32 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA39760 for ; Thu, 17 Apr 1997 18:11:59 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA19376 for ; Thu, 17 Apr 1997 18:11:58 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA14791 for ; Thu, 17 Apr 1997 18:11:55 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <292ADGS7>; Thu, 17 Apr 1997 18:12:04 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACEEB049@DABONE> Date: Thu, 17 Apr 1997 18:11:54 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: IMAP Discusson List , "'Chris Newman (Innosoft)'" Subject: RE: IMAP URLs MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN *** Comments within > ---------- > From: Chris Newman[SMTP:Chris.Newman@Innosoft.COM] > Sent: Thursday, April 17, 1997 10:12 AM > To: IMAP Discusson List > Subject: IMAP URLs > > So, I'm going to have to do *yet another* revision on the IMAP URL > document. These are the changes which been required or hinted at > before > the IMAP URL document will be allowed to move to proposed standard: > *** No strong feelings either way on 1) and 2) > (3) The proposed process language for URLs > currently has text which > recommends > the use of hex-encoded UTF-8 in new URL schemes. This language has > caused > controversy and might be removed. The current IMAP URL spec contains > some > weasel wording in section 9 on this topic. I could take the next > step > and REQUIRE conversion between IMAP's modified UTF-7 and URL > hex-encoded > UTF-8 (were I to do this, I'd probably put a code snippet in an > appendix). > Comments? *** We would prefer to NOT require the conversion from modified UTF-7 to UTF8. This seems to be an unecessary conversion for IMAP clients and servers to go through. > I suspect these changes are signficant enough that another last call > is > merited, so there won't be an IMAP URL standard for a bit longer. > > So is anyone implementing IMAP URLs? *** We are using them for referrals.   Received: from cnri by ietf.org id aa03099; 17 Apr 97 21:31 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa25898; 17 Apr 97 21:31 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA04542; Thu, 17 Apr 1997 18:27:40 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA34166 for ; Thu, 17 Apr 1997 18:27:12 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA06897 for ; Thu, 17 Apr 1997 18:27:09 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (lum@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA15004 for ; Thu, 17 Apr 1997 18:27:06 -0700 Received: from Ikkoku-Kan.Panda.COM (icz@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id SAA24565; Thu, 17 Apr 1997 18:27:01 -0700 (PDT) Received: from localhost (hik@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id SAA13257; Thu, 17 Apr 1997 18:26:57 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 18:19:48 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: "Mike Gahrns (Exchange)" Cc: IMAP Discusson List , "'Chris Newman (Innosoft)'" Subject: RE: IMAP URLs In-Reply-To: <0A684133865BCF118F0E08002BE7ADACEEB049@DABONE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997 18:11:54 -0700, Mike Gahrns (Exchange) wrote: > *** We would prefer to NOT require the conversion from modified UTF-7 to > UTF8. This seems to be an unecessary conversion for IMAP clients and > servers to go through. IMAP servers have nothing to do with this. An IMAP server isn't going to deal with a URL at all (modulo your REFERRAL extension). IMAP clients are going to need to do conversions from UTF-8 anyway; what if they get an 8-bit URL? It is pretty clear that the URL guys are going to do with hex encoded UTF-8 for multinational characters in URLs, and that they emphatically do not want to see other conventions (such as IMAP modified UTF-7) appear in URLs. I support their position; or put another way, I do not support the use of modified UTF-7 in URLs and I will make no attempt to justify it to anyone. There is nothing that prevents a modified UTF-7 string from appearing in an IMAP URL. But it's highly unlikely that the URL end of things would see it as anything other than ASCII. Bottom line: you're going to have to handle UTF-8 and hex encoded UTF-8 anyway if you deal with IMAP URLs, because that's what you're likely to get. So, it's best not to ever deal with modified UTF-7 in URLs; it's never necessary.   Received: from cnri by ietf.org id aa05729; 17 Apr 97 22:55 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa27247; 17 Apr 97 22:55 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id TAA45152; Thu, 17 Apr 1997 19:51:55 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA43644 for ; Thu, 17 Apr 1997 19:51:32 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA12747 for ; Thu, 17 Apr 1997 19:51:29 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (rambo@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id TAA29443 for ; Thu, 17 Apr 1997 19:51:27 -0700 Received: from Ikkoku-Kan.Panda.COM (kkt@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id TAA24675; Thu, 17 Apr 1997 19:51:23 -0700 (PDT) Received: from localhost (keil@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id TAA13540; Thu, 17 Apr 1997 19:51:18 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 19:05:08 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: "Larry Osterman (Exchange)" Cc: IMAP Interest List Subject: RE: RFC2060: Bad example in 6.4.6. STORE Command In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997 18:48:24 -0700, Larry Osterman (Exchange) wrote: > The issue is the "#flag". I'd think that it should be simply "flag". Actually, it should be 1#flag, and that's in the errata as item #2. It was intended (see RFC-1064) that it be as you suggest (either a flag list or a single flag). > I > recognize that this is NOT an errata, however I talked to JGM at the > IETF, and he was unable to come up with a reason for this - it's been in > the grammer since 1730, so this is clearly NOT a bug, I'm just wondering > what the history is..... Once upon a time, the DEC-20 server permitted: A001 STORE 2 +FLAGS \Deleted \Seen because rather than parsing a flag or a list, it simply took the remainder of the line after the store attribute, stripped off parens at each end, and processed it as a flag list. Bill Yeager's UNIX server was also lax. Unfortunately, certain clients took advantage of it. It's easier to do: sprintf (cmd,"%s STORE %d",tag,msgno); if (deleted) strcat (cmd," \\Deleted"); if (seen) strcat (cmd," \\Seen"); than it is to build a proper parenthesized list. I found out the hard way, when early versions of my new UNIX server wouldn't work with those clients. 1730 bowed to reality. It was easier to put this in 1730 than it was to deal with flames from certain individuals about "unnecessary" parenthesis. I hope that everybody builds proper lists today. But, do you want to be the one who finds out otherwise, especially now that 1730 and 2060 have blessed the practice? -- Mark --   Received: from cnri by ietf.org id aa12509; 18 Apr 97 1:05 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa02344; 18 Apr 97 1:05 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id WAA00293; Thu, 17 Apr 1997 22:01:39 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA05564 for ; Thu, 17 Apr 1997 22:01:08 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA21204 for ; Thu, 17 Apr 1997 22:01:06 -0700 Received: from greendragon.com (mail.GreenDragon.Com [206.31.151.70]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA17889 for ; Thu, 17 Apr 1997 22:01:03 -0700 Received: from [206.31.151.87] by greendragon.com with ESMTP (Apple Internet Mail Server 1.1.1); Thu, 17 Apr 1997 23:59:46 -0600 Message-Id: Date: Thu, 17 Apr 1997 23:58:46 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Hanson To: IMAP Interest List Subject: Re: Bad practice: STATUS command on currently selected mailbox In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: chanson@mailbox.mcs.com X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN At 1:39 PM -0500 4/17/97, Mark Crispin wrote: >This rewards bad client behavior, and worse, it prevents the broken clients >from being fixed. By issuing STATUS commands for the currently-selected mailbox, are the clients in question violating protocol? If not, then they're not technically broken. They may be doing something non-optimal for your implementation, but that doesn't mean it doesn't work well for someone else's.   Received: from cnri by ietf.org id aa12735; 18 Apr 97 1:24 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa02654; 18 Apr 97 1:24 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id WAA25467; Thu, 17 Apr 1997 22:20:33 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA05516 for ; Thu, 17 Apr 1997 22:20:10 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA25795 for ; Thu, 17 Apr 1997 22:20:06 -0700 Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id WAA01877 for ; Thu, 17 Apr 1997 22:20:04 -0700 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA20171; Thu, 17 Apr 1997 22:18:57 -0700 Received: from mcm-nitro by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA02890; Thu, 17 Apr 1997 22:18:56 -0700 Received: from gentilly (awe182-47.AWE.Sun.COM) by mcm-nitro.eng.sun.com (Sun Internet MTA V3.1) with SMTP id <0E8TISQ4700FN5@mcm-nitro.eng.sun.com>; Thu, 17 Apr 1997 22:19:39 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 22:16:05 -0700 (PDT) Reply-To: William Yeager Sender: IMAP-owner@u.washington.edu Precedence: bulk From: William Yeager To: Chris Hanson Cc: IMAP Interest List Subject: Re: Bad practice: STATUS command on currently selected mailbox In-Reply-To: Your message with ID MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN >By issuing STATUS commands for the currently-selected mailbox, are the >clients in question violating protocol? If not, then they're not >technically broken. They may be doing something non-optimal for your >implementation, but that doesn't mean it doesn't work well for someone >else's. This depends on what the status command returns. We have extensions where the STATUS command supplies a "magic number" that tells us whether or not a client will need to resynchronize when reconnecting a disconnected session. Although this STATUS is returned after every write to the mailbox by the server, a client can ask for it at any time, eg, before disconnecting. More often than not, a client does NOT have to resync after a disconnected session because the magic number is valid when reconnecting. This is returned by the server at SELECT time if enabled by the client. So, no, I do not see this is a violation of the protocol. Bill   Received: from cnri by ietf.org id aa13415; 18 Apr 97 2:18 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa03375; 18 Apr 97 2:18 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id XAA02742; Thu, 17 Apr 1997 23:14:09 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA51944 for ; Thu, 17 Apr 1997 23:13:17 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA09405 for ; Thu, 17 Apr 1997 23:13:16 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (mel@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA18822 for ; Thu, 17 Apr 1997 23:13:14 -0700 Received: from Ikkoku-Kan.Panda.COM (mishk@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id XAA25018; Thu, 17 Apr 1997 23:13:11 -0700 (PDT) Received: from localhost (metka@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id XAA14147; Thu, 17 Apr 1997 23:13:06 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 22:12:55 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: IMAP Interest List Subject: Re: Bad practice: STATUS command on currently selected mailbox In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997 23:58:46 -0500, Chris Hanson wrote: > By issuing STATUS commands for the currently-selected mailbox, are the > clients in question violating protocol? If not, then they're not > technically broken. They may be doing something non-optimal for your > implementation, but that doesn't mean it doesn't work well for someone > else's. "The protocol does not forbid you from doing it" and "you should not do it" are two entirely separate concepts. The IP protocol permits you to send hundreds of 64K broadcast pings a second. That doesn't mean that you should do it. NFS and AFS protocol won't stop you from doing "ls -lRF /" but that doesn't mean that you should do such a thing (or for that matter even on a local filesystem). There is at least a (bad) justification for doing "ls -lRF /" -- one can argue that they want to load their GUI. This is the equivalent of doing a LIST * followed by a STATUS of each separate mailbox. Some sites have, as per the first paragraph of page 32 of RFC 2060, modified their servers so that LIST * returns nothing, or coerces * to %, as a defense against such bad behavior. This trend will undoubtably increase. But there is no purpose at all to doing a STATUS of the selected mailbox. By issuing a STATUS command for the currently-selected mailbox, a client betrays a fundamental misunderstanding and misimplementation of the IMAP protocol. Most clients that do this have the mistaken belief that this is how you check for new mail. It's like doing a stat() on an AFS path when you have an open file descriptor, with the expectation that the path is still in cache. You can get the same information with fstat(). More importantly that it's possible that (due to timing and cache considerations) stat() may not return the correct information for your open file descriptor. In effect, I'm telling you "use fstat(), not stat()"; and you're saying "it's just your implementation where stat() is a problem, why should we change what we're doing?"   Received: from cnri by ietf.org id aa28035; 21 Apr 97 3:12 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa02362; 21 Apr 97 3:12 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id AAA06789; Mon, 21 Apr 1997 00:05:15 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id AAA38346 for ; Mon, 21 Apr 1997 00:03:08 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id AAA29242 for ; Mon, 21 Apr 1997 00:03:06 -0700 Received: from angelico.CS.Berkeley.EDU (angelico.CS.Berkeley.EDU [128.32.42.120]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id AAA17881 for ; Mon, 21 Apr 1997 00:03:03 -0700 Received: from localhost (jefleung@localhost) by angelico.CS.Berkeley.EDU (8.6.10/8.6.9) with SMTP id AAA19629 for ; Mon, 21 Apr 1997 00:03:06 -0700 Message-Id: Date: Mon, 21 Apr 1997 00:03:05 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jeff!?! Leung To: IMAP Mailing List Subject: Question about second DELETE example in RFC2060... MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Authentication-Warning: angelico.CS.Berkeley.EDU: jefleung owned process doing -bs X-Sender: jefleung@angelico.CS.Berkeley.EDU X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN In 6.3.4 of RFC2060, there are two example of DELETE. Here is the second example: C: A82 LIST "" * S: * LIST () "." blurdybloop S: * LIST () "." foo S: * LIST () "." foo.bar S: A82 OK LIST completed C: A83 DELETE blurdybloop S: A83 OK DELETE completed C: A84 DELETE foo S: A84 OK DELETE Completed C: A85 LIST "" * S: * LIST () "." foo.bar S: A85 OK LIST completed C: A86 LIST "" % S: * LIST (\Noselect) "." foo S: A86 OK LIST completed I am confused now. After foo was successfully deleted, shouldn't it still appear in the response to A85 as it does in the response to A86? -- Jeff.   Received: from cnri by ietf.org id aa18544; 21 Apr 97 13:16 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa02655; 21 Apr 97 13:15 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA07592; Mon, 21 Apr 1997 10:08:30 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA49814 for ; Mon, 21 Apr 1997 10:07:01 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA06797 for ; Mon, 21 Apr 1997 10:06:57 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (johnbill@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA26973 for ; Mon, 21 Apr 1997 10:06:54 -0700 Received: from Ikkoku-Kan.Panda.COM (wml@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id KAA03308; Mon, 21 Apr 1997 10:06:50 -0700 (PDT) Received: from localhost (whlam@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id KAA02445; Mon, 21 Apr 1997 10:06:44 -0700 (PDT) Message-Id: Date: Mon, 21 Apr 1997 10:05:15 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Jeff!?! Leung Cc: IMAP Mailing List Subject: re: Question about second DELETE example in RFC2060... In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Mon, 21 Apr 1997 00:03:05 -0700 (PDT), Jeff!?! Leung wrote: > I am confused now. After foo was successfully deleted, shouldn't it still > appear in the response to A85 as it does in the response to A86? There is a specific reason why that second example was there; to demonstrate that it is not required that superior levels of hierarchy exist when inferior levels exist. Consider netnews. "comp.mail.misc" and "comp.mail.mime" exists, but "comp.mail" and "comp" do not.   Received: from cnri by ietf.org id aa21209; 21 Apr 97 14:03 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa14449; 21 Apr 97 14:03 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA44566; Mon, 21 Apr 1997 10:52:29 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA19528 for ; Mon, 21 Apr 1997 10:51:39 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA09067 for ; Mon, 21 Apr 1997 10:51:35 -0700 Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA28257; Mon, 21 Apr 1997 10:51:29 -0700 Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0wJNIJ-000UnYC; Mon, 21 Apr 97 11:54 MDT Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wJNHc-000RVMC; Mon, 21 Apr 97 11:53 MDT Message-Id: Date: Mon, 21 Apr 1997 11:51:46 -0600 (MDT) Reply-To: Steve Hole Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Steve Hole To: Mark Crispin Cc: IMAP Interest List , andy@hsl.meitca.com, Chris Newman Subject: re: Internationalized Server Response Text? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1b3 Build (8) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 17 Apr 1997 13:08:57 -0700 (PDT) Mark Crispin wrote: > On Thu, 17 Apr 1997 09:52:03 -0700 (PDT), Chris Newman wrote: > > > I want to consider abolishing text_mime2 from resp_text > > That sounds like the right way to do it to me. > > Do you think that we can abolish text_mime2 as a protocol simplification > without resetting the clock? We don't need to change the 7-bit nature of > resp_text, since the LANGUAGE extension could relax that. I agree that it'd > be best to go with UTF-8. When I was talking with Andrew about this exact thing at the IETF I had recommended against it because it might reset the clock. It would be *very* nice at the client end to make the change. I'm all for it if doesn't reset. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6   Received: from cnri by ietf.org id aa02546; 21 Apr 97 17:43 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa08315; 21 Apr 97 17:43 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA21447; Mon, 21 Apr 1997 14:39:50 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA17586 for ; Mon, 21 Apr 1997 14:37:56 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA11265 for ; Mon, 21 Apr 1997 14:37:54 -0700 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA17458 for ; Mon, 21 Apr 1997 14:37:48 -0700 Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Mon, 21 Apr 1997 17:36:55 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Mon, 21 Apr 1997 17:36:54 -0400 Message-Id: <3.0.32.19970421173813.00c08ef0@lacroix.wildbear.on.ca> Date: Mon, 21 Apr 1997 17:38:14 -0400 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: IMAP@cac.washington.edu Subject: queestion regarding FETCH and sections... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Just going over the specs, and I have an interesting question regarding sections and partial fetches. Assume that you have 3 mailboxes. 1) multipart, one part GIF and one part text, 60K and 4K for 64K 2) a text message, 5K 3) another text message, 50K Now, if my understanding of the specs is up to snuff, we want to only relay the FETCH information if we can present all of it to the user. Hence the discussions we had on what to do with FETCHes where one of the messages had been expunged. Now, given that, what would the IMAP list think is approriate behaviour if the above commands were issued? a) a01 fetch 1:3 body[]<6184.8192> b) a02 fetch 1:3 body[1.1] c) a03 fetch 1:3 body[1.1.MIME] d) a01 fetch 1:3 body[1.2]<6184.8192> (covered by a and b individually) Now, all of these will work in some case, and I think it would be difficult to justify searching through every case with the entire range of messages before sending any of them out. 6.4.5 deals with a read beyond the end, but doesn't say anything about a start beyond the end. so, I am missing something here, can I send out only the applicable fetches, or should I parse all messages within the given range, and then do another pass to output the messages? If there is nothing in the spec about it, what is the general consensus on 'the right thing'? regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa13098; 22 Apr 97 17:14 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa21001; 22 Apr 97 17:14 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA21112; Tue, 22 Apr 1997 14:11:07 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA43828 for ; Tue, 22 Apr 1997 14:09:50 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA26013 for ; Tue, 22 Apr 1997 14:09:49 -0700 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA29296 for ; Tue, 22 Apr 1997 14:09:44 -0700 Received: by lacroix.wildbear.on.ca from localhost (router,SLmailNT V3.0 (alpha 10)); Tue, 22 Apr 1997 17:08:17 -0400 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLmailNT V3.0 (alpha 10)); Tue, 22 Apr 1997 17:08:16 -0400 Message-Id: <3.0.32.19970422170943.00c95858@lacroix.wildbear.on.ca> Date: Tue, 22 Apr 1997 17:09:44 -0400 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: "Mike Gahrns (Exchange)" , "IMAP@cac.washington.edu" Subject: RE: queestion regarding FETCH and sections... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN At 01:44 PM 4/22/97 -0700, Mike Gahrns (Exchange) wrote: >This is already covered in rfc2060. > >For the messages where the FETCH would result in no data, you return >"NIL" in the fetch response. > >This is defined in the spec in the grammar section. Actually, the problem is conflicting definitions. In the case of the start and number of octets, it says in 6.4.5 that if the starting position goes past the end of known data, you return an empty string. But the grammar allows for a nstring and previous examples on the list would lend to a NIL response. So, its a question of whether a starting position past the end of the body part in question generates an "" or a NIL. With the client requesting a part of the message, say 1.1.MIME where there is no part 1.1, the question is whether or not this is an error or if this a case for NIL. If it is an error, then we need to treat this kind of like the EXPUNGEd message case, otherwise we can just spew out the NIL. Is it possible to clarify the specs on these points? Perhaps in the errata? Since we all seem to be talking a lot on FETCH responses, it might be useful to outline examples so that this is in the docs, and not a matter of interpretation of the specs. At a minimum, we should really be outlining what cases generate empty strings, which generate NILs, and which generate legitimate responses. regards, Jack p.s. and while these are technically in the specs, it does not lend itself to easy reading if you have to constantly try and guess whether something is one case or another because it isn't documented explicitly as either. ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa14657; 22 Apr 97 18:07 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa21984; 22 Apr 97 18:07 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA24536; Tue, 22 Apr 1997 15:03:31 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA48408 for ; Tue, 22 Apr 1997 15:02:52 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id PAA23546 for ; Tue, 22 Apr 1997 15:02:49 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id PAA00871 for ; Tue, 22 Apr 1997 15:02:47 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <292AFK4X>; Tue, 22 Apr 1997 15:02:32 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACEEB07A@DABONE> Date: Tue, 22 Apr 1997 15:02:37 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: "IMAP@cac.washington.edu" , "'Jack De Winters (Wildbear)'" Subject: RE: queestion regarding FETCH and sections... MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Oops, my mistake about the "NIL" in the case of the starting octet going past the end of known data. sorry. *** within > ---------- > From: Jack De Winter[SMTP:jack@wildbear.on.ca] > Sent: Tuesday, April 22, 1997 2:09 PM > To: Mike Gahrns (Exchange); IMAP@cac.washington.edu > Subject: RE: queestion regarding FETCH and sections... > > At 01:44 PM 4/22/97 -0700, Mike Gahrns (Exchange) wrote: > >This is already covered in rfc2060. > > > >For the messages where the FETCH would result in no data, you return > >"NIL" in the fetch response. > > > >This is defined in the spec in the grammar section. > > Actually, the problem is conflicting definitions. In the case of the > start and number of octets, it says in 6.4.5 that if the starting > position > goes past the end of known data, you return an empty string. But the > grammar allows for a nstring *** since empty string "" is also allowed by nstring, as per 6.4.5 you should return the empty string for this case. Sorry, when I replied earlier about "NIL" , I just was looking at the grammar and didn't read the 6.4.5 text. I guess there is a subtle difference between the non-existence of a particular data item vs. reading past the end of the data item, so maybe this is what motivated the 6.4.5 text to say to return an empty string. I could see one arguing that "NIL" is appropriate in this case as well, but it is probably safest/easiest just to follow what was specified in the 6.4.5 text. > and previous examples on the list would lend > to a NIL response. So, its a question of whether a starting position > past the end of the body part in question generates an "" or a NIL. > > With the client requesting a part of the message, say 1.1.MIME where > there is no part 1.1, the question is whether or not this is an error > or > if this a case for NIL. If it is an error, then we need to treat this > kind of like the EXPUNGEd message case, otherwise we can just spew out > the NIL. *** for this case the NIL should be sent out. as per rfc2060, "NIL" represents the non-existance of a particular data item that is represented as a string or parenthesized list. > Is it possible to clarify the specs on these points? Perhaps in the > errata? Since we all seem to be talking a lot on FETCH responses, it > might be useful to outline examples so that this is in the docs, and > not a matter of interpretation of the specs. At a minimum, we should > really be outlining what cases generate empty strings, which generate > NILs, and which generate legitimate responses. > > regards, > Jack > > p.s. and while these are technically in the specs, it does not lend > itself > to easy reading if you have to constantly try and guess whether > something > is one case or another because it isn't documented explicitly as > either. > ------------------------------------------------- > Jack De Winter - Wildbear Consulting, Inc. > (519) 576-3873 http://www.wildbear.on.ca/ > > Author of SLMail for 95 & NT (http://www.seattlelab.com/) >   Received: from cnri by ietf.org id aa15003; 22 Apr 97 18:32 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa22531; 22 Apr 97 18:32 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA19435; Tue, 22 Apr 1997 13:47:46 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA50716 for ; Tue, 22 Apr 1997 13:44:38 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA23083 for ; Tue, 22 Apr 1997 13:44:35 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA28581 for ; Tue, 22 Apr 1997 13:44:32 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <292AF2GL>; Tue, 22 Apr 1997 13:44:22 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACEEB078@DABONE> Date: Tue, 22 Apr 1997 13:44:28 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: "IMAP@cac.washington.edu" , "'Jack De Winters (Wildbear)'" Subject: RE: queestion regarding FETCH and sections... MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN This is already covered in rfc2060. For the messages where the FETCH would result in no data, you return "NIL" in the fetch response. This is defined in the spec in the grammar section. > ---------- > From: Jack De Winter[SMTP:jack@wildbear.on.ca] > Sent: Monday, April 21, 1997 2:38 PM > To: IMAP@cac.washington.edu > Subject: queestion regarding FETCH and sections... > > Just going over the specs, and I have an interesting question > regarding sections and partial fetches. Assume that you have > 3 mailboxes. > > 1) multipart, one part GIF and one part text, 60K and 4K for 64K > 2) a text message, 5K > 3) another text message, 50K > > Now, if my understanding of the specs is up to snuff, we want > to only relay the FETCH information if we can present all of it > to the user. Hence the discussions we had on what to do with > FETCHes where one of the messages had been expunged. > > Now, given that, what would the IMAP list think is approriate > behaviour > if the above commands were issued? > > a) a01 fetch 1:3 body[]<6184.8192> > b) a02 fetch 1:3 body[1.1] > c) a03 fetch 1:3 body[1.1.MIME] > d) a01 fetch 1:3 body[1.2]<6184.8192> (covered by a and b > individually) > > Now, all of these will work in some case, and I think it would be > difficult to justify searching through every case with the entire > range of messages before sending any of them out. 6.4.5 deals with > a read beyond the end, but doesn't say anything about a start beyond > the end. > > so, I am missing something here, can I send out only the applicable > fetches, or should I parse all messages within the given range, and > then do another pass to output the messages? If there is nothing in > the spec about it, what is the general consensus on 'the right thing'? > > regards, > Jack > ------------------------------------------------- > Jack De Winter - Wildbear Consulting, Inc. > (519) 576-3873 http://www.wildbear.on.ca/ > > Author of SLMail for 95 & NT (http://www.seattlelab.com/) >   Received: from cnri by ietf.org id aa00942; 23 Apr 97 21:06 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa24456; 23 Apr 97 21:06 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA00684; Wed, 23 Apr 1997 18:02:03 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA46286 for ; Wed, 23 Apr 1997 17:59:38 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA02493 for ; Wed, 23 Apr 1997 17:59:36 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA15444 for ; Wed, 23 Apr 1997 17:59:33 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <292AG1L9>; Wed, 23 Apr 1997 17:59:33 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACEEB094@DABONE> Date: Wed, 23 Apr 1997 17:59:29 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: 'IMAP Mailing List' Subject: FW: I-D ACTION:draft-gahrns-imap-referrals-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I've submitted another IMAP referrals draft. Based upon some experiences we have had while implementing, it extends IMAP referrals to other IMAP commands such as APPEND. The rest is the same as before. Chris Newman, Mark Crispin, Matt Wall: This is the same as the draft I forwarded right before the IETF with suggestions incorporated. Sorry, it took so long to reach the list, but it got bogged down when the IETF stopped taking submissions due to the Memphis IETF mtg. thx, -mikega > ---------- > From: Internet-Drafts@ietf.org[SMTP:Internet-Drafts@ietf.org] > Reply To: Internet-Drafts@ietf.org > Sent: Wednesday, April 23, 1997 6:45 AM > To: IETF-Announce@ietf.org > Subject: I-D ACTION:draft-gahrns-imap-referrals-02.txt > > > A Revised Internet-Draft is available from the on-line > Internet-Drafts > directories. > > > Note: This revision reflects comments received during the last call > period. > > Title : IMAP4 Referrals > > Author(s) : M. Gahrns > Filename : draft-gahrns-imap-referrals-02.txt > Pages : 9 > Date : 04/22/1997 > > When dealing with large amounts of users, messages and geographically > dispersed IMAP4 [RFC-2060] servers, it is often desirable to > distribute > messages amongst different servers within an organization. For > example an > administrator may choose to store user's personal mailboxes on a local > > IMAP4 server, while storing shared mailboxes remotely on another > server. > This type of configuration is common when it is uneconomical to store > all > data centrally due to limited bandwidth or disk resources. > Additionally, > users may be frequently moved from one IMAP4 server to another because > of > hardware failures or organizational changes. > > Referrals allow clients to seamlessly access mailboxes that are > distributed > across several IMAP4 servers or to transparently connect to an > alternate > IMAP4 server. > > A referral mechanism can provide efficiencies over the alternative > "proxy method", in which the local IMAP4 server contacts the remote > server on behalf of the client, and then transfers the data from the > remote server to itself, and then on to the client. The referral > mechanism's direct client connection to the remote server is often a > more efficient use of bandwidth, and does not require the local server > > to impersonate the client when authenticating to the remote server. > > Internet-Drafts are 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-gahrns-imap-referrals-02.txt". > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-referrals-02.t > xt > > Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: ftp.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-gahrns-imap-referrals-02.txt". > > NOTE: The mail server at ds.internic.net 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. >   Received: from cnri by ietf.org id aa13139; 24 Apr 97 3:33 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa04570; 24 Apr 97 3:33 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id AAA14292; Thu, 24 Apr 1997 00:25:48 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id AAA51858 for ; Thu, 24 Apr 1997 00:23:48 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id AAA24542 for ; Thu, 24 Apr 1997 00:23:45 -0700 Received: from jimi-hendrix.mcom.com (h-205-217-228-33.netscape.com [205.217.228.33]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id AAA07255 for ; Thu, 24 Apr 1997 00:23:44 -0700 Received: from jimi-hendrix.mcom.com ([205.217.228.33]) by jimi-hendrix.mcom.com (Netscape Messaging Server 3.0b2) with SMTP id AAA2618; Thu, 24 Apr 1997 00:23:10 -0700 Message-Id: Date: Thu, 24 Apr 1997 00:23:09 -0700 (PDT) Reply-To: Mike Macgirvin Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mike Macgirvin To: "Mike Gahrns (Exchange)" Cc: 'IMAP Mailing List' Subject: Re: FW: I-D ACTION:draft-gahrns-imap-referrals-02.txt In-Reply-To: <0A684133865BCF118F0E08002BE7ADACEEB094@DABONE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: "Mike Macgirvin" X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I got a few funny characters about 2/3 through section 3 (document retrieved from ftp://ds.internic.net). LIST ~~ #SHARED%~ where '~' indicates a non-printable ASCII char (high bit set, my Window Manager wouldn't paste it in without mangling it). -- Maybe this has been covered before, but I question the requirement that LIST and LSUB should list out mailboxes which would be referrals. Granted, it's marked SHOULD, but you're requiring a server to know some pretty intimate details of something which doesn't belong to it. This implies that a home server (system 'a') needs to know the entire state of affairs w/r/t NoSelect, Marked/Unmarked, NoInferiors, etc. of the mailboxes on system 'b'. That's a tall order and if indeed the authority for this info is on system 'b', and system 'a' has to go out and hunt it down, it tends to violate the 2060 requirement that a server should do its darndest to return from LIST in a timely fashion. I think this section is going to cause problems. It also doesn't seem right that list returns * LIST () '/' #shared/foo yet "SELECT #shared/foo" could return a NO to a client that is unaware of referrals. Of course it's legal for a command to fail, but likely to cause a great deal of consternation because it claims to be selectable. If you just replaced the SHOULD in section 3 (para 7) with MAY it would minimize my concerns. In short, I'd like to be able to _not_ support "remote" LIST and LSUB, yet provide other referral mechanisms. Can this be accommodated?   Received: from cnri by ietf.org id aa09649; 24 Apr 97 14:11 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa17077; 24 Apr 97 14:11 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA06683; Thu, 24 Apr 1997 10:56:34 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA22502 for ; Thu, 24 Apr 1997 10:54:33 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA27501 for ; Thu, 24 Apr 1997 10:54:30 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA01135 for ; Thu, 24 Apr 1997 10:54:28 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Thu, 24 Apr 1997 10:54:08 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACEEB095@DABONE> Date: Thu, 24 Apr 1997 10:53:38 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: 'Mike Macgirvin' Cc: 'IMAP Mailing List' Subject: RE: FW: I-D ACTION:draft-gahrns-imap-referrals-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hi Mike, *** Within > ---------- > From: Mike Macgirvin[SMTP:MAX@Netscape.COM] > Reply To: Mike Macgirvin > Sent: Thursday, April 24, 1997 12:23 AM > To: Mike Gahrns (Exchange) > Cc: 'IMAP Mailing List' > Subject: Re: FW: I-D ACTION:draft-gahrns-imap-referrals-02.txt > > > I got a few funny characters about 2/3 through section 3 (document > retrieved > from ftp://ds.internic.net). > LIST ~~ #SHARED%~ > where '~' indicates a non-printable ASCII char (high bit set, my > Window Manager > wouldn't paste it in without mangling it). *** Sorry about that. I will track down and fix > -- > Maybe this has been covered before, but I question the requirement > that LIST > and LSUB should list out mailboxes which would be referrals. Granted, > it's > marked SHOULD, but you're requiring a server to know some pretty > intimate > details of something which doesn't belong to it. This implies that a > home > server (system 'a') needs to know the entire state of affairs w/r/t > NoSelect, > Marked/Unmarked, NoInferiors, etc. of the mailboxes on system 'b'. > That's a > tall order and if indeed the authority for this info is on system 'b', > and > system 'a' has to go out and hunt it down, it tends to violate the > 2060 > requirement that a server should do its darndest to return from LIST > in a > timely fashion. I think this section is going to cause problems. *** I can see how this may be difficult to implement for some servers. It really depends upon how a server implement things as to how difficult it will be to return this information in a timely fashion. For example, some servers have a distributed hierachy that is replicated automatically and can instantly return this info. That said, I think you bring up a valid point in that there are some aspects of referrals that may be of interest to a server, and the draft should not preclude a server from implementing a subset. There really are 2 classes of problems we are solving with referrals 1a) Move Server and 1b) Move User , where we give a Login referral and 2) Distributed hierarchy where mailboxes may be scattered across several servers and we give a Mailbox referral I am now thinking that maybe the draft should be split into two - Login Referrals and Mailbox Referrals What would people think of this? > It also doesn't seem right that list returns > > * LIST () '/' #shared/foo > > yet "SELECT #shared/foo" could return a NO to a client that is unaware > of > referrals. Of course it's legal for a command to fail, but likely to > cause a > great deal of consternation because it claims to be selectable. If you > just > replaced the SHOULD in section 3 (para 7) with MAY it would minimize > my > concerns. In short, I'd like to be able to _not_ support "remote" LIST > and > LSUB, yet provide other referral mechanisms. Can this be accommodated? *** I could change the wording to accomodate. However, Chris Newman and some others have expressed some concerns in this area as well, so perhaps a stronger solution is necessary. I know that Mark Crispin has some strong arguments that say having a client issue a command that would put the server in a particular mode is problematic. So I think a command like ENABLE_REFERRALS that would make the referred mailboxes appear in a LIST response is out of consideration. What I think would work, however, is to define a new Referrals List command called RLIST. If a client supported mailbox referrals, and it was operating against a mailbox referrals enabled server, it would issue RLIST instead of LIST. Everything about the two commands would be the same, but now remote mailboxes would be returned. Would people be okay with this? So to recap: 1) Propose to split the draft into a Login Referrals and a Mailbox Referrals Draft. 2) Create a new command RLIST, that will include remote mailboxes in the LIST response. Comments > > >   Received: from cnri by ietf.org id aa12370; 28 Apr 97 2:21 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa03137; 28 Apr 97 2:21 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id XAA26172; Sun, 27 Apr 1997 23:06:10 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA51554 for ; Sun, 27 Apr 1997 23:04:00 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA14294 for ; Sun, 27 Apr 1997 23:03:59 -0700 Received: from uxmail.ust.hk (root@uxmail.ust.hk [143.89.14.30]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id XAA15370; Sun, 27 Apr 1997 23:03:47 -0700 Received: from ccsu51 ([143.89.103.20]) by uxmail.ust.hk with SMTP id <102341-14532>; Mon, 28 Apr 1997 14:03:20 +0800 Received: by ccsu51 (SMI-8.6//ident-1.0) id OAA20661; Mon, 28 Apr 1997 14:03:05 +0800 Message-Id: <199704280603.OAA20661@ccsu51> Date: Mon, 28 Apr 1997 14:03:05 +0800 (HKT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: ccyflai@uxmail.ust.hk MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US To: MRC@cac.washington.edu Cc: IMAP@cac.washington.edu Subject: IMAP toolkit crash: Lock when already locked Content-Type: text X-Mailer: ELM [version 2.4 PL24alpha3] X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN It found that the the captioned error occurs quite frequently with IMAP4rev1 v10.168. Everytime such error is encountered, the imapd died out. Checking from source code, the mail_lock()/mail_unlock() functions are simply setting a variable flag for locking and unlocking. Is it possible a race condition occured that lead to the problem? What is the function of these routines? It seems that it's not related to mbox locking mechanism for exclusive access. How about the latest version of IMAPrev1? Has it already tackled this problem as well? Thank you for any kind assistance of this problem. Rgds, ======================================================================= Lai Yiu Fai | Tel.: (852) 2358-6202 Centre of Computing Services | Fax.: (852) 2358-0967 & Telecommunications | E-mail: ccyflai@uxmail.ust.hk | The Hong Kong University of | Clear Water Bay, Science & Technology | Kowloon, Hong Kong.   Received: from cnri by ietf.org id aa14452; 28 Apr 97 4:32 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa04979; 28 Apr 97 4:32 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id BAA29784; Mon, 28 Apr 1997 01:20:47 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA41556 for ; Mon, 28 Apr 1997 01:20:03 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA19984 for ; Mon, 28 Apr 1997 01:20:01 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (lum@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA17069 for ; Mon, 28 Apr 1997 01:19:59 -0700 Received: from Ikkoku-Kan.Panda.COM (nark@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id BAA12651; Mon, 28 Apr 1997 01:19:56 -0700 (PDT) Received: from localhost (mturn@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id BAA29912; Mon, 28 Apr 1997 01:19:50 -0700 (PDT) Message-Id: Date: Mon, 28 Apr 1997 00:53:36 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: ccyflai@uxmail.ust.hk Cc: IMAP@cac.washington.edu Subject: re: IMAP toolkit crash: Lock when already locked In-Reply-To: <199704280603.OAA20661@ccsu51> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN The most likely cause of your problem is the use of Netscape's IMAP client. Netscape's IMAP client has a bug in which it opens many IMAP sessions (one session for each message being downloaded) in rapid succession. The UNIX mailbox format does not support multiple read/write sessions. This triggers a mechanism to seize the UNIX mailbox write lock (which can only be held by one imapd) from any prior imapd. Part of that mechanism is an attempt to save the user's changes in that prior imapd session. Unfortunately, Netscape does it so fast that it catches the prior imapd while it was doing something else, thus causing an invalid recursion that the "lock when already locked" check rejects. In other words, the UNIX mailbox code interprets Netscape's multiple session behavior as a sequence of crashed clients and session restarts, but the "crash" happens while the server is still actively doing a previous client request. Even with mailbox formats that support multiple read/write sessions, it is bad to have the same client open multiple sessions to the same mailbox. The only way to fix this, which has been done in more recent versions, is not to try to save the user's changes any more. Some users may lose their work, but Netscape left no choice. It has been reported that newer versions of Netscape's client no longer do this bad behavior as often, but it still happens. Remember that even Netscape says that their client is beta software; you should take their word and not use it on production systems.   Received: from cnri by ietf.org id aa19392; 28 Apr 97 14:28 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa15967; 28 Apr 97 14:28 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA30842; Mon, 28 Apr 1997 11:17:25 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA45264 for ; Mon, 28 Apr 1997 11:15:03 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id LAA11899 for ; Mon, 28 Apr 1997 11:14:58 -0700 Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id LAA24959 for ; Mon, 28 Apr 1997 11:14:56 -0700 Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0wLuzr-000UlrC; Mon, 28 Apr 97 12:17 MDT Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wLuwu-000RWrC; Mon, 28 Apr 97 12:14 MDT Message-Id: Date: Mon, 28 Apr 1997 11:54:54 -0600 (MDT) Reply-To: Steve Hole Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Steve Hole To: "Mike Gahrns (Exchange)" Cc: 'Mike Macgirvin' , 'IMAP Mailing List' Subject: RE: FW: I-D ACTION:draft-gahrns-imap-referrals-02.txt MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1b3 Build (8) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Thu, 24 Apr 1997 10:53:38 -0700 "Mike Gahrns (Exchange)" wrote: > 2) Distributed hierarchy where mailboxes may be scattered across several > servers and we give a Mailbox referral This is the really valuable thing I think. > I am now thinking that maybe the draft should be split into two - Login > Referrals and Mailbox Referrals > > What would people think of this? Well, I still think that mailbox distribution is valid in the presence of a global authentication framework (Kerberos). I am not sure how that would solve the problem of distribution of mailbox space -- I would certainly wish to distribute in the presence of a global authentication namespace. A login referral is really a service referral and I would suggest that Service Location (svrloc) would be a better way to handle that. > > concerns. In short, I'd like to be able to _not_ support "remote" LIST > > and LSUB, yet provide other referral mechanisms. Can this be > > accommodated? Stuff deleted ... > What I think would work, however, is to define a new Referrals List > command called RLIST. If a client supported mailbox referrals, and it > was operating against a mailbox referrals enabled server, it would issue > RLIST instead of LIST. Everything about the two commands would be the > same, but now remote mailboxes would be returned. > > Would people be okay with this? It would be really nice to have servers list mailbox referrals, but it should not be manditory (Mike's reasons are very valid). It seems to me that this is a quality of service issue. If the server can do mailbox list referrals, that is great. If it can't then the client will still find out when it tries to select the mailbox. A good client really shouldn't make the referral transaction visible anyway. The big issue from the client point of view is representing the "state" of the folder correctly and (perhaps) disabling or enabling functionality that is specific to a certain state. For example a client would disable a "mailbox create" function if the mailbox is marked as \NoInferiors. That way a user can never attempt a create that will fail. By having list referrals, it just makes the information to the client better (more intuitive) and avoids potential user surprise. The client would still operate correctly in the end. It will fail to open the folder and get a referral, which it may or may not be able to follow. So, to summarize: 1. I would not put in a special command. The quality of information to the client is useful but not critical. The server can either provide it or not. There is no special syntactic or semantic content that a client needs to process differently other than the referral syntax itself. The client simply needs to handle referrals, which it needs to handle anyway. 2. I would relax the language to say MAY for listing. If the server can do it, great. I would like to use such a server. For many sites it just wouldn't be necessary. If the server can't support it, the client can still get the referral on select and act appropriately. > So to recap: > > 1) Propose to split the draft into a Login Referrals and a Mailbox > Referrals Draft. I don't think this is necessary (or even useful?). > 2) Create a new command RLIST, that will include remote mailboxes in the > LIST response. I don't think this is useful. The client can deal with a referral or not. The server can issue referrals or not. It is quality of service information. Cheers. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6   Received: from cnri by ietf.org id aa05603; 28 Apr 97 20:48 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa24344; 28 Apr 97 20:48 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA30826; Mon, 28 Apr 1997 17:41:30 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA17672 for ; Mon, 28 Apr 1997 17:40:44 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id RAA22026 for ; Mon, 28 Apr 1997 17:40:42 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id RAA07517 for ; Mon, 28 Apr 1997 17:40:38 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Mon, 28 Apr 1997 17:40:16 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACEEB0D1@DABONE> Date: Mon, 28 Apr 1997 17:40:10 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: 'Steve Hole' Cc: 'Mike Macgirvin' , "'IMAP Mailing List'"@u.washington.edu Subject: RE: FW: I-D ACTION:draft-gahrns-imap-referrals-02.txt MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I have had a couple of requests to seperate mailbox referrals and login referrals and think it is the right thing to do. After conferring with Harald Alvestrand, the Area Director, I am even more convinced. So in the next week or two, I will make 2 seperate drafts available. Steve Hole writes: > So, to summarize: > > 1. I would not put in a special command. The quality of information > to > the client is useful but not critical. The server can either provide > it > or not. There is no special syntactic or semantic content that a > client > needs to process differently other than the referral syntax itself. > The client simply needs to handle referrals, which it needs to handle > anyway. > > 2. I would relax the language to say MAY for listing. If the server > can > do it, great. I would like to use such a server. For many sites it > just > wouldn't be necessary. If the server can't support it, the client > can > still get the referral on select and act appropriately. *** An alternative to a new command like RLIST that listed both local and remote mailboxes, that was suggested by Harald was to return an untagged NO response with a REFERRAL response code. e.g. A001 LIST "" % * LIST () "/" "Local" * NO () [REFERRAL IMAP://Server2/Remote] Remote Mailbox A001 OK This avoids the overhead of inventing a new command, and saves the a non-referral enable client from presenting remote mailboxes that would be unselectable to the client. The rational behind this being that non referral enable clients will ignore the untagged NO and not display remote mailboxes, which referral enabled clients would display. (Or am I mistaken here, and will some clients actually try to display the info on untagged NOs to the user? The text in 7.1.1 describing the OK response explicitly states that the human readable text MAY be presented to the user as an information message, but the text for 7.1.2 describing the NO response omits this statement) Thoughts on the above approach?   Received: from cnri by ietf.org id aa16660; 30 Apr 97 12:40 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa14482; 30 Apr 97 12:40 EDT Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with SMTP id JAA35114; Wed, 30 Apr 1997 09:19:25 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with ESMTP id JAA19160 for ; Wed, 30 Apr 1997 09:16:28 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with ESMTP id JAA29391 for ; Wed, 30 Apr 1997 09:16:24 -0700 Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with ESMTP id JAA13882 for ; Wed, 30 Apr 1997 09:16:20 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIB7UFO9W099EXJN@INNOSOFT.COM> for imap@cac.washington.edu; Wed, 30 Apr 1997 09:15:17 PDT Message-Id: Date: Wed, 30 Apr 1997 09:16:45 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: IMAP Discusson List Cc: IETF URI list Subject: UTF8 IMAP URLs MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-862417005=:16628" X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1804928587-862417005=:16628 Content-Type: TEXT/PLAIN; charset=US-ASCII So I bit the bullet and wrote _experimental_ code to convert between an IMAP mailbox (encoded with modified UTF-7) and a hex-encoded UTF-8 URL path. It's actually considerably more complex than I thought it would be. Of course this code also does proper quoting of unsafe URL characters, deals with UTF-16 encoding correctly (thus supporting up to 2 million characters), and correctly interprets 8-bit URLs as UTF-8 (mapping them back to IMAP's modified UTF-7). Interesting facts I noticed in the process: * UTF-7 can be a denser format than UTF-8. The bound for worst case conversion has UTF-8 taking up 9/8 the space of a UTF-7 string. * Hex encoded UTF-8 is really gross. It has a worst case bound of 3.375 times the input UTF-7 string. (I'll note this may be a feature since it will give implementors a lot of incentive to support 8-bit UTF-8 strings). * Hex encoded UTF-8 is probably the only way to add multilingual support to any URLs that's not completely hostle to the URL installed base. * Since it's necessary to quote a literal "&" as "&-" when converting to modified-UTF-7, the URLtoMailbox() routine will not work with a modified UTF-7 URL as input. --- So, given that public domain code now exists to do it, would there be any strong objections to replacing the current weasel wording in the IMAP URL draft with a rule that IMAP URLs MUST use UTF-8? ---559023410-1804928587-862417005=:16628 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="imapurl.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyogaW1hcHVybC5jIC0tIElNQVAgbW9kaWZpZWQgVVRGLTcgdG8gVVJMIFVU Ri04IGNvbnZlcnNpb24gdXRpbGl0aWVzDQogKi8NCg0KI2luY2x1ZGUgPHN0 ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8c3RyaW5n Lmg+DQoNCi8qIGhleGFkZWNpbWFsIGxvb2t1cCB0YWJsZSAqLw0Kc3RhdGlj IGNoYXIgaGV4W10gPSAiMDEyMzQ1Njc4OUFCQ0RFRiI7DQoNCi8qIFVSTCB1 bnNhZmUgcHJpbnRhYmxlIGNoYXJhY3RlcnMgKi8NCnN0YXRpYyBjaGFyIHVy bHVuc2FmZVtdID0gIiBcIiMlJis6Ozw9Pj9AW1xcXV5ge3x9IjsNCg0KLyog VVRGNyBtb2RpZmllZCBiYXNlNjQgYWxwaGFiZXQgKi8NCnN0YXRpYyBjaGFy IGJhc2U2NGNoYXJzW10gPQ0KICAiQUJDREVGR0hJSktMTU5PUFFSU1RVVldY WVphYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5ejAxMjM0NTY3ODkrLCI7DQoj ZGVmaW5lIFVOREVGSU5FRCA2NA0KDQovKiBVVEYxNiBkZWZpbml0aW9ucyAq Lw0KI2RlZmluZSBVVEYxNk1BU0sJMHgwM0ZGVUwNCiNkZWZpbmUgVVRGMTZT SElGVAkxMA0KI2RlZmluZSBVVEYxNkhJR0hTVEFSVAkweEQ4MDBVTA0KI2Rl ZmluZSBVVEYxNkhJR0hFTkQJMHhEQkZGVUwNCiNkZWZpbmUgVVRGMTZMT1NU QVJUCTB4REMwMFVMDQojZGVmaW5lIFVURjE2TE9FTkQJMHhERkZGVUwNCg0K LyogQ29udmVydCBhbiBJTUFQIG1haWxib3ggdG8gYSBVUkwgcGF0aA0KICog IGRzdCBuZWVkcyB0byBoYXZlIHJvdWdobHkgNCB0aW1lcyB0aGUgc3RvcmFn ZSBzcGFjZSBvZiBzcmMNCiAqICAgIEhleCBlbmNvZGluZyBjYW4gdHJpcGxl IHRoZSBzaXplIG9mIHRoZSBpbnB1dA0KICogICAgVVRGLTcgY2FuIGJlIHNs aWdodGx5IGRlbnNlciB0aGFuIFVURi04DQogKiAgICAgKHdvcnN0IGNhc2U6 IDggb2N0ZXRzIFVURi03IGJlY29tZXMgOSBvY3RldHMgVVRGLTgpDQogKi8N CnZvaWQgTWFpbGJveFRvVVJMKGNoYXIgKmRzdCwgY2hhciAqc3JjKQ0Kew0K ICAgIHVuc2lnbmVkIGNoYXIgYywgaSwgYml0Y291bnQ7DQogICAgdW5zaWdu ZWQgbG9uZyB1Y3M0LCB1dGYxNiwgYml0YnVmOw0KICAgIHVuc2lnbmVkIGNo YXIgYmFzZTY0WzI1Nl0sIHV0ZjhbNl07DQoNCiAgICAvKiBpbml0aWFsaXpl IG1vZGlmaWVkIGJhc2U2NCBkZWNvZGluZyB0YWJsZSAqLw0KICAgIG1lbXNl dChiYXNlNjQsIFVOREVGSU5FRCwgc2l6ZW9mIChiYXNlNjQpKTsNCiAgICBm b3IgKGkgPSAwOyBpIDwgc2l6ZW9mIChiYXNlNjRjaGFycyk7ICsraSkgew0K CWJhc2U2NFtiYXNlNjRjaGFyc1tpXV0gPSBpOw0KICAgIH0NCiAgICANCiAg ICAvKiBsb29wIHVudGlsIGVuZCBvZiBzdHJpbmcgKi8NCiAgICB3aGlsZSAo KnNyYyAhPSAnXDAnKSB7DQoJYyA9ICpzcmMrKzsNCgkvKiBkZWFsIHdpdGgg bGl0ZXJhbCBjaGFyYWN0ZXJzIGFuZCAmLSAqLw0KCWlmIChjICE9ICcmJyB8 fCAqc3JjID09ICctJykgew0KCSAgICBpZiAoYyA8ICcgJyB8fCBjID4gJ34n IHx8IHN0cmNocih1cmx1bnNhZmUsIGMpICE9IE5VTEwpIHsNCgkJLyogaGV4 IGVuY29kZSBpZiBuZWNlc3NhcnkgKi8NCgkJZHN0WzBdID0gJyUnOw0KCQlk c3RbMV0gPSBoZXhbYyA+PiA0XTsNCgkJZHN0WzJdID0gaGV4W2MgJiAweDBm XTsNCgkJZHN0ICs9IDM7DQoJICAgIH0gZWxzZSB7DQoJCS8qIGVuY29kZSBs aXRlcmFsbHkgKi8NCgkJKmRzdCsrID0gYzsNCgkgICAgfQ0KCSAgICAvKiBz a2lwIG92ZXIgdGhlICctJyBpZiB0aGlzIGlzIGFuICYtIHNlcXVlbmNlICov DQoJICAgIGlmIChjID09ICcmJykgKytzcmM7DQoJfSBlbHNlIHsNCgkgICAg LyogY29udmVydCBtb2RpZmllZCBVVEYtNyAtPiBVVEYtMTYgLT4gVUNTLTQg LT4gVVRGLTggLT4gSEVYICovDQoJICAgIGJpdGJ1ZiA9IDA7DQoJICAgIGJp dGNvdW50ID0gMDsNCgkgICAgdWNzNCA9IDA7DQoJICAgIHdoaWxlICgoYyA9 IGJhc2U2NFsodW5zaWduZWQgY2hhcikgKnNyY10pICE9IFVOREVGSU5FRCkg ew0KCQkrK3NyYzsNCgkJYml0YnVmID0gKGJpdGJ1ZiA8PCA2KSB8IGM7DQoJ CWJpdGNvdW50ICs9IDY7DQoJCS8qIGVub3VnaCBiaXRzIGZvciBhIFVURi0x NiBjaGFyYWN0ZXI/ICovDQoJCWlmIChiaXRjb3VudCA+PSAxNikgew0KCQkg ICAgYml0Y291bnQgLT0gMTY7DQoJCSAgICB1dGYxNiA9IChiaXRjb3VudCA/ IGJpdGJ1ZiA+PiBiaXRjb3VudCA6IGJpdGJ1ZikgJiAweGZmZmY7DQoJCSAg ICAvKiBjb252ZXJ0IFVURjE2IHRvIFVDUzQgKi8NCgkJICAgIGlmICh1dGYx NiA+PSBVVEYxNkhJR0hTVEFSVCAmJiB1dGYxNiA8PSBVVEYxNkhJR0hFTkQp IHsNCgkJCXVjczQgPSAodXRmMTYgJiBVVEYxNk1BU0spIDw8IFVURjE2U0hJ RlQ7DQoJCQljb250aW51ZTsNCgkJICAgIH0gZWxzZSBpZiAodXRmMTYgPj0g VVRGMTZMT1NUQVJUICYmIHV0ZjE2IDw9IFVURjE2TE9FTkQpIHsNCgkJCXVj czQgfD0gdXRmMTYgJiBVVEYxNk1BU0s7DQoJCSAgICB9IGVsc2Ugew0KCQkJ dWNzNCA9IHV0ZjE2Ow0KCQkgICAgfQ0KCQkgICAgLyogY29udmVydCBVVEYt MTYgcmFuZ2Ugb2YgVUNTNCB0byBVVEYtOCAqLw0KCQkgICAgaWYgKHVjczQg PD0gMHg3ZlVMKSB7DQoJCQl1dGY4WzBdID0gdWNzNDsNCgkJCWkgPSAxOw0K CQkgICAgfSBlbHNlIGlmICh1Y3M0IDw9IDB4N2ZmVUwpIHsNCgkJCXV0Zjhb MF0gPSAweGMwIHwgKHVjczQgPj4gNik7DQoJCQl1dGY4WzFdID0gMHg4MCB8 ICh1Y3M0ICYgMHgzZik7DQoJCQlpID0gMjsNCgkJICAgIH0gZWxzZSBpZiAo dWNzNCA8PSAweGZmZmZVTCkgew0KCQkJdXRmOFswXSA9IDB4ZTAgfCAodWNz NCA+PiAxMik7DQoJCQl1dGY4WzFdID0gMHg4MCB8ICgodWNzNCA+PiA2KSAm IDB4M2YpOw0KCQkJdXRmOFsyXSA9IDB4ODAgfCAodWNzNCAmIDB4M2YpOw0K CQkJaSA9IDM7DQoJCSAgICB9IGVsc2Ugew0KCQkJdXRmOFswXSA9IDB4ZjAg fCAodWNzNCA+PiAxOCk7DQoJCQl1dGY4WzFdID0gMHg4MCB8ICgodWNzNCA+ PiAxMikgJiAweDNmKTsNCgkJCXV0ZjhbMl0gPSAweDgwIHwgKCh1Y3M0ID4+ IDYpICYgMHgzZik7DQoJCQl1dGY4WzNdID0gMHg4MCB8ICh1Y3M0ICYgMHgz Zik7DQoJCQlpID0gNDsNCgkJICAgIH0NCgkJICAgIC8qIGNvbnZlcnQgdXRm OCB0byBoZXggKi8NCgkJICAgIGZvciAoYyA9IDA7IGMgPCBpOyArK2MpIHsN CgkJCWRzdFswXSA9ICclJzsNCgkJCWRzdFsxXSA9IGhleFt1dGY4W2NdID4+ IDRdOw0KCQkJZHN0WzJdID0gaGV4W3V0ZjhbY10gJiAweDBmXTsNCgkJCWRz dCArPSAzOw0KCQkgICAgfQ0KCQl9DQoJICAgIH0NCgkgICAgLyogc2tpcCBv dmVyIHRyYWlsaW5nICctJyBpbiBtb2RpZmllZCBVVEYtNyBlbmNvZGluZyAq Lw0KCSAgICBpZiAoKnNyYyA9PSAnLScpICsrc3JjOw0KCX0NCiAgICB9DQog ICAgLyogdGVybWluYXRlIGRlc3RpbmF0aW9uIHN0cmluZyAqLw0KICAgICpk c3QgPSAnXDAnOw0KfQ0KDQptYWluKGludCBhcmdjLCBjaGFyICoqYXJndikN CnsNCiAgICBjaGFyICpkc3Q7DQoNCiAgICBpZiAoYXJnYyA8IDIgfHwgISoo YXJndlsxXSkpIHsNCglmcHJpbnRmKHN0ZGVyciwgInVzYWdlOiBpbWFwdXJs IDxtYWlsYm94bmFtZT5cbiIpOw0KCWV4aXQoMSk7DQogICAgfQ0KICAgIGRz dCA9IG1hbGxvYyhzdHJsZW4oYXJndlsxXSkgKiA0KTsNCiAgICBNYWlsYm94 VG9VUkwoZHN0LCBhcmd2WzFdKTsNCiAgICBwcmludGYoImltYXA6Ly88aG9z dD4vJXNcbiIsIGRzdCk7DQogICAgZnJlZShkc3QpOw0KICAgIGV4aXQoMCk7 DQp9DQo= ---559023410-1804928587-862417005=:16628 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="urlimap.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyogdXJsaW1hcC5jIC0tIGNvbnZlcnQgaGV4IFVURi04IFVSTCBwYXRoIHRv IG1vZGlmaWVkIFVURi03IElNQVAgbWFpbGJveA0KICovDQoNCiNpbmNsdWRl IDxzdGRpby5oPg0KI2luY2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHN0 cmluZy5oPg0KDQovKiBoZXhhZGVjaW1hbCBsb29rdXAgdGFibGUgKi8NCnN0 YXRpYyBjaGFyIGhleFtdID0gIjAxMjM0NTY3ODlBQkNERUYiOw0KDQovKiBV VEY3IG1vZGlmaWVkIGJhc2U2NCBhbHBoYWJldCAqLw0Kc3RhdGljIGNoYXIg YmFzZTY0Y2hhcnNbXSA9DQogICJBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZ WmFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4OSssIjsNCg0K LyogVVRGMTYgZGVmaW5pdGlvbnMgKi8NCiNkZWZpbmUgVVRGMTZNQVNLCTB4 MDNGRlVMDQojZGVmaW5lIFVURjE2U0hJRlQJMTANCiNkZWZpbmUgVVRGMTZI SUdIU1RBUlQJMHhEODAwVUwNCiNkZWZpbmUgVVRGMTZISUdIRU5ECTB4REJG RlVMDQojZGVmaW5lIFVURjE2TE9TVEFSVAkweERDMDBVTA0KI2RlZmluZSBV VEYxNkxPRU5ECTB4REZGRlVMDQoNCi8qIENvbnZlcnQgaGV4IGNvZGVkIFVU Ri04IFVSTCBwYXRoIHRvIG1vZGlmaWVkIFVURi03IElNQVAgbWFpbGJveA0K ICogIGRzdCBzaG91bGQgYmUgYWJvdXQgdHdpY2UgdGhlIGxlbmd0aCBvZiBz cmMgdG8gZGVhbCB3aXRoIG5vbi1oZXggY29kZWQgVVJMcw0KICovDQp2b2lk IFVSTHRvTWFpbGJveChjaGFyICpkc3QsIGNoYXIgKnNyYykNCnsNCiAgICB1 bnNpZ25lZCBpbnQgdXRmOHBvcywgdXRmOHRvdGFsLCBpLCBjLCB1dGY3bW9k ZSwgYml0c3RvZ28sIHV0ZjE2ZmxhZzsNCiAgICB1bnNpZ25lZCBsb25nIHVj czQsIGJpdGJ1ZjsNCiAgICB1bnNpZ25lZCBjaGFyIGhleHRhYlsyNTZdOw0K DQogICAgLyogaW5pdGlhbGl6ZSBoZXggbG9va3VwIHRhYmxlICovDQogICAg bWVtc2V0KGhleHRhYiwgMCwgc2l6ZW9mIChoZXh0YWIpKTsNCiAgICBmb3Ig KGkgPSAwOyBpIDwgc2l6ZW9mIChoZXgpOyArK2kpIHsNCgloZXh0YWJbaGV4 W2ldXSA9IGk7DQoJaWYgKGlzdXBwZXIoaGV4W2ldKSkgaGV4dGFiW3RvbG93 ZXIoaGV4W2ldKV0gPSBpOw0KICAgIH0NCg0KICAgIHV0Zjdtb2RlID0gMDsN CiAgICB1dGY4dG90YWwgPSAwOw0KICAgIGJpdHN0b2dvID0gMDsNCiAgICB3 aGlsZSAoKGMgPSAqc3JjKSAhPSAnXDAnKSB7DQoJKytzcmM7DQoJLyogdW5k byBoZXgtZW5jb2RpbmcgKi8NCglpZiAoYyA9PSAnJScpIHsNCgkgICAgYyA9 IChoZXh0YWJbc3JjWzBdXSA8PCA0KSB8IGhleHRhYltzcmNbMV1dOw0KCSAg ICBzcmMgKz0gMjsNCgl9DQoJLyogbm9ybWFsIGNoYXJhY3Rlcj8gKi8NCglp ZiAoYyA+PSAnICcgJiYgYyA8PSAnficpIHsNCgkgICAgLyogc3dpdGNoIG91 dCBvZiBVVEYtNyBtb2RlICovDQoJICAgIGlmICh1dGY3bW9kZSkgew0KCQlp ZiAoYml0c3RvZ28pIHsNCgkJICAgICpkc3QrKyA9IGJhc2U2NGNoYXJzWyhi aXRidWYgPDwgKDYgLSBiaXRzdG9nbykpICYgMHgzRl07DQoJCX0NCgkJKmRz dCsrID0gJy0nOw0KCQl1dGY3bW9kZSA9IDA7DQoJICAgIH0NCgkgICAgKmRz dCsrID0gYzsNCgkgICAgLyogZW5jb2RlICcmJyBhcyAnJi0nICovDQoJICAg IGlmIChjID09ICcmJykgew0KCQkqZHN0KysgPSAnLSc7DQoJICAgIH0NCgkg ICAgY29udGludWU7DQoJfQ0KCS8qIHN3aXRjaCB0byBVVEYtNyBtb2RlICov DQoJaWYgKCF1dGY3bW9kZSkgew0KCSAgICAqZHN0KysgPSAnJic7DQoJICAg IHV0Zjdtb2RlID0gMTsNCgl9DQoJLyogRW5jb2RlIFVTLUFTQ0lJIGNoYXJh Y3RlcnMgYXMgdGhlbXNlbHZlcyAqLw0KCWlmIChjIDwgMHg4MCkgew0KCSAg ICB1Y3M0ID0gYzsNCgkgICAgdXRmOHRvdGFsID0gMTsNCgl9IGVsc2UgaWYg KHV0Zjh0b3RhbCkgew0KCSAgICAvKiBzYXZlIFVURjggYml0cyBpbnRvIFVD UzQgKi8NCgkgICAgdWNzNCA9ICh1Y3M0IDw8IDYpIHwgKGMgJiAweDNGVUwp Ow0KCSAgICBpZiAoKyt1dGY4cG9zIDwgdXRmOHRvdGFsKSB7DQoJCWNvbnRp bnVlOw0KCSAgICB9DQoJfSBlbHNlIHsNCgkgICAgdXRmOHBvcyA9IDE7DQoJ ICAgIGlmIChjIDwgMHhFMCkgew0KCQl1dGY4dG90YWwgPSAyOw0KCQl1Y3M0 ID0gYyAmIDB4MUY7DQoJICAgIH0gZWxzZSBpZiAoYyA8IDB4RjApIHsNCgkJ dXRmOHRvdGFsID0gMzsNCgkJdWNzNCA9IGMgJiAweDBGOw0KCSAgICB9IGVs c2Ugew0KCQkvKiBOT1RFOiBjYW4ndCBjb252ZXJ0IFVURjggc2VxdWVuY2Vz IGxvbmdlciB0aGFuIDQgKi8NCgkJdXRmOHRvdGFsID0gNDsNCgkJdWNzNCA9 IGMgJiAweDAzOw0KCSAgICB9DQoJICAgIGNvbnRpbnVlOw0KCX0NCgkvKiBs b29wIHRvIHNwbGl0IHVjczQgaW50byB0d28gdXRmMTYgY2hhcnMgaWYgbmVj ZXNzYXJ5ICovDQoJdXRmOHRvdGFsID0gMDsNCglkbyB7DQoJICAgIGlmICh1 Y3M0ID4gMHhmZmZmVUwpIHsNCgkJYml0YnVmID0gKGJpdGJ1ZiA8PCAxNikg fCAoKHVjczQgPj4gVVRGMTZTSElGVCkNCgkJCQkJICAgKyBVVEYxNkhJR0hT VEFSVCk7DQoJCXVjczQgPSAodWNzNCAmIFVURjE2TUFTSykgKyBVVEYxNkxP U1RBUlQ7DQoJCXV0ZjE2ZmxhZyA9IDE7DQoJICAgIH0gZWxzZSB7DQoJCWJp dGJ1ZiA9IChiaXRidWYgPDwgMTYpIHwgdWNzNDsNCgkJdXRmMTZmbGFnID0g MDsNCgkgICAgfQ0KCSAgICBiaXRzdG9nbyArPSAxNjsNCgkgICAgLyogc3Bl dyBvdXQgYmFzZTY0ICovDQoJICAgIHdoaWxlIChiaXRzdG9nbyA+PSA2KSB7 DQoJCWJpdHN0b2dvIC09IDY7DQoJCSpkc3QrKyA9IGJhc2U2NGNoYXJzWyhi aXRzdG9nbyA/IChiaXRidWYgPj4gYml0c3RvZ28pIDogYml0YnVmKQ0KCQkJ CSAgICAgJiAweDNGXTsNCgkgICAgfQ0KCX0gd2hpbGUgKHV0ZjE2ZmxhZyk7 DQogICAgfQ0KICAgIC8qIGlmIGluIFVURi03IG1vZGUsIGZpbmlzaCBpbiBB U0NJSSAqLw0KICAgIGlmICh1dGY3bW9kZSkgew0KCWlmIChiaXRzdG9nbykg ew0KCSAgICAqZHN0KysgPSBiYXNlNjRjaGFyc1soYml0YnVmIDw8ICg2IC0g Yml0c3RvZ28pKSAmIDB4M0ZdOw0KCX0NCgkqZHN0KysgPSAnLSc7DQogICAg fQ0KICAgIC8qIHRpZSBvZmYgc3RyaW5nICovDQogICAgKmRzdCA9ICdcMCc7 DQp9DQoNCm1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQ0Kew0KICAgIGNo YXIgKmRzdDsNCg0KICAgIGlmIChhcmdjIDwgMiB8fCAhKihhcmd2WzFdKSkg ew0KCWZwcmludGYoc3RkZXJyLCAidXNhZ2U6IHVybGltYXAgPHVybHBhdGg+ XG4iKTsNCglleGl0KDEpOw0KICAgIH0NCiAgICBkc3QgPSBtYWxsb2Moc3Ry bGVuKGFyZ3ZbMV0pICogNCk7DQogICAgVVJMdG9NYWlsYm94KGRzdCwgYXJn dlsxXSk7DQogICAgcHJpbnRmKCIlc1xuIiwgZHN0KTsNCiAgICBmcmVlKGRz dCk7DQogICAgZXhpdCgwKTsNCn0NCg== ---559023410-1804928587-862417005=:16628--   Received: from cnri by ietf.org id aa21386; 30 Apr 97 16:01 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa19196; 30 Apr 97 16:01 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with SMTP id MAA09162; Wed, 30 Apr 1997 12:54:37 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with ESMTP id MAA42836 for ; Wed, 30 Apr 1997 12:52:36 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with ESMTP id MAA04168 for ; Wed, 30 Apr 1997 12:52:34 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (dak@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with ESMTP id MAA19581 for ; Wed, 30 Apr 1997 12:52:31 -0700 Received: from Ikkoku-Kan.Panda.COM (keil@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id MAA18228; Wed, 30 Apr 1997 12:52:18 -0700 (PDT) Received: from localhost (jtw@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id MAA10770; Wed, 30 Apr 1997 12:52:13 -0700 (PDT) Message-Id: Date: Wed, 30 Apr 1997 11:15:38 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Chris Newman Cc: IMAP Discusson List , IETF URI list Subject: re: UTF8 IMAP URLs In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN > So, given that public domain code now exists to do it, would there be > any strong objections to replacing the current weasel wording in the IMAP > URL draft with a rule that IMAP URLs MUST use UTF-8? IMHO, this is absolutely the right thing, and matches the concensus that I had with Martin Duerst at Tsukuba. I agree that trying to support modified UTF-7 in URLs causes more trouble than it saves.   Received: from cnri by ietf.org id aa21882; 30 Apr 97 16:16 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa19511; 30 Apr 97 16:16 EDT Received: from host (server@lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with SMTP id NAA48238; Wed, 30 Apr 1997 13:10:26 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with ESMTP id NAA51984 for ; Wed, 30 Apr 1997 13:08:08 -0700 Received: from mx2.cac.washington.edu (mx2.cac.washington.edu [140.142.33.1]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with ESMTP id NAA00750 for ; Wed, 30 Apr 1997 13:08:06 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with SMTP id NAA19985 for ; Wed, 30 Apr 1997 13:08:04 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id ; Wed, 30 Apr 1997 13:07:54 -0700 Message-Id: <0A684133865BCF118F0E08002BE7ADACEEB0ED@DABONE> Date: Wed, 30 Apr 1997 13:07:47 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Mike Gahrns (Exchange)" To: Chris Newman , "'Mark Crispin'"@u.washington.edu Cc: IMAP Discusson List , "IETF URI list"@u.washington.edu Subject: RE: UTF8 IMAP URLs MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN When Chris first suggested this, I had expressed some misgivings about requiring UTF8 in the URLs. In retrospect, we can live with the UTF8 requirement, so no strong objections from MS on this. > ---------- > From: Mark Crispin[SMTP:MRC@Panda.COM] > Sent: Wednesday, April 30, 1997 11:15 AM > To: Chris Newman > Cc: IMAP Discusson List; IETF URI list > Subject: re: UTF8 IMAP URLs > > > So, given that public domain code now exists to do it, would there > be > > any strong objections to replacing the current weasel wording in the > IMAP > > URL draft with a rule that IMAP URLs MUST use UTF-8? > > IMHO, this is absolutely the right thing, and matches the concensus > that I had > with Martin Duerst at Tsukuba. > > I agree that trying to support modified UTF-7 in URLs causes more > trouble than > it saves. >   Received: from cnri by ietf.org id aa23786; 30 Apr 97 17:25 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa21108; 30 Apr 97 17:25 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with SMTP id OAA28076; Wed, 30 Apr 1997 14:17:00 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW97.04/8.8.4+UW97.04) with ESMTP id OAA26634 for ; Wed, 30 Apr 1997 14:16:28 -0700 Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with ESMTP id OAA14039 for ; Wed, 30 Apr 1997 14:16:25 -0700 Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mx1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.04) with ESMTP id OAA24842 for ; Wed, 30 Apr 1997 14:16:21 -0700 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IIBID4C35899F9KB@INNOSOFT.COM> for imap@cac.washington.edu; Wed, 30 Apr 1997 14:15:54 PDT Message-Id: Date: Wed, 30 Apr 1997 14:17:21 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: IMAP Discusson List Cc: IETF URI list Subject: IMAP URL document MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="-559023410-1297389768-862435041=:16628" X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1297389768-862435041=:16628 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's a new version of the IMAP URL document. The following substantial changes were made: (1) Instead of imap://server/path;uidvalidity=foo;uid=foo;section=foo, it now uses imap://server/path;uidvalidity=foo/;uid=foo/;section=foo This matches the relative URL resolution rules in the new URL internet draft rather than the rules in RFC 1808. It is also believed to work better with the installed base of relative URL resolution. (2) Removed cleartext passwords. (3) Added UTF-8 requirement including an example and sample code in an appendix. These are sufficient changes to merit another last call, IMHO. As this spec is long overdue already, I'd appreciate feedback promptly. Thanks. ---559023410-1297389768-862435041=:16628 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="imapurl.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQy4gTmV3bWFuDQpJbnRl cm5ldCBEcmFmdDogSU1BUCBVUkwgU2NoZW1lICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSW5ub3NvZnQNCkRvY3VtZW50OiBkcmFmdC1uZXdt YW4tdXJsLWltYXAtMDZiaXMudHh0ICAgICAgICAgICAgICAgICAgICAgICBN YXkgMTk5Nw0KRXhwaXJlcyBpbiBzaXggbW9udGhzDQoNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIElNQVAgVVJMIFNjaGVtZQ0KDQoNClN0YXR1 cyBvZiB0aGlzIG1lbW8NCg0KICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIElu dGVybmV0IERyYWZ0LiAgSW50ZXJuZXQgRHJhZnRzIGFyZSB3b3JraW5nDQog ICAgIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFz ayBGb3JjZSAoSUVURiksIGl0cyBBcmVhcywNCiAgICAgYW5kIGl0cyBXb3Jr aW5nIEdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZQ0KICAgICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l dCBEcmFmdHMuDQoNCiAgICAgSW50ZXJuZXQgRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgNCiAgICAgbW9u dGhzLiAgSW50ZXJuZXQgRHJhZnRzIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5DQogICAgIG90aGVyIGRvY3VtZW50cyBhdCBh bnkgdGltZS4gIEl0IGlzIG5vdCBhcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu ZXQNCiAgICAgRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBj aXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBhDQogICAgIGBgd29ya2luZyBkcmFm dCcnIG9yIGBgd29yayBpbiBwcm9ncmVzc2BgLg0KDQogICAgIFRvIGxlYXJu IHRoZSBjdXJyZW50IHN0YXR1cyBvZiBhbnkgSW50ZXJuZXQtRHJhZnQsIHBs ZWFzZSBjaGVjayB0aGUNCiAgICAgMWlkLWFic3RyYWN0cy50eHQgbGlzdGlu ZyBjb250YWluZWQgaW4gdGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAg ICAgRGlyZWN0b3JpZXMgb24gZHMuaW50ZXJuaWMubmV0LCBuaWMubm9yZHUu bmV0LCBmdHAuaXNpLmVkdSwgb3INCiAgICAgbXVubmFyaS5vei5hdS4NCg0K ICAgICBBIHJldmlzZWQgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGRvY3VtZW50 IHdpbGwgYmUgc3VibWl0dGVkIHRvIHRoZQ0KICAgICBSRkMgZWRpdG9yIGFz IGEgUHJvcG9zZWQgU3RhbmRhcmQgZm9yIHRoZSBJbnRlcm5ldCBDb21tdW5p dHkuDQogICAgIERpc2N1c3Npb24gYW5kIHN1Z2dlc3Rpb25zIGZvciBpbXBy b3ZlbWVudCBhcmUgcmVxdWVzdGVkLiAgVGhpcw0KICAgICBkb2N1bWVudCB3 aWxsIGV4cGlyZSBzaXggbW9udGhzIGFmdGVyIHB1YmxpY2F0aW9uLiAgRGlz dHJpYnV0aW9uIG9mDQogICAgIHRoaXMgZHJhZnQgaXMgdW5saW1pdGVkLg0K DQoNCkFic3RyYWN0DQoNCiAgICAgSU1BUCBbSU1BUDRdIGlzIGEgcmljaCBw cm90b2NvbCBmb3IgYWNjZXNzaW5nIHJlbW90ZSBtZXNzYWdlDQogICAgIHN0 b3Jlcy4gIEl0IHByb3ZpZGVzIGFuIGlkZWFsIG1lY2hhbmlzbSBmb3IgYWNj ZXNzaW5nIHB1YmxpYw0KICAgICBtYWlsaW5nIGxpc3QgYXJjaGl2ZXMgYXMg d2VsbCBhcyBwcml2YXRlIGFuZCBzaGFyZWQgbWVzc2FnZSBzdG9yZXMuDQog ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFVSTCBzY2hlbWUgZm9yIHJl ZmVyZW5jaW5nIG9iamVjdHMgb24gYW4NCiAgICAgSU1BUCBzZXJ2ZXIuDQoN Cg0KMS4gQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50DQoNCiAg ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsIGFuZCAiTUFZIg0KICAgICBpbiB0aGlzIGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZWZpbmVkIGluICJLZXkg d29yZHMgZm9yDQogICAgIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVp cmVtZW50IExldmVscyIgW0tFWVdPUkRTXS4NCg0KDQoNCk5ld21hbiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAg ICAgIElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAgICAgICAgICAgIE1heSAx OTk3DQoNCg0KMi4gSU1BUCBzY2hlbWUNCg0KICAgICBUaGUgSU1BUCBVUkwg c2NoZW1lIGlzIHVzZWQgdG8gZGVzaWduYXRlIG1haWxib3hlcywgbWVzc2Fn ZXMsIE1JTUUNCiAgICAgYm9kaWVzIFtNSU1FXSwgYW5kIHNlYXJjaCBwcm9n cmFtcyBvbiBJbnRlcm5ldCBob3N0cyBhY2Nlc3NpYmxlDQogICAgIHVzaW5n IHRoZSBJTUFQIHByb3RvY29sLg0KDQogICAgIFRoZSBJTUFQIFVSTCBmb2xs b3dzIHRoZSBjb21tb24gSW50ZXJuZXQgc2NoZW1lIHN5bnRheCBhcyBkZWZp bmVkDQogICAgIGluIFJGQyAxNzM4IFtCQVNJQy1VUkxdIGV4Y2VwdCB0aGF0 IGNsZWFyIHRleHQgcGFzc3dvcmRzIGFyZSBub3QNCiAgICAgcGVybWl0dGVk LiAgSWYgOjxwb3J0PiBpcyBvbWl0dGVkLCB0aGUgcG9ydCBkZWZhdWx0cyB0 byAxNDMuDQoNCiAgICAgQW4gSU1BUCBVUkwgdGFrZXMgb25lIG9mIHRoZSBm b2xsb3dpbmcgZm9ybXM6DQoNCiAgICAgICAgIGltYXA6Ly88aXNlcnZlcj4v PGVuY19saXN0X21haWxib3g+O1RZUEU9PGxpc3RfdHlwZT4NCiAgICAgICAg IGltYXA6Ly88aXNlcnZlcj4vPGVuY19tYWlsYm94Plt1aWR2YWxpZGl0eV1b PzxlbmNfc2VhcmNoPl0NCiAgICAgICAgIGltYXA6Ly88aXNlcnZlcj4vPGVu Y19tYWlsYm94Plt1aWR2YWxpZGl0eV08aXVpZD5baXNlY3Rpb25dDQoNCiAg ICAgVGhlIGZpcnN0IGZvcm0gaXMgdXNlZCB0byByZWZlciB0byBhIGxpc3Qg b2YgbWFpbGJveGVzLCB0aGUgc2Vjb25kDQogICAgIGZvcm0gcmVmZXJzIHRv IHRoZSBjb250ZW50cyBvZiBhIG1haWxib3ggb3IgYSBzZXQgb2YgbWVzc2Fn ZXMNCiAgICAgcmVzdWx0aW5nIGZyb20gYSBzZWFyY2gsIGFuZCB0aGUgZmlu YWwgZm9ybSByZWZlcnMgdG8gYSBzcGVjaWZpYw0KICAgICBtZXNzYWdlIG9y IG1lc3NhZ2UgcGFydC4NCg0KDQozLiBJTUFQIFVzZXIgTmFtZSBhbmQgQXV0 aGVudGljYXRpb24gTWVjaGFuaXNtDQoNCiAgICAgQSB1c2VyIG5hbWUgYW5k L29yIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSBtYXkgYmUgc3VwcGxpZWQu ICBUaGV5DQogICAgIGFyZSB1c2VkIGluIHRoZSAiTE9HSU4iIG9yICJBVVRI RU5USUNBVEUiIGNvbW1hbmRzIGFmdGVyIG1ha2luZyB0aGUNCiAgICAgY29u bmVjdGlvbiB0byB0aGUgSU1BUCBzZXJ2ZXIuICBJZiBubyB1c2VyIG5hbWUg b3IgYXV0aGVudGljYXRpb24NCiAgICAgbWVjaGFuaXNtIGlzIHN1cHBsaWVk LCB0aGUgdXNlciBuYW1lICJhbm9ueW1vdXMiIGlzIHVzZWQgd2l0aCB0aGUN CiAgICAgIkxPR0lOIiBjb21tYW5kIGFuZCB0aGUgcGFzc3dvcmQgaXMgc3Vw cGxpZWQgYXMgdGhlIEludGVybmV0IGUtbWFpbA0KICAgICBhZGRyZXNzIG9m IHRoZSBlbmQgdXNlciBhY2Nlc3NpbmcgdGhlIHJlc291cmNlLiAgSWYgdGhl IFVSTA0KICAgICBzdXBwbGllcyBhIHVzZXIgbmFtZSwgdGhlIHByb2dyYW0g aW50ZXJwcmV0aW5nIHRoZSBJTUFQIFVSTCBTSE9VTEQNCiAgICAgcmVxdWVz dCBvbmUgZnJvbSB0aGUgdXNlciBpZiBuZWNlc3NhcnkuDQoNCiAgICAgQW4g YXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGNhbiBiZSBleHByZXNzZWQgYnkg YWRkaW5nDQogICAgICI7QVVUSD08ZW5jX2F1dGhfdHlwZT4iIHRvIHRoZSBl bmQgb2YgdGhlIHVzZXIgbmFtZS4gIFdoZW4gc3VjaCBhbg0KICAgICA8ZW5j X2F1dGhfdHlwZT4gaXMgaW5kaWNhdGVkLCB0aGUgY2xpZW50IFNIT1VMRCBy ZXF1ZXN0IGFwcHJvcHJpYXRlDQogICAgIGNyZWRlbnRpYWxzIGZyb20gdGhh dCBtZWNoYW5pc20gYW5kIHVzZSB0aGUgIkFVVEhFTlRJQ0FURSIgY29tbWFu ZA0KICAgICBpbnN0ZWFkIG9mIHRoZSAiTE9HSU4iIGNvbW1hbmQuICBJZiBu byB1c2VyIG5hbWUgaXMgc3BlY2lmaWVkLCBvbmUNCiAgICAgU0hPVUxEIGJl IG9idGFpbmVkIGZyb20gdGhlIG1lY2hhbmlzbSBvciByZXF1ZXN0ZWQgZnJv bSB0aGUgdXNlciBhcw0KICAgICBhcHByb3ByaWF0ZS4NCg0KICAgICBUaGUg c3RyaW5nICI7QVVUSD0qIiBpbmRpY2F0ZXMgdGhhdCB0aGUgY2xpZW50IFNI T1VMRCBzZWxlY3QgYW4NCiAgICAgYXBwcm9wcmlhdGUgYXV0aGVudGljYXRp b24gbWVjaGFuaXNtLiAgSXQgTUFZIHVzZSBhbnkgbWVjaGFuaXNtDQogICAg IGxpc3RlZCBpbiB0aGUgQ0FQQUJJTElUWSBjb21tYW5kIG9yIHVzZSBhbiBv dXQgb2YgYmFuZCBzZWN1cml0eQ0KICAgICBzZXJ2aWNlIHJlc3VsdGluZyBp biBhIFBSRUFVVEggY29ubmVjdGlvbi4gIElmIG5vIHVzZXIgbmFtZSBpcw0K ICAgICBzcGVjaWZpZWQgYW5kIG5vIGFwcHJvcHJpYXRlIGF1dGhlbnRpY2F0 aW9uIG1lY2hhbmlzbXMgYXJlDQogICAgIGF2YWlsYWJsZSwgdGhlIGNsaWVu dCBTSE9VTEQgZmFsbCBiYWNrIHRvIGFub255bW91cyBsb2dpbiBhcw0KICAg ICBkZXNjcmliZWQgYWJvdmUuICBUaGlzIGFsbG93cyBhIFVSTCB3aGljaCBn cmFudHMgcmVhZC13cml0ZSBhY2Nlc3MNCg0KDQoNCk5ld21hbiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAg IElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAgICAgICAgICAgIE1heSAxOTk3 DQoNCg0KICAgICB0byBhdXRob3JpemVkIHVzZXJzLCBhbmQgcmVhZC1vbmx5 IGFub255bW91cyBhY2Nlc3MgdG8gb3RoZXIgdXNlcnMuDQoNCiAgICAgTm90 ZSB0aGF0IGlmIHVuc2FmZSBvciByZXNlcnZlZCBjaGFyYWN0ZXJzIHN1Y2gg YXMgIiAiIG9yICI7IiBhcmUNCiAgICAgcHJlc2VudCBpbiB0aGUgdXNlciBu YW1lIG9yIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSwgdGhleSBNVVNUIGJl DQogICAgIGVuY29kZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAxNzM4IFtCQVNJ Qy1VUkxdLg0KDQoNCjQuIExpc3RzIG9mIG1haWxib3hlcw0KDQogICAgIEFu IElNQVAgVVJMIHJlZmVycmluZyB0byBhIGxpc3Qgb2YgbWFpbGJveGVzIGhh cyB0aGUgZm9sbG93aW5nDQogICAgIGZvcm06DQoNCiAgICAgICAgIGltYXA6 Ly88aXNlcnZlcj4vPGVuY19saXN0X21haWxib3g+O1RZUEU9PGxpc3RfdHlw ZT4NCg0KICAgICBUaGUgPGxpc3RfdHlwZT4gbWF5IGJlIGVpdGhlciAiTElT VCIgb3IgIkxTVUIiLCBhbmQgaXMgY2FzZQ0KICAgICBpbnNlbnNpdGl2ZS4g IFRoZSBmaWVsZCAiO1RZUEU9PGxpc3RfdHlwZT4iIE1VU1QgYmUgaW5jbHVk ZWQuDQoNCiAgICAgVGhlIDxlbmNfbGlzdF9tYWlsYm94PiBpcyBhbnkgYXJn dW1lbnQgc3VpdGFibGUgZm9yIHRoZQ0KICAgICBsaXN0X21haWxib3ggZmll bGQgb2YgdGhlIElNQVAgW0lNQVA0XSBMSVNUIG9yIExTVUIgY29tbWFuZHMu ICBUaGUNCiAgICAgZmllbGQgPGVuY19saXN0X21haWxib3g+IG1heSBiZSBv bWl0dGVkLCBpbiB3aGljaCBjYXNlIHRoZSBwcm9ncmFtDQogICAgIGludGVy cHJldGluZyB0aGUgSU1BUCBVUkwgbWF5IHVzZSAiKiIgb3IgIiUiIGFzIHRo ZQ0KICAgICA8ZW5jX2xpc3RfbWFpbGJveD4uICBUaGUgcHJvZ3JhbSBTSE9V TEQgdXNlICIlIiBpZiBpdCBzdXBwb3J0cyBhDQogICAgIGhpZXJhcmNoaWNh bCB2aWV3LCBvdGhlcndpc2UgaXQgU0hPVUxEIHVzZSAiKiIuDQoNCiAgICAg Tm90ZSB0aGF0IGlmIHVuc2FmZSBvciByZXNlcnZlZCBjaGFyYWN0ZXJzIHN1 Y2ggYXMgIiAiIG9yICIlIiBhcmUNCiAgICAgcHJlc2VudCBpbiA8ZW5jX2xp c3RfbWFpbGJveD4gdGhleSBNVVNUIGJlIGVuY29kZWQgYXMgZGVzY3JpYmVk IGluDQogICAgIFJGQyAxNzM4IFtCQVNJQy1VUkxdLiAgSWYgdGhlIGNoYXJh Y3RlciAiLyIgaXMgcHJlc2VudCBpbg0KICAgICBlbmNfbGlzdF9tYWlsYm94 LCBpdCBTSE9VTEQgTk9UIGJlIGVuY29kZWQuDQoNCg0KNS4gTGlzdHMgb2Yg bWVzc2FnZXMNCg0KICAgICBBbiBJTUFQIFVSTCByZWZlcnJpbmcgdG8gYSBs aXN0IG9mIG1lc3NhZ2VzIGhhcyB0aGUgZm9sbG93aW5nIGZvcm06DQoNCiAg ICAgICAgIGltYXA6Ly88aXNlcnZlcj4vPGVuY19tYWlsYm94Plt1aWR2YWxp ZGl0eV1bPzxlbmNfc2VhcmNoPl0NCg0KICAgICBUaGUgPGVuY19tYWlsYm94 PiBmaWVsZCBpcyB1c2VkIGFzIHRoZSBhcmd1bWVudCB0byB0aGUgSU1BUDQN CiAgICAgIlNFTEVDVCIgY29tbWFuZC4gIE5vdGUgdGhhdCBpZiB1bnNhZmUg b3IgcmVzZXJ2ZWQgY2hhcmFjdGVycyBzdWNoDQogICAgIGFzICIgIiwgIjsi LCBvciAiPyIgYXJlIHByZXNlbnQgaW4gPGVuY19tYWlsYm94PiB0aGV5IE1V U1QgYmUNCiAgICAgZW5jb2RlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDE3Mzgg W0JBU0lDLVVSTF0uICBJZiB0aGUgY2hhcmFjdGVyICIvIg0KICAgICBpcyBw cmVzZW50IGluIGVuY19tYWlsYm94LCBpdCBTSE9VTEQgTk9UIGJlIGVuY29k ZWQuDQoNCiAgICAgVGhlIFt1aWR2YWxpZGl0eV0gZmllbGQgaXMgb3B0aW9u YWwuICBJZiBpdCBpcyBwcmVzZW50LCBpdCBNVVNUIGJlDQogICAgIHRoZSBh cmd1bWVudCB0byB0aGUgSU1BUDQgVUlEVkFMSURJVFkgc3RhdHVzIHJlc3Bv bnNlIGF0IHRoZSB0aW1lDQogICAgIHRoZSBVUkwgd2FzIGNyZWF0ZWQuICBU aGlzIFNIT1VMRCBiZSB1c2VkIGJ5IHRoZSBwcm9ncmFtDQogICAgIGludGVy cHJldGluZyB0aGUgSU1BUCBVUkwgdG8gZGV0ZXJtaW5lIGlmIHRoZSBVUkwg aXMgc3RhbGUuDQoNCiAgICAgVGhlIFs/PGVuY19zZWFyY2g+XSBmaWVsZCBp cyBvcHRpb25hbC4gIElmIGl0IGlzIG5vdCBwcmVzZW50LCB0aGUNCg0KDQoN Ck5ld21hbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQgRHJh ZnQgICAgICAgICAgICAgIElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAgICAg ICAgICAgIE1heSAxOTk3DQoNCg0KICAgICBjb250ZW50cyBvZiB0aGUgbWFp bGJveCBTSE9VTEQgYmUgcHJlc2VudGVkIGJ5IHRoZSBwcm9ncmFtDQogICAg IGludGVycHJldGluZyB0aGUgVVJMLiAgSWYgaXQgaXMgcHJlc2VudCwgaXQg U0hPVUxEIGJlIHVzZWQgYXMgdGhlDQogICAgIGFyZ3VtZW50cyBmb2xsb3dp bmcgYW4gSU1BUDQgU0VBUkNIIGNvbW1hbmQgd2l0aCB1bnNhZmUgY2hhcmFj dGVycw0KICAgICBzdWNoIGFzICIgIiAod2hpY2ggYXJlIGxpa2VseSB0byBi ZSBwcmVzZW50IGluIHRoZSA8ZW5jX3NlYXJjaD4pDQogICAgIGVuY29kZWQg YXMgZGVzY3JpYmVkIGluIFJGQyAxNzM4IFtCQVNJQy1VUkxdLg0KDQoNCjYu IEEgc3BlY2lmaWMgbWVzc2FnZSBvciBtZXNzYWdlIHBhcnQNCg0KICAgICBB biBJTUFQIFVSTCByZWZlcnJpbmcgdG8gYSBzcGVjaWZpYyBtZXNzYWdlIG9y IG1lc3NhZ2UgcGFydCBoYXMgdGhlDQogICAgIGZvbGxvd2luZyBmb3JtOg0K DQogICAgICAgICBpbWFwOi8vPGlzZXJ2ZXI+LzxlbmNfbWFpbGJveD5bdWlk dmFsaWRpdHldPGl1aWQ+W2lzZWN0aW9uXQ0KDQogICAgIFRoZSA8ZW5jX21h aWxib3g+IGFuZCBbdWlkdmFsaWRpdHldIGFyZSBhcyBkZWZpbmVkIGFib3Zl Lg0KDQogICAgIElmIFt1aWR2YWxpZGl0eV0gaXMgcHJlc2VudCBpbiB0aGlz IGZvcm0sIGl0IFNIT1VMRCBiZSB1c2VkIGJ5IHRoZQ0KICAgICBwcm9ncmFt IGludGVycHJldGluZyB0aGUgVVJMIHRvIGRldGVybWluZSBpZiB0aGUgVVJM IGlzIHN0YWxlLg0KDQogICAgIFRoZSA8dWlkPiByZWZlcnMgdG8gYW4gSU1B UDQgbWVzc2FnZSBVSUQsIGFuZCBTSE9VTEQgYmUgdXNlZCBhcyB0aGUNCiAg ICAgPHNldD4gYXJndW1lbnQgdG8gdGhlIElNQVA0ICJVSUQgRkVUQ0giIGNv bW1hbmQuDQoNCiAgICAgVGhlIFtpc2VjdGlvbl0gZmllbGQgaXMgb3B0aW9u YWwuICBJZiBub3QgcHJlc2VudCwgdGhlIFVSTCByZWZlcnMNCiAgICAgdG8g dGhlIGVudGlyZSBJbnRlcm5ldCBtZXNzYWdlIGFzIHJldHVybmVkIGJ5IHRo ZSBJTUFQIGNvbW1hbmQgIlVJRA0KICAgICBGRVRDSCA8dWlkPiBCT0RZLlBF RUtbXSIuICBJZiBwcmVzZW50LCB0aGUgVVJMIHJlZmVycyB0byB0aGUgb2Jq ZWN0DQogICAgIHJldHVybmVkIGJ5IGEgIlVJRCBGRVRDSCA8dWlkPiBCT0RZ LlBFRUtbPHNlY3Rpb24+XSIgY29tbWFuZC4gIFRoZQ0KICAgICB0eXBlIG9m IHRoZSBvYmplY3QgbWF5IGJlIGRldGVybWluZWQgd2l0aCBhICJVSUQgRkVU Q0ggPHVpZD4NCiAgICAgQk9EWVNUUlVDVFVSRSIgY29tbWFuZCBhbmQgbG9j YXRpbmcgdGhlIGFwcHJvcHJpYXRlIHBhcnQgaW4gdGhlDQogICAgIHJlc3Vs dGluZyBCT0RZU1RSVUNUVVJFLiAgTm90ZSB0aGF0IHVuc2FmZSBjaGFyYWN0 ZXJzIGluDQogICAgIFtpc2VjdGlvbl0sIHN1Y2ggYXMgIiAiIE1VU1QgYmUg ZW5jb2RlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDE3MzgNCiAgICAgW0JBU0lD LVVSTF0uDQoNCg0KNy4gUmVsYXRpdmUgSU1BUCBVUkxzDQoNCiAgICAgUmVs YXRpdmUgSU1BUCBVUkxzIGFyZSBwZXJtaXR0ZWQgYW5kIGFyZSByZXNvbHZl ZCBhY2NvcmRpbmcgdG8gdGhlDQogICAgIHJ1bGVzIGRlZmluZWQgaW4gUkZD IDE4MDggW1JFTC1VUkxdIHdpdGggb25lIGV4Y2VwdGlvbi4gIEluIElNQVAN CiAgICAgVVJMcywgcGFyYW1ldGVycyBhcmUgdHJlYXRlZCBhcyBwYXJ0IG9m IHRoZSBub3JtYWwgcGF0aCB3aXRoDQogICAgIHJlc3BlY3QgdG8gcmVsYXRp dmUgVVJMIHJlc29sdXRpb24uICBUaGlzIGlzIGJlbGlldmVkIHRvIGJlIHRo ZQ0KICAgICBiZWhhdmlvciBvZiB0aGUgaW5zdGFsbGVkIGJhc2UgYW5kIGlz IGxpa2VseSB0byBiZSBkb2N1bWVudGVkIGluIGENCiAgICAgZnV0dXJlIHJl dmlzaW9uIG9mIHRoZSByZWxhdGl2ZSBVUkwgc3BlY2lmaWNhdGlvbi4NCg0K ICAgICBUaGUgZm9sbG93aW5nIG9ic2VydmF0aW9ucyBhcmUgYWxzbyBpbXBv cnRhbnQ6DQoNCiAgICAgVGhlIDxpYXV0aD4gZ3JhbW1hciBlbGVtZW50IGlz IGNvbnNpZGVyZWQgcGFydCBvZiB0aGUgdXNlciBuYW1lIGZvcg0KICAgICBw dXJwb3NlcyBvZiByZXNvbHZpbmcgcmVsYXRpdmUgSU1BUCBVUkxzLiAgVGhp cyBtZWFucyB0aGF0IHVubGVzcyBhDQogICAgIG5ldyBsb2dpbi9zZXJ2ZXIg c3BlY2lmaWNhdGlvbiBpcyBpbmNsdWRlZCBpbiB0aGUgcmVsYXRpdmUgVVJM LCB0aGUNCiAgICAgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGlzIGluaGVy aXRlZCBmcm9tIGEgYmFzZSBJTUFQIFVSTC4NCg0KDQoNCk5ld21hbiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAg ICAgIElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAgICAgICAgICAgIE1heSAx OTk3DQoNCg0KICAgICBVUkxzIGFsd2F5cyB1c2UgIi8iIGFzIHRoZSBoaWVy YXJjaHkgZGVsaW1pdGVyIGZvciB0aGUgcHVycG9zZSBvZg0KICAgICByZXNv bHZpbmcgcGF0aHMgaW4gcmVsYXRpdmUgVVJMcy4gIElNQVA0IHBlcm1pdHMg dGhlIHVzZSBvZiBhbnkNCiAgICAgaGllcmFyY2h5IGRlbGltaXRlciBpbiBt YWlsYm94IG5hbWVzLiAgRm9yIHRoaXMgcmVhc29uLCByZWxhdGl2ZQ0KICAg ICBtYWlsYm94IHBhdGhzIHdpbGwgb25seSB3b3JrIGlmIHRoZSBtYWlsYm94 IHVzZXMgIi8iIGFzIHRoZQ0KICAgICBoaWVyYXJjaHkgZGVsaW1pdGVyLiAg UmVsYXRpdmUgVVJMcyBtYXkgYmUgdXNlZCBvbiBtYWlsYm94ZXMgd2hpY2gN CiAgICAgdXNlIG90aGVyIGRlbGltaXRlcnMsIGJ1dCBpbiB0aGF0IGNhc2Us IHRoZSBlbnRpcmUgbWFpbGJveCBuYW1lDQogICAgIE1VU1QgYmUgc3BlY2lm aWVkIGluIHRoZSByZWxhdGl2ZSBVUkwgb3IgaW5oZXJpdGVkIGFzIGEgd2hv bGUgZnJvbQ0KICAgICB0aGUgYmFzZSBVUkwuDQoNCiAgICAgVGhlIGJhc2Ug VVJMIGZvciBhIGxpc3Qgb2YgbWFpbGJveGVzIG9yIG1lc3NhZ2VzIHdoaWNo IHdhcyByZWZlcnJlZA0KICAgICB0byBieSBhbiBJTUFQIFVSTCBpcyBhbHdh eXMgdGhlIHJlZmVycmluZyBJTUFQIFVSTCBpdHNlbGYuICBUaGUNCiAgICAg YmFzZSBVUkwgZm9yIGEgbWVzc2FnZSBvciBtZXNzYWdlIHBhcnQgd2hpY2gg d2FzIHJlZmVycmVkIHRvIGJ5IGFuDQogICAgIElNQVAgVVJMIG1heSBiZSBt b3JlIGNvbXBsaWNhdGVkIHRvIGRldGVybWluZS4gIFRoZSBwcm9ncmFtDQog ICAgIGludGVycHJldGluZyB0aGUgcmVsYXRpdmUgVVJMIHdpbGwgaGF2ZSB0 byBjaGVjayB0aGUgaGVhZGVycyBvZiB0aGUNCiAgICAgTUlNRSBlbnRpdHkg YW5kIGFueSBlbmNsb3NpbmcgTUlNRSBlbnRpdGllcyBpbiBvcmRlciB0byBs b2NhdGUgdGhlDQogICAgICJDb250ZW50LUJhc2UiIGFuZCAiQ29udGVudC1M b2NhdGlvbiIgaGVhZGVycy4gIFRoZXNlIGhlYWRlcnMgYXJlDQogICAgIHVz ZWQgdG8gZGV0ZXJtaW5lIHRoZSBiYXNlIFVSTCBhcyBkZWZpbmVkIGluIFtI VFRQXS4gIEZvciBleGFtcGxlLA0KICAgICBpZiB0aGUgcmVmZXJyaW5nIElN QVAgVVJMIGNvbnRhaW5zIGEgIi87U0VDVElPTj0xLjIiIHBhcmFtZXRlciwN CiAgICAgdGhlbiB0aGUgTUlNRSBoZWFkZXJzIGZvciBzZWN0aW9uIDEuMiwg Zm9yIHNlY3Rpb24gMSwgYW5kIGZvciB0aGUNCiAgICAgZW5jbG9zaW5nIG1l c3NhZ2UgaXRzZWxmIFNIT1VMRCBiZSBjaGVja2VkIGluIHRoYXQgb3JkZXIg Zm9yDQogICAgICJDb250ZW50LUJhc2UiIG9yICJDb250ZW50LUxvY2F0aW9u IiBoZWFkZXJzLg0KDQoNCjguIE11bHRpbmF0aW9uYWwgQ29uc2lkZXJhdGlv bnMNCg0KICAgICBJTUFQNCBbSU1BUDRdIHNlY3Rpb24gNS4xLjMgaW5jbHVk ZXMgYSBjb252ZW50aW9uIGZvciBlbmNvZGluZw0KICAgICBub24tVVMtQVND SUkgY2hhcmFjdGVycyBpbiBJTUFQIG1haWxib3ggbmFtZXMuICBCZWNhdXNl IHRoaXMNCiAgICAgY29udmVudGlvbiBpcyBwcml2YXRlIHRvIElNQVAsIGl0 IGlzIG5lY2Vzc2FyeSB0byBjb252ZXJ0IElNQVAncw0KICAgICBlbmNvZGlu ZyB0byBvbmUgdGhhdCBjYW4gYmUgbW9yZSBlYXNpbHkgaW50ZXJwcmV0ZWQg YnkgYSBVUkwNCiAgICAgZGlzcGxheSBwcm9ncmFtLiAgRm9yIHRoaXMgcmVh c29uLCBJTUFQJ3MgbW9kaWZpZWQgVVRGLTcgZW5jb2RpbmcNCiAgICAgZm9y IG1haWxib3hlcyBNVVNUIGJlIGNvbnZlcnRlZCB0byBVVEYtOCBbVVRGOF0u ICBTaW5jZSA4LWJpdA0KICAgICBjaGFyYWN0ZXJzIGFyZSBub3QgcGVybWl0 dGVkIGluIFVSTHMsIHRoZSBVVEYtOCBjaGFyYWN0ZXJzIGFyZQ0KICAgICBl bmNvZGVkIGFzIHJlcXVpcmVkIGJ5IHRoZSBVUkwgc3BlY2lmaWNhdGlvbiBb QkFTSUMtVVJMXS4gIFNhbXBsZQ0KICAgICBjb2RlIGlzIGluY2x1ZGVkIGlu IEFwcGVuZGl4IEEgdG8gZGVtb25zdHJhdGUgdGhpcyBjb252ZXJzaW9uLg0K DQoNCjkuIEV4YW1wbGVzDQoNCiAgICAgVGhlIGZvbGxvd2luZyBleGFtcGxl cyBkZW1vbnN0cmF0ZSBob3cgYW4gSU1BUDQgY2xpZW50IHByb2dyYW0NCiAg ICAgbWlnaHQgdHJhbnNsYXRlIHZhcmlvdXMgSU1BUDQgVVJMIGludG8gYSBz ZXJpZXMgb2YgSU1BUDQgY29tbWFuZHMuDQogICAgIENvbW1hbmRzIHNlbnQg ZnJvbSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgYXJlIHByZWZpeGVkIHdp dGggIkM6IiwNCiAgICAgYW5kIHJlc3BvbnNlcyBzZW50IGZyb20gdGhlIHNl cnZlciB0byB0aGUgY2xpZW50IGFyZSBwcmVmaXhlZCB3aXRoDQogICAgICJT OiIuDQoNCg0KDQoNCg0KDQoNCg0KTmV3bWFuICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDVdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgSU1BUCBVUkwg U2NoZW1lICAgICAgICAgICAgICAgICAgICAgTWF5IDE5OTcNCg0KDQogICAg IFRoZSBVUkw6DQoNCiAgICAgIDxpbWFwOi8vbWluYmFyaS5vcmcvZ3JheS1j b3VuY2lsO1VJRFZBTElESVRZPTM4NTc1OTA0NS87VUlEPTIwPg0KDQogICAg IFJlc3VsdHMgaW4gdGhlIGZvbGxvd2luZyBjbGllbnQgY29tbWFuZHM6DQoN CiAgICAgICAgIDxjb25uZWN0IHRvIG1pbmJhcmkub3JnLCBwb3J0IDE0Mz4N CiAgICAgICAgIEM6IEEwMDEgTE9HSU4gQU5PTllNT1VTIHNoZXJpZGFuQGJh Ynlsb241Lm9yZw0KICAgICAgICAgQzogQTAwMiBTRUxFQ1QgZ3JheS1jb3Vu Y2lsDQogICAgICAgICA8Y2xpZW50IHZlcmlmaWVzIHRoZSBVSURWQUxJRElU WSBtYXRjaGVzPg0KICAgICAgICAgQzogQTAwMyBVSUQgRkVUQ0ggMjAgQk9E WS5QRUVLW10NCg0KICAgICBUaGUgVVJMOg0KDQogICAgICA8aW1hcDovL21p Y2hhZWxAbWluYmFyaS5vcmcvdXNlcnMuKjt0eXBlPWxpc3Q+DQoNCiAgICAg UmVzdWx0cyBpbiB0aGUgZm9sbG93aW5nIGNsaWVudCBjb21tYW5kczoNCg0K ICAgICAgICAgPGNsaWVudCByZXF1ZXN0cyBwYXNzd29yZCBmcm9tIHVzZXI+ DQogICAgICAgICA8Y29ubmVjdCB0byBtaW5iYXJpLm9yZywgcG9ydCAxNDM+ DQogICAgICAgICBDOiBBMDAxIExPR0lOIE1JQ0hBRUwgemlwcGVyDQogICAg ICAgICBDOiBBMDAyIExJU1QgIiIgdXNlcnMuKg0KDQogICAgIFRoZSBVUkw6 DQoNCiAgICAgIDxpbWFwOi8vcHN5LmVhcnRoL35wZXRlci8lRTYlOTclQTUl RTYlOUMlQUMlRTglQUElOUUvJUU1JThGJUIwJUU1JThDJTk3Pg0KDQogICAg IFJlc3VsdHMgaW4gdGhlIGZvbGxvd2luZyBjbGllbnQgY29tbWFuZHM6DQoN CiAgICAgICAgIDxjb25uZWN0IHRvIHBzeS5lYXJ0aCwgcG9ydCAxNDM+DQog ICAgICAgICBDOiBBMDAxIExPR0lOIEFOT05ZTU9VUyBiZXN0ZXJAcHN5Y29w LnBzeS5lYXJ0aA0KICAgICAgICAgQzogQTAwMiBTRUxFQ1QgfnBldGVyLyZa ZVZuTElxZS0vJlUsQlRGdy0NCiAgICAgICAgIDxjb21tYW5kcyB0aGUgY2xp ZW50IHVzZXMgZm9yIHZpZXdpbmcgdGhlIGNvbnRlbnRzIG9mIGEgbWFpbGJv eD4NCg0KICAgICBUaGUgVVJMOg0KDQogICAgICA8aW1hcDovLztBVVRIPUtF UkJFUk9TX1Y0QG1pbmJhcmkub3JnL2dyYXktY291bmNpbC87dWlkPTIwLztz ZWN0aW9uPTEuMj4NCg0KICAgICBSZXN1bHRzIGluIHRoZSBmb2xsb3dpbmcg Y2xpZW50IGNvbW1hbmRzOg0KDQogICAgICAgICA8Y29ubmVjdCB0byBtaW5i YXJpLm9yZywgcG9ydCAxNDM+DQogICAgICAgICBDOiBBMDAxIEFVVEhFTlRJ Q0FURSBLRVJCRVJPU19WNA0KICAgICAgICAgPGF1dGhlbnRpY2F0aW9uIGV4 Y2hhbmdlPg0KICAgICAgICAgQzogQTAwMiBTRUxFQ1QgZ3JheS1jb3VuY2ls DQogICAgICAgICBDOiBBMDAzIFVJRCBGRVRDSCAyMCBCT0RZLlBFRUtbMS4y XQ0KDQoNCg0KDQoNCg0KTmV3bWFuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoM DQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgSU1BUCBVUkwgU2NoZW1l ICAgICAgICAgICAgICAgICAgICAgTWF5IDE5OTcNCg0KDQogICAgIElmIHRo ZSBmb2xsb3dpbmcgcmVsYXRpdmUgVVJMIGlzIGxvY2F0ZWQgaW4gdGhhdCBi b2R5IHBhcnQ6DQoNCiAgICAgIDw7c2VjdGlvbj0xLjQ+DQoNCiAgICAgVGhp cyBjb3VsZCByZXN1bHQgaW4gdGhlIGZvbGxvd2luZyBjbGllbnQgY29tbWFu ZHM6DQoNCiAgICAgICAgIEM6IEEwMDQgVUlEIEZFVENIIDIwIChCT0RZLlBF RUtbMS4yLk1JTUVdDQogICAgICAgICAgICAgICAgIEJPRFkuUEVFS1sxLk1J TUVdDQogICAgICAgICAgICAgICAgIEJPRFkuUEVFS1tIRUFERVIuRklFTERT IChDb250ZW50LUJhc2UgQ29udGVudC1Mb2NhdGlvbildKQ0KICAgICAgICAg PENsaWVudCBsb29rcyBmb3IgQ29udGVudC1CYXNlIG9yIENvbnRlbnQtTG9j YXRpb24gaGVhZGVycyBpbg0KICAgICAgICAgIHJlc3VsdC4gIElmIG5vIHN1 Y2ggaGVhZGVycywgdGhlbiBpdCBkb2VzIHRoZSBmb2xsb3dpbmc+DQogICAg ICAgICBDOiBBMDA1IFVJRCBGRVRDSCAyMCBCT0RZLlBFRUtbMS40XQ0KDQog ICAgIFRoZSBVUkw6DQoNCiAgICAgIDxpbWFwOi8vO0FVVEg9KkBtaW5iYXJp Lm9yZy9ncmF5JTIwY291bmNpbD9TVUJKRUNUJTIwc2hhZG93cz4NCg0KICAg ICBDb3VsZCByZXN1bHQgaW4gdGhlIGZvbGxvd2luZzoNCg0KICAgICAgICAg PGNvbm5lY3QgdG8gbWluYmFyaS5vcmcsIHBvcnQgMTQzPg0KICAgICAgICAg QzogQTAwMSBDQVBBQklMSVRZDQogICAgICAgICBTOiAqIENBUEFCSUxJVFkg SU1BUDRyZXYxIEFVVEg9R1NTQVBJDQogICAgICAgICBTOiBBMDAxIE9LDQog ICAgICAgICBDOiBBMDAyIEFVVEhFTlRJQ0FURSBHU1NBUEkNCiAgICAgICAg IDxhdXRoZW50aWNhdGlvbiBleGNoYW5nZT4NCiAgICAgICAgIFM6IEEwMDIg T0sgdXNlciBsZW5uaWVyIGF1dGhlbnRpY2F0ZWQNCiAgICAgICAgIEM6IEEw MDMgU0VMRUNUICJncmF5IGNvdW5jaWwiDQogICAgICAgICAuLi4NCiAgICAg ICAgIEM6IEEwMDQgU0VBUkNIIFNVQkpFQ1Qgc2hhZG93cw0KICAgICAgICAg UzogKiBTRUFSQ0ggOCAxMCAxMyAxNCAxNSAxNg0KICAgICAgICAgUzogQTAw NCBPSyBTRUFSQ0ggY29tcGxldGVkDQogICAgICAgICBDOiBBMDA1IEZFVENI IDgsMTAsMTM6MTYgQUxMDQogICAgICAgICAuLi4NCg0KICAgICBOT1RFOiBJ biB0aGlzIGZpbmFsIGV4YW1wbGUsIHRoZSBjbGllbnQgaGFzIGltcGxlbWVu dGF0aW9uIGRlcGVuZGVudA0KICAgICBjaG9pY2VzLiAgVGhlIGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbSBjb3VsZCBiZSBhbnl0aGluZywgaW5jbHVkaW5n DQogICAgIFBSRUFVVEguICBBbmQgdGhlIGZpbmFsIEZFVENIIGNvbW1hbmQg Y291bGQgZmV0Y2ggbW9yZSBvciBsZXNzDQogICAgIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBtZXNzYWdlcywgZGVwZW5kaW5nIG9uIHdoYXQgaXQgd2lzaGVz IHRvIGRpc3BsYXkNCiAgICAgdG8gdGhlIHVzZXIuDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCklu dGVybmV0IERyYWZ0ICAgICAgICAgICAgICBJTUFQIFVSTCBTY2hlbWUgICAg ICAgICAgICAgICAgICAgICBNYXkgMTk5Nw0KDQoNCjEwLiBBQk5GIGZvciBJ TUFQIFVSTCBzY2hlbWUNCg0KICAgICBUaGlzIHVzZXMgQUJORiBhcyBkZWZp bmVkIGluIFJGQyA4MjIgW0lNQUlMXS4gIFRlcm1pbmFscyBmcm9tIHRoZQ0K ICAgICBCTkYgZm9yIElNQVAgW0lNQVBdIGFuZCBVUkxzIFtCQVNJQy1VUkxd IGFyZSBhbHNvIHVzZWQuICBTdHJpbmdzDQogICAgIGFyZSBub3QgY2FzZSBz ZW5zaXRpdmUgYW5kIGZyZWUgaW5zZXJ0aW9uIG9mIGxpbmVhci13aGl0ZS1z cGFjZSBpcw0KICAgICBub3QgcGVybWl0dGVkLg0KDQogICAgIGFjaGFyICAg ICAgICAgICAgPSB1Y2hhciAvICImIiAvICI9IiAvICJ+Ig0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA7IHNlZSBbQkFTSUMtVVJMXSBmb3IgInVj aGFyIiBkZWZpbml0aW9uDQoNCiAgICAgYmNoYXIgICAgICAgICAgICA9IGFj aGFyIC8gIjoiIC8gIkAiIC8gIi8iDQoNCiAgICAgZW5jX2F1dGhfdHlwZSAg ICA9IDEqYWNoYXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBl bmNvZGVkIHZlcnNpb24gb2YgW0lNQVAtQVVUSF0gImF1dGhfdHlwZSINCg0K ICAgICBlbmNfbGlzdF9tYWlsYm94ID0gMSpiY2hhcg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA7IGVuY29kZWQgdmVyc2lvbiBvZiBbSU1BUDRd ICJsaXN0X21haWxib3giDQoNCiAgICAgZW5jX21haWxib3ggICAgICA9IDEq YmNoYXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBlbmNvZGVk IHZlcnNpb24gb2YgW0lNQVA0XSAibWFpbGJveCINCg0KICAgICBlbmNfc2Vh cmNoICAgICAgID0gMSpiY2hhcg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA7IGVuY29kZWQgdmVyc2lvbiBvZiBzZWFyY2hfcHJvZ3JhbSBiZWxv dw0KDQogICAgIGVuY19zZWN0aW9uICAgICAgPSAxKmJjaGFyDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDsgZW5jb2RlZCB2ZXJzaW9uIG9mIHNl Y3Rpb24gYmVsb3cNCg0KICAgICBlbmNfdXNlciAgICAgICAgID0gKmFjaGFy DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgZW5jb2RlZCB2ZXJz aW9uIG9mIFtJTUFQNF0gInVzZXJpZCINCg0KICAgICBpbWFwdXJsICAgICAg ICAgID0gImltYXA6Ly8iIGlzZXJ2ZXIgIi8iIFsgaWNvbW1hbmQgXSBbIGlh dXRoIF0NCg0KICAgICBpYXV0aCAgICAgICAgICAgID0gIjtBVVRIPSIgKCAi KiIgLyBlbmNfYXV0aF90eXBlICkNCg0KICAgICBpY29tbWFuZCAgICAgICAg ID0gaW1haWxib3hsaXN0IC8gaXBhdGggLyBpc2VhcmNoDQoNCiAgICAgaW1h aWxib3hsaXN0ICAgICA9IFtlbmNfbGlzdF9tYWlsYm94XSBbICI7VFlQRT0i IGxpc3RfdHlwZSBdDQoNCiAgICAgaXBhdGggICAgICAgICAgICA9IGVuY19t YWlsYm94IFt1aWR2YWxpZGl0eV0gaXVpZCBbaXNlY3Rpb25dDQoNCiAgICAg aXNlYXJjaCAgICAgICAgICA9IGVuY19tYWlsYm94IFsgIj8iIGVuY19zZWFy Y2ggXSBbdWlkdmFsaWRpdHldDQoNCiAgICAgaXNlY3Rpb24gICAgICAgICA9 ICIvO1NFQ1RJT049IiBlbmNfc2VjdGlvbg0KDQogICAgIGlzZXJ2ZXIgICAg ICAgICAgPSBbZW5jX3VzZXIgWyBpYXV0aCBdICJAIl0gaG9zdHBvcnQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBTZWUgW0JBU0lDLVVSTF0g Zm9yICJob3N0cG9ydCIgZGVmaW5pdGlvbg0KDQoNCg0KDQoNCk5ld21hbiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgIElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAgICAgICAgICAgIE1h eSAxOTk3DQoNCg0KICAgICBpdWlkICAgICAgICAgICAgID0gIi87VUlEPSIg bnpfbnVtYmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgU2Vl IFtJTUFQNF0gZm9yICJuel9udW1iZXIiIGRlZmluaXRpb24NCg0KICAgICBs aXN0X3R5cGUgICAgICAgID0gIkxJU1QiIC8gIkxTVUIiDQoNCiAgICAgc2Vh cmNoX3Byb2dyYW0gICA9IFsiQ0hBUlNFVCIgU1BBQ0UgYXN0cmluZyBTUEFD RV0gMSNzZWFyY2hfa2V5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg IDsgSU1BUDQgbGl0ZXJhbHMgbWF5IG5vdCBiZSB1c2VkDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDsgU2VlIFtJTUFQNF0gZm9yICJhc3RyaW5n IiBhbmQgInNlYXJjaF9rZXkiDQoNCiAgICAgc2VjdGlvbiAgICAgICAgICA9 IHNlY3Rpb25fdGV4dCAvIChuel9udW1iZXIgKlsiLiIgbnpfbnVtYmVyXQ0K ICAgICAgICAgICAgICAgICAgICAgICAgIFsiLiIgKHNlY3Rpb25fdGV4dCAv ICJNSU1FIildKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IFNl ZSBbSU1BUDRdIGZvciAic2VjdGlvbl90ZXh0IiBhbmQgIm56X251bWJlciIN Cg0KICAgICB1aWR2YWxpZGl0eSAgICAgID0gIjtVSURWQUxJRElUWT0iIG56 X251bWJlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IFNlZSBb SU1BUDRdIGZvciAibnpfbnVtYmVyIiBkZWZpbml0aW9uDQoNCg0KMTEuIFJl ZmVyZW5jZXMNCg0KICAgICBbQkFTSUMtVVJMXSBCZXJuZXJzLUxlZSwgTWFz aW50ZXIsIE1jQ2FoaWxsLCAiVW5pZm9ybSBSZXNvdXJjZQ0KICAgICBMb2Nh dG9ycyAoVVJMKSIsIFJGQyAxNzM4LCBDRVJOLCBYZXJveCBDb3Jwb3JhdGlv biwgVW5pdmVyc2l0eSBvZg0KICAgICBNaW5uZXNvdGEsIERlY2VtYmVyIDE5 OTQuDQoNCiAgICAgICAgIDxmdHA6Ly9kcy5pbnRlcm5pYy5uZXQvcmZjL3Jm YzE3MzgudHh0Pg0KDQogICAgIFtJTUFQNF0gQ3Jpc3BpbiwgTS4sICJJbnRl cm5ldCBNZXNzYWdlIEFjY2VzcyBQcm90b2NvbCAtIFZlcnNpb24NCiAgICAg NHJldjEiLCBSRkMgMjA2MCwgVW5pdmVyc2l0eSBvZiBXYXNoaW5ndG9uLCBE ZWNlbWJlciAxOTk2Lg0KDQogICAgICAgICA8ZnRwOi8vZHMuaW50ZXJuaWMu bmV0L3JmYy9yZmMyMDYwLnR4dD4NCg0KICAgICBbSU1BUC1BVVRIXSBNeWVy cywgSi4sICJJTUFQNCBBdXRoZW50aWNhdGlvbiBNZWNoYW5pc20iLCBSRkMg MTczMSwNCiAgICAgQ2FybmVnaWUtTWVsbG9uIFVuaXZlcnNpdHksIERlY2Vt YmVyIDE5OTQuDQoNCiAgICAgICAgIDxmdHA6Ly9kcy5pbnRlcm5pYy5uZXQv cmZjL3JmYzE3MzEudHh0Pg0KDQogICAgIFtIVFRQXSBGaWVsZGluZywgR2V0 dHlzLCBNb2d1bCwgRnJ5c3R5aywgQmVybmVycy1MZWUsICJIeXBlcnRleHQN CiAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEiLCBSRkMgMjA2 OCwgVUMgSXJ2aW5lLCBERUMsIE1JVC9MQ1MsDQogICAgIEphbnVhcnkgMTk5 Ny4NCg0KICAgICAgICAgPGZ0cDovL2RzLmludGVybmljLm5ldC9yZmMvcmZj MjA2OC50eHQ+DQoNCiAgICAgW0lNQUlMXSBDcm9ja2VyLCAiU3RhbmRhcmQg Zm9yIHRoZSBGb3JtYXQgb2YgQVJQQSBJbnRlcm5ldCBUZXh0DQogICAgIE1l c3NhZ2VzIiwgU1REIDExLCBSRkMgODIyLCBVbml2ZXJzaXR5IG9mIERlbGF3 YXJlLCBBdWd1c3QgMTk4Mi4NCg0KICAgICAgICAgPGZ0cDovL2RzLmludGVy bmljLm5ldC9yZmMvcmZjODIyLnR4dD4NCg0KDQoNCg0KDQoNCk5ld21hbiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgIElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAgICAgICAgICAgIE1h eSAxOTk3DQoNCg0KICAgICBbS0VZV09SRFNdIEJyYWRuZXIsICJLZXkgd29y ZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgIFJlcXVpcmVt ZW50IExldmVscyIsIFJGQyAyMTE5LCBIYXJ2YXJkIFVuaXZlcnNpdHksIE1h cmNoIDE5OTcuDQoNCiAgICAgICAgIDxmdHA6Ly9kcy5pbnRlcm5pYy5uZXQv cmZjL3JmYzIxMTkudHh0Pg0KDQogICAgIFtNSU1FXSBGcmVlZCwgTi4sIEJv cmVuc3RlaW4sIE4uLCAiTXVsdGlwdXJwb3NlIEludGVybmV0IE1haWwNCiAg ICAgRXh0ZW5zaW9ucyIsIFJGQyAyMDQ1LCBJbm5vc29mdCwgRmlyc3QgVmly dHVhbCwgTm92ZW1iZXIgMTk5Ni4NCg0KICAgICAgICA8ZnRwOi8vZHMuaW50 ZXJuaWMubmV0L3JmYy9yZmMyMDQ1LnR4dD4NCg0KICAgICBbUkVMLVVSTF0g RmllbGRpbmcsICJSZWxhdGl2ZSBVbmlmb3JtIFJlc291cmNlIExvY2F0b3Jz IiwgUkZDIDE4MDgsDQogICAgIFVDIElydmluZSwgSnVuZSAxOTk1Lg0KDQog ICAgICAgICA8ZnRwOi8vZHMuaW50ZXJuaWMubmV0L3JmYy9yZmMxODA4LnR4 dD4NCg0KICAgICBbVVRGOF0gWWVyZ2VhdSwgRi4gIlVURi04LCBhIHRyYW5z Zm9ybWF0aW9uIGZvcm1hdCBvZiBVbmljb2RlIGFuZA0KICAgICBJU08gMTA2 NDYiLCBSRkMgMjA0NCwgQWxpcyBUZWNobm9sb2dpZXMsIE9jdG9iZXIgMTk5 Ni4NCg0KICAgICAgICAgPGZ0cDovL2RzLmludGVybmljLm5ldC9yZmMvcmZj MjA0NC50eHQ+DQoNCg0KMTIuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoN CiAgICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIHRo ZSBJTUFQIHNwZWNpZmljYXRpb24gW0lNQVA0XQ0KICAgICBhbmQgdGhlIFVS TCBzcGVjaWZpY2F0aW9uIFtCQVNJQy1VUkxdIGFyZSByZWxldmFudC4NCg0K ICAgICBDbGllbnQgYXV0aG9ycyBTSE9VTEQgYmUgY2FyZWZ1bCB3aGVuIHNl bGVjdGluZyBhbiBhdXRoZW50aWNhdGlvbg0KICAgICBtZWNoYW5pc20gaWYg IjtBVVRIPSoiIGlzIHNwZWNpZmllZCB3aXRob3V0IGEgdXNlciBuYW1lLiAg Q2xpZW50cw0KICAgICBTSE9VTEQgTk9UIGZhbGwgYmFjayB0byB0aGUgIkxP R0lOIiBjb21tYW5kIHdpdGggYSB1c2VyIG90aGVyIHRoYW4NCiAgICAgImFu b255bW91cyIuICBBIGNsaWVudCB3aGljaCB2aW9sYXRlcyB0aGlzIHJ1bGUg aXMgdnVsbmVyYWJsZSB0byBhbg0KICAgICBhY3RpdmUgYXR0YWNrZXIgd2hp Y2ggc3Bvb2ZzIHRoZSBzZXJ2ZXIgYW5kIGRvZXMgbm90IGRlY2xhcmUNCiAg ICAgc3VwcG9ydCBmb3IgYW55IEFVVEhFTlRJQ0FURSBtZWNoYW5pc21zLg0K DQogICAgIE1hbnkgZW1haWwgY2xpZW50cyBzdG9yZSB0aGUgcGxhaW4gdGV4 dCBwYXNzd29yZCBmb3IgbGF0ZXIgdXNlDQogICAgIGFmdGVyIGxvZ2dpbmcg aW50byBhbiBJTUFQIHNlcnZlci4gIFN1Y2ggY2xpZW50cyBNVVNUIE5PVCB1 c2UgYQ0KICAgICBzdG9yZWQgcGFzc3dvcmQgaW4gcmVzcG9uc2UgdG8gYW4g SU1BUCBVUkwgd2l0aG91dCBleHBsaWNpdA0KICAgICBwZXJtaXNzaW9uIGZy b20gdGhlIHVzZXIgdG8gc3VwcGx5IHRoYXQgcGFzc3dvcmQgdG8gdGhlIHNw ZWNpZmllZA0KICAgICBob3N0IG5hbWUuDQoNCg0KMTMuIEF1dGhvcidzIEFk ZHJlc3MNCg0KICAgICBDaHJpcyBOZXdtYW4NCiAgICAgSW5ub3NvZnQgSW50 ZXJuYXRpb25hbCwgSW5jLg0KICAgICAxMDUwIEVhc3QgR2FydmV5IEF2ZS4g U291dGgNCiAgICAgV2VzdCBDb3ZpbmEsIENBIDkxNzkwIFVTQQ0KDQogICAg IEVtYWlsOiBjaHJpcy5uZXdtYW5AaW5ub3NvZnQuY29tDQoNCg0KDQpOZXdt YW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0IERyYWZ0ICAg ICAgICAgICAgICBJTUFQIFVSTCBTY2hlbWUgICAgICAgICAgICAgICAgICAg ICBNYXkgMTk5Nw0KDQoNCkFwcGVuZGl4IEEuICBTYW1wbGUgY29kZQ0KDQpI ZXJlIGlzIHNhbXBsZSBDIHNvdXJjZSBjb2RlIHRvIGNvbnZlcnQgYmV0d2Vl biBVUkwgcGF0aHMgYW5kIElNQVANCm1haWxib3ggbmFtZXMsIHRha2luZyBp bnRvIGFjY291bnQgbWFwcGluZyBiZXR3ZWVuIElNQVAncyBtb2RpZmllZCBV VEYtNw0KW0lNQVBdIGFuZCBoZXgtZW5jb2RlZCBVVEYtOCB3aGljaCBpcyBt b3JlIGFwcHJvcHJpYXRlIGZvciBVUkxzLiAgVGhpcw0KY29kZSBoYXMgbm90 IGJlZW4gcmlnb3JvdXNseSB0ZXN0ZWQgbm9yIGRvZXMgaXQgbmVjZXNzYXJp bHkgYmVoYXZlDQpyZWFzb25hYmx5IHdpdGggaW52YWxpZCBpbnB1dCwgYnV0 IGl0IHNob3VsZCBzZXJ2ZSBhcyBhIHVzZWZ1bCBleGFtcGxlLg0KVGhpcyBj b2RlIGp1c3QgY29udmVydHMgdGhlIG1haWxib3ggcG9ydGlvbiBvZiB0aGUg VVJMIGFuZCBkb2VzIG5vdCBkZWFsDQp3aXRoIHBhcmFtZXRlcnMsIHF1ZXJ5 IG9yIHNlcnZlciBjb21wb25lbnRzIG9mIHRoZSBVUkwuDQoNCiNpbmNsdWRl IDxzdGRpby5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KDQovKiBoZXhhZGVj aW1hbCBsb29rdXAgdGFibGUgKi8NCnN0YXRpYyBjaGFyIGhleFtdID0gIjAx MjM0NTY3ODlBQkNERUYiOw0KDQovKiBVUkwgdW5zYWZlIHByaW50YWJsZSBj aGFyYWN0ZXJzICovDQpzdGF0aWMgY2hhciB1cmx1bnNhZmVbXSA9ICIgXCIj JSYrOjs8PT4/QFtcXF1eYHt8fSI7DQoNCi8qIFVURjcgbW9kaWZpZWQgYmFz ZTY0IGFscGhhYmV0ICovDQpzdGF0aWMgY2hhciBiYXNlNjRjaGFyc1tdID0N CiAgIkFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5v cHFyc3R1dnd4eXowMTIzNDU2Nzg5KywiOw0KI2RlZmluZSBVTkRFRklORUQg NjQNCg0KLyogVVRGMTYgZGVmaW5pdGlvbnMgKi8NCiNkZWZpbmUgVVRGMTZN QVNLICAgICAgIDB4MDNGRlVMDQojZGVmaW5lIFVURjE2U0hJRlQgICAgICAx MA0KI2RlZmluZSBVVEYxNkhJR0hTVEFSVCAgMHhEODAwVUwNCiNkZWZpbmUg VVRGMTZISUdIRU5EICAgIDB4REJGRlVMDQojZGVmaW5lIFVURjE2TE9TVEFS VCAgICAweERDMDBVTA0KI2RlZmluZSBVVEYxNkxPRU5EICAgICAgMHhERkZG VUwNCg0KLyogQ29udmVydCBhbiBJTUFQIG1haWxib3ggdG8gYSBVUkwgcGF0 aA0KICogIGRzdCBuZWVkcyB0byBoYXZlIHJvdWdobHkgNCB0aW1lcyB0aGUg c3RvcmFnZSBzcGFjZSBvZiBzcmMNCiAqICAgIEhleCBlbmNvZGluZyBjYW4g dHJpcGxlIHRoZSBzaXplIG9mIHRoZSBpbnB1dA0KICogICAgVVRGLTcgY2Fu IGJlIHNsaWdodGx5IGRlbnNlciB0aGFuIFVURi04DQogKiAgICAgKHdvcnN0 IGNhc2U6IDggb2N0ZXRzIFVURi03IGJlY29tZXMgOSBvY3RldHMgVVRGLTgp DQogKi8NCnZvaWQgTWFpbGJveFRvVVJMKGNoYXIgKmRzdCwgY2hhciAqc3Jj KQ0Kew0KICAgIHVuc2lnbmVkIGNoYXIgYywgaSwgYml0Y291bnQ7DQogICAg dW5zaWduZWQgbG9uZyB1Y3M0LCB1dGYxNiwgYml0YnVmOw0KICAgIHVuc2ln bmVkIGNoYXIgYmFzZTY0WzI1Nl0sIHV0ZjhbNl07DQoNCiAgICAvKiBpbml0 aWFsaXplIG1vZGlmaWVkIGJhc2U2NCBkZWNvZGluZyB0YWJsZSAqLw0KICAg IG1lbXNldChiYXNlNjQsIFVOREVGSU5FRCwgc2l6ZW9mIChiYXNlNjQpKTsN CiAgICBmb3IgKGkgPSAwOyBpIDwgc2l6ZW9mIChiYXNlNjRjaGFycyk7ICsr aSkgew0KICAgICAgICBiYXNlNjRbYmFzZTY0Y2hhcnNbaV1dID0gaTsNCg0K DQoNCk5ld21hbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQg RHJhZnQgICAgICAgICAgICAgIElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAg ICAgICAgICAgIE1heSAxOTk3DQoNCg0KICAgIH0NCg0KICAgIC8qIGxvb3Ag dW50aWwgZW5kIG9mIHN0cmluZyAqLw0KICAgIHdoaWxlICgqc3JjICE9ICdc MCcpIHsNCiAgICAgICAgYyA9ICpzcmMrKzsNCiAgICAgICAgLyogZGVhbCB3 aXRoIGxpdGVyYWwgY2hhcmFjdGVycyBhbmQgJi0gKi8NCiAgICAgICAgaWYg KGMgIT0gJyYnIHx8ICpzcmMgPT0gJy0nKSB7DQogICAgICAgICAgICBpZiAo YyA8ICcgJyB8fCBjID4gJ34nIHx8IHN0cmNocih1cmx1bnNhZmUsIGMpICE9 IE5VTEwpIHsNCiAgICAgICAgICAgICAgICAvKiBoZXggZW5jb2RlIGlmIG5l Y2Vzc2FyeSAqLw0KICAgICAgICAgICAgICAgIGRzdFswXSA9ICclJzsNCiAg ICAgICAgICAgICAgICBkc3RbMV0gPSBoZXhbYyA+PiA0XTsNCiAgICAgICAg ICAgICAgICBkc3RbMl0gPSBoZXhbYyAmIDB4MGZdOw0KICAgICAgICAgICAg ICAgIGRzdCArPSAzOw0KICAgICAgICAgICAgfSBlbHNlIHsNCiAgICAgICAg ICAgICAgICAvKiBlbmNvZGUgbGl0ZXJhbGx5ICovDQogICAgICAgICAgICAg ICAgKmRzdCsrID0gYzsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIC8q IHNraXAgb3ZlciB0aGUgJy0nIGlmIHRoaXMgaXMgYW4gJi0gc2VxdWVuY2Ug Ki8NCiAgICAgICAgICAgIGlmIChjID09ICcmJykgKytzcmM7DQogICAgICAg IH0gZWxzZSB7DQogICAgICAgICAgICAvKiBjb252ZXJ0IG1vZGlmaWVkIFVU Ri03IC0+IFVURi0xNiAtPiBVQ1MtNCAtPiBVVEYtOCAtPiBIRVggKi8NCiAg ICAgICAgICAgIGJpdGJ1ZiA9IDA7DQogICAgICAgICAgICBiaXRjb3VudCA9 IDA7DQogICAgICAgICAgICB1Y3M0ID0gMDsNCiAgICAgICAgICAgIHdoaWxl ICgoYyA9IGJhc2U2NFsodW5zaWduZWQgY2hhcikgKnNyY10pICE9IFVOREVG SU5FRCkgew0KICAgICAgICAgICAgICAgICsrc3JjOw0KICAgICAgICAgICAg ICAgIGJpdGJ1ZiA9IChiaXRidWYgPDwgNikgfCBjOw0KICAgICAgICAgICAg ICAgIGJpdGNvdW50ICs9IDY7DQogICAgICAgICAgICAgICAgLyogZW5vdWdo IGJpdHMgZm9yIGEgVVRGLTE2IGNoYXJhY3Rlcj8gKi8NCiAgICAgICAgICAg ICAgICBpZiAoYml0Y291bnQgPj0gMTYpIHsNCiAgICAgICAgICAgICAgICAg ICAgYml0Y291bnQgLT0gMTY7DQogICAgICAgICAgICAgICAgICAgIHV0ZjE2 ID0gKGJpdGNvdW50ID8gYml0YnVmID4+IGJpdGNvdW50IDogYml0YnVmKSAm IDB4ZmZmZjsNCiAgICAgICAgICAgICAgICAgICAgLyogY29udmVydCBVVEYx NiB0byBVQ1M0ICovDQogICAgICAgICAgICAgICAgICAgIGlmICh1dGYxNiA+ PSBVVEYxNkhJR0hTVEFSVCAmJiB1dGYxNiA8PSBVVEYxNkhJR0hFTkQpIHsN CiAgICAgICAgICAgICAgICAgICAgICAgIHVjczQgPSAodXRmMTYgJiBVVEYx Nk1BU0spIDw8IFVURjE2U0hJRlQ7DQogICAgICAgICAgICAgICAgICAgICAg ICBjb250aW51ZTsNCiAgICAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICh1 dGYxNiA+PSBVVEYxNkxPU1RBUlQgJiYgdXRmMTYgPD0gVVRGMTZMT0VORCkg ew0KICAgICAgICAgICAgICAgICAgICAgICAgdWNzNCB8PSB1dGYxNiAmIFVU RjE2TUFTSzsNCiAgICAgICAgICAgICAgICAgICAgfSBlbHNlIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgIHVjczQgPSB1dGYxNjsNCiAgICAgICAgICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAvKiBjb252ZXJ0IFVU Ri0xNiByYW5nZSBvZiBVQ1M0IHRvIFVURi04ICovDQogICAgICAgICAgICAg ICAgICAgIGlmICh1Y3M0IDw9IDB4N2ZVTCkgew0KICAgICAgICAgICAgICAg ICAgICAgICAgdXRmOFswXSA9IHVjczQ7DQogICAgICAgICAgICAgICAgICAg ICAgICBpID0gMTsNCiAgICAgICAgICAgICAgICAgICAgfSBlbHNlIGlmICh1 Y3M0IDw9IDB4N2ZmVUwpIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIHV0 ZjhbMF0gPSAweGMwIHwgKHVjczQgPj4gNik7DQogICAgICAgICAgICAgICAg ICAgICAgICB1dGY4WzFdID0gMHg4MCB8ICh1Y3M0ICYgMHgzZik7DQoNCg0K DQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0IERy YWZ0ICAgICAgICAgICAgICBJTUFQIFVSTCBTY2hlbWUgICAgICAgICAgICAg ICAgICAgICBNYXkgMTk5Nw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg IGkgPSAyOw0KICAgICAgICAgICAgICAgICAgICB9IGVsc2UgaWYgKHVjczQg PD0gMHhmZmZmVUwpIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIHV0Zjhb MF0gPSAweGUwIHwgKHVjczQgPj4gMTIpOw0KICAgICAgICAgICAgICAgICAg ICAgICAgdXRmOFsxXSA9IDB4ODAgfCAoKHVjczQgPj4gNikgJiAweDNmKTsN CiAgICAgICAgICAgICAgICAgICAgICAgIHV0ZjhbMl0gPSAweDgwIHwgKHVj czQgJiAweDNmKTsNCiAgICAgICAgICAgICAgICAgICAgICAgIGkgPSAzOw0K ICAgICAgICAgICAgICAgICAgICB9IGVsc2Ugew0KICAgICAgICAgICAgICAg ICAgICAgICAgdXRmOFswXSA9IDB4ZjAgfCAodWNzNCA+PiAxOCk7DQogICAg ICAgICAgICAgICAgICAgICAgICB1dGY4WzFdID0gMHg4MCB8ICgodWNzNCA+ PiAxMikgJiAweDNmKTsNCiAgICAgICAgICAgICAgICAgICAgICAgIHV0Zjhb Ml0gPSAweDgwIHwgKCh1Y3M0ID4+IDYpICYgMHgzZik7DQogICAgICAgICAg ICAgICAgICAgICAgICB1dGY4WzNdID0gMHg4MCB8ICh1Y3M0ICYgMHgzZik7 DQogICAgICAgICAgICAgICAgICAgICAgICBpID0gNDsNCiAgICAgICAgICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAvKiBjb252ZXJ0IHV0 ZjggdG8gaGV4ICovDQogICAgICAgICAgICAgICAgICAgIGZvciAoYyA9IDA7 IGMgPCBpOyArK2MpIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIGRzdFsw XSA9ICclJzsNCiAgICAgICAgICAgICAgICAgICAgICAgIGRzdFsxXSA9IGhl eFt1dGY4W2NdID4+IDRdOw0KICAgICAgICAgICAgICAgICAgICAgICAgZHN0 WzJdID0gaGV4W3V0ZjhbY10gJiAweDBmXTsNCiAgICAgICAgICAgICAgICAg ICAgICAgIGRzdCArPSAzOw0KICAgICAgICAgICAgICAgICAgICB9DQogICAg ICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICAgICAgLyog c2tpcCBvdmVyIHRyYWlsaW5nICctJyBpbiBtb2RpZmllZCBVVEYtNyBlbmNv ZGluZyAqLw0KICAgICAgICAgICAgaWYgKCpzcmMgPT0gJy0nKSArK3NyYzsN CiAgICAgICAgfQ0KICAgIH0NCiAgICAvKiB0ZXJtaW5hdGUgZGVzdGluYXRp b24gc3RyaW5nICovDQogICAgKmRzdCA9ICdcMCc7DQp9DQoNCi8qIENvbnZl cnQgaGV4IGNvZGVkIFVURi04IFVSTCBwYXRoIHRvIG1vZGlmaWVkIFVURi03 IElNQVAgbWFpbGJveA0KICogIGRzdCBzaG91bGQgYmUgYWJvdXQgdHdpY2Ug dGhlIGxlbmd0aCBvZiBzcmMgdG8gZGVhbCB3aXRoIG5vbi1oZXggY29kZWQg VVJMcw0KICovDQp2b2lkIFVSTHRvTWFpbGJveChjaGFyICpkc3QsIGNoYXIg KnNyYykNCnsNCiAgICB1bnNpZ25lZCBpbnQgdXRmOHBvcywgdXRmOHRvdGFs LCBpLCBjLCB1dGY3bW9kZSwgYml0c3RvZ28sIHV0ZjE2ZmxhZzsNCiAgICB1 bnNpZ25lZCBsb25nIHVjczQsIGJpdGJ1ZjsNCiAgICB1bnNpZ25lZCBjaGFy IGhleHRhYlsyNTZdOw0KDQogICAgLyogaW5pdGlhbGl6ZSBoZXggbG9va3Vw IHRhYmxlICovDQogICAgbWVtc2V0KGhleHRhYiwgMCwgc2l6ZW9mIChoZXh0 YWIpKTsNCiAgICBmb3IgKGkgPSAwOyBpIDwgc2l6ZW9mIChoZXgpOyArK2kp IHsNCiAgICAgICAgaGV4dGFiW2hleFtpXV0gPSBpOw0KICAgICAgICBpZiAo aXN1cHBlcihoZXhbaV0pKSBoZXh0YWJbdG9sb3dlcihoZXhbaV0pXSA9IGk7 DQogICAgfQ0KDQogICAgdXRmN21vZGUgPSAwOw0KICAgIHV0Zjh0b3RhbCA9 IDA7DQoNCg0KDQpOZXdtYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCklu dGVybmV0IERyYWZ0ICAgICAgICAgICAgICBJTUFQIFVSTCBTY2hlbWUgICAg ICAgICAgICAgICAgICAgICBNYXkgMTk5Nw0KDQoNCiAgICBiaXRzdG9nbyA9 IDA7DQogICAgd2hpbGUgKChjID0gKnNyYykgIT0gJ1wwJykgew0KICAgICAg ICArK3NyYzsNCiAgICAgICAgLyogdW5kbyBoZXgtZW5jb2RpbmcgKi8NCiAg ICAgICAgaWYgKGMgPT0gJyUnKSB7DQogICAgICAgICAgICBjID0gKGhleHRh YltzcmNbMF1dIDw8IDQpIHwgaGV4dGFiW3NyY1sxXV07DQogICAgICAgICAg ICBzcmMgKz0gMjsNCiAgICAgICAgfQ0KICAgICAgICAvKiBub3JtYWwgY2hh cmFjdGVyPyAqLw0KICAgICAgICBpZiAoYyA+PSAnICcgJiYgYyA8PSAnficp IHsNCiAgICAgICAgICAgIC8qIHN3aXRjaCBvdXQgb2YgVVRGLTcgbW9kZSAq Lw0KICAgICAgICAgICAgaWYgKHV0Zjdtb2RlKSB7DQogICAgICAgICAgICAg ICAgaWYgKGJpdHN0b2dvKSB7DQogICAgICAgICAgICAgICAgICAgICpkc3Qr KyA9IGJhc2U2NGNoYXJzWyhiaXRidWYgPDwgKDYgLSBiaXRzdG9nbykpICYg MHgzRl07DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICpk c3QrKyA9ICctJzsNCiAgICAgICAgICAgICAgICB1dGY3bW9kZSA9IDA7DQog ICAgICAgICAgICB9DQogICAgICAgICAgICAqZHN0KysgPSBjOw0KICAgICAg ICAgICAgLyogZW5jb2RlICcmJyBhcyAnJi0nICovDQogICAgICAgICAgICBp ZiAoYyA9PSAnJicpIHsNCiAgICAgICAgICAgICAgICAqZHN0KysgPSAnLSc7 DQogICAgICAgICAgICB9DQogICAgICAgICAgICBjb250aW51ZTsNCiAgICAg ICAgfQ0KICAgICAgICAvKiBzd2l0Y2ggdG8gVVRGLTcgbW9kZSAqLw0KICAg ICAgICBpZiAoIXV0Zjdtb2RlKSB7DQogICAgICAgICAgICAqZHN0KysgPSAn Jic7DQogICAgICAgICAgICB1dGY3bW9kZSA9IDE7DQogICAgICAgIH0NCiAg ICAgICAgLyogRW5jb2RlIFVTLUFTQ0lJIGNoYXJhY3RlcnMgYXMgdGhlbXNl bHZlcyAqLw0KICAgICAgICBpZiAoYyA8IDB4ODApIHsNCiAgICAgICAgICAg IHVjczQgPSBjOw0KICAgICAgICAgICAgdXRmOHRvdGFsID0gMTsNCiAgICAg ICAgfSBlbHNlIGlmICh1dGY4dG90YWwpIHsNCiAgICAgICAgICAgIC8qIHNh dmUgVVRGOCBiaXRzIGludG8gVUNTNCAqLw0KICAgICAgICAgICAgdWNzNCA9 ICh1Y3M0IDw8IDYpIHwgKGMgJiAweDNGVUwpOw0KICAgICAgICAgICAgaWYg KCsrdXRmOHBvcyA8IHV0Zjh0b3RhbCkgew0KICAgICAgICAgICAgICAgIGNv bnRpbnVlOw0KICAgICAgICAgICAgfQ0KICAgICAgICB9IGVsc2Ugew0KICAg ICAgICAgICAgdXRmOHBvcyA9IDE7DQogICAgICAgICAgICBpZiAoYyA8IDB4 RTApIHsNCiAgICAgICAgICAgICAgICB1dGY4dG90YWwgPSAyOw0KICAgICAg ICAgICAgICAgIHVjczQgPSBjICYgMHgxRjsNCiAgICAgICAgICAgIH0gZWxz ZSBpZiAoYyA8IDB4RjApIHsNCiAgICAgICAgICAgICAgICB1dGY4dG90YWwg PSAzOw0KICAgICAgICAgICAgICAgIHVjczQgPSBjICYgMHgwRjsNCg0KDQoN Ck5ld21hbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQgRHJh ZnQgICAgICAgICAgICAgIElNQVAgVVJMIFNjaGVtZSAgICAgICAgICAgICAg ICAgICAgIE1heSAxOTk3DQoNCg0KICAgICAgICAgICAgfSBlbHNlIHsNCiAg ICAgICAgICAgICAgICAvKiBOT1RFOiBjYW4ndCBjb252ZXJ0IFVURjggc2Vx dWVuY2VzIGxvbmdlciB0aGFuIDQgKi8NCiAgICAgICAgICAgICAgICB1dGY4 dG90YWwgPSA0Ow0KICAgICAgICAgICAgICAgIHVjczQgPSBjICYgMHgwMzsN CiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIGNvbnRpbnVlOw0KICAgICAg ICB9DQogICAgICAgIC8qIGxvb3AgdG8gc3BsaXQgdWNzNCBpbnRvIHR3byB1 dGYxNiBjaGFycyBpZiBuZWNlc3NhcnkgKi8NCiAgICAgICAgdXRmOHRvdGFs ID0gMDsNCiAgICAgICAgZG8gew0KICAgICAgICAgICAgaWYgKHVjczQgPiAw eGZmZmZVTCkgew0KICAgICAgICAgICAgICAgIGJpdGJ1ZiA9IChiaXRidWYg PDwgMTYpIHwgKCh1Y3M0ID4+IFVURjE2U0hJRlQpDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyBVVEYxNkhJR0hTVEFS VCk7DQogICAgICAgICAgICAgICAgdWNzNCA9ICh1Y3M0ICYgVVRGMTZNQVNL KSArIFVURjE2TE9TVEFSVDsNCiAgICAgICAgICAgICAgICB1dGYxNmZsYWcg PSAxOw0KICAgICAgICAgICAgfSBlbHNlIHsNCiAgICAgICAgICAgICAgICBi aXRidWYgPSAoYml0YnVmIDw8IDE2KSB8IHVjczQ7DQogICAgICAgICAgICAg ICAgdXRmMTZmbGFnID0gMDsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAg IGJpdHN0b2dvICs9IDE2Ow0KICAgICAgICAgICAgLyogc3BldyBvdXQgYmFz ZTY0ICovDQogICAgICAgICAgICB3aGlsZSAoYml0c3RvZ28gPj0gNikgew0K ICAgICAgICAgICAgICAgIGJpdHN0b2dvIC09IDY7DQogICAgICAgICAgICAg ICAgKmRzdCsrID0gYmFzZTY0Y2hhcnNbKGJpdHN0b2dvID8gKGJpdGJ1ZiA+ PiBiaXRzdG9nbykgOiBiaXRidWYpDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJiAweDNGXTsNCiAgICAgICAgICAgIH0NCiAgICAg ICAgfSB3aGlsZSAodXRmMTZmbGFnKTsNCiAgICB9DQogICAgLyogaWYgaW4g VVRGLTcgbW9kZSwgZmluaXNoIGluIEFTQ0lJICovDQogICAgaWYgKHV0Zjdt b2RlKSB7DQogICAgICAgIGlmIChiaXRzdG9nbykgew0KICAgICAgICAgICAg KmRzdCsrID0gYmFzZTY0Y2hhcnNbKGJpdGJ1ZiA8PCAoNiAtIGJpdHN0b2dv KSkgJiAweDNGXTsNCiAgICAgICAgfQ0KICAgICAgICAqZHN0KysgPSAnLSc7 DQogICAgfQ0KICAgIC8qIHRpZSBvZmYgc3RyaW5nICovDQogICAgKmRzdCA9 ICdcMCc7DQp9DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk5ld21hbiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KDQo= ---559023410-1297389768-862435041=:16628--   Received: from cnri by ietf.org id aa18001; 2 Apr 97 5:05 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa06086; 2 Apr 97 5:05 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id BAA18045; Wed, 2 Apr 1997 01:56:25 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA22742 for ; Wed, 2 Apr 1997 01:55:49 -0800 Received: from relay.olivettiricerca.it (relay.olivettiricerca.it [193.76.87.5]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA11299 for ; Wed, 2 Apr 1997 01:55:44 -0800 Received: from nevada.Ico.Olivetti.Com ([131.1.75.4]) by relay.olivettiricerca.it (Netscape Mail Server v2.01) with SMTP id AAA109 for <@relay.olivettiricerca.it:imap@u.washington.edu>; Wed, 2 Apr 1997 11:51:49 +0200 Received: from olivettiricerca.it by nevada.Ico.Olivetti.Com; Wed, 2 Apr 97 12:00:32 UTC Message-Id: <3.0.1.32.19970402115649.006962b0@nevada> Date: Wed, 02 Apr 1997 11:56:49 +0200 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: rdaddabbo@olivettiricerca.it To: imap@u.washington.edu >From: Rossana Daddabbo Subject: new mail notification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: daddabbo@nevada X-Mailer: Windows Eudora Light Version 3.0.1 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hello all! I'd like to know if there is a way for a user/application to be notified when new messages come in the mailboxes of an SMTP server. In other words, are there any MAPI functions or commands which can be used to provide notification about new mail and the users to whom these messages are addressed? Of course, I'd like to avoid to continuosly poll all the existing mailboxes, instead I'd like to use some suspensive command waiting for such a notification. ========================================================= Rossana Daddabbo Olivetti Ricerca SCpA Lab.R&D Reti Telematiche C.da "La Marchesa" - SS 271 Km. 8.680 70020 Bitritto (BA) - IT tel: +39 80 635.2102 fax: +39 80 635.2089 Email: rdaddabbo@olivettiricerca.it =========================================================   Received: from cnri by ietf.org id aa23909; 2 Apr 97 10:29 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa11770; 2 Apr 97 10:29 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id HAA25464; Wed, 2 Apr 1997 07:21:29 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA05426 for ; Wed, 2 Apr 1997 07:20:26 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA01233 for ; Wed, 2 Apr 1997 07:20:22 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Wed, 2 Apr 1997 10:19:37 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Wed, 2 Apr 1997 10:19:36 -0500 Message-Id: <3.0.32.19970402101705.0070cf60@lacroix.wildbear.on.ca> Date: Wed, 02 Apr 1997 10:17:06 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: rdaddabbo@olivettiricerca.it, imap@u.washington.edu Subject: Re: new mail notification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN At 11:56 AM 4/2/97 +0200, rdaddabbo@OlivettiRicerca.IT wrote: >Hello all! >I'd like to know if there is a way for a user/application to be notified >when new messages come in the mailboxes of an SMTP server. >In other words, are there any MAPI functions or commands which can be used >to provide notification about new mail and the users to whom these messages >are addressed? Of course, I'd like to avoid to continuosly poll all the >existing mailboxes, instead I'd like to use some suspensive command waiting >for such a notification. Um... you do realize this is for IMAP, right? IMAP has built in asynronous notification to take care of new messages. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa05769; 4 Apr 97 1:17 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa02307; 4 Apr 97 1:17 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id WAA13149; Thu, 3 Apr 1997 22:12:34 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA24692 for ; Thu, 3 Apr 1997 22:11:46 -0800 Received: from mail1.cern.ch (mail1.cern.ch [137.138.128.19]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id WAA14411 for ; Thu, 3 Apr 1997 22:11:44 -0800 Received: from hpplus10.cern.ch (hpplus10.cern.ch [137.138.129.105]) by mail1.cern.ch with SMTP id IAA08763 (8.8.5/IDA-1.6); Fri, 4 Apr 1997 08:11:33 +0200 (MET DST) Message-Id: Date: Fri, 4 Apr 1997 08:11:32 +0200 (METDST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Arnaud Taddei To: Jack De Winter Cc: rdaddabbo@olivettiricerca.it, imap@u.washington.edu Subject: Re: new mail notification In-Reply-To: <3.0.32.19970402101705.0070cf60@lacroix.wildbear.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: taddei@hpplus10.cern.ch X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Wed, 2 Apr 1997, Jack De Winter wrote: > At 11:56 AM 4/2/97 +0200, rdaddabbo@OlivettiRicerca.IT wrote: > >Hello all! > >I'd like to know if there is a way for a user/application to be notified > >when new messages come in the mailboxes of an SMTP server. > >In other words, are there any MAPI functions or commands which can be used > >to provide notification about new mail and the users to whom these messages > >are addressed? Of course, I'd like to avoid to continuosly poll all the > >existing mailboxes, instead I'd like to use some suspensive command waiting > >for such a notification. > > Um... you do realize this is for IMAP, right? IMAP has built in > asynronous notification to take care of new messages. Well, ok, but can you get the notification done on many folders? Which are the clients which are offering that? Can you have an utility which is doing the equivalent of xbiff? Could ACAP provide this _signalisation_ channel that we are missing? ----------------------------------------------------------- Arnaud Taddei tel: +41 22 767 9349 IT Division 513 1-019 fax: +41 22 767 7155 CERN mail: Arnaud.Taddei@cern.ch CH-1211 Geneve 23 URL: http://wwwcn.cern.ch/~taddei -----------------------------------------------------------   Received: from cnri by ietf.org id aa13325; 4 Apr 97 8:44 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa08787; 4 Apr 97 8:44 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id FAA02068; Fri, 4 Apr 1997 05:37:32 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA36888 for ; Fri, 4 Apr 1997 05:36:43 -0800 Received: from relay.olivettiricerca.it (relay.olivettiricerca.it [193.76.87.5]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id FAA13803 for ; Fri, 4 Apr 1997 05:36:40 -0800 Received: from nevada.Ico.Olivetti.Com ([131.1.75.4]) by relay.olivettiricerca.it (Netscape Mail Server v2.01) with SMTP id AAA166 for <@relay.olivettiricerca.it:imap@u.washington.edu>; Fri, 4 Apr 1997 15:31:56 +0200 Received: from olivettiricerca.it by nevada.Ico.Olivetti.Com; Fri, 4 Apr 97 15:41:13 UTC Message-Id: <3.0.1.32.19970404153746.006aaa34@nevada> Date: Fri, 04 Apr 1997 15:37:46 +0200 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: rdaddabbo@olivettiricerca.it To: imap@u.washington.edu >From: Rossana Daddabbo Subject: new mail notification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: daddabbo@nevada X-Mailer: Windows Eudora Light Version 3.0.1 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Thanks to all for your answers. I'll better explain my needs to get new mail notification. I should realise an agent, which should be running on a WinNT 3.51 system where an ISOCOR Internet Mailer (N-Plex 1.2) is running. This agent should be notified by the mail server: when new mail arrives in mailboxes (for one or more users) it should receive information about the subject, the receiver and sender, and few body lines of the messages. The notification mechanism should be quite similar to the behaviuor of the biff and comsat utilities, but it is strongly required that the agent does not poll the mailboxes on the server. Is there anything already implemented for WinNT to generate such kind a notification? Has anybody suggestions on how to proceede to realise this notification mechanism? Regards. ========================================================= Rossana Daddabbo Olivetti Ricerca SCpA Lab.R&D Reti Telematiche C.da "La Marchesa" - SS 271 Km. 8.680 70020 Bitritto (BA) - IT tel: +39 80 635.2102 fax: +39 80 635.2089 Email: rdaddabbo@olivettiricerca.it =========================================================   Received: from cnri by ietf.org id aa16216; 4 Apr 97 10:35 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa10973; 4 Apr 97 10:35 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id HAA26456; Fri, 4 Apr 1997 07:26:02 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA44934 for ; Fri, 4 Apr 1997 07:25:17 -0800 Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA13066 for ; Fri, 4 Apr 1997 07:25:11 -0800 Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 4 Apr 1997 10:24:11 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 4 Apr 1997 10:24:10 -0500 Message-Id: <3.0.32.19970404102149.006f75a4@lacroix.wildbear.on.ca> Date: Fri, 04 Apr 1997 10:21:51 -0500 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jack De Winter To: Arnaud Taddei Cc: rdaddabbo@olivettiricerca.it, imap@u.washington.edu Subject: Re: new mail notification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN >> >Hello all! >> >I'd like to know if there is a way for a user/application to be notified >> >when new messages come in the mailboxes of an SMTP server. >> >In other words, are there any MAPI functions or commands which can be used >> >to provide notification about new mail and the users to whom these messages >> >are addressed? Of course, I'd like to avoid to continuosly poll all the >> >existing mailboxes, instead I'd like to use some suspensive command waiting >> >for such a notification. >> >> Um... you do realize this is for IMAP, right? IMAP has built in >> asynronous notification to take care of new messages. >Well, ok, but can you get the notification done on many folders? Which are >the clients which are offering that? Can you have an utility which is >doing the equivalent of xbiff? Could ACAP provide this _signalisation_ >channel that we are missing? Um... at the risk of sounding nasty, could you please read the specification before asking such questions? You can get notification done on any open folders, and xbiff is not used as much, but there is cross session syncronization. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail for 95 & NT (http://www.seattlelab.com/)   Received: from cnri by ietf.org id aa16412; 4 Apr 97 10:47 EST Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa11253; 4 Apr 97 10:47 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id HAA07929; Fri, 4 Apr 1997 07:40:15 -0800 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA51098 for ; Fri, 4 Apr 1997 07:39:50 -0800 Received: from moss.verinet.com (moss.verinet.com [204.144.246.15]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id HAA11156 for ; Fri, 4 Apr 1997 07:39:47 -0800 Received: from bamboo.verinet.com (bamboo.verinet.com [204.144.246.3]) by moss.verinet.com (8.7.6/8.6.9) with ESMTP id IAA29132 for ; Fri, 4 Apr 1997 08:37:46 -0700 Received: from jon (ad32-156.compuserve.com [199.174.135.156]) by bamboo.verinet.com (8.8.5/8.7.1) with SMTP id IAA26164 for ; Fri, 4 Apr 1997 08:38:09 -0700 Message-Id: <33451E89.5200@Verinet.COM> Date: Fri, 04 Apr 1997 09:30:17 -0600 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Jon Nash To: imap@u.washington.edu Subject: IMAP Clients for Comp. Lab use? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hello, I have recently taken on the responsibility of creating a computer lab at a university in Mexico. There are no pre-existing networks or computer systems to speak of. I've searched the IMAP list archives for ideas but was unable to find the information I need. In many of the IMAP documents it is stated that IMAP is especially good for use in cases where people need to access their mail from different computers (a computer lab for example). What I need to find out is, what IMAP clients does one use (Win 3.11 and Win95) that will force the students to supply a login name and password before the client attempts to retrieve mail. I've looked at PC-Pine and Embla - both fine programs, but they seem to be designed in such a way that one configures them for a particular user and then saves the configuration. Is there a way that a student could sit down at a Win95 desktop, click on an "email" icon, be presented with a login/password screen, and after verification read his/her email? I know that I could also use a telnet session with the server (a Unix box in this case) and then make the student use pine. I would like to avoid this, however, since it places an unecessary load on the server and forces the students (95% of whom are currently computer illiterate) to use a GUI, in Englih, which isn't quite as slick as Embla, for example. I'm also aware that one could do something different, like use an NT box with M$ Exchange but I would prefer to use a cheaper, less commercial solution if possible. Can someone point me in a good directiion?! Thanks in advance, Dr. Jon Nash Universidad de Montemorelos, N.L. Mexico Jon@Verinet.COM   Received: from cnri by ietf.org id aa00420; 4 Apr 97 18:06 EST Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa20601; 4 Apr 97 18:06 EST Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA15723; Fri, 4 Apr 1997 14:08:25 -0800 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA36834 for ; Fri, 4 Apr 1997 14:08:05 -0800 Received: from mailhost2.cac.washington.edu (mailhost2.cac.washington.edu [140.142.33.2]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA18232 for ; Fri, 4 Apr 1997 14:08:04 -0800 Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.100.202]) by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA14715; Fri, 4 Apr 1997 14:07:58 -0800 Message-Id: Date: Fri, 4 Apr 1997 14:07:55 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: David L Miller To: Jon Nash Cc: imap@u.washington.edu Subject: Re: IMAP Clients for Comp. Lab use? In-Reply-To: <33451E89.5200@Verinet.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN PC-Pine can be used in the way you want. I've seen several approaches described, so you might want to ask on the comp.mail.pine newsgroup (aka pine-info@u.washington.edu) or look at the archives at http://www.washington.edu/pine/pine-info/ ftp://ftp.cac.washington.edu/pine/pine-info/ imap://anonymous@ftp.cac.washington.edu/pine/pine-info/ -- David L. Miller | Opportunities multiply as they are Software Engineer, Pine Development Team | seized. -- Sun Tzu Box 354841, University of Washington | 4545 15th Ave NE, Seattle WA 98105, USA | Phone: (206)685-6240 FAX: (206)685-4045 | On Fri, 4 Apr 1997, Jon Nash wrote: > I have recently taken on the responsibility of creating a computer lab > at a university in Mexico. There are no pre-existing networks or > computer systems to speak of. I've searched the IMAP list archives for > ideas but was unable to find the information I need. > > In many of the IMAP documents it is stated that IMAP is especially good > for use in cases where people need to access their mail from different > computers (a computer lab for example). What I need to find out is, > what IMAP clients does one use (Win 3.11 and Win95) that will force the > students to supply a login name and password before the client attempts > to retrieve mail. I've looked at PC-Pine and Embla - both fine > programs, but they seem to be designed in such a way that one configures > them for a particular user and then saves the configuration. > > Is there a way that a student could sit down at a Win95 desktop, click > on an "email" icon, be presented with a login/password screen, and after > verification read his/her email? > > I know that I could also use a telnet session with the server (a Unix > box in this case) and then make the student use pine. I would like to > avoid this, however, since it places an unecessary load on the server > and forces the students (95% of whom are currently computer illiterate) > to use a GUI, in Englih, which isn't quite as slick as Embla, for > example. > > I'm also aware that one could do something different, like use an NT box > with M$ Exchange but I would prefer to use a cheaper, less commercial > solution if possible. > > Can someone point me in a good directiion?! > > Thanks in advance, > > Dr. Jon Nash > Universidad de Montemorelos, N.L. Mexico > Jon@Verinet.COM >   Received: from cnri by ietf.org id aa11870; 6 Apr 97 5:46 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa04977; 6 Apr 97 5:46 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id BAA18467; Sun, 6 Apr 1997 01:42:14 -0800 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA06020 for ; Sun, 6 Apr 1997 01:38:12 -0800 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA09758 for ; Sun, 6 Apr 1997 01:38:09 -0800 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHD8V3LDRK99DJ6M@INNOSOFT.COM> for imap@u.washington.edu; Sun, 6 Apr 1997 01:37:08 PST Message-Id: Date: Sun, 06 Apr 1997 01:38:28 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: Arnaud Taddei Cc: imap@u.washington.edu Subject: Re: new mail notification In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Fri, 4 Apr 1997, Arnaud Taddei wrote: > Well, ok, but can you get the notification done on many folders? Which are > the clients which are offering that? Can you have an utility which is > doing the equivalent of xbiff? Could ACAP provide this _signalisation_ > channel that we are missing? The ACAP mailbox/folder list dataset class is intended for this purpose, with the goal of "one stop shopping" for notification of multiple incoming folders on potentially multiple IMAP servers.   Received: from cnri by ietf.org id aa11916; 6 Apr 97 5:50 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa05034; 6 Apr 97 5:50 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id BAA18609; Sun, 6 Apr 1997 01:47:09 -0800 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA39900 for ; Sun, 6 Apr 1997 01:40:07 -0800 Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id BAA04153 for ; Sun, 6 Apr 1997 01:40:06 -0800 Received: from eleanor.innosoft.com by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IHD8XIZ4MG99DJ6M@INNOSOFT.COM> for imap@u.washington.edu; Sun, 6 Apr 1997 01:39:05 PST Message-Id: Date: Sun, 06 Apr 1997 01:40:25 -0800 (PST) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Chris Newman To: Jon Nash Cc: imap@u.washington.edu Subject: Re: IMAP Clients for Comp. Lab use? In-Reply-To: <33451E89.5200@Verinet.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Unfortunately, IMSP/ACAP is needed in order to get the proper "lab" model of operation. The only client which supports IMSP is Simeon from ESYS. ACAP (IMSP v2) isn't finalized in the standards process yet. On Fri, 4 Apr 1997, Jon Nash wrote: > Hello, > > I have recently taken on the responsibility of creating a computer lab > at a university in Mexico. There are no pre-existing networks or > computer systems to speak of. I've searched the IMAP list archives for > ideas but was unable to find the information I need. > > In many of the IMAP documents it is stated that IMAP is especially good > for use in cases where people need to access their mail from different > computers (a computer lab for example). What I need to find out is, > what IMAP clients does one use (Win 3.11 and Win95) that will force the > students to supply a login name and password before the client attempts > to retrieve mail. I've looked at PC-Pine and Embla - both fine > programs, but they seem to be designed in such a way that one configures > them for a particular user and then saves the configuration. > > Is there a way that a student could sit down at a Win95 desktop, click > on an "email" icon, be presented with a login/password screen, and after > verification read his/her email? > > I know that I could also use a telnet session with the server (a Unix > box in this case) and then make the student use pine. I would like to > avoid this, however, since it places an unecessary load on the server > and forces the students (95% of whom are currently computer illiterate) > to use a GUI, in Englih, which isn't quite as slick as Embla, for > example. > > I'm also aware that one could do something different, like use an NT box > with M$ Exchange but I would prefer to use a cheaper, less commercial > solution if possible. > > Can someone point me in a good directiion?! > > Thanks in advance, > > Dr. Jon Nash > Universidad de Montemorelos, N.L. Mexico > Jon@Verinet.COM >   Received: from cnri by ietf.org id aa20599; 7 Apr 97 13:41 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa15428; 7 Apr 97 13:41 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA03284; Mon, 7 Apr 1997 10:31:06 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA22924 for ; Mon, 7 Apr 1997 10:29:07 -0700 Received: from gpu.utcc.utoronto.ca (gpu.utcc.utoronto.ca [128.100.102.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA12386 for ; Mon, 7 Apr 1997 10:29:03 -0700 Received: from localhost by gpu.utcc.utoronto.ca with SMTP id <336973>; Mon, 7 Apr 1997 13:28:53 -0400 Message-Id: Date: Mon, 7 Apr 1997 13:28:51 -0400 Reply-To: alex.nishri@utoronto.ca Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Alex Nishri To: Jon Nash Cc: imap@u.washington.edu Subject: Re: IMAP Clients for Comp. Lab use? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: nishri@gpu.utcc X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Depending what configuration information you want to centrally keep for each user, Simeon with IMSP might be the right answer. Another answer is to set up a LAN where each student has some disk space. After authenticating with the LAN OS, each student would be getting their own email package's configuration files and space to save working files. In a lab where we didn't want to run a LAN OS and needed to provide the Windows version of PC-Pine we have a simple solution. When students click on the Windows95 "Pine" icon, they are actually invoking a locally written short program. It puts up a dialog asking for their IMAP userid. With this userid it asks a server (10 lines of Perl code running a UNIX box we call the "pre-ACAP" server) for their configuration information. Using this information it builds a PINERC configuration file and invokes the real Pine. The next thing the student sees is a password prompt from the real Pine. (Students get no local storage to save files, address books, etc. in this heavily used lab.) Maybe someday Pine will support ACAP ... Alex Nishri Network Services University of Toronto alex.nishri@utoronto.ca -- Date: Sun, 6 Apr 1997 05:40:25 -0400 From: Chris Newman To: Jon Nash Cc: imap@u.washington.edu Subject: Re: IMAP Clients for Comp. Lab use? Unfortunately, IMSP/ACAP is needed in order to get the proper "lab" model of operation. The only client which supports IMSP is Simeon from ESYS. ACAP (IMSP v2) isn't finalized in the standards process yet. On Fri, 4 Apr 1997, Jon Nash wrote: > Hello, > > I have recently taken on the responsibility of creating a computer lab > at a university in Mexico. There are no pre-existing networks or > computer systems to speak of. I've searched the IMAP list archives for > ideas but was unable to find the information I need. > > In many of the IMAP documents it is stated that IMAP is especially good > for use in cases where people need to access their mail from different > computers (a computer lab for example). What I need to find out is, > what IMAP clients does one use (Win 3.11 and Win95) that will force the > students to supply a login name and password before the client attempts > to retrieve mail. I've looked at PC-Pine and Embla - both fine > programs, but they seem to be designed in such a way that one configures > them for a particular user and then saves the configuration. > > Is there a way that a student could sit down at a Win95 desktop, click > on an "email" icon, be presented with a login/password screen, and after > verification read his/her email? > > I know that I could also use a telnet session with the server (a Unix > box in this case) and then make the student use pine. I would like to > avoid this, however, since it places an unecessary load on the server > and forces the students (95% of whom are currently computer illiterate) > to use a GUI, in Englih, which isn't quite as slick as Embla, for > example. > > I'm also aware that one could do something different, like use an NT box > with M$ Exchange but I would prefer to use a cheaper, less commercial > solution if possible. > > Can someone point me in a good directiion?! > > Thanks in advance, > > Dr. Jon Nash > Universidad de Montemorelos, N.L. Mexico > Jon@Verinet.COM   Received: from cnri by ietf.org id aa00680; 7 Apr 97 21:09 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa28860; 7 Apr 97 21:09 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA12375; Mon, 7 Apr 1997 18:04:43 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA33830 for ; Mon, 7 Apr 1997 18:03:54 -0700 Received: from gpu.utcc.utoronto.ca (gpu.utcc.utoronto.ca [128.100.102.1]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA28983 for ; Mon, 7 Apr 1997 18:03:52 -0700 Received: from localhost by gpu.utcc.utoronto.ca with SMTP id <336744>; Mon, 7 Apr 1997 21:03:45 -0400 Message-Id: Date: Mon, 7 Apr 1997 21:03:42 -0400 Reply-To: alex.nishri@utoronto.ca Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Alex Nishri To: imap@u.washington.edu Subject: IMAP INBOX required? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sender: nishri@gpu.utcc X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN We have set up an IMAP server with just shared folders. (Individual inboxes are all on another IMAP server.) Yet the IMAP client and server pair we are using display in each user's folder list an INBOX folder on this shared folder IMAP server. I suspect this is in conformance with rfc2060 section 5.1 which says that the INBOX is the "primary mailbox for this user on this server"--although this is a clear case where there is no "primary" inbox for any user on this server. Since it is meaningless we would want no INBOX listed or accepted. Must every user have an INBOX on every IMAP server? Alex Nishri University of Toronto   Received: from cnri by ietf.org id aa22321; 8 Apr 97 11:53 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa15015; 8 Apr 97 11:53 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id IAA07279; Tue, 8 Apr 1997 08:48:47 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA39518 for ; Tue, 8 Apr 1997 08:47:22 -0700 Received: from river.tay.ac.uk (river.tay.ac.uk [193.60.160.99]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id IAA21708 for ; Tue, 8 Apr 1997 08:47:14 -0700 Received: from ZEUS.tay.ac.uk ("port 1333"@zeus.tay.ac.uk) by tay.ac.uk (PMDF V5.0-4 #15107) id <01IHGX3QWCOWECXTQ5@tay.ac.uk>; Tue, 08 Apr 1997 16:43:40 +0100 Message-Id: Date: Tue, 08 Apr 1997 17:43:40 +0100 (BST) Reply-To: g.gorrie@tay.ac.uk Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Graeme Gorrie To: imap@u.washington.edu, Jon Nash Subject: Re: IMAP Clients for Comp. Lab use? In-Reply-To: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-Sender: ccdggg@tay.ac.uk X-Mailer: Simeon for Win32 Version 4.1 Build (2) Evaluation X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hi, We are intending setting up all labs to use Simeon at our university. We run OpenVMS/PMDF mail and therefore have no IMSP/ACAP support. The labs will have Win95 machines that log on to a NT server. Each student will have an account on the server and an associated home directory. The home directory will be accessed via a virtual drive, i.e m:\ from the client PC. Simeon supports a command line option that allows the location of the personal configuration file to be defined. This will be used in the 'target' in a Win95 shortcut, specifying the configuration file on the home drive. Also, the virtual drive will be specified in the 'start in' box. Simeon will be installed locally. We've tested it and it seems to work fine. Hope this helps On Mon, 07 Apr 1997 13:28:51 -0400 Alex Nishri wrote: > Depending what configuration information you want to centrally keep for each > user, Simeon with IMSP might be the right answer. > > Another answer is to set up a LAN where each student has some disk space. > After authenticating with the LAN OS, each student would be getting their > own email package's configuration files and space to save working files. > > Alex Nishri > Network Services > University of Toronto > alex.nishri@utoronto.ca > > -- > Date: Sun, 6 Apr 1997 05:40:25 -0400 > From: Chris Newman > To: Jon Nash > Cc: imap@u.washington.edu > Subject: Re: IMAP Clients for Comp. Lab use? > > Unfortunately, IMSP/ACAP is needed in order to get the proper "lab" model > of operation. The only client which supports IMSP is Simeon from ESYS. > ACAP (IMSP v2) isn't finalized in the standards process yet. > > On Fri, 4 Apr 1997, Jon Nash wrote: > > > Hello, > > > > I have recently taken on the responsibility of creating a computer lab > > at a university in Mexico. There are no pre-existing networks or > > computer systems to speak of. I've searched the IMAP list archives for > > ideas but was unable to find the information I need. > > > > In many of the IMAP documents it is stated that IMAP is especially good > > for use in cases where people need to access their mail from different > > computers (a computer lab for example). What I need to find out is, > > what IMAP clients does one use (Win 3.11 and Win95) that will force the > > students to supply a login name and password before the client attempts > > to retrieve mail. I've looked at PC-Pine and Embla - both fine > > programs, but they seem to be designed in such a way that one configures > > them for a particular user and then saves the configuration. > > > > Is there a way that a student could sit down at a Win95 desktop, click > > on an "email" icon, be presented with a login/password screen, and after > > verification read his/her email? > > > > Can someone point me in a good directiion?! > > > > Thanks in advance, > > > > Dr. Jon Nash > > Universidad de Montemorelos, N.L. Mexico > > Jon@Verinet.COM > ---------------------- Graeme Gorrie IT Analyst University of Abertay Dundee Scotland g.gorrie@tay.ac.uk   Received: from cnri by ietf.org id aa17722; 16 Apr 97 16:06 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa20870; 16 Apr 97 16:06 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA01640; Wed, 16 Apr 1997 13:02:02 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA45258 for ; Wed, 16 Apr 1997 13:01:12 -0700 Received: from hanoi.software.com ([208.139.190.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA12029 for ; Wed, 16 Apr 1997 13:01:10 -0700 Received: from hanoi.software.com ([127.0.0.0]) by hanoi.software.com (Post.Office MTA v2.999 release 123 ID# 105-123L0S0) with SMTP id AAA15089 for ; Wed, 16 Apr 1997 12:58:14 -0700 Message-Id: <9704161258.ZM15087@hanoi.software.com> Date: Wed, 16 Apr 1997 12:58:13 -0700 Reply-To: Paul Falstad Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Paul Falstad To: imap@u.washington.edu Subject: nested encoding Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Shakespearean-Insult: Thou roguish tardy-gaited minnow! X-Mailer: Z-Mail (3.2.1 24feb96 Caldera) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I notice a few places in src/c-client/rfc822.c where logs a message saying "Ignoring nested encoding ..." This happens, say, when a message/rfc822 bodypart is encoded with, say, base64, which would make the job of parsing that bodypart much harder. Is this a bug that needs to be fixed? Or can encoded message/rfc822 body parts be safely left unparsed? It seems quite reasonable to me, but I couldn't find anything in the MIME RFC which disallows this. I'm trying to decide if we should go to the extra work of attempting to undo this encoding and parse the decoded bodypart. -- Paul Falstad Software.com, Inc. paul.falstad@software.com 805-957-1790 x520 http://www.ttinet.com/pjf/ http://www.software.com/ Besides the device, the box should contain: * Eight little rectangular snippets of paper that say "WARNING" * A plastic packet containing four 5/17 inch pilfer grommets and two club-ended 6/93 inch boxcar prawns. YOU WILL NEED TO SUPPLY: a matrix wrench and 60,000 feet of tram cable. IF ANYTHING IS DAMAGED OR MISSING: You IMMEDIATELY should turn to your spouse and say: "Margaret, you know why this country can't make a car that can get all the way through the drive-through at Burger King without a major transmission overhaul? Because nobody cares, that's why." WARNING: This is assuming your spouse's name is Margaret.   Received: from cnri by ietf.org id aa18646; 16 Apr 97 16:25 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa21372; 16 Apr 97 16:25 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA26668; Wed, 16 Apr 1997 13:22:06 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA40738 for ; Wed, 16 Apr 1997 13:21:14 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA07146 for ; Wed, 16 Apr 1997 13:21:12 -0700 Received: from POPDOG by doggate.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 292AC26Q; Wed, 16 Apr 1997 13:20:55 -0700 Received: from RAYCH.dns.microsoft.com by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 20SJ0J0N; Wed, 16 Apr 1997 13:20:43 -0700 Message-Id: <199704162021.NAA07146@mx5.u.washington.edu> Date: Wed, 16 Apr 1997 20:18:57 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Raymond Cheng To: IMAP Mailing List Subject: Internationalized Server Response Text? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook Express 4.71.0710.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0710.0 X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN I was wondering if any server vendors had any intention of producing any = localized versions of their servers. For instance, a Japanese IMAP = server might be expected to return Japanese response text. IMAP defines the use of UTF-7 to support international mailboxes. Has = there been any thought about using UTF-7 in response text to encode = international characters? Just wondering. Thanks! ...Cheng ----- Email: raych@microsoft.com Microsoft Outlook Express Developer My opinions are mine, all MINE!   Received: from cnri by ietf.org id aa19025; 16 Apr 97 16:33 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa21499; 16 Apr 97 16:33 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA27162; Wed, 16 Apr 1997 13:30:08 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA22422 for ; Wed, 16 Apr 1997 13:29:29 -0700 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA15196 for ; Wed, 16 Apr 1997 13:29:27 -0700 Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.2/8.8.2/MOON) with ESMTP id NAA29999; Wed, 16 Apr 1997 13:29:27 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.7.6/8.7.3) id NAA21439; Wed, 16 Apr 1997 13:29:15 -0700 Message-Id: <970416132915.ZM21438@candle.brasslantern.com> Date: Wed, 16 Apr 1997 13:29:15 -0700 Reply-To: schaefer@nbn.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bart Schaefer To: Paul Falstad , imap@u.washington.edu Subject: Re: nested encoding In-Reply-To: "Paul Falstad" "nested encoding" (Apr 16, 12:58pm) References: <9704161258.ZM15087@hanoi.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.820 20aug96) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Apr 16, 12:58pm, Paul Falstad wrote: } Subject: nested encoding } } I notice a few places in src/c-client/rfc822.c where logs a message } saying "Ignoring nested encoding ..." This happens, say, when a } message/rfc822 bodypart is encoded with, say, base64, which would } make the job of parsing that bodypart much harder. } } Is this a bug that needs to be fixed? Or can encoded message/rfc822 } body parts be safely left unparsed? It seems quite reasonable to me, } but I couldn't find anything in the MIME RFC which disallows this. RFC2046, section 5.2.1. RFC822 Subtype, says: No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. If you're receiving messages containing encoded message/rfc822 entities, then the sending agent is acting improperly. You can refuse to undo the extra level of encoding if your customers let you get away with it. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern   Received: from cnri by ietf.org id aa19272; 16 Apr 97 16:39 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa21584; 16 Apr 97 16:39 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id NAA03685; Wed, 16 Apr 1997 13:36:17 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA35572 for ; Wed, 16 Apr 1997 13:35:47 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id NAA21954 for ; Wed, 16 Apr 1997 13:35:45 -0700 Received: from Ikkoku-Kan.Panda.COM (nightowl@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id NAA21385; Wed, 16 Apr 1997 13:35:42 -0700 (PDT) Received: from localhost (nark@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id NAA07477; Wed, 16 Apr 1997 13:35:36 -0700 (PDT) Message-Id: Date: Wed, 16 Apr 1997 13:26:34 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: Raymond Cheng Cc: IMAP Mailing List Subject: re: Internationalized Server Response Text? In-Reply-To: <199704162021.NAA07146@mx5.u.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Wed, 16 Apr 1997 20:18:57 -0700, Raymond Cheng wrote: > I was wondering if any server vendors had any intention of producing any > localized versions of their servers. For instance, a Japanese IMAP server > might be expected to return Japanese response text. There has been some talk about localization. However, as has been pointed by many people many times, the proper order is to do internationalization first, then localization, and then finally multi-lingualization. We're still working on deploying the existing internationalization solutions that IMAP defines. I hope to have international SEARCH and SORT in the version that ships with Pine 4.00 (it's not there yet). There's a *lot* of work still needed to do this right (anyone have tables for GB, KSC, and CNS to UNICODE?). This doesn't mean that localization is unimportant. It's just that things should be done in correct order, otherwise you destroy interoperability. Doing a localization without a proper internationalization framework in place leads to problems if, for example, a Japanese client talks to a Korean server. Also, some normal localization tasks shouldn't be done in IMAP. For example, internaldates should not be localized, since their syntax is defined by the protocol and they're intended to be machine-readable. > IMAP defines the use of UTF-7 to support international mailboxes. Has there > been any thought about using UTF-7 in response text to encode international > characters? Just wondering. Thanks! Yes, there has been. But no specification has been written up yet, primarily because there have been more important internationalization tasks to do first. The basic notion is a LANGUAGE capability and command to set the language for the "human-readable" text in responses. So you can get your computerese gobbletygook such as "lock when already locked" in Japanese computerese gobbletygook instead of English computerese gobbletygook. But many clients consider that those messages are gobbletygook, and generally don't show messages that aren't ALERTs to the human user anyway.   Received: from cnri by ietf.org id aa20866; 16 Apr 97 17:16 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa22485; 16 Apr 97 17:16 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA47502; Wed, 16 Apr 1997 14:12:41 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA41666 for ; Wed, 16 Apr 1997 14:11:52 -0700 Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA13045 for ; Wed, 16 Apr 1997 14:11:47 -0700 Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA25826; Wed, 16 Apr 1997 14:11:45 -0700 Received: from shorter.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA24887; Wed, 16 Apr 1997 14:11:42 -0700 Received: from rita.eng.sun.com by shorter.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21138; Wed, 16 Apr 1997 14:11:43 -0700 Received: from cochin by rita.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04684; Wed, 16 Apr 1997 14:11:41 -0700 Message-Id: Date: Wed, 16 Apr 1997 14:11:42 -0700 (PDT) Reply-To: John Mani Sender: IMAP-owner@u.washington.edu Precedence: bulk From: John Mani To: MRC@cac.washington.edu Cc: imap@u.washington.edu Subject: re: Internationalized Server Response Text? MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aF7hQAVyiUETGCG9O5OzZw== X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN > > We're still working on deploying the existing internationalization solutions > that IMAP defines. I hope to have international SEARCH and SORT in the Is this server side SORT - thru a protocol xtension ? Is there a draft on this ? thanx -john   Received: from cnri by ietf.org id aa21397; 16 Apr 97 17:27 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa22791; 16 Apr 97 17:27 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA00967; Wed, 16 Apr 1997 14:22:55 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA42818 for ; Wed, 16 Apr 1997 14:22:10 -0700 Received: from dpw.meitca.com (dpw.meitca.com [137.203.10.23]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA27044 for ; Wed, 16 Apr 1997 14:22:08 -0700 Received: from [137.203.8.102] (psycho.meitca.com [137.203.8.102]) by dpw.meitca.com (8.7.1/8.7.1) with SMTP id RAA00443 for ; Wed, 16 Apr 1997 17:22:04 -0400 (EDT) Message-Id: Date: Wed, 16 Apr 1997 17:20:17 -0500 Reply-To: andy@hsl.meitca.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Andrew McCown To: IMAP Mailing List Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Wed, 16 Apr 1997 13:26:34 -0700 (PDT) MRC@CAC.Washington.EDU (Mark Crispin) wrote: >The basic notion is a LANGUAGE capability and command to set the language for >the "human-readable" text in responses. So you can get your computerese >gobbletygook such as "lock when already locked" in Japanese computerese >gobbletygook instead of English computerese gobbletygook. But many clients >consider that those messages are gobbletygook, and generally don't show >messages that aren't ALERTs to the human user anyway. I have a draft for that extension that should be hitting the list within the next few days - just need to clean up a couple of things in it. Andy   Received: from cnri by ietf.org id aa22691; 16 Apr 97 17:48 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa23454; 16 Apr 97 17:48 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id OAA02488; Wed, 16 Apr 1997 14:44:39 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA20996 for ; Wed, 16 Apr 1997 14:44:18 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id OAA24107 for ; Wed, 16 Apr 1997 14:44:11 -0700 Received: from Ikkoku-Kan.Panda.COM (pth@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id OAA21464; Wed, 16 Apr 1997 14:44:07 -0700 (PDT) Received: from localhost (pra@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id OAA08154; Wed, 16 Apr 1997 14:44:03 -0700 (PDT) Message-Id: Date: Wed, 16 Apr 1997 14:33:10 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: John Mani Cc: imap@u.washington.edu Subject: re: Internationalized Server Response Text? In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Wed, 16 Apr 1997 14:11:42 -0700 (PDT), John Mani wrote: > Is this server side SORT - thru a protocol xtension ? Is there a > draft on this ? Yes, and no. My original design (which was done as a gedanken exercise) had flaws. It's being redone (it's #2 on my project list right now), and this time there will be code to implement it before the draft comes out. That way the design will be working (like most of IMAP) instead of non-working bad ideas (such as the late unlamented PARTIAL command). Of course, that doesn't guarantee that it isn't a bad idea, but at least it'll be a working bad idea... ;-)   Received: from cnri by ietf.org id aa02916; 17 Apr 97 21:18 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa25697; 17 Apr 97 21:18 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA48134; Thu, 17 Apr 1997 18:15:36 -0700 Received: from mx4.u.washington.edu (mx4.u.washington.edu [140.142.33.5]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA17622 for ; Thu, 17 Apr 1997 18:14:49 -0700 Received: from moon.nbn.com (moon.nbn.com [199.4.65.1]) by mx4.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA09764 for ; Thu, 17 Apr 1997 18:14:47 -0700 Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by moon.nbn.com (8.8.2/8.8.2/MOON) with ESMTP id SAA21745 for ; Thu, 17 Apr 1997 18:14:48 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.7.6/8.7.3) id SAA25374 for imap@u.washington.edu; Thu, 17 Apr 1997 18:14:35 -0700 Message-Id: <970417181434.ZM25373@candle.brasslantern.com> Date: Thu, 17 Apr 1997 18:14:34 -0700 Reply-To: schaefer@nbn.com Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Bart Schaefer To: imap@u.washington.edu Subject: RFC2060: Bad example in 6.4.6. STORE Command MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Z-Mail (4.0b.820 20aug96) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN This: Example: C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH FLAGS (\Deleted \Seen) S: * 3 FETCH FLAGS (\Deleted) S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) S: A003 OK STORE completed Should read: Example: C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH (FLAGS (\Deleted \Seen)) S: * 3 FETCH (FLAGS (\Deleted)) S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) S: A003 OK STORE completed -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.nbn.com/people/lantern   Received: from cnri by ietf.org id aa03132; 17 Apr 97 21:32 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa25914; 17 Apr 97 21:32 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA21968; Thu, 17 Apr 1997 18:29:02 -0700 Received: from mx2.u.washington.edu (mx2.u.washington.edu [140.142.32.7]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA48130 for ; Thu, 17 Apr 1997 18:28:39 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) by mx2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA07002 for ; Thu, 17 Apr 1997 18:28:38 -0700 Received: from Ikkoku-Kan.Panda.COM (jim@UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id SAA24578; Thu, 17 Apr 1997 18:28:35 -0700 (PDT) Received: from localhost (jesus@localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id SAA13274; Thu, 17 Apr 1997 18:28:31 -0700 (PDT) Message-Id: Date: Thu, 17 Apr 1997 18:28:09 -0700 (PDT) Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Mark Crispin To: schaefer@nbn.com Cc: imap@u.washington.edu Subject: re: RFC2060: Bad example in 6.4.6. STORE Command In-Reply-To: <970417181434.ZM25373@candle.brasslantern.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sender: Mark Crispin X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN This was already discovered. It's item #3 in ftp://ftp.cac.washington.edu/mail/rfc2060-errata   Received: from cnri by ietf.org id aa03408; 17 Apr 97 21:52 EDT Received: from lists2.u.washington.edu by CNRI.Reston.VA.US id aa26243; 17 Apr 97 21:52 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA18519; Thu, 17 Apr 1997 18:48:49 -0700 Received: from mx3.u.washington.edu (mx3.u.washington.edu [140.142.13.230]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id SAA26552 for ; Thu, 17 Apr 1997 18:48:32 -0700 Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mx3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id SAA22185 for ; Thu, 17 Apr 1997 18:48:30 -0700 Received: by DOGGATE with Internet Mail Service (5.0.1457.3) id <292ADHG8>; Thu, 17 Apr 1997 18:48:27 -0700 Message-Id: Date: Thu, 17 Apr 1997 18:48:24 -0700 Sender: IMAP-owner@u.washington.edu Precedence: bulk From: "Larry Osterman (Exchange)" To: schaefer@nbn.com, 'Mark Crispin' Cc: imap@u.washington.edu Subject: RE: RFC2060: Bad example in 6.4.6. STORE Command MIME-Version: 1.0 Content-Type: text/plain X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN While we're on the subject of errata, I noticed that the grammer for STORE has: store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT]) SPACE (flag_list / #flag) The issue is the "#flag". I'd think that it should be simply "flag". I recognize that this is NOT an errata, however I talked to JGM at the IETF, and he was unable to come up with a reason for this - it's been in the grammer since 1730, so this is clearly NOT a bug, I'm just wondering what the history is..... Larry Osterman Via Exchange Osmium on Lothair with NT 4.0. Since these are not all released products, please notify the sender of any difficulties. > ---------- > From: Mark Crispin[SMTP:MRC@Panda.COM] > Sent: Thursday, April 17, 1997 6:28 PM > To: schaefer@nbn.com > Cc: imap@u.washington.edu > Subject: re: RFC2060: Bad example in 6.4.6. STORE Command > > This was already discovered. It's item #3 in > ftp://ftp.cac.washington.edu/mail/rfc2060-errata >   Received: from cnri by ietf.org id aa21123; 21 Apr 97 14:00 EDT Received: from lists.u.washington.edu by CNRI.Reston.VA.US id aa13807; 21 Apr 97 14:00 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA41966; Mon, 21 Apr 1997 10:51:59 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id KAA38408 for ; Mon, 21 Apr 1997 10:51:32 -0700 Received: from service.esys.ca (service.esys.ca [141.118.1.124]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id KAA15315 for ; Mon, 21 Apr 1997 10:51:30 -0700 Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0wJNIK-000UnmC; Mon, 21 Apr 97 11:54 MDT Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wJNHd-000Ra7C; Mon, 21 Apr 97 11:53 MDT Message-Id: Date: Mon, 21 Apr 1997 11:51:46 -0600 (MDT) Reply-To: Steve Hole Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Steve Hole To: Mark Crispin Cc: Raymond Cheng , IMAP Mailing List Subject: re: Internationalized Server Response Text? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailer: Simeon for Win32 Version 4.1.1b3 Build (8) X-Authentication: none X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN On Wed, 16 Apr 1997 13:26:34 -0700 (PDT) Mark Crispin wrote: > There's a *lot* of > work still needed to do this right (anyone have tables for GB, KSC, and CNS to > UNICODE?). I got a set of 1.1 tables from the UNICODE consortium home page Mark. Note that some of the KSC mapping code points have reportedly changed in in UNICODE version 2.0. I was unable to get anyone at UNICODE to tell me whether or not the mapping table is affected or not. Cheers. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6   Received: from cnri by ietf.org id aa14321; 26 Apr 97 4:00 EDT Received: from lists3.u.washington.edu by CNRI.Reston.VA.US id aa04277; 26 Apr 97 4:00 EDT Received: from host (lists.u.washington.edu [140.142.56.13]) by lists3.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id AAA07560; Sat, 26 Apr 1997 00:53:34 -0700 Received: from mx5.u.washington.edu (mx5.u.washington.edu [140.142.32.6]) by lists.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with ESMTP id AAA44378 for ; Sat, 26 Apr 1997 00:11:49 -0700 Received: from unifix.ava.taby.se (unifix.ava.taby.se [194.237.76.2]) by mx5.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id AAA11189 for ; Sat, 26 Apr 1997 00:11:46 -0700 Received: from mail.ava.taby.se (194.237.76.4) by unifix.ava.taby.se (EMWAC SMTPRS 0.81) with SMTP id ; Sat, 26 Apr 1997 09:11:53 +0200 Received: from MEGAFIX/SpoolDir by mail.ava.taby.se (Mercury 1.31); 26 Apr 97 09:11:55 GMT +0100 Received: from SpoolDir by MEGAFIX (Mercury 1.31); 26 Apr 97 09:11:26 GMT +0100 Received: from unihome by mail.ava.taby.se (Mercury 1.31); 26 Apr 97 09:11:18 GMT +0100 Message-Id: <3361A918.2F83@ava.taby.se> Date: Sat, 26 Apr 1997 09:04:56 +0200 Reply-To: shi@ava.taby.se Sender: IMAP-owner@u.washington.edu Precedence: bulk From: Shi Chen To: imap@u.washington.edu Subject: Shadow support? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (Win95; I) X-Listprocessor-Version: 8.1 beta -- ListProcessor(tm) by CREN Hello:-) I kind new on useing IMAP4...i wander if IMAP4rev1 support shadow? -- _\|/_ Shi Chen < mailto:shi@ava.taby.se > (o o) WWWurl: < http://www.ava.taby.se > ---oOO-(_)-OOo------------------------------------------------------ ALL RIGHT. I admit I have stolen this, and so what:-)