From c-client-request@cac.washington.edu Mon Aug 31 22:03:16 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19927; Mon, 31 Aug 92 22:03:16 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21670; Mon, 31 Aug 92 22:03:15 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21664; Mon, 31 Aug 92 22:03:14 -0700 Date: Mon, 31 Aug 1992 21:47:56 -0700 (PDT) From: Mark Crispin Subject: welcome to the c-client interest list To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello. If you received this message, you are on the c-client interest list at the University of Washington. The purpose of this list is for discussion and announcements related to the c-client library for mail software. You are on this list because at some point in the past you expressed an interest in this topic. It is intended that this list be of a low-volume, high-signal, and technical nature. To post mail to this list, send mail to: c-client@CAC.Washington.EDU To request addition/deletions to the list, send mail to: c-client-request@CAC.Washington.EDU Related mailing lists which may be of interest: IMAP@CAC.Washington.EDU IMAP protocol pine-info@CAC.Washington.EDU Pine mail UA information ECS-info@EDM.ISAC.CA ECS (Windows IMAP client) information Regards, Mark Crispin Networks and Distributed Computing University of Washington From c-client-request@cac.washington.edu Tue Sep 1 05:15:17 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26528; Tue, 1 Sep 92 05:15:17 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23717; Tue, 1 Sep 92 05:15:16 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay1.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23711; Tue, 1 Sep 92 05:15:14 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18837; Tue, 1 Sep 92 08:15:13 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 081349.23280; Tue, 1 Sep 1992 08:13:49 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA09174; Tue, 1 Sep 92 14:54:28 IDT Received: by xenia.bwc.org (4.1/SMI-4.1) id AA04763; Tue, 1 Sep 92 14:56:08 IDT Date: Tue, 1 Sep 1992 14:14:05 +0300 (IDT) From: Laurence Lundblade Subject: Hostnames for hostless addresses To: C-Client Mailing List Cc: Bob Gregory Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm looking for a way to tell the c-client what address to use when qualifying domainless addresses. Right now it use the result of gethostbyname (the /etc/hosts, YP and DNS lookup). This results in an address with a hostname in it, where it might be better not to have one. Also, one can't always control what the hostname is set too. I realize that it would be best to have the addresses in the mail files fully qualified, but that isn't possible in this case. Could either an argument be added to mail_open, or a mail_setdomain() call be added to set the domain name so the calling program could control this? Then for example in Pine, all the domain names would be consistent. Thanks... Laurence Lundblade 206-543-5617 lgl@cac.washington.edu Computing and Communications, University of Washington, Seattle (Temporarily abroad till Sept 19; reply to lgl@cac.washington.edu) From c-client-request@cac.washington.edu Tue Sep 8 01:14:28 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04850; Tue, 8 Sep 92 01:14:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25077; Tue, 8 Sep 92 01:14:16 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay2.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25071; Tue, 8 Sep 92 01:14:15 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26974; Tue, 8 Sep 92 04:14:14 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 041358.9727; Tue, 8 Sep 1992 04:13:58 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA06945; Tue, 8 Sep 92 10:13:09 IST Received: by xenia.bwc.org (4.1/SMI-4.1) id AA12745; Tue, 8 Sep 92 10:14:55 IST Date: Tue, 8 Sep 1992 10:02:39 +0200 (IST) From: Laurence Lundblade Subject: mail_append() To: C-Client Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm starting to work on mail_append() for the c-client driver I'm writing here. Don't quite know who all's on this list so I'll mention that this corresponds the the APPEND command in an upcoming version of IMAP2bis. What I'm trying to figure out is how to decide what driver to call. Mail_append() is a bit of a new thing in that it is not an operation on an already open mailbox, the format of which known, and therefor the driver is known. I'm planning on passing mail_append the mailbox name and a string which contains the RFC-822 message. Seems like the choices are: - Just pass it the mailbox name and the message and let it decide on the format of the mailbox either based on a default, or based on the format of the existing mailbox if it exists. Would have to default if it didn't exist. - Pass it a stream of some other open mailbox to serve to indicate the format of the mailbox. - Some other way, indicate the format of the mailbox I'll probably pick #2 for now since it's easy and there's not much code involved in any of these options. I'm mainly sending this message to see if anyone has any immediate ideas or plans. Thanks, LL From c-client-request@cac.washington.edu Tue Sep 8 10:55:54 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13530; Tue, 8 Sep 92 10:55:54 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29411; Tue, 8 Sep 92 10:55:39 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29405; Tue, 8 Sep 92 10:55:38 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA12584; Tue, 8 Sep 92 10:50:32 PDT Date: Tue, 8 Sep 1992 10:56:00 PDT From: Bill Yeager Subject: Re: mail_append() To: Laurence Lundblade Cc: C-Client Mailing List In-Reply-To: Your message of Tue, 8 Sep 1992 10:02:39 +0200 (IST) Message-Id: >> - Pass it a stream of some other open mailbox to serve to indicate the format of the mailbox. I think this can be somewhat subtle. 1. If the mailbox to which one is appending exists, then the driver can be automatically decided by the mailbox type of this mailbox. 2. If it doesn't exist, then if the mailbox type of INBOX is known, I imagine a user would like to have that format for append. I certainly would, even if I often open mailboxes of a different mailbox type. I, for example, use tenex format for the majority of my messages, but often read bezerkly mailboxes. I'd want my backing-store of saved messages to be in tenex format(*). 3. If INBOX format isn't known, then your plan above makes sense. The question I have is: What does append mean if a user's INBOX mailbox type is mh mode? Does one create a subdirectory in the Mail/ folder called Append/ and then iterate by message number as is done in mh mode? Bill (*) The intention all along with IMAP was that the user should never have to worry about the format of mail on the repository, but this hasn't worked out because people often connect directly to this system to read their mail from home. This mode of operation will persist until most users have network connections to their homes which I think is still in the near-distant future. So, I guess it is necessary to be able to accomodate all of these formats. ------- From c-client-request@cac.washington.edu Wed Sep 9 09:56:30 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05868; Wed, 9 Sep 92 09:56:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10250; Wed, 9 Sep 92 09:55:26 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10244; Wed, 9 Sep 92 09:55:19 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA00591; Wed, 9 Sep 92 09:55:10 PDT Date: Wed, 9 Sep 1992 09:49:50 -0700 (PDT) From: Mark Crispin Subject: re: mail_append() To: Laurence Lundblade Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Laurence - I have already decided to add a `driver type' string to the driver dispatch table, and make those functions which create a mailbox use that. In the case of an existing mailbox, it should use the format of that mailbox. I haven't gotten around to it yet because I've been tied up with lots of other stuff. -- Mark -- From c-client-request@cac.washington.edu Thu Sep 10 05:43:29 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19470; Thu, 10 Sep 92 05:43:29 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19303; Thu, 10 Sep 92 05:43:22 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay1.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19297; Thu, 10 Sep 92 05:43:20 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29215; Thu, 10 Sep 92 08:43:16 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 084223.9412; Thu, 10 Sep 1992 08:42:23 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA10715; Thu, 10 Sep 92 14:39:20 IST Received: by xenia.bwc.org (4.1/SMI-4.1) id AA16311; Thu, 10 Sep 92 14:41:08 IST Date: Thu, 10 Sep 1992 14:30:54 +0200 (IST) From: Laurence Lundblade Subject: re: mail_append() To: Mark Crispin Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mark, I don't quite know what you mean. Are you adding the "driver type" to each entry in the dispatch table (the "DRIVER" defined in mail.h) or are you adding on type to the whole dispatch table to act as a default type. I've thought about this a little bit and concluded that we don't really have to support multiple different mail formats for mail_find(), mail_append() and such since 99% of all users will only have mail in one format. I know we all enjoy a challenge, but it seems a reasonable simplification to support one driver at a time for the active mail, and other drivers in case the fellow wants to occasionally browse a mailbox in some other format. Phrased another way, it seems much more important to get things like net news, subscribe/unsubscribe, fancy searching, and append running than it does to support some fellow who wants to have his mail in three different formats and operate freely between them because the searching and news are what the users will care about. Based on this I suggest that mail_append(), mail_find(), mail_rename(), mail_delete() and mail_create() only operate on the first driver that is lunk in with mail_link(). Seems it will make our lives much easier. LL On Wed, 9 Sep 1992, Mark Crispin wrote: > > Laurence - > > I have already decided to add a `driver type' string to the driver > dispatch table, and make those functions which create a mailbox use that. In > the case of an existing mailbox, it should use the format of that mailbox. > > I haven't gotten around to it yet because I've been tied up with lots of > other stuff. > > -- Mark -- > From c-client-request@cac.washington.edu Thu Sep 10 10:20:51 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24578; Thu, 10 Sep 92 10:20:51 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21840; Thu, 10 Sep 92 10:20:36 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21834; Thu, 10 Sep 92 10:20:35 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA25837; Thu, 10 Sep 92 10:08:59 PDT Date: Thu, 10 Sep 1992 10:14:32 PDT From: Bill Yeager Subject: re: mail_append() To: Laurence Lundblade Cc: Mark Crispin , C-Client Mailing List In-Reply-To: Your message of Thu, 10 Sep 1992 14:30:54 +0200 Message-Id: >> Based on this I suggest that mail_append(), mail_find(), mail_rename(), mail_delete() and mail_create() only operate on the first driver that is lunk in with mail_link(). Seems it will make our lives much easier. Seems a little strange to me that which mail box format is chosen is a function of the hardcoded sequence of calls to mail_link() from imapd.c. That certainly would not work here where we have: mail_link (&tenexdriver); /* install the Tenex mail driver */ mail_link (&mboxdriver); /* install the mbox driver - wjy 17 Aout 92*/ mail_link (&bezerkdriver); /* install the Berkeley mail driver */ And, most people use tenex format by others also use the other two formats. Maybe you don't mean hard linked in the code, but perhaps the first driver loaded in mail_open() as the "factory?" I don't think either of these choices are good solutions in environments where multiple mailbox formats are supported. Bill ------- From c-client-request@cac.washington.edu Thu Sep 10 10:30:36 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24786; Thu, 10 Sep 92 10:30:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21942; Thu, 10 Sep 92 10:30:33 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21936; Thu, 10 Sep 92 10:30:23 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA00471; Thu, 10 Sep 92 10:30:17 PDT Date: Thu, 10 Sep 1992 10:27:09 -0700 (PDT) From: Mark Crispin Subject: re: mail_append() To: Laurence Lundblade Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Laurence - The `driver type' will be a string in the dispatch table, a single entry such as "mbox", etc. So you can get a `name' of the type of mailbox. The idea then is that you can do something like: mail_create (name,"tenex"); Of course, there *will* be defaulting. I haven't thought all of this through since, as you noted, there are other things that are much higher on the queue to do. -- Mark -- From c-client-request@cac.washington.edu Fri Sep 11 11:49:46 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16287; Fri, 11 Sep 92 11:49:46 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04382; Fri, 11 Sep 92 11:49:27 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from relay2.UU.NET by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04376; Fri, 11 Sep 92 11:49:17 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08605; Fri, 11 Sep 92 14:48:48 -0400 Received: from bwc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 144358.10763; Fri, 11 Sep 1992 14:43:58 EDT Received: from xenia.bwc.org by bwc.org (4.1/SMI-4.1) id AA12557; Fri, 11 Sep 92 20:27:18 IST Received: by xenia.bwc.org (4.1/SMI-4.1) id AA18016; Fri, 11 Sep 92 20:29:09 IST Date: Fri, 11 Sep 1992 20:22:37 +0200 (IST) From: Laurence Lundblade Subject: re: mail_append() To: Mark Crispin Cc: C-Client Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sounds great Mark! It give us the option to do what we want. I was worried about things like the ambiguity of mailboxes of the same name in different formats and naming mailboxes in formats like mh where the the mailbox isn't a particular file. This sounds like it will take care of things just fine. Bill, What I was thinking about the mail_link() calls, was that you have control at run time as to which driver you link first. You could have command line flags that cause the drivers to be linked in various orders, though it's true that you'll only get to create, delete and append for that one driver. Mark's solution is much better. LL On Thu, 10 Sep 1992, Mark Crispin wrote: > > Laurence - > > The `driver type' will be a string in the dispatch table, a single entry > such as "mbox", etc. So you can get a `name' of the type of mailbox. The > idea then is that you can do something like: > mail_create (name,"tenex"); > > Of course, there *will* be defaulting. I haven't thought all of this > through since, as you noted, there are other things that are much higher on > the queue to do. > > -- Mark -- > From c-client-request@cac.washington.edu Fri Sep 11 14:13:18 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19443; Fri, 11 Sep 92 14:13:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05995; Fri, 11 Sep 92 14:13:14 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05989; Fri, 11 Sep 92 14:13:12 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA14828; Fri, 11 Sep 92 13:57:37 PDT Date: Fri, 11 Sep 1992 14:03:13 PDT From: Bill Yeager Subject: re: mail_append() To: Laurence Lundblade Cc: Mark Crispin , C-Client Mailing List In-Reply-To: Your message of Fri, 11 Sep 1992 20:22:37 +0200 Message-Id: Laurence, Thanks for the clarification. I too agree with Mark's approach with appropriate defaulting for environments like ours where different users have different default INBOX types. Bill ------- From c-client-request@cac.washington.edu Wed Sep 23 12:05:47 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01930; Wed, 23 Sep 92 12:05:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25618; Wed, 23 Sep 92 12:03:30 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from olive.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25612; Wed, 23 Sep 92 12:03:29 -0700 Received: by olive.cac.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.21 ) id AA07372; Wed, 23 Sep 92 11:59:38 PDT Date: Wed, 23 Sep 1992 11:50:12 -0700 (PDT) From: Laurence Lundblade Subject: Re: Domain names (fwd) To: c-client@cac.washington.edu Cc: Bob Gregory Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A while ago I indicated that it would be nice if you could set the mail domain the c-client uses for parsing unqaulified addresses. Here's some other folks that would like to see it happen. I suppose we could be pedegogical and say no to encourage people to fully qualify addresses, but sendmail configuration is difficult and I don't know if this is a battle worth fighting. I think this would also make Pine a little more self consistent. LL ---------- Forwarded message ---------- Date: Wed, 23 Sep 1992 17:13:40 +0100 (BST) From: Laurie Cuthbert To: Philip Hazel Cc: pine-info@cac.washington.edu Subject: Re: Domain names Yes - it does do this and at first we thought, like you, that it would be a major problem. However, we have decided that pine is so worth using that we changed the sendmail configuration to add the local domain name to all mail, irrespective of the MUA being used. Presumably you are using the UK sendmail configuration version 2.1 - if so there is a parameter that turns on or off the local channel domain stamping. In fact it proved to have an added benefit for us becuase we use departmental domains internally, but only the site domain for external messages, with PP massaging the name fields. By ensuring that the domain name is ALWAYS stamped PP will correctly massage all fields, including local CC fields. Regards Laurie Cuthbert On Wed, 23 Sep 1992, Philip Hazel wrote: > I've had to back off using Pine for the moment, because of the problem > described below. Luckily, I was just experimenting with it. Any ideas as > to how to get round it, apart from hacking the code? > > I have > > # Domain name you are in e.g. nwnet.net, cac.washington.edu, bwc.org > user-domain=cus.cam.ac.uk > > # Eliminate host part from hostname, using only domain part for domain name > use-only-domain-name=yes > > and for all the mail I send out, this works fine. Unqualified names end up > as "name@cus.cam.ac.uk", which is what is wanted. There are several > machines in the cus.cam.ac.uk domain, but they form a common mail system. > The problem arises when I receive mail from another local user whose mail > user agent does *not* fully qualify names. So I have something like > > From: someuser > > in my inbox. Pine displays this as > > From: someuser@bootes.cus.cam.ac.uk > > when I am running it on the machine bootes.cus.cam.ac.uk, or with a > different name if I run it on another machine. This is disastrous, > especially if I want to reply. [It is more disastrous for a machine in the > UK than for other Internet machines, because of the dual mail registration > with the JANET network. Only the shorter name is registered with JANET.] > It looks as if Pine (version 3.05, running on a Sun) is ignoring the > use-only-domain-name parameter when displaying unqualified names in > incoming mail. > > Philip Hazel > > -- > Internet: P.Hazel@ucs.cam.ac.uk University Computing Service, > JANET: P.Hazel@uk.ac.cam.ucs Computer Laboratory, Pembroke St, > Phone: +44 223 334714 Cambridge CB2 3QG, England. From c-client-request@cac.washington.edu Wed Sep 23 13:18:01 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03296; Wed, 23 Sep 92 13:18:01 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26464; Wed, 23 Sep 92 13:17:56 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26458; Wed, 23 Sep 92 13:17:46 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.16 $) id AA00944; Wed, 23 Sep 92 16:18:15 -0400 Message-Id: <9209232018.AA00944@eco.twg.com> Received: from navajo.twg.com by apache.twg.com id <12747-0@apache.twg.com>; Wed, 23 Sep 1992 13:17:15 -0700 From: "David Herron" Subject: Re: Domain names (fwd) To: Laurence Lundblade Cc: c-client@cac.washington.edu, Bob Gregory Date: Wed, 23 Sep 92 13:20:27 PDT In-Reply-To: Your message of Wed, 23 Sep 1992 11:50:12 -0700 (PDT). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 26 TEXT , 4 TEXT Always stamping fully qualified domain names on mail addresses is a Very Good Practice. One of the major misfeatures that Sendmail has foisted upon the world is the practice of not doing so. Places where I've seen problems: - If the nameservers are currently dead & you've got a partially qualified name it might do the wrong thing (or at least take a long time to do nothing because it's waiting for nameserver timeouts). NOTE: It's been a couple of years since this was seen and I don't remember details. - If someone forwards a piece of mail sent by a local user, it doesn't have qualified addresses. If it's forwarded to a non-local user the local MTA is unable to rewrite the addresses & the recipient gets mail with an embedded message containing addresses which looks to be local to that user. If the user then tries to use that embedded message to create a reply, the addresses are way-wrong & confusion can easily result. - Some digest creators do not qualify addresses in the embedded headers. This is the same as the previous problem, and is the common case where it happens. Some UA's provide a command for automagically bursting a digest and turning it into `n' new messages in the users mailbox. The user may wish to reply and/or forward to any of those messages but they've got screwed up addresses ... <- David Herron (work) (home) <- <- During the '80s Usenet's mantra was: "Not all the world's a VAX". <- During the '90s I hope it becomes: "Not all the world's DOS (ick)". From c-client-request@cac.washington.edu Wed Sep 23 13:59:42 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04062; Wed, 23 Sep 92 13:59:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26927; Wed, 23 Sep 92 13:59:37 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26917; Wed, 23 Sep 92 13:58:13 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00329; Wed, 23 Sep 92 13:56:37 -0700 Date: Wed, 23 Sep 1992 13:45:01 -0700 (PDT) From: Mark Crispin Subject: Re: Domain names (fwd) To: Laurence Lundblade Cc: c-client@cac.washington.edu, Bob Gregory In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mr. c-client is aware of this problem. He is of the religion that states that addresses without a fully-qualified domain name cannot possibly work well enough to ever be trusted. Furthermore, he feels that what bits are on the disk should be of little concern to the user; if users want host-less addressing that is what their wonderful user interfaces are supposed to accomplish for them. However, he is also aware that circumstances force him to do something to parse an address without a host name other than just toss it out. And he is also aware that it's all his fault that he sets that default host name to the local host name and gives the main program no opportunity to change it. So... he is probably going to make that default host name be a global variable that gets defaulted to the local host name if the main program doesn't take care of it first. This will hopefully solve the immediate hassle in Pine. However, that doesn't change his fundamental lack of sympathy for the idea that it is ever reasonable to transmit e-mail bits without proper domain names. He has wasted entirely too many hours of his life in dealing with something that is essentially invalid and undefined. -- Mark -- From c-client-request@cac.washington.edu Wed Sep 23 14:06:38 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04309; Wed, 23 Sep 92 14:06:38 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA27034; Wed, 23 Sep 92 14:06:30 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from olive.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA27027; Wed, 23 Sep 92 14:06:29 -0700 Received: by olive.cac.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.21 ) id AA07434; Wed, 23 Sep 92 14:00:02 PDT Date: Wed, 23 Sep 1992 13:58:06 -0700 (PDT) From: Laurence Lundblade Subject: Re: Domain names (fwd) To: Mark Crispin Cc: c-client@cac.washington.edu, Bob Gregory In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sounds good to me Mark. I will also happily reflect your advise in the Pine tech-notes that use of this features is best considered a transitionary measure until the site can get to the point where they can use fully qualified host names. Thanks! LL On Wed, 23 Sep 1992, Mark Crispin wrote: > Date: Wed, 23 Sep 1992 13:45:01 -0700 (PDT) > From: Mark Crispin > To: Laurence Lundblade > Cc: c-client@cac.washington.edu, Bob Gregory > Subject: Re: Domain names (fwd) > > Mr. c-client is aware of this problem. > > He is of the religion that states that addresses without a fully-qualified > domain name cannot possibly work well enough to ever be trusted. Furthermore, > he feels that what bits are on the disk should be of little concern to the > user; if users want host-less addressing that is what their wonderful user > interfaces are supposed to accomplish for them. > > However, he is also aware that circumstances force him to do something to > parse an address without a host name other than just toss it out. And he is > also aware that it's all his fault that he sets that default host name to the > local host name and gives the main program no opportunity to change it. > > So... he is probably going to make that default host name be a global > variable that gets defaulted to the local host name if the main program > doesn't take care of it first. This will hopefully solve the immediate hassle > in Pine. > > However, that doesn't change his fundamental lack of sympathy for the idea > that it is ever reasonable to transmit e-mail bits without proper domain > names. He has wasted entirely too many hours of his life in dealing with > something that is essentially invalid and undefined. > > -- Mark -- > From c-client-request@cac.washington.edu Fri Oct 2 02:37:06 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04922; Fri, 2 Oct 92 02:37:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25532; Fri, 2 Oct 92 02:36:51 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25526; Fri, 2 Oct 92 02:36:49 -0700 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA06806; Fri, 2 Oct 92 02:36:46 -0700 Date: Fri, 2 Oct 1992 02:35:11 -0700 (PDT) From: Mark Crispin Subject: re: Hostnames for hostless addresses To: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Sep 1992 14:14:05 +0300 (IDT), Laurence Lundblade wrote: > I'm looking for a way to tell the c-client what address to use > when qualifying domainless addresses. Right now it use the result > of gethostbyname (the /etc/hosts, YP and DNS lookup). This > results in an address with a hostname in it, where it might be > better not to have one. Also, one can't always control what the > hostname is set too. I realize that it would be best to have the > addresses in the mail files fully qualified, but that isn't > possible in this case. > Could either an argument be added to mail_open, or a > mail_setdomain() call be added to set the domain name so the > calling program could control this? Then for example in Pine, > all the domain names would be consistent. The very latest c-client (not yet publicly released) makes this available via a global char* variable called lhostn which the main program can set. If it does not, c-client defaults it as before. From c-client-request@cac.washington.edu Thu Oct 22 20:42:09 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13672; Thu, 22 Oct 92 20:42:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04976; Thu, 22 Oct 92 20:42:01 -0700 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04970; Thu, 22 Oct 92 20:41:58 -0700 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA07863; Thu, 22 Oct 92 20:41:54 -0700 Date: Thu, 22 Oct 1992 20:40:20 -0700 (PDT) From: Mark Crispin Subject: c-client mailing list archives now available To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You can ftp it from ftp.cac.washington.edu on mail/c-client_archive This is a copy of the actual archive, updated daily at 1AM. From c-client-request@cac.washington.edu Mon Oct 26 21:40:45 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29123; Mon, 26 Oct 92 21:40:45 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11938; Mon, 26 Oct 92 21:40:41 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11926; Mon, 26 Oct 92 21:40:26 -0800 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA12290; Mon, 26 Oct 92 22:40:17 -0700 Date: Mon, 26 Oct 1992 21:32:06 -0800 (PST) From: Mark Crispin Subject: bug discovered in UW imapd server To: c-client Interest List Cc: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the course of adding support for the IMAP2bis APPEND command to c-client, I discovered that the UW IMAP server didn't properly handle literals from the client to the server. Specifically, the `+' response to prompt for more output did not get transmitted until after the literal was transmitted. This bug did not show up in the current version of c-client. Client literals were only used for passwords in LOGIN and mailbox names in SELECT, and the complete command was sent in one chunk instead of waiting for the `+' response as the specification says. This was an expedient kludge to handle certain bizarre passwords and mailbox names until I implemented it right. Well, I implemented it right today. The bug is fixed in the 2.2 distribution of c-client, now available on ftp.cac.washington.edu as mail/imap.tar.Z (which is a link to imap-2.2.tar.Z). I urge developers to pick up this version as soon as possible, since there will be interoperability problems with support for the new APPEND command (as well as funny characters in passwords and mailbox names) until the older versions of imapd are exterminated. This new version also has the fix for certain base64 conversions outlined by Laurence Lundblade in his announcement to the Pine list, as well as the change to the IMAP client software to do client literals right. It would probably be prudent to hold off on using the new c-client/imap2.c in this new version until you have made sure that the new imapd is deployed. From c-client-request@cac.washington.edu Mon Oct 26 22:20:59 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29459; Mon, 26 Oct 92 22:20:59 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11938; Mon, 26 Oct 92 21:40:41 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11926; Mon, 26 Oct 92 21:40:26 -0800 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA12290; Mon, 26 Oct 92 22:40:17 -0700 Date: Mon, 26 Oct 1992 21:32:06 -0800 (PST) From: Mark Crispin Subject: bug discovered in UW imapd server To: c-client Interest List Cc: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the course of adding support for the IMAP2bis APPEND command to c-client, I discovered that the UW IMAP server didn't properly handle literals from the client to the server. Specifically, the `+' response to prompt for more output did not get transmitted until after the literal was transmitted. This bug did not show up in the current version of c-client. Client literals were only used for passwords in LOGIN and mailbox names in SELECT, and the complete command was sent in one chunk instead of waiting for the `+' response as the specification says. This was an expedient kludge to handle certain bizarre passwords and mailbox names until I implemented it right. Well, I implemented it right today. The bug is fixed in the 2.2 distribution of c-client, now available on ftp.cac.washington.edu as mail/imap.tar.Z (which is a link to imap-2.2.tar.Z). I urge developers to pick up this version as soon as possible, since there will be interoperability problems with support for the new APPEND command (as well as funny characters in passwords and mailbox names) until the older versions of imapd are exterminated. This new version also has the fix for certain base64 conversions outlined by Laurence Lundblade in his announcement to the Pine list, as well as the change to the IMAP client software to do client literals right. It would probably be prudent to hold off on using the new c-client/imap2.c in this new version until you have made sure that the new imapd is deployed. From c-client-request@cac.washington.edu Tue Nov 3 01:21:05 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22042; Tue, 3 Nov 92 01:21:05 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24080; Tue, 3 Nov 92 01:20:48 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from cc.nsysu.edu.tw by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24067; Tue, 3 Nov 92 01:20:19 -0800 Received: by cc.nsysu.edu.tw (4.1/SysuNet-1.1-C.C) id ; Tue, 3 Nov 92 17:20:20 CST Date: Tue, 3 Nov 92 17:20:20 CST From: hsu@cc.nsysu.edu.tw (Hsu Li-Cheng) Message-Id: <9211030920.AA00413@cc.nsysu.edu.tw> To: c-client@cac.washington.edu Subject: addition From c-client-request@cac.washington.edu Fri Nov 13 11:22:37 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07172; Fri, 13 Nov 92 11:22:37 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18141; Fri, 13 Nov 92 11:22:17 -0800 Errors-To: c-client-request@cac.washington.edu Sender: c-client-request@cac.washington.edu Received: from madhaus.utcs.utoronto.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18133; Fri, 13 Nov 92 11:22:11 -0800 Received: from cathaus.utcs.utoronto.ca by madhaus.utcs.utoronto.ca (5.65/1.34) id AA04335; Fri, 13 Nov 92 14:22:09 -0500 Received: by cathaus.utcs.utoronto.ca (4.1/1.34) id AA05269; Fri, 13 Nov 92 14:21:50 EST Message-Id: <9211131921.AA05269@cathaus.utcs.utoronto.ca> To: imap-request@cac.washington.edu, c-client@cac.washington.edu Subject: please add Organization: UTCC Network & Operations Services, Network Development Phone: +1 416 978 6134 Date: Fri, 13 Nov 92 14:21:49 -0500 From: "Eric M. Carroll" Please add eric@utcs.utoronto.ca to the mailing lists. Thanks. Eric Carroll University of Toronto Computing & Communications Network & Operations Services, Network Development From owner-c-client@cac.washington.edu Fri Dec 4 23:12:04 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15151; Fri, 4 Dec 92 23:12:04 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23948; Fri, 4 Dec 92 23:11:49 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23936; Fri, 4 Dec 92 23:11:22 -0800 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA06089; Fri, 4 Dec 92 23:11:13 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA11308; Fri, 4 Dec 92 23:11:05 -0800 Date: Fri, 4 Dec 1992 23:00:25 -0800 (PST) From: Mark Crispin Subject: Bugfix to the `Bogus entry in new cache list' crash To: dmandell@saintmarys.edu Cc: pine-info@cac.washington.edu, c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="16816888-2078917053-723539469:#10458" --16816888-2078917053-723539469:#10458 Content-Type: TEXT/PLAIN; charset=US-ASCII The MIME-attached difference file fixes a bug in c-client's berkeley mail driver (bezerk.c) which caused a crash with the message `Bogus entry in new cache list' when it encounted a mailbox that had empty messages such as in this example (I have inserted leading spaces to prevent possible confusion): From <@UICVM.UIC.EDU:WMST-L@UMDD.BITNET> Fri Dec 4 07:08 EST 1992 From <@UICVM.UIC.EDU:WMST-L@UMDD.BITNET> Fri Dec 4 07:23 EST 1992 From <@UICVM.UIC.EDU:WMST-L@UMDD.BITNET> Fri Dec 4 07:27 EST 1992 From <@pucc.PRINCETON.EDU:SBN@INDYCMS.BITNET> Fri Dec 4 07:30 EST 1992 From albr8047@jade.saintmarys.edu Fri Dec 4 09:58 EST 1992 When the mailbox is rewritten by c-client, two additional newlines will be inserted as well as a Status and X-Status line. Thanks to Dan Mandell for giving me excellent sample data which reproduced the problem. This problem was evidentally caused by a disk full condition on their HP-UX system, leading to appends to the mailbox of the `From ' headers but not the actual mail data. This fix is also in the latest mail/imap.tar.Z on ftp.cac.washington.edu. -- Mark -- --16816888-2078917053-723539469:#10458 Content-Type: APPLICATION/OCTET-DATA; NAME="bezerk.diff" Content-Transfer-Encoding: BASE64 Content-Description: attached file KioqIGJlemVyay5jLm9sZAlGcmkgRGVjICA0IDE2OjIyOjIwIDE5OTIKLS0t IGJlemVyay5jCUZyaSBEZWMgIDQgMjI6NTE6MTIgMTk5MgoqKioqKioqKioq KioqKioKKioqIDEyODEsMTI5MCAqKioqCiAgCWlmIChlKSBqID0gKGUgLSBz KSAtIDE7CS8qIGNhbGN1bGF0ZSBtZXNzYWdlIGxlbmd0aCAqLwogIAllbHNl IGogPSBzdHJsZW4gKHMpIC0gMTsvKiBvdGhlcndpc2UgaXMgcmVtYWluZGVy IG9mIGRhdGEgKi8KICAJaWYgKG0pIHsJCS8qIG5ldyBjYWNoZSBuZWVkZWQs IGhhdmUgcHJldmlvdXMgZGF0YT8gKi8KISAJICBuLT5oZWFkZXIgPSAoY2hh ciAqKSBmc19nZXQgKHNpemVvZiAoRklMRUNBQ0hFKSArIGopOwogIAkgIG4g PSAoRklMRUNBQ0hFICopIG4tPmhlYWRlcjsKICAJfQohIAllbHNlIG0gPSBu ID0gKEZJTEVDQUNIRSAqKSBmc19nZXQgKHNpemVvZiAoRklMRUNBQ0hFKSAr IGopOwogIAkJCQkvKiBjb3B5IG1lc3NhZ2UgZGF0YSAqLwogIAlzdHJuY3B5 IChuLT5pbnRlcm5hbCxzLGopOwogIAluLT5pbnRlcm5hbFtqXSA9ICdcMCc7 Ci0tLSAxMjgxLDEyOTAgLS0tLQogIAlpZiAoZSkgaiA9IChlIC0gcykgLSAx OwkvKiBjYWxjdWxhdGUgbWVzc2FnZSBsZW5ndGggKi8KICAJZWxzZSBqID0g c3RybGVuIChzKSAtIDE7Lyogb3RoZXJ3aXNlIGlzIHJlbWFpbmRlciBvZiBk YXRhICovCiAgCWlmIChtKSB7CQkvKiBuZXcgY2FjaGUgbmVlZGVkLCBoYXZl IHByZXZpb3VzIGRhdGE/ICovCiEgCSAgbi0+aGVhZGVyID0gKGNoYXIgKikg ZnNfZ2V0IChzaXplb2YgKEZJTEVDQUNIRSkgKyBqICsgMSk7CiAgCSAgbiA9 IChGSUxFQ0FDSEUgKikgbi0+aGVhZGVyOwogIAl9CiEgCWVsc2UgbSA9IG4g PSAoRklMRUNBQ0hFICopIGZzX2dldCAoc2l6ZW9mIChGSUxFQ0FDSEUpICsg aiArIDEpOwogIAkJCQkvKiBjb3B5IG1lc3NhZ2UgZGF0YSAqLwogIAlzdHJu Y3B5IChuLT5pbnRlcm5hbCxzLGopOwogIAluLT5pbnRlcm5hbFtqXSA9ICdc MCc7CioqKioqKioqKioqKioqKgoqKiogMTMyOCwxMzM0ICoqKioKICAgIGZv ciAoaSA9IHN0cmVhbS0+bm1zZ3MsIG4gPSBtOyBpIDwgbm1zZ3M7IGkrKykg ewogICAgICBMT0NBTC0+bXNnc1tpXSA9IG0gPSBuOwkvKiBzZXQgY2FjaGUs IGFuZCBuZXh0IGNhY2hlIHBvaW50ZXIgKi8KICAgICAgbiA9IChGSUxFQ0FD SEUgKikgbi0+aGVhZGVyOwohICAgICBpZiAoISgocyA9IG0tPmludGVybmFs KSAmJiBWQUxJRCkpIGZhdGFsICgiQm9ndXMgZW50cnkgaW4gbmV3IGNhY2hl IGxpc3QiKTsKICAgICAgbS0+aGVhZGVyID0gcyA9ICsrdDsJLyogcG9pbnRl ciB0byBtZXNzYWdlIGhlYWRlciAqLwogICAgICBtLT5oZWFkZXJzaXplIC09 IG0tPmhlYWRlciAtIG0tPmludGVybmFsOwogICAgICBtLT5ib2R5ID0gTklM OwkJLyogYXNzdW1lIG5vIGJvZHkgYXMgeWV0ICovCi0tLSAxMzI4LDEzNDAg LS0tLQogICAgZm9yIChpID0gc3RyZWFtLT5ubXNncywgbiA9IG07IGkgPCBu bXNnczsgaSsrKSB7CiAgICAgIExPQ0FMLT5tc2dzW2ldID0gbSA9IG47CS8q IHNldCBjYWNoZSwgYW5kIG5leHQgY2FjaGUgcG9pbnRlciAqLwogICAgICBu ID0gKEZJTEVDQUNIRSAqKSBuLT5oZWFkZXI7CiEgICAgIC8qIFRoaXMgaXMg YSBidWd0cmFwIGZvciBib2dvbnMgaW4gdGhlIG5ldyBtZXNzYWdlIGNhY2hl LCB3aGljaCBtYXkgaGFwcGVuCiEgICAgICAqIGlmIG1lbW9yeSBpcyBjb3Jy dXB0ZWQuICBOb3RlIHRoYXQgaW4gdGhlIGNhc2Ugb2YgYSB0b3RhbGx5IGVt cHR5CiEgICAgICAqIG1lc3NhZ2UsIGEgbmV3bGluZSBpcyBhcHBlbmRlZCBh bmQgY291bnRzIGFkanVzdGVkLgohICAgICAgKi8KISAgICAgaWYgKCghKChz ID0gbS0+aW50ZXJuYWwpICYmIFZBTElEKSkgJiYKISAJIShzICYmICFzdHJj aHIgKHMsJ1xuJykgJiYgc3RyY2F0IChzLCJcbiIpICYmIFZBTElEICYmCiEg CSAgbS0+aGVhZGVyc2l6ZSsrKSkgZmF0YWwgKCJCb2d1cyBlbnRyeSBpbiBu ZXcgY2FjaGUgbGlzdCIpOwogICAgICBtLT5oZWFkZXIgPSBzID0gKyt0Owkv KiBwb2ludGVyIHRvIG1lc3NhZ2UgaGVhZGVyICovCiAgICAgIG0tPmhlYWRl cnNpemUgLT0gbS0+aGVhZGVyIC0gbS0+aW50ZXJuYWw7CiAgICAgIG0tPmJv ZHkgPSBOSUw7CQkvKiBhc3N1bWUgbm8gYm9keSBhcyB5ZXQgKi8K --16816888-2078917053-723539469:#10458-- From owner-c-client@cac.washington.edu Fri Dec 11 15:00:15 1992 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18313; Fri, 11 Dec 92 15:00:15 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04670; Fri, 11 Dec 92 15:00:43 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04650; Fri, 11 Dec 92 15:00:07 -0800 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA01803; Fri, 11 Dec 92 14:59:11 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA04157; Fri, 11 Dec 92 14:59:05 -0800 Date: Fri, 11 Dec 1992 14:47:59 -0800 (PST) From: Mark Crispin Subject: MIME-Version after Content-Type bug in Pine To: pine-info@cac.washington.edu Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks to data provided to me by Mike Seibel that demonstrated the bug, I was able to find a bug in the header parsing code in c-client and fix it. This fixes the problem that the fellow in Finland reported. I have just updated the mail/imap.tar.Z c-client distribution on ftp.cac.washington.edu to incorporate this bugfix. Problem: Messages in which the MIME-Version: header occurs as the line immediately after the Content-Type: header are not recognized and parsed as MIME. If the MIME-Version: header occurs later in the header, everything works. Diagnosis: The code to scan the remainder of the header for the string `MIME-Version' prefixes the search string with a newline to make sure it only sees ones that start a line. Unfortunately, it starts the search at the first character of the next line, instead of at the newline that terminates the current header line. Solution: Begin the search a character earlier. In routine rfc822_parse_msg() in rfc822.c, there is the following code: case 'C': /* possible cc: or Content-*/ if (!strcmp (tmp+1,"C")) rfc822_parse_adrlist (&env->cc,d,host); else if ((tmp[1] == 'O') && (tmp[2] == 'N') && (tmp[3] == 'T') && (tmp[4] == 'E') && (tmp[5] == 'N') && (tmp[6] == 'T') && (tmp[7] == '-') && body && (MIMEp || (search (s-1,i,"\012MIME-Version",(long) 13)))) rfc822_parse_content_header (body,tmp+8,d); break; Note the ``s-1'' in the call to search(). Version with the bug have ``s'' instead. Change the ``s'' to ``s-1'' and rebuild. From owner-c-client@cac.washington.edu Tue Jan 19 13:08:21 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09430; Tue, 19 Jan 93 13:08:21 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26902; Tue, 19 Jan 93 13:08:00 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26896; Tue, 19 Jan 93 13:07:58 -0800 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA21164; Tue, 19 Jan 93 13:07:56 -0800 Received: from set.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA14519; Tue, 19 Jan 93 13:03:13 PST Received: by set.twinsun.com (4.1/SMI-4.1) id AA15829; Tue, 19 Jan 93 13:03:11 PST Date: Tue, 19 Jan 93 13:03:11 PST From: makr@twinsun.com (Makr Keasling) Message-Id: <9301192103.AA15829@set.twinsun.com> To: c-client@cac.washington.edu Subject: EINTR received during connect when opening a remote folder. Cc: mrc@cac.washington.edu Here is the error message: !! Can't connect to set,143: Interrupted system call my fix is to: MAILSTREAM *my_mail_open (MAILSTREAM *stream, char *mailbox) { int mask = sigblock (sigmask (SIGCHLD)); stream = mail_open (stream, mailbox, 0); sigsetmask (mask); return stream; } I need to receive SIGCHLD's because I am running processes in the "background" and need to know when they are finished. The SIGCHLD that is received is from the process that gets forked when trying to connect via /etc/rimapd. The problem occurs when network latency is high. I would like to know if there is a better, more portable solution to this problem. Mark Keasling makr@twinsun.com From owner-c-client@cac.washington.edu Wed Jan 20 22:47:35 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25164; Wed, 20 Jan 93 22:47:35 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11406; Wed, 20 Jan 93 22:47:28 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11400; Wed, 20 Jan 93 22:47:27 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA06676; Wed, 20 Jan 93 22:47:20 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00461; Wed, 20 Jan 93 22:47:11 -0800 Date: Wed, 20 Jan 1993 22:35:58 -0800 (PST) From: Mark Crispin Subject: re: EINTR received during connect when opening a remote folder. To: Makr Keasling Cc: c-client Interest List In-Reply-To: <9301192103.AA15829@set.twinsun.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 19 Jan 93 13:03:11 PST, Makr Keasling wrote: > I need to receive SIGCHLD's because I am running processes in the > "background" > and need to know when they are finished. The SIGCHLD that is received is > from the process that gets forked when trying to connect via /etc/rimapd. > The problem occurs when network latency is high. > > I would like to know if there is a better, more portable solution to this > problem. You probably have to defer any signal which may adversely impact TCP every time you call c-client. I'm sure SIGCHLD isn't the only one; nor is TCP open the only thing that can be adversely impacted by a signal at the wrong time. This is a deficiency in the Unix kernel. Ideally, a signal should just call the signal handler and let you resume the TCP system call (perhaps by backing out into user mode so redoing the system call resumes the operation). Very few operating systems do this right; ITS (R.I.P.) is the only one I know of that did. ;-( One possible way of dealing with the problem is by having the c-client part of your application run in a separate child, so it would never get SIGCHLDs. I don't know how badly this may tangle your application though. -- Mark -- From owner-c-client@cac.washington.edu Mon Feb 15 20:54:32 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05294; Mon, 15 Feb 93 20:54:32 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06079; Mon, 15 Feb 93 20:54:12 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06073; Mon, 15 Feb 93 20:54:11 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA08521; Mon, 15 Feb 93 20:54:06 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00743; Mon, 15 Feb 93 20:54:01 -0800 Date: Mon, 15 Feb 1993 20:23:15 -0800 (PST) From: Mark Crispin Subject: c-client 2.3 frozen; 2.4 started To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Version 2.3 of the IMAP toolkit has been frozen. It has, as of this writing, no known bugs. Besides bugfixes from 2.2 (frozen last October 26), 2.3 has the following major features: . Implementation of the new mailbox naming rules in imap/Naming.TXT. Note that these have tripped up a few people; so please read this document carefully. . Subscription management for mailboxes and bboards is now implemented. . The ``ms'' demo client supports the mailbox management features (create, delete, rename, subscribe, unsubscribe). . The IMAP server now supports PARTIAL fetching, and has a dummy for PURGE, making it fully IMAP2bis compliant. . Berkeley parser now handles 10 different formats of ``From '' line. . NNTP client implemented for Unix and for DOS. The mailbox syntax is *[host]newsgroup . SUN-OS port has its own version of strstr(), since the one provided by SUN is buggy and extremely slow. A full list is in imap/Updates.DOC. - - - - - The first version of 2.4 is now available; note that this is NOT a stable or final version of 2.4!! 2.4 begins with an implementation of Kiss Of Death for Berkeley/mbox mailbox streams. If a process attempts to open a Berkeley mailbox that is already open and locked read/write by another process, it will send a SIGUSR2 signal as a ``kiss of death'' to the process which has it open. If the other process releases the mailbox within 15 seconds, the process sending the KOD will take over the read/write lock. This is intended to help the annoying ``mailbox already open by another process, access is read-only'' condition when the other process is an abandoned or lost imapd or Pine. The action taken upon receipt of a KOD depends upon the main program. At this writing (8:40PM on February 16) only imapd has a KOD handler. If it has been more than 2 minutes since the last IMAP operation, imapd will relenquish the read/write lock and go read-only on the stream. imapd will continue to run until its autologout timer (currently 30 minutes from the time of the last IMAP operation) expires. I'm not sure precisely what sort of action Pine will take when it gets a KOD, but I'm sure the Pine UA folks will do something neat now that they're no longer waiting on me. It is also now possible in 2.4 to change a read/write stream into a readonly stream. If anyone using c-client is currently using SIGUSR2 for some other purpose, please get in touch with me right away while there's still the opportunity to go with some other mechanism. Other items likely to go into subsequent edits of 2.4: . Disconnected operation extensions to IMAP2bis (more on this to come on the IMAP list) . Possible conversion of the tenex driver to not use much memory at all (at the expense of possible slower searches). . Possible mechanism to import a Berkeley mbox folder to DOS. . Support for smail-style `` remote from node'' suffix in mbox folders. . Possible support for the new SVR4 ``Content-Length'' header (this may be a problem since it could slow down Berkeley mbox parsing for everyone else). . Possible MMDF folder support. -- Mark -- From owner-c-client@cac.washington.edu Mon Feb 15 21:25:30 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05612; Mon, 15 Feb 93 21:25:30 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15594; Mon, 15 Feb 93 21:25:24 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15588; Mon, 15 Feb 93 21:25:23 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21117; Mon, 15 Feb 93 21:25:22 -0800 Date: Mon, 15 Feb 1993 21:20:04 -0800 (PST) From: Terry Gray Subject: Re: c-client 2.3 frozen; 2.4 started To: Mark Crispin Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just a small caveat for all interested parties: the mailbox naming rules and syntax decisions (e.g. [host]) should be considered work in progress, and may well change. Hopefully these issues will get nailed down in the next two weeks. -teg On Mon, 15 Feb 1993, Mark Crispin wrote: > Version 2.3 of the IMAP toolkit has been frozen. It has, as of this writing, > no known bugs. Besides bugfixes from 2.2 (frozen last October 26), 2.3 has > the following major features: > . Implementation of the new mailbox naming rules in imap/Naming.TXT. Note > that these have tripped up a few people; so please read this document > carefully. > . Subscription management for mailboxes and bboards is now implemented. > . The ``ms'' demo client supports the mailbox management features (create, > delete, rename, subscribe, unsubscribe). > . The IMAP server now supports PARTIAL fetching, and has a dummy for PURGE, > making it fully IMAP2bis compliant. > . Berkeley parser now handles 10 different formats of ``From '' line. > . NNTP client implemented for Unix and for DOS. The mailbox syntax is > *[host]newsgroup > . SUN-OS port has its own version of strstr(), since the one provided by SUN > is buggy and extremely slow. > > A full list is in imap/Updates.DOC. > > - - - - - > > The first version of 2.4 is now available; note that this is NOT a stable or > final version of 2.4!! > > 2.4 begins with an implementation of Kiss Of Death for Berkeley/mbox mailbox > streams. If a process attempts to open a Berkeley mailbox that is already > open and locked read/write by another process, it will send a SIGUSR2 signal > as a ``kiss of death'' to the process which has it open. If the other process > releases the mailbox within 15 seconds, the process sending the KOD will take > over the read/write lock. This is intended to help the annoying ``mailbox > already open by another process, access is read-only'' condition when the > other process is an abandoned or lost imapd or Pine. > > The action taken upon receipt of a KOD depends upon the main program. At this > writing (8:40PM on February 16) only imapd has a KOD handler. If it has been > more than 2 minutes since the last IMAP operation, imapd will relenquish the > read/write lock and go read-only on the stream. imapd will continue to run > until its autologout timer (currently 30 minutes from the time of the last > IMAP operation) expires. > > I'm not sure precisely what sort of action Pine will take when it gets a KOD, > but I'm sure the Pine UA folks will do something neat now that they're no > longer waiting on me. > > It is also now possible in 2.4 to change a read/write stream into a readonly > stream. > > If anyone using c-client is currently using SIGUSR2 for some other purpose, > please get in touch with me right away while there's still the opportunity to > go with some other mechanism. > > Other items likely to go into subsequent edits of 2.4: > . Disconnected operation extensions to IMAP2bis (more on this to come on the > IMAP list) > . Possible conversion of the tenex driver to not use much memory at all (at > the expense of possible slower searches). > . Possible mechanism to import a Berkeley mbox folder to DOS. > . Support for smail-style `` remote from node'' suffix in mbox folders. > . Possible support for the new SVR4 ``Content-Length'' header (this may be a > problem since it could slow down Berkeley mbox parsing for everyone else). > . Possible MMDF folder support. > > -- Mark -- > From owner-c-client@cac.washington.edu Tue Feb 16 19:48:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02226; Tue, 16 Feb 93 19:48:13 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07354; Tue, 16 Feb 93 19:47:57 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07303; Tue, 16 Feb 93 19:47:50 -0800 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Tue, 16 Feb 93 22:47:44 EST Received: via switchmail; Tue, 16 Feb 1993 22:47:43 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 22:45:50 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 22:45:40 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 16 Feb 1993 22:45:34 -0500 (EST) Message-Id: Date: Tue, 16 Feb 1993 22:45:34 -0500 (EST) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Naming rules w.r.t. ambiguous names Beak: is Not I disagree with the following rule in Naming.txt: "c-client will look for ambiguous names ONLY in the same technology as the INBOX mailbox." C-client should look for ambiguous names in all technologies. Each technology must have the ability to determine whether or not it has an object of that name. When two or more technologies have an object with the same name it is an implementation issue to determine which has precedence. It is reasonable to state the rule that ambiguous names will only be CREATED in the same technology as the INBOX mailbox. _.John From owner-c-client@cac.washington.edu Tue Feb 16 20:06:45 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02507; Tue, 16 Feb 93 20:06:45 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22046; Tue, 16 Feb 93 20:06:29 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22002; Tue, 16 Feb 93 20:06:24 -0800 Received: by andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Tue, 16 Feb 93 23:06:19 EST Received: via switchmail; Tue, 16 Feb 1993 23:06:19 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 23:05:51 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 16 Feb 1993 23:05:47 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 16 Feb 1993 23:05:43 -0500 (EST) Message-Id: Date: Tue, 16 Feb 1993 23:05:43 -0500 (EST) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Subscription management and ambiguous names Beak: is Not When subscribing to an ambiguous name, the bezerk driver in c-client 2.3 converts it into an unambiguous name before adding it to the subscription database. Also, bezerk_find_all() given an ambiguous pattern will return unambiguous names. In my opinion, this is incorrect. In many cases, it will cause imapd to behave contrary to the protocol spec. It also exposes implementation information that should remain hidden from the user. For example, I gave imapd a "tag subscribe INBOX" command and a subsequent "tag find mailboxes *" command returned "* MAILBOX /usr/spool/mail/jm36". A "tag find all.mailboxes *" command gave information as to where the user's mailboxes were stored on the imap server. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Tue Feb 16 22:46:43 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04427; Tue, 16 Feb 93 22:46:43 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15792; Tue, 16 Feb 93 22:46:30 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15786; Tue, 16 Feb 93 22:46:29 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA01788; Tue, 16 Feb 93 22:46:24 -0800 Date: Tue, 16 Feb 1993 20:24:25 -0800 (PST) From: Mark Crispin Subject: re: Subscription management and ambiguous names To: John Gardiner Myers Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII John (& the c-client list) - The idea was to have a constant frame of reference. Home-directory relative unambiguous names are supposed to be of the form ~/name, not something like /u1/users/jm36 which is subject to change. The recording of the special name INBOX as an absolute /usr/spool/mail pathname is probably a bug though. It is certainly not intended. Anyway, this stuff is still under development, so expect to see more changes in 2.4. -- Mark -- From owner-c-client@cac.washington.edu Wed Feb 17 06:47:42 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11145; Wed, 17 Feb 93 06:47:42 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17913; Wed, 17 Feb 93 06:47:35 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17907; Wed, 17 Feb 93 06:47:33 -0800 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA07739; Wed, 17 Feb 1993 09:47:28 -0500 Date: Wed, 17 Feb 1993 09:46:58 -0500 (EST) From: Laurence Lundblade Subject: Re: Subscription management and ambiguous names To: John Gardiner Myers Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here here! I agree, but Mark and company already know that all to well. LL On Tue, 16 Feb 1993, John Gardiner Myers wrote: > When subscribing to an ambiguous name, the bezerk driver in c-client > 2.3 converts it into an unambiguous name before adding it to the > subscription database. Also, bezerk_find_all() given an ambiguous > pattern will return unambiguous names. > > In my opinion, this is incorrect. In many cases, it will cause imapd > to behave contrary to the protocol spec. It also exposes > implementation information that should remain hidden from the user. > For example, I gave imapd a "tag subscribe INBOX" command and a > subsequent "tag find mailboxes *" command returned > "* MAILBOX /usr/spool/mail/jm36". A "tag find all.mailboxes *" > command gave information as to where the user's mailboxes were stored > on the imap server. > > -- > _.John G. Myers Internet: jgm+@CMU.EDU > LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up > > From owner-c-client@cac.washington.edu Thu Feb 18 05:01:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08404; Thu, 18 Feb 93 05:01:25 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29268; Thu, 18 Feb 93 05:01:09 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29262; Thu, 18 Feb 93 05:01:06 -0800 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA29111; Thu, 18 Feb 1993 08:01:02 -0500 Date: Thu, 18 Feb 1993 07:55:19 -0500 (EST) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: Naming rules w.r.t. ambiguous names To: John Gardiner Myers Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I agree with John here, as long as the ambiguous names across all technologies are not required to be unique, as I believe is the current implementation is. I also agree that Pine 3.05 knows too much about technology formats. It's probably in the worst state possible now as the process of moving all that stuff into the c-client is not complete. Some is in the c-client, but there's a huge amount of code in Pine. The work hasn't progresses because we've found the naming scheme and semantics of some routines in the c-client lacking. For example mail_find() always returns FQ (fully qualified -- unambiguous) names, it is not really appropriate to present such names to the use, and it's not possible to undo the FQ without knowledge of the OS of the server. The basic name of a folder includes: technology, path, ambiguous name, and host. The basic problem is how to put these all together. At the moment I've got a ton of beginning Pascal progams to grade and home work due, so I won't say more for a day or two, but have more thoughts. LL On Tue, 16 Feb 1993, John Gardiner Myers wrote: > I disagree with the following rule in Naming.txt: > > "c-client will look for ambiguous names ONLY in the same technology as > the INBOX mailbox." > > C-client should look for ambiguous names in all technologies. Each > technology must have the ability to determine whether or not it has an > object of that name. When two or more technologies have an object > with the same name it is an implementation issue to determine which > has precedence. > > It is reasonable to state the rule that ambiguous names will only be > CREATED in the same technology as the INBOX mailbox. > > _.John From owner-c-client@cac.washington.edu Tue Mar 2 05:16:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17229; Tue, 2 Mar 93 05:16:53 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26624; Tue, 2 Mar 93 05:16:42 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from genesis.iti.gov.sg by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26618; Tue, 2 Mar 93 05:16:37 -0800 Received: from pollux.iti.gov.sg by iti.gov.sg (4.1/SMI-4.1) id AA13483; Tue, 2 Mar 93 21:18:42 SST Date: Tue, 2 Mar 93 21:18:42 SST From: jinho@iti.gov.sg (Tan Jin Ho) Message-Id: <9303021318.AA13483@iti.gov.sg> To: c-client@CAC.Washington.edu Subject: c-clients for Windows Hi, Is there anyone who is working on a Windows c-client library (or have already done so) ? I tried compiling c-client with win wattcp but failed (it compiles fine but mtest crashed). Thanks, Jin-Ho From owner-c-client@cac.washington.edu Tue Mar 2 10:58:18 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24164; Tue, 2 Mar 93 10:58:18 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29120; Tue, 2 Mar 93 10:58:12 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29114; Tue, 2 Mar 93 10:57:58 -0800 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42134>; Tue, 2 Mar 1993 11:57:12 -0700 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Tue, 2 Mar 93 11:52 MST Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0nTc9Q-000cv9C; Tue, 2 Mar 93 11:57 MST Date: Tue, 2 Mar 1993 11:55:02 -0700 From: Steve Hole Subject: Re: c-clients for Windows To: Tan Jin Ho Cc: c-client@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 2 Mar 1993 12:18:42 -0700 Tan Jin Ho wrote: > From: Tan Jin Ho > Date: Tue, 2 Mar 1993 12:18:42 -0700 > Subject: c-clients for Windows > To: c-client@cac.washington.edu > > > Hi, > Is there anyone who is working on a Windows c-client library (or have > already done so) ? I tried compiling c-client with win wattcp but > failed (it compiles fine but mtest crashed). > We have been using the c-client inside windows for about 6 months now as the basis for ECSMail. It works fine. The problem would have to be in the win wattcp stack. We have noticed other problems with this stack, but haven't gotten around to correcting them. I believe that we will try to do so sometime this month. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: steve@edm.isac.ca Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Tue Mar 2 11:10:49 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24599; Tue, 2 Mar 93 11:10:49 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29796; Tue, 2 Mar 93 11:10:40 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29790; Tue, 2 Mar 93 11:10:39 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA03071; Tue, 2 Mar 93 11:10:21 -0800 Date: Tue, 2 Mar 1993 11:04:52 -0800 (PST) From: Mark Crispin Subject: re: c-clients for Windows To: Tan Jin Ho Cc: c-client Interest List In-Reply-To: <9303021318.AA13483@iti.gov.sg> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is there anyone who is working on a Windows c-client library (or have > already done so) ? I tried compiling c-client with win wattcp but > failed (it compiles fine but mtest crashed). Hi - I am concerned about all reports of c-client crashes, and I will happily debug the problem if you give me enough information. Telling me that mtest crashed is inadequate. Preferably, I need to be able to reproduce the problem, or at least have an idea of what is going on. Can you tell me exactly what you did to cause the c-client crash? Is there any reason to believe that a particular piece of e-mail data may be associated with the crash? Thanks, -- Mark -- From owner-c-client@cac.washington.edu Fri Mar 19 01:19:35 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA14283; Fri, 19 Mar 93 01:19:35 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25494; Fri, 19 Mar 93 01:19:21 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25488; Fri, 19 Mar 93 01:19:20 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA00505; Fri, 19 Mar 93 01:19:18 -0800 Date: Fri, 19 Mar 1993 00:51:30 -0800 (PST) From: Mark Crispin Subject: change coming to address lists To: IMAP Interest List Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A change is forthcoming to address lists in IMAP, and the corresponding structures in c-client, to provide a more useful representation of the envelope data for Pine. This change is largely upwards-compatible, but it may trip up some unprepared software. My ms and MailManager applications were. Because of its possible consequences, these changes will not appear until version 3.0 of the IMAP toolkit, so 2.4 is frozen as it stands now. I don't plan on releasing 3.0 of the IMAP toolkit until after the next release of Pine is released. The change makes it possible for an address structure to have a NIL host name and mailbox name. This is being used to support group syntax. An address structure with a non-NIL mailbox name but a NIL host name indicates the start of a group; one with both NIL indicates the end of a group. For example, the address list: To: Friends: Bob@FOO, Lisa@Bar;, Romans: Julius@CAESAR;, Joe@GARP will now be structured in IMAP as: ((NIL NIL Friends NIL) (NIL NIL Bob FOO) (NIL NIL Lisa Bar) (NIL NIL NIL NIL) (NIL NIL Romans NIL) (NIL NIL Julius CAESAR) (NIL NIL NIL NIL) (NIL NIL Joe GARP)) Previously, it was: ((NIL NIL Bob FOO) (NIL NIL Lisa Bar) (NIL NIL Julius CAESAR) (NIL NIL Joe GARP)) that is, the group information was ignored. More changes of this sort are likely in the near future to introduce netnews newsgroups. c-client software which religiously use c-client's routines will upgrade automatically on a relink. [ms and MailManager didn't, but they do now!] Implementors of c-client based software should look for cases where their program outputs data from an ADDRESS structure (as opposed to calling the routines in c-client). IMAP implementors should look for cases where they assume the mailbox or host name are non-NIL. -- Mark -- From owner-c-client@cac.washington.edu Tue Mar 23 13:05:22 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11702; Tue, 23 Mar 93 13:05:22 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23594; Tue, 23 Mar 93 13:05:03 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23588; Tue, 23 Mar 93 13:05:01 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA06465; Tue, 23 Mar 93 13:05:00 -0800 Date: Tue, 23 Mar 1993 11:33:56 -0800 (PST) From: Mark Crispin Subject: c-client network mailbox syntax To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the present c-client, network mailboxes are accessed with the following syntax for their names: {host}mailbox mailbox on host using IMAP {host:port}mailbox mailbox on host using IMAP on this port instead of 143 *{host}bboard bboard on host using IMAP *{host:port}mailbox bboard on host using IMAP on this port instead of 143 [host]mailbox mailbox on host using POP (future) *[host]bboard bboard on host using NNTP The notion is that {} refers to IMAP whereas [] refers to the older protocols. It has been proposed that the last two become instead: {host/POP2}mailbox *{host/NNTP}bboard That is, that slash followed by a service name identify an alternative service instead of IMAP. The default would, of course, be IMAP. Advantages: . possible elimination of confusion over the meaning of [] vs {}. It's felt that if users encounter this they would be seriously confused. . possible future extensibility. . fewer special characters in mailbox names. . simpler top-level rules, at the cost of more complex rules for {}. Disadvantages: . *{host/NNTP}bboard is arguably as mystical to users as *[host]bboard. . silly concepts such as *{host/POP}mailbox or {host/NNTP}bboard would exist, whereas they don't exist now. . extensibility arguments assume that anything we plan now would be at all suitable for a future mechanism. . it is necessary to state a protocol name, whereas before the protocol was inferred from the syntax. . more work for name parsers; they can't just grab things starting with { or [ any more. There has been a long, drawn out argument on this that finally ended with a general recognition that either one was arguably ``cleaner and better'' than the other. There is no clear technical superiority of one over the other; also, it can be reasonably argued that it is an implementation detail that can be hidden from users no matter what syntax is used. I'll state flat out: I like the current scheme. It's nice and tight with no loose ends, and it doesn't create silly cases (those of you will remember from the MIME WG that I *hate* silly states). But if the majority favors a change to the proposed format, I'll go along. So, if you have any feelings either way (or even if you don't particularly care), please share them. We do need to commit one way or another soon. -- Mark -- From owner-c-client@cac.washington.edu Tue Mar 23 13:33:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12719; Tue, 23 Mar 93 13:33:35 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19566; Tue, 23 Mar 93 13:33:17 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19560; Tue, 23 Mar 93 13:33:16 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13632; Tue, 23 Mar 93 13:33:14 -0800 Date: Tue, 23 Mar 1993 13:25:12 -0800 (PST) From: Terry Gray Subject: Re: c-client network mailbox syntax To: Mark Crispin Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There has been a long, drawn out argument on this that finally ended with > a general recognition that either one was arguably ``cleaner and better'' > than the other. Gosh Mark, my recollection was that there was only one person in the room who thought using { } and [] (with/without * ) was "cleaner and better"! :) > There is no clear technical superiority of one over the > other; also, it can be reasonably argued that it is an implementation > detail that can be hidden from users no matter what syntax is used. As John Meyers once pointed out, internal syntax has a nasty habit of creeping out and becoming user-visible! -teg From owner-c-client@cac.washington.edu Tue Mar 23 14:29:24 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14239; Tue, 23 Mar 93 14:29:24 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20485; Tue, 23 Mar 93 14:29:15 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from SUMEX-AIM.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20479; Tue, 23 Mar 93 14:29:11 -0800 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by SUMEX-AIM.Stanford.EDU (4.1/inc-1.0) id AA24682; Tue, 23 Mar 93 14:29:09 PST Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA12790; Tue, 23 Mar 93 14:28:13 -0800 Date: Tue, 23 Mar 1993 14:26:26 -0800 (PST) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: c-client network mailbox syntax To: Mark Crispin Cc: c-client Interest List In-Reply-To: Mark Crispin's message of Tue, 23 Mar 1993 11:33:56 -0800 (PST): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >I'll state flat out: I like the current scheme I too think the current scheme is sufficient. Bill From owner-c-client@cac.washington.edu Tue Mar 23 14:50:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15142; Tue, 23 Mar 93 14:50:53 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20972; Tue, 23 Mar 93 14:50:45 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20966; Tue, 23 Mar 93 14:50:38 -0800 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA04497; Tue, 23 Mar 93 17:50:42 -0500 Message-Id: <9303232250.AA04497@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <25822-0@apache.twg.com>; Tue, 23 Mar 1993 14:50:14 -0800 From: "David Herron" Subject: Re: c-client network mailbox syntax To: Mark Crispin Cc: c-client Interest List Date: Tue, 23 Mar 93 14:50:12 PST In-Reply-To: Your message of Tue, 23 Mar 1993 11:33:56 -0800 (PST). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 26 TEXT , 4 TEXT IMO, using `*' to distinguish a `bboard' is pretty silly. So why not unify on something like {host/access-method}mailbox-idenifier-string Or {server/bboard}sf-lovers or {server/nntp}rec.arts.sf This means that a mailbox-access-method would provide a `type name' along with the function pointers. The users shouldn't be seeing these strings anyway. Even {host}mailbox is pretty ugly. The software should be encapsulating representation details like this and providing them a way to specify "host" and "mailbox-name" and it takes care of munging up the right strings. . it is necessary to state a protocol name, whereas before the protocol was inferred from the syntax. To me specifying the protocol by syntax is a big disadvantage to the current encoding. It greatly limits the number of available protocols because for every one you have to invent a new leading character. With the proposal above there is one syntax which you parse to find the appropriate server code. <- David Herron (work) (home) <- <- "That's our advantage at Microsoft; we set the standards and we can change them." <- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial. From owner-c-client@cac.washington.edu Thu Mar 25 19:07:53 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27540; Thu, 25 Mar 93 19:07:53 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07957; Thu, 25 Mar 93 19:07:39 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07951; Thu, 25 Mar 93 19:07:37 -0800 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA21127; Thu, 25 Mar 93 19:07:35 -0800 Received: from sirius by twinsun.com (4.1/SMI-4.1) id AA16243; Thu, 25 Mar 93 18:50:05 PST Message-Id: <9303260250.AA16243@twinsun.com> Date: Thu, 25 Mar 1993 18:44:38 EST From: Ram Krishnan Subject: Please add me to this mailing list To: imap@cac.washington.edu, c-client@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Description: Please add me to this mailing list. Ram ====================================================================== Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea. From owner-c-client@cac.washington.edu Sun Mar 28 22:06:16 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00114; Sun, 28 Mar 93 22:06:16 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22855; Sun, 28 Mar 93 22:06:03 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22849; Sun, 28 Mar 93 22:06:01 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA13416; Sun, 28 Mar 93 22:06:00 -0800 Date: Sun, 28 Mar 1993 21:43:01 -0800 (PST) From: Mark Crispin Subject: remote mailbox naming syntax for c-client To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The next version of c-client will support a new naming syntax for NNTP access, as a result of action to standardize the format of all remote mailbox names to be (in BNF form): ["*"] "{" host [":" port] ["/" access "}" [mailbox] where: "*" indicator to use bboard access host remote IP host to connect port TCP port number to use (defaults to service's normal port) access access mechanism, imap2 or nntp (defaults to imap2) mailbox defaults to INBOX for mail, general for bboard The syntax *[host]newsgroup for NNTP access is hereby declared dead. All of the people who supported that syntax indicated that it wouldn't be a show stopper for them if it changed, whereas those who advocated the change had quite strong feelings on the matter. -- Mark -- From owner-c-client@cac.washington.edu Sun Mar 28 22:19:01 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00251; Sun, 28 Mar 93 22:19:01 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22917; Sun, 28 Mar 93 22:18:56 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22911; Sun, 28 Mar 93 22:18:55 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA13431; Sun, 28 Mar 93 22:18:53 -0800 Date: Sun, 28 Mar 1993 22:09:28 -0800 (PST) From: Mark Crispin Subject: new memory-miser tenex driver To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The next version of the c-client distribution will come with tenex2, a new memory-miser version of the tenex driver, as the default driver for the mail.txt format. It does not read the entire mailbox into memory, and thus uses what can be significantly less memory than the original tenex driver. For systems on which virtual memory/swap space is at a premium, this could result in swap space savings and resultant performance improvement. Users who have particularly large mailboxes may wish to consider using the mail.txt format once the tenex2 driver is installed in their mailer, since it may result in significant real time speedups and a reduction of system overhead. This is done at the possible cost of extra disk traffic and slower global free text searches. On a system with adequate memory for buffer cache, the overhead compared to the original driver may be merely a matter of some extra system call and context-switching overhead. For the nonce, the original mail.txt format driver will still be available as tenex.c/h, but the makefiles will only build the tenex2.c/h version. If the tenex2 driver turns out to be a winner, the original driver may be allowed to succumb to software rot, so please let me know if the original driver is still needed in your environment. From owner-c-client@cac.washington.edu Sun Apr 18 19:36:58 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20519; Sun, 18 Apr 93 19:36:58 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14715; Sun, 18 Apr 93 19:36:48 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14709; Sun, 18 Apr 93 19:36:46 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA00452; Sun, 18 Apr 93 19:36:45 -0700 Date: Sun, 18 Apr 1993 19:18:29 -0700 (PDT) From: Mark Crispin Subject: proposed IMAP protocol enhancement To: IMAP Interest List Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I, perhaps more than anyone else, want to put a lid on further IMAP additions in the name of stability and getting a Proposed Standard out of this. However, something has come out that has survived even my harsh filters, and I'm throwing it out to the list to be blessed (or damned, as the case may be). The proposed change is a new form of FETCH which allows the selecting fetching of message headers. The problem to be solved is that RFC-822 certain header lines are not represented in the IMAP envelope structure, nor is there any reasonable way to extend the envelope structure to accomodate them. It is considered mandatory that any extension be upwards/downwards compatible and not require revisiting the next time we need to be able to snarf another header. The most obvious example is the ReSent-Date/ReSent-From/ReSent-To header lines. There is an additional problem with these particular header lines in that they can not be arbitrarily reordered and retain the same meaning. Other headers, such as Newsgroups:, are also perceived as interesting. The proposed two new functions are a ``fetch all header lines of this message whose field names match any in this list'' and ``fetch all header lines of this message whose names do not match any in this list''. They take an argument which consists of a list of the field names. The result of these functions is a text string similar to that from RFC822.HEADER. All header lines are returned in the original order of the message (note this is a requirement for useful ReSent information). For example (note that line breaks are here only for clarity): A001 FETCH 23:30 (ENVELOPE RFC822.HEADER.LINES ("Resent-Date" "Resent-From" "Resent-To") would fetch the envelopes and remail information for messages 23 to 30. A001 FETCH 23 RFC822.HEADER.LINES.NOT ("Return-Path" "Received") would fetch the header of message 23 without the ``Return-Path'' or ``Received'' header lines. This would become a fundamental API call in c-client, and c-client would simulate its results if it finds itself talking to an IMAP server that does not support it. Comments please. From owner-c-client@cac.washington.edu Sun Apr 18 20:20:32 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20958; Sun, 18 Apr 93 20:20:32 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28848; Sun, 18 Apr 93 20:20:26 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28836; Sun, 18 Apr 93 20:20:04 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA05499; Sun, 18 Apr 1993 23:20:02 -0400 Date: Sun, 18 Apr 1993 23:10:39 -0400 (EDT) From: Laurence Lundblade Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'd welcome the addition of these to IMAP. I've got a few questions: Would the functions just return plain unparsed strings? If so, then the Resent-xxxx: cases would require the client to do address parsing. This isn't a huge problem since the routines are there in the client anyway. It sounds like you have a choice of requesting the header lines that you want, one at a time, or parsing a big string that comes back. The problem with requesting the lines one at a time would be an RTT for each one, right? I'm also having trouble coming up with a use for the LINES.NOT function. Did you have something in mind? That's not to say it should be take out. I'm interested in the References: field for threading news groups and other mail folders. I think you need it because the full tree of In-Reply-To:'s might not be in the mailbox being threaded. Laurence Lundblade lgl@csgrad.cs.vt.edu or lgl@cac.washington.edu (forwarded to same place) Blacksburg, Virginia or Seattle, Washington On Sun, 18 Apr 1993, Mark Crispin wrote: > > I, perhaps more than anyone else, want to put a lid on further IMAP additions > in the name of stability and getting a Proposed Standard out of this. > However, something has come out that has survived even my harsh filters, and > I'm throwing it out to the list to be blessed (or damned, as the case may be). > > The proposed change is a new form of FETCH which allows the selecting fetching > of message headers. The problem to be solved is that RFC-822 certain header > lines are not represented in the IMAP envelope structure, nor is there any > reasonable way to extend the envelope structure to accomodate them. It is > considered mandatory that any extension be upwards/downwards compatible and > not require revisiting the next time we need to be able to snarf another > header. > > The most obvious example is the ReSent-Date/ReSent-From/ReSent-To header > lines. There is an additional problem with these particular header lines in > that they can not be arbitrarily reordered and retain the same meaning. > > Other headers, such as Newsgroups:, are also perceived as interesting. > > The proposed two new functions are a ``fetch all header lines of this message > whose field names match any in this list'' and ``fetch all header lines of > this message whose names do not match any in this list''. They take an > argument which consists of a list of the field names. The result of these > functions is a text string similar to that from RFC822.HEADER. All header > lines are returned in the original order of the message (note this is a > requirement for useful ReSent information). > > For example (note that line breaks are here only for clarity): > > A001 FETCH 23:30 (ENVELOPE RFC822.HEADER.LINES ("Resent-Date" "Resent-From" > "Resent-To") > > would fetch the envelopes and remail information for messages 23 to 30. > > A001 FETCH 23 RFC822.HEADER.LINES.NOT ("Return-Path" "Received") > > would fetch the header of message 23 without the ``Return-Path'' or > ``Received'' header lines. > > This would become a fundamental API call in c-client, and c-client would > simulate its results if it finds itself talking to an IMAP server that does > not support it. > > Comments please. > From owner-c-client@cac.washington.edu Sun Apr 18 22:10:40 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22077; Sun, 18 Apr 93 22:10:40 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15104; Sun, 18 Apr 93 22:10:34 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15092; Sun, 18 Apr 93 22:10:23 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA00786; Sun, 18 Apr 93 22:10:16 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA14216; Sun, 18 Apr 93 22:10:09 -0700 Date: Sun, 18 Apr 1993 22:00:17 -0700 (PDT) From: Mark Crispin Subject: Re: proposed IMAP protocol enhancement To: Laurence Lundblade Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 18 Apr 1993 23:10:39 -0400 (EDT), Laurence Lundblade wrote: > Would the functions just return plain unparsed strings? If so, then the > Resent-xxxx: cases would require the client to do address parsing. This > isn't a huge problem since the routines are there in the client anyway. Yes, just plain unparsed strings would be returned. I don't particularly understand why you would want to address-parse the ReSent-* strings (other than perhaps to canonicalize their format), but as you point out the routines you need are in c-client anyway. > It sounds like you have a choice of requesting the header lines that you > want, one at a time, or parsing a big string that comes back. The problem > with requesting the lines one at a time would be an RTT for each one, > right? Yes, that's correct. The real intent is to be able to gobble down the useful header lines in addition to what the envelope gives to you and possibly just blat them to the screen without any processing. > I'm also having trouble coming up with a use for the LINES.NOT function. > Did you have something in mind? That's not to say it should be take out. It's in there primarily for symmetry. I don't think Pine will need it, but I'm fairly confident that if I don't put it in now, someone will be nagging me for it later! :-) Also, it was a basic function in MM's header filters, so there is some precedent for its use. > I'm interested in the References: field for threading news groups and other > mail folders. I think you need it because the full tree of In-Reply-To:'s > might not be in the mailbox being threaded. I would be delighted if Pine solved the threading problem this way! ;-) Yes, enabling this sort of thing without having to go and change IMAP again was one of the motivations. It doesn't rescue me from someday having to deal with cross-post suppression in the .newsrc on the server case though. :-( -- Mark -- From owner-c-client@cac.washington.edu Mon Apr 19 10:47:43 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05382; Mon, 19 Apr 93 10:47:43 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05276; Mon, 19 Apr 93 10:47:36 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05270; Mon, 19 Apr 93 10:47:34 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 19 Apr 93 13:47:30 EDT Received: via switchmail; Mon, 19 Apr 1993 13:47:29 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 19 Apr 1993 13:46:23 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 19 Apr 1993 13:46:15 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 19 Apr 1993 13:46:00 -0400 (EDT) Message-Id: Date: Mon, 19 Apr 1993 13:46:00 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu, imap@cac.washington.edu Subject: Re: proposed IMAP protocol enhancement In-Reply-To: References: Beak: Is I strongly support the FETCH RFC822.HEADER.LINES parameter. I don't see the point of FETCH RFC822.HEADER.LINES.NOT. It could be helpful to a client that wants to avoid presenting "uninteresting" headers like "Received:" to a user, but any client that wants to provide this feature is going to have to deal with a server's not providing that parameter anyway. I suppose it comes down to a question of whether the bandwidth saved would justify the cost of the additional parameter. Would it be possible to consider adding an analogous "HEADER name string" SEARCH criteria without opening the entire Pandora's box that is associated with SEARCH? This extension would help greatly in implementing kill files. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Mon Apr 19 14:01:34 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12680; Mon, 19 Apr 93 14:01:34 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19403; Mon, 19 Apr 93 14:01:26 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19397; Mon, 19 Apr 93 14:01:24 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA01277; Mon, 19 Apr 93 14:01:16 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA17018; Mon, 19 Apr 93 14:01:09 -0700 Date: Mon, 19 Apr 1993 13:53:26 -0700 (PDT) From: Mark Crispin Subject: Re: proposed IMAP protocol enhancement To: John Gardiner Myers Cc: c-client Interest List , IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Apr 1993 13:46:00 -0400 (EDT), John Gardiner Myers wrote: > I don't see the point of FETCH RFC822.HEADER.LINES.NOT. My main concern is to avoid regretting having *not* put it in. I think it is rather trivial to do at the same time. The same arguments against it could also be applied against the RFC822.HEADER.LINES functionality as well, but there is a definite groundswell of support for it (and especially for support in c-client). > Would it be possible to consider adding an analogous "HEADER name > string" SEARCH criteria without opening the entire Pandora's box that > is associated with SEARCH? This extension would help greatly in > implementing kill files. If you can come up with a way of doing this without opening Pandora's box on searching, please feel free to suggest it. I'm totally clueless! From owner-c-client@cac.washington.edu Tue Apr 20 21:00:27 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20045; Tue, 20 Apr 93 21:00:27 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27775; Tue, 20 Apr 93 21:00:20 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27760; Tue, 20 Apr 93 20:59:49 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA19328; Tue, 20 Apr 1993 23:59:39 -0400 Date: Tue, 20 Apr 1993 23:52:45 -0400 (EDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sun, 18 Apr 1993, Mark Crispin wrote: > Yes, just plain unparsed strings would be returned. I don't particularly > understand why you would want to address-parse the ReSent-* strings (other > than perhaps to canonicalize their format), but as you point out the routines > you need are in c-client anyway. OK, The reason I had in mind was canonicalization of their format for presentation to the user -- it's a nice thing to keep all the addresses looking similar. > > It sounds like you have a choice of requesting the header lines that you > > want, one at a time, or parsing a big string that comes back. The problem > > with requesting the lines one at a time would be an RTT for each one, > > right? > > Yes, that's correct. The real intent is to be able to gobble down the useful > header lines in addition to what the envelope gives to you and possibly just > blat them to the screen without any processing. I'm a little concerned about RTT's in a mailer that regularly fetches the Resent-XXX:, References: and other fields (presumably many if not most good IMAP clients will do this). You're probably one to think about this more than I, but wouldn't it at least double the number of RTT's for a lot of the normal operations? Is doubling the RTT's a problem? I know there's probably not much else that can be done without breaking existing IMAP clients. Laurence Lundblade lgl@csgrad.cs.vt.edu or lgl@cac.washington.edu (both forward to same place) Blacksburg, Virginia or Seattle, Washington From owner-c-client@cac.washington.edu Fri Apr 23 03:00:39 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24400; Fri, 23 Apr 93 03:00:39 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12177; Fri, 23 Apr 93 03:00:26 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12171; Fri, 23 Apr 93 03:00:24 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA07229; Fri, 23 Apr 93 03:00:15 -0700 Date: Fri, 23 Apr 1993 02:56:50 -0700 (PDT) From: Mark Crispin Subject: Re: proposed IMAP protocol enhancement To: Laurence Lundblade Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Apr 1993 23:52:45 -0400 (EDT), Laurence Lundblade wrote: > I'm a little concerned about RTT's in a mailer that regularly fetches the > Resent-XXX:, References: and other fields (presumably many if not most > good IMAP clients will do this). You're probably one to think about this > more than I, but wouldn't it at least double the number of RTT's for a lot > of the normal operations? Is doubling the RTT's a problem? I know there's > probably not much else that can be done without breaking existing IMAP > clients. That's a good point. I think that when the API is done for this there should be some sort of means to all for it to be fetched it along with something else to avoid the extra RTT. How about fetching it along with section 1 of the body? It'd be a new API function, no matter what. From owner-c-client@cac.washington.edu Fri Apr 23 06:15:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26999; Fri, 23 Apr 93 06:15:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00451; Fri, 23 Apr 93 06:15:29 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00439; Fri, 23 Apr 93 06:15:07 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA12505; Fri, 23 Apr 1993 09:15:05 -0400 Date: Fri, 23 Apr 1993 09:02:07 -0400 (EDT) From: Laurence Lundblade Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, creating a new call in the API that fetches the extended header along with the 1st body part seems fine. I was going to mention this last time, but I was also thinking about the case when you're fetching envelopes. If we do threading based on the References: field (I'm still investigating whether or not that is the way to go) then you'll want to fetch this extended header information with all the envelopes. Since you can fetch them all with one RTT it's still only doubling, so I guess it's OK. I am a little worried about performance for threading. To do threading one has to fetch the envelopes of all the messages in the mailbox, as well as the References fields. While you're redesigning API's maybe an extended mail_fetchstructure could get the Resent-xxx, References and Newsgroups fields. Those are the ones for which we've got a clear need that I can think of. LL On Fri, 23 Apr 1993, Mark Crispin wrote: > > On Tue, 20 Apr 1993 23:52:45 -0400 (EDT), Laurence Lundblade wrote: > > I'm a little concerned about RTT's in a mailer that regularly fetches the > > Resent-XXX:, References: and other fields (presumably many if not most > > good IMAP clients will do this). You're probably one to think about this > > more than I, but wouldn't it at least double the number of RTT's for a lot > > of the normal operations? Is doubling the RTT's a problem? I know there's > > probably not much else that can be done without breaking existing IMAP > > clients. > > That's a good point. I think that when the API is done for this there should > be some sort of means to all for it to be fetched it along with something else > to avoid the extra RTT. How about fetching it along with section 1 of the > body? > > It'd be a new API function, no matter what. > From owner-c-client@cac.washington.edu Fri Apr 23 06:59:06 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27538; Fri, 23 Apr 93 06:59:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00756; Fri, 23 Apr 93 06:59:00 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from info.cren.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00744; Fri, 23 Apr 93 06:58:47 -0700 Received: by info.cren.net (4.1/1.0-BITnet NIC); id AA13199; Fri, 23 Apr 93 09:53:55 EDT Date: Fri, 23 Apr 1993 09:47:35 -0400 (EDT) From: Jim Conklin Subject: Re: proposed IMAP protocol enhancement To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Until a Mail Requirements group defines a real standard for list mail, CREN's RFP for Internet list-management software proposes to use the Resent- headers, so capturing those headers is of considerable importance to us. (It's available from info.cren.net as the files ip-listserv.txt, ip-listserv.ps, or ip-listserv.rtf in the directory /cren-rfp, if you haven't seen it and are interested.) Thanks, Jim Conklin From owner-c-client@cac.washington.edu Wed Apr 28 10:44:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27988; Wed, 28 Apr 93 10:44:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29013; Wed, 28 Apr 93 10:44:14 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29007; Wed, 28 Apr 93 10:44:10 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA15576; Wed, 28 Apr 93 13:44:04 -0400 Message-Id: <9304281744.AA15576@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <9288-0@apache.twg.com>; Wed, 28 Apr 1993 10:44:00 -0700 From: "David Herron" Subject: IMAP on SysVr3 To: c-client Interest List (Non Receipt Notification Requested) (IPM Return Requested) Date: Wed, 28 Apr 93 10:43:58 PDT Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 15 TEXT , 4 TEXT Greetings! I don't want to disrupt the mailing list too much .. but a question came to me of whether IMAP had been ported to System Vr3 (on either 3B2 or Amdahl .. which shouldn't make any difference). The reference implementation is only running on SysVr4 and there are some system calls (ftruncate() being the biggy) which are only on r4 and not r3. At one time I attempted a workaround for the missing ftruncate() but the workaround (copy needed bytes to a second file, then copy back) ended up losing the entire mailbox in some cases (full disk). Has anybody done this ?? David <- David Herron (work) (home) <- <- <- Where su-b-tlety is taken to an art! From owner-c-client@cac.washington.edu Wed Apr 28 13:47:15 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05185; Wed, 28 Apr 93 13:47:15 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12659; Wed, 28 Apr 93 13:47:01 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12653; Wed, 28 Apr 93 13:46:59 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA01006; Wed, 28 Apr 93 13:46:51 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA02517; Wed, 28 Apr 93 13:46:43 -0700 Date: Wed, 28 Apr 1993 13:29:55 -0700 (PDT) From: Mark Crispin Subject: re: IMAP on SysVr3 To: David Herron Cc: c-client Interest List In-Reply-To: <9304281744.AA15576@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There is a system call in some versions of SysV called chsize() which does the exact same thing as ftruncate(). It doesn't seem to be common though. From owner-c-client@cac.washington.edu Tue May 25 16:36:58 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25606; Tue, 25 May 93 16:36:58 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09240; Tue, 25 May 93 16:36:47 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09234; Tue, 25 May 93 16:36:45 -0700 Received: from ssrg-ipc-5.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA02639; Tue, 25 May 93 16:36:42 PDT Date: Tue, 25 May 1993 15:53:16 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: message/rfc822 (the other direction) To: c-client@cac.washington.edu Cc: mrc@camis.stanford.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I got the type message/rfc822 stuff working very well on the incoming side (Many thanks Mark, many things got cleaned up as a result). Now I'm having troubles going the other direction (building a multipart for sending which includes an rfc822 message). I don't know the recommended way to do this, so please don't flame if I've overlooked something obvious, or I'm doing something foolish. All I have to go on right now is from looking at Pine code and reading Internal.DOC. Anyway, I put together a new body part and fill in the envelope and type info such just as for any other attachment (which work fine). In this case I have (part->body)->contents.msg.text point at the actual message text (a complete message w/header). This appears to be what Pine does. Other than that, it's processed like any other attachment (which all work correctly). smtp_mail() is called on the top-level body, and any other parts are sent intact, while the rfc822 attachment always arrives devoid of contents. So, any clues as to what I've done wrong here? From owner-c-client@cac.washington.edu Thu May 27 00:27:56 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07720; Thu, 27 May 93 00:27:56 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20748; Thu, 27 May 93 00:26:46 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20742; Thu, 27 May 93 00:26:44 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA10036; Thu, 27 May 93 00:26:42 -0700 Date: Thu, 27 May 1993 00:08:22 -0700 (PDT) From: Mark Crispin Subject: re: message/rfc822 (the other direction) To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mike - The answer to your question is that the MESSAGE structure is used by the MIME parser only (note the comment to that effect in mail.h in the definition of the BODY structure at the contents union. In particular, body->contents.msg.text is something that is private to the imap2 driver and MUST NOT be used by main programs. The only things in the MESSAGE structure that you may look at are the env and body pointers (body->contents.msg.env and body->contents.msg.body). The text and offset members are private for various drivers (and I'll probably smash them together in a union too since both are never used simultaneously). In order to send a MESSAGE attachment, you have to put it on body- >contents.text like you would any other type of attachment. See the routine rfc822_encode_body() in rfc822.c for how this works. I will be the first to admit that this is ugly, hideous, and inconsistent and I'll probably be reincarnated as a banana slug for doing it that way, but it was easier to program that way, both in c-client and in the main programs. Probably I'll get reincarnated as a banana slug right next to a hungry garter snake (or a fellow with a salt shaker) for this, but Internal.DOC is way out of date (almost a year old). I don't think there are very many lies in it and certainly no egregious ones, but it is missing quite a bit that was added or changed in the past year. The only 100% reliable document right now is the c-client sources, so when in doubt you should refer to them. I'll probably update Internal.DOC sometime after updating the IMAP2 protocol specification, which is a looming Urgent Problem. -- Mark -- From owner-c-client@cac.washington.edu Thu May 27 08:09:16 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16227; Thu, 27 May 93 08:09:16 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00321; Thu, 27 May 93 08:09:07 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00315; Thu, 27 May 93 08:09:06 -0700 Received: from ssrg-ipc-5.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA12103; Thu, 27 May 93 08:09:04 PDT Date: Thu, 27 May 1993 07:23:14 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: re: message/rfc822 (the other direction) To: Mark Crispin Cc: c-client Interest List In-Reply-To: Mark Crispin's message of Thu, 27 May 1993 00:08:22 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > In order to send a MESSAGE attachment, you have to put it > on body-contents.text like you would any other type of attachment. > See the routine rfc822_encode_body() in rfc822.c for how this > works. Yes, I was tracing through yesterday, and found the reference in rfc822_encode_body(). You might do implementors a small favor by changing: /* case MESSAGE: */ /* here for documentation */ to "TYPEMESSAGE" so it's easier to grep. ;-) (Perhaps you've done this already). I might have found it long ago... > I will be the first to admit that this is ugly, hideous, > and inconsistent and I'll probably be reincarnated as a banana > slug for doing it that way, but it was easier to program that > way, both in c-client and in the main programs. I agree it's ugly. > Probably I'll get reincarnated as a banana slug right > next to a hungry garter snake (or a fellow with a salt shaker) > for this, but Internal.DOC is way out of date (almost a year > old). I don't think there are very many lies in it and > certainly no egregious ones, but it is missing quite a bit > that was added or changed in the past year. The only 100% > reliable document right now is the c-client sources, so when > in doubt you should refer to them. > > I'll probably update Internal.DOC sometime after updating > the IMAP2 protocol specification, which is a looming Urgent > Problem. I try to use the sources when I can, but not yet knowing them intimately, the fact that most function calls are through function pointers (I understand and agree with the reasons for doing this), it makes it difficult to really find out the logic flow without single stepping (no fun). I find that the doc is, as you say, almost always correct; but we're left swinging a bit on actually using the MIME interface. But this isn't a flame. As long as I can work through it somehow... But, I may have uncovered a bug "somewhere" in the client related to the rfc822 attachments. I haven't been able to pinpoint it yet. The scenario is, I build the body (with rfc822 attachment sitting in contents.text) and pass it smtp_mail(). When it returns from that function, the msg.env pointer for the attachment has been altered, i.e. is non-zero, but isn't a valid envelope. This causes seg faults immediately afterward when mail_free_body() is called to de-allocate the entire body structure. I'm punting temporarily; going through the partlist and zeroing envelopes for rfc822 attachments before freeing the body. This could cause me to be re-incarnated as a dodo bird, so I could use a little help. mike From owner-c-client@cac.washington.edu Fri May 28 01:11:45 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09661; Fri, 28 May 93 01:11:45 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26761; Fri, 28 May 93 01:10:50 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26755; Fri, 28 May 93 01:10:48 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA11605; Fri, 28 May 93 01:08:29 -0700 Date: Thu, 27 May 1993 19:26:22 -0700 (PDT) From: Mark Crispin Subject: re: message/rfc822 (the other direction) To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mike - I take back what I told you before. Use body->contents.msg.text for attachments of type message. I've changed the rfc822.c source to conform with this. It's cleaner all around. The problem with mail_free_body() was the final straw. If you want to fix it in your own sources without getting the latest version, make that ``case MESSAGE:'' comment be a real ``case TYPEMESSAGE:'' conditional with a break in it (do *not* fall into the default case -- this is a bugfix). Note that the message sending routines do not use the env or body members of the MESSAGE structure; the entire message must appear as a char * string in the text member (msg.text). It turns out that you're the first person who tried to use this code. Pine has its own private code (using disk files), because it has to run on DOS and can't use in-memory buffers the way the c-client code wants to. Please let me know if tonight's version on ftp.cac.washington.edu works any better. -- Mark -- From owner-c-client@cac.washington.edu Sun Jul 11 16:53:15 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22418; Sun, 11 Jul 93 16:53:15 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25800; Sun, 11 Jul 93 16:52:58 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25794; Sun, 11 Jul 93 16:52:56 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA03138; Sun, 11 Jul 93 16:52:55 -0700 Date: Sun, 11 Jul 1993 14:20:40 -0700 (PDT) From: Mark Crispin Subject: message state preservation in COPY and APPEND operations To: IMAP Interest List Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII BACKGROUND: The issue of message state (flags) preservation in COPY and APPEND operations has come up again. This also relates to the behavior of c-client's mail_copy(), mail_move(), and mail_append() operations. The problem is that when messages are copied into a mailbox by one of these operations, their external state is not preserved. That is, their internal date, user flags (a.k.a. keywords), and system flags (deleted, seen, answered, and flagged) are not preserved. In general, what happens is that the copy receives the current date/time as the internal date, and all NIL user and system flags. In the past, some early versions of c-client made some attempt at preservation, although this has pretty much been eliminated in the name of consistency. An egregious exception is that a copy/move (but not an append) of a message in the bezerk (/usr/spool/mail) format preserves the original date of the message as an implementation artifact. Arguably, this behavior is justified; the copy of the message is a separate instance of the message, and the state could be thought of as being associated with the instance instead of with the message. For example, you can define the internal date as being ``when the message was placed in this mailbox'' as opposed to ``when the user received this message''. However, to end users of applications such as Pine, the loss of seen status when a message is copied from one folder to another is a bug. PROBLEMS WITH PRESERVING STATUS: In the case of user flags (keywords), in c-client they are only implemented in the tenex (mail.txt) format, and as implemented are represented as one of 30 binary states whose interpretation as a flag name is per-user and possibly per-mailbox. In the case of system flags, there is no clear concensus of what is ``right'' and what is not. Generally, the idea of flag preservation has revolved around the seen flag. The answered flag is another candidate for preservation, the flagged (urgent) less so. Generally the deleted flag is felt *not* to be a candidate for preservation. A more serious problem is that there is no mechanism at all for preserving or transmitting flags or internal dates via an IMAP APPEND operation. POINTS TO PONDER: Should c-client attempt to preserve message status when copying messages to other folders? If so, what do we do about nasty things such as keywords (which may not make any sense in the target mailbox) and possible ``should not preserve'' flags such as deleted? Can we explain what gets preserved and what does not get preserved in a fashion that mere mortals can understand? [Remember, the current definition is more or less ``never preserved'']. How do we solve the APPEND problem? It seems that perhaps there needs to be a new form of APPEND that includes internal date and flags arguments. Is this worth doing, considering the interoperability costs it would entail? Discussion solicited. -- Mark -- From owner-c-client@cac.washington.edu Sun Jul 11 18:10:27 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23102; Sun, 11 Jul 93 18:10:27 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08776; Sun, 11 Jul 93 18:10:20 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08768; Sun, 11 Jul 93 18:10:18 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Sun, 11 Jul 93 21:10:14 EDT Received: via switchmail; Sun, 11 Jul 1993 21:10:13 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 11 Jul 1993 21:09:29 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 11 Jul 1993 21:09:24 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Sun, 11 Jul 1993 21:09:21 -0400 (EDT) Message-Id: Date: Sun, 11 Jul 1993 21:09:21 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu, imap@cac.washington.edu Subject: Re: message state preservation in COPY and APPEND operations In-Reply-To: References: Beak: Is INTERNALDATE should most definitely *not* be preserved. Any implementation which does so violates RFC 1176, which explictly defines it as "the date and time the message was written to the mailbox." As for preserving flags, the implementation should either preserve all flags it can (except \RECENT, which is magic) or none. I see no reason to make \DELETED a special case. We shouldn't try to second-guess what the user really wants. A client could probably follow an APPEND with a SELECT/SEARCH/STORE FLAGS in order to transmit flags. Problems with this approach include a window where the default flags are visible, difficulty in finding the right message, and interaction with /RECENT. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Sun Jul 11 19:20:45 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23668; Sun, 11 Jul 93 19:20:45 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26217; Sun, 11 Jul 93 19:20:38 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26211; Sun, 11 Jul 93 19:20:37 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA03285; Sun, 11 Jul 93 19:20:36 -0700 Date: Sun, 11 Jul 1993 19:04:07 -0700 (PDT) From: Mark Crispin Subject: non-netnews bboard access in c-client/imapd To: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I expect to soon be implementing non-netnews bboard support in c-client (and, by extension, imapd). Essentially, what will happen is that the bezerk (/usr/spool/mail), tenex (mail.txt), etc. drivers will start responding to open bboard and find bboard requests (presently, there are stubs). There are some issues that need to be straightened out, and I would appreciate input. Tenatively, we have decided that a bboard name that begins with / is not in the netnews namespace. Essentially, a well-known bboard directory name will be prepended to the specification to form a complete filename (or perhaps some sort of chroot() would be done). We are planning on using ~ftp as the directory name, as part of an embryonic capability of being able to use IMAP as an access mechanism to our archives. ~ftp has the advantage of being a well-known place for files that are exported to the network at large, so anonymous interaction is less of an issue here. There has been some discussion about possibly also using /usr/spool/bboard (ala SUMEX) but no conclusion has been reached. Plus, people currently using that name may have some strong feelings on the interaction with anonymous (e.g. they don't want their /usr/spool/bboard to be exported to the entire Internet via IMAP). Present feeling is to shelve this until it is better thought out and there is a concensus. Another anonymous interaction issue is preserving server state ala .newsrc if anonymous is not enabled. Present feeling is to shelve this question as well. So, as currently contemplated, if a user opens the bboard *{ftp.cac.washington.edu}/mail/imap_archive it would open mail/imap_archive on the ~ftp directory as a read-only folder. I'm not sure what should be done for non-anonymous access right now; if it should be treated identically to anonymous access or if it should be an error pending further definition. Ideas? Any other ideas about what this new capability might look like would be gratefully appreciated. I'm hoping to have something running by the end of this week, and I fully expect that this issue will be re-visited again in the future, so please think in terms of a Phase I (albeit not precluding future changes) implementation. Thanks, -- Mark -- From owner-c-client@cac.washington.edu Sun Jul 11 23:07:11 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25568; Sun, 11 Jul 93 23:07:11 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09951; Sun, 11 Jul 93 23:07:04 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09932; Sun, 11 Jul 93 23:06:48 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA08771; Sun, 11 Jul 93 23:06:44 -0700 Date: Sun, 11 Jul 1993 22:59:43 -0700 (PDT) From: Laurence Lundblade Subject: Re: message state preservation in COPY and APPEND operations To: John Gardiner Myers Cc: c-client@cac.washington.edu, imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, and the fact that the mailbox the message is being appened to is probably not even open for the flag setting operation. For some implementations were memory is in short supply, the cost of opening another mailbox would make doing this problematic. I think one of the important questions is how many implementations would break if APPEND was changed, or replaced with a different one. LL On 11 Jul 1993, John Gardiner Myers wrote: > > A client could probably follow an APPEND with a SELECT/SEARCH/STORE > FLAGS in order to transmit flags. Problems with this approach include > a window where the default flags are visible, difficulty in finding > the right message, and interaction with /RECENT. > > -- > _.John G. Myers Internet: jgm+@CMU.EDU > LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up > > > From owner-c-client@cac.washington.edu Sun Jul 11 23:33:42 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25915; Sun, 11 Jul 93 23:33:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10055; Sun, 11 Jul 93 23:33:36 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10049; Sun, 11 Jul 93 23:33:35 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04919; Sun, 11 Jul 93 23:33:34 -0700 Date: Sun, 11 Jul 1993 23:32:05 -0700 (PDT) From: Terry Gray Subject: Re: non-netnews bboard access in c-client/imapd To: Mark Crispin Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 11 Jul 1993, Mark Crispin wrote: > So, as currently contemplated, if a user opens the bboard > *{ftp.cac.washington.edu}/mail/imap_archive > it would open mail/imap_archive on the ~ftp directory as a read-only folder. Mark, Is there a "/anonymous" missing from the above example? (If not, why not?) -teg From owner-c-client@cac.washington.edu Sun Jul 11 23:42:29 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25994; Sun, 11 Jul 93 23:42:29 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26988; Sun, 11 Jul 93 23:42:23 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26982; Sun, 11 Jul 93 23:42:21 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA03441; Sun, 11 Jul 93 23:42:15 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA20074; Sun, 11 Jul 93 23:42:08 -0700 Date: Sun, 11 Jul 1993 23:40:17 -0700 (PDT) From: Mark Crispin Subject: Re: non-netnews bboard access in c-client/imapd To: Terry Gray Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 11 Jul 1993 23:32:05 -0700 (PDT), Terry Gray wrote: > On Sun, 11 Jul 1993, Mark Crispin wrote: > > So, as currently contemplated, if a user opens the bboard > > *{ftp.cac.washington.edu}/mail/imap_archive > > it would open mail/imap_archive on the ~ftp directory as a read-only > > folder. > > Is there a "/anonymous" missing from the above example? Yes and no. > (If not, why not?) Yes, because we're defining anonymous access behavior. No, because we haven't defined non-anonymous access behavior (but need to, at least a stub). From owner-c-client@cac.washington.edu Mon Jul 12 07:50:26 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03740; Mon, 12 Jul 93 07:50:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13035; Mon, 12 Jul 93 07:50:17 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13028; Mon, 12 Jul 93 07:50:15 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 12 Jul 93 10:50:11 EDT Received: via switchmail; Mon, 12 Jul 1993 10:50:11 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 10:48:57 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 10:48:55 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 12 Jul 1993 10:48:53 -0400 (EDT) Message-Id: <4gELbJS00WBwA_LfA8@andrew.cmu.edu> Date: Mon, 12 Jul 1993 10:48:53 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Re: non-netnews bboard access in c-client/imapd In-Reply-To: References: Beak: is Not For non-anonymous access, c-client should do .newsrc-style preservation of \SEEN state. You proabably don't want to use .newsrc itself in order to avoid interaction with netnews systems. Other flags (except \RECENT) are associated with the bboard and should only be manipulated if the user has write access to the bboard (and only if you want to deal with the locking issues) The "don't want /usr/spool/bboard to be exported to anonymous" issue is just an instance of the ACL problem. I hate the "/" naming convention. What's wrong with scanning the netnews driver first, followed by the bezerk and tenex drivers? -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Mon Jul 12 08:24:29 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04370; Mon, 12 Jul 93 08:24:29 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13458; Mon, 12 Jul 93 08:24:19 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13452; Mon, 12 Jul 93 08:24:17 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14583; Mon, 12 Jul 93 08:23:57 -0700 Date: Mon, 12 Jul 1993 08:16:36 -0700 (PDT) From: Terry Gray Subject: Re: non-netnews bboard access in c-client/imapd To: John Gardiner Myers Cc: c-client@cac.washington.edu In-Reply-To: <4gELbJS00WBwA_LfA8@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993, John Gardiner Myers wrote: > I hate the "/" naming convention. What's wrong with scanning the > netnews driver first, followed by the bezerk and tenex drivers? I think what's wrong is that it defines the berzerk namespace as (a) what's left after all possible newsgroup names are subtracted, or worse (b) what's left after *current* newsgroup names are subtracted. Since these two worlds are often administered independently (different places, different people) it is much worse than in a personal/home directory situation where the user *may* be able to avoid conflicts. It's not that I love the "/" convention, I just see the search-path approach as leading to unpredictable behavior, and therefore much greater confusion. -teg From owner-c-client@cac.washington.edu Mon Jul 12 08:31:38 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04698; Mon, 12 Jul 93 08:31:38 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13571; Mon, 12 Jul 93 08:31:32 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13563; Mon, 12 Jul 93 08:31:30 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15024; Mon, 12 Jul 93 08:31:29 -0700 Date: Mon, 12 Jul 1993 08:27:55 -0700 (PDT) From: Terry Gray Subject: Re: non-netnews bboard access in c-client/imapd To: John Gardiner Myers , c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993, Terry Gray wrote: > It's not that I love the "/" convention, I just see the search-path > approach as leading to unpredictable behavior, and therefore much greater > confusion. I just wanted to add that I see great value in this facility if it can be dropped into lots of existing ftp archive servers... but I think the odds are high that somewhere there already exists an archive name that matches a netnews name. (I know I have plenty of conflicts in my own archives.) -teg From owner-c-client@cac.washington.edu Mon Jul 12 08:38:52 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04908; Mon, 12 Jul 93 08:38:52 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13637; Mon, 12 Jul 93 08:38:42 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13631; Mon, 12 Jul 93 08:38:41 -0700 Received: from ssrg-ipc-5.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA09573; Mon, 12 Jul 93 08:38:40 PDT Date: Mon, 12 Jul 1993 08:04:48 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: RE: non-netnews bboard access in c-client/imapd To: Mark Crispin Cc: c-client Interest List In-Reply-To: Mark Crispin's message of Sun, 11 Jul 1993 19:04:07 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII mrc: > There has been some discussion about possibly also using > /usr/spool/bboard (ala SUMEX) but no conclusion has been > reached. Plus, people currently using that name may have some > strong feelings on the interaction with anonymous (e.g. they > don't want their /usr/spool/bboard to be exported to the > entire Internet via IMAP). Present feeling is to shelve this > until it is better thought out and there is a concensus. This is no longer in active use for SUMEX or derivative systems. Unless there are others still using this name, I'm inclined to let it fade into oblivion. > So, as currently contemplated, if a user opens the bboard > *{ftp.cac.washington.edu}/mail/imap_archive > it would open mail/imap_archive on the ~ftp directory as a > read-only folder. I wouldn't want to force this on anybody. If not a run-time option, the directory prefix should be at least a build-time option. The best long-term strategy (IMHO) would be to have a generalized alias for this much as the "INBOX" spec does for mail locations. I may be old-fashioned, but I consider a leading path separator to mean that you want this path taken literally. How about: *{ftp.cac.washington.edu}$ARCHIVE/imap_archive (with or without the '$' or some other character you could check quickly.). ..and as an implementaation concern, you couldn't enter an absolute pathname unless logged in. From owner-c-client@cac.washington.edu Mon Jul 12 09:05:41 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05995; Mon, 12 Jul 93 09:05:41 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14137; Mon, 12 Jul 93 09:05:35 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from HARPER-HALL.CIT.CORNELL.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14131; Mon, 12 Jul 93 09:05:33 -0700 Received: from [132.236.69.173] ([132.236.69.173]) by harper-hall.cit.cornell.edu with SMTP id <511409>; Mon, 12 Jul 1993 12:05:22 -0400 X-Sender: mss1@postoffice.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Jul 1993 13:06:29 -0400 To: Mark Crispin , IMAP Interest List From: mss1@cornell.edu (Michael S Shappe) Subject: Re: message state preservation in COPY and APPEND operations Cc: c-client Interest List Message-Id: <93Jul12.120522edt.511409@harper-hall.cit.cornell.edu> At 17.20 930711 -0400, Mark Crispin wrote: >Should c-client attempt to preserve message status when copying messages to >other folders? I think that status flags should be preserved. If I move a message to another mailbox, that does not mean I'm finished with it; therefore, knowing for certain whether or not I've already responded (for example) to a message is useful information that would be best kepts. It seems to me that user flags could theoretically be preserved in other formats as well -- for example, as an X- header in bezerkly format... From owner-c-client@cac.washington.edu Mon Jul 12 09:45:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07126; Mon, 12 Jul 93 09:45:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14752; Mon, 12 Jul 93 09:45:29 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14746; Mon, 12 Jul 93 09:45:28 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA13898; Mon, 12 Jul 93 09:45:27 -0700 Date: Mon, 12 Jul 1993 09:42:05 -0700 (PDT) From: Laurence Lundblade Subject: Re: non-netnews bboard access in c-client/imapd To: Mark Crispin Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The only thought I had is that it might be desireable for some situations in the future to have the IMAP anon archive set up differently from the anon FTP archive. This is thinking from a NIC operations view. Perhaps some way to configure the path would be good (environment variable?). Also, is there a problem when the /anonymous gets appended that would make it impossible to name the file xxx/anonymous? LL From owner-c-client@cac.washington.edu Mon Jul 12 12:05:09 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12501; Mon, 12 Jul 93 12:05:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16857; Mon, 12 Jul 93 12:04:55 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16851; Mon, 12 Jul 93 12:04:53 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 12 Jul 93 15:04:48 EDT Received: via switchmail; Mon, 12 Jul 1993 15:04:46 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 15:04:32 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 15:04:26 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 12 Jul 1993 15:04:26 -0400 (EDT) Message-Id: Date: Mon, 12 Jul 1993 15:04:26 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Re: non-netnews bboard access in c-client/imapd In-Reply-To: References: Beak: is Not Conflicts with the netnews namespace can be dealt with by proper selection of the namespace. Sites have been defining their own local hierarchies for quite some time. For example, there is no netnews "archive" hierarchy in use, so it is relatively safe to name the archive for this list "archive.c-client". I maintain that it is a mistake to expose implementation details through the interface unless the user is explicitly making implementation-specific requests. In particular, it is wrong to expose the storage format through the default "rubber-room" namespace. Why should the user have to know or care whether the mailing list archives are stored in netnews, berkeley, or tenex format? -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Mon Jul 12 12:41:02 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14461; Mon, 12 Jul 93 12:41:02 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00420; Mon, 12 Jul 93 12:40:55 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00414; Mon, 12 Jul 93 12:40:53 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA04000; Mon, 12 Jul 93 12:40:47 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA22093; Mon, 12 Jul 93 12:40:40 -0700 Date: Mon, 12 Jul 1993 12:39:58 -0700 (PDT) From: Mark Crispin Subject: Re: non-netnews bboard access in c-client/imapd To: Laurence Lundblade Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993 09:42:05 -0700 (PDT), Laurence Lundblade wrote: > The only thought I had is that it might be desireable for some situations > in the future to have the IMAP anon archive set up differently from the > anon FTP archive. This is thinking from a NIC operations view. Perhaps > some way to configure the path would be good (environment variable?). It looks like something of this nature will need to be done, perhaps in a Phase II. > Also, is there a problem when the /anonymous gets appended that would > make it impossible to name the file xxx/anonymous? No, because the /anonymous occurs within the {} set. From owner-c-client@cac.washington.edu Mon Jul 12 12:45:21 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14547; Mon, 12 Jul 93 12:45:21 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00461; Mon, 12 Jul 93 12:45:16 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00455; Mon, 12 Jul 93 12:45:14 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA04006; Mon, 12 Jul 93 12:45:08 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA22105; Mon, 12 Jul 93 12:45:00 -0700 Date: Mon, 12 Jul 1993 12:40:52 -0700 (PDT) From: Mark Crispin Subject: Re: non-netnews bboard access in c-client/imapd To: John Gardiner Myers Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am sympathetic to both John's and Terry's points of view, and can go either way. In defense of Terry's point of view, the context management layer in Pine would tend to hide the implementation details; or rather, the implementation details would only be in a .pinerc file. However, I believe that John has a point about hiding implementation details in general, and that the best way to deal with namespace conflicts is by proper selection of the names within the namespace. From owner-c-client@cac.washington.edu Mon Jul 12 12:49:20 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14597; Mon, 12 Jul 93 12:49:20 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00483; Mon, 12 Jul 93 12:49:14 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00477; Mon, 12 Jul 93 12:49:12 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 12 Jul 93 15:49:09 EDT Received: via switchmail; Mon, 12 Jul 1993 15:49:09 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 15:48:45 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 15:48:38 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 12 Jul 1993 15:48:32 -0400 (EDT) Message-Id: <8gEQ0Eu00WBw8_TpQ1@andrew.cmu.edu> Date: Mon, 12 Jul 1993 15:48:32 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Re: non-netnews bboard access in c-client/imapd In-Reply-To: References: Beak: Is Mark Crispin writes: > In defense of Terry's point of view, the context management layer in Pine > would tend to hide the implementation details; or rather, the implementation > details would only be in a .pinerc file. In this case, wouldn't that be in a .imapdrc file? It should be the IMAP server that hides this particular implementation detail, not the client. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Mon Jul 12 12:53:30 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14788; Mon, 12 Jul 93 12:53:30 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00513; Mon, 12 Jul 93 12:53:23 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00505; Mon, 12 Jul 93 12:53:21 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA04011; Mon, 12 Jul 93 12:53:15 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA22164; Mon, 12 Jul 93 12:53:08 -0700 Date: Mon, 12 Jul 1993 12:51:11 -0700 (PDT) From: Mark Crispin Subject: Re: non-netnews bboard access in c-client/imapd To: John Gardiner Myers Cc: c-client Interest List In-Reply-To: <8gEQ0Eu00WBw8_TpQ1@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993 15:48:32 -0400 (EDT), John Gardiner Myers wrote: > Mark Crispin writes: > > In defense of Terry's point of view, the context management layer in Pine > > would tend to hide the implementation details; or rather, the > > implementation > > details would only be in a .pinerc file. > > In this case, wouldn't that be in a .imapdrc file? It should be the > IMAP server that hides this particular implementation detail, not the > client. No, because the ambiguity would still exist at the IMAP level, and the whole purpose of the ugly syntax is to eliminate the ambiguity. Of course, you can (as you have proposed) declare the ambiguity unimportant, and thus eliminate the need for the ugly syntax. From owner-c-client@cac.washington.edu Mon Jul 12 13:04:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15315; Mon, 12 Jul 93 13:04:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17784; Mon, 12 Jul 93 13:04:43 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17778; Mon, 12 Jul 93 13:04:40 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 12 Jul 93 16:04:29 EDT Received: via switchmail; Mon, 12 Jul 1993 16:04:28 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 16:04:08 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 16:04:05 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 12 Jul 1993 16:04:03 -0400 (EDT) Message-Id: Date: Mon, 12 Jul 1993 16:04:03 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: message state preservation in COPY and APPEND operations Cc: c-client Interest List In-Reply-To: <93Jul12.120522edt.511409@harper-hall.cit.cornell.edu> References: <93Jul12.120522edt.511409@harper-hall.cit.cornell.edu> Beak: Is We could easily extend the APPEND command to accept an optional FLAGS flag_list after the mailbox and string arguments. Clients would have to do fallback on BAD, of course. _.John From owner-c-client@cac.washington.edu Mon Jul 12 13:29:54 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16015; Mon, 12 Jul 93 13:29:54 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18210; Mon, 12 Jul 93 13:29:46 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18204; Mon, 12 Jul 93 13:29:44 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 12 Jul 93 16:29:28 EDT Received: via switchmail; Mon, 12 Jul 1993 16:29:26 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 16:28:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 16:27:48 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 12 Jul 1993 16:27:45 -0400 (EDT) Message-Id: <8gEQZ1m00WBw4_TuUY@andrew.cmu.edu> Date: Mon, 12 Jul 1993 16:27:45 -0400 (EDT) From: John Gardiner Myers To: Mark Crispin Subject: Re: non-netnews bboard access in c-client/imapd Cc: c-client Interest List In-Reply-To: References: Beak: Is Mark Crispin writes: > No, because the ambiguity would still exist at the IMAP level, and the whole > purpose of the ugly syntax is to eliminate the ambiguity. Oh boy, it's the old ambiguous/unambiguous namespace argument again. I mistakenly thought we had gotten this resolved. Exporting an ambiguous/"rubber room" name does not prevent you from also accepting an implementation-dependent unambiguous name, for clients that care. In the absense of a user who explicitly gives implementation-specific information, clients and servers should communicate with ambiguous/"rubber room" names. Otherwise, clients have to make possibly invalid assumptions about the server implementation. If pine assumes that the IMAP server is a c-client imapd, it's likely to get very confused when talking to a non-c-client IMAP server. The CMU IMAP server, for instance, will tell any client trying to use a mailbox or bboard name with a "/" in it to go jump in a lake. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Mon Jul 12 13:32:02 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16073; Mon, 12 Jul 93 13:32:02 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18269; Mon, 12 Jul 93 13:31:56 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18263; Mon, 12 Jul 93 13:31:54 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25975; Mon, 12 Jul 93 13:31:50 -0700 Date: Mon, 12 Jul 1993 13:14:07 -0700 (PDT) From: Terry Gray Subject: Re: non-netnews bboard access in c-client/imapd To: John Gardiner Myers Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993, John Gardiner Myers wrote: > I maintain that it is a mistake to expose implementation details > through the interface unless the user is explicitly making > implementation-specific requests. In particular, it is wrong to > expose the storage format through the default "rubber-room" namespace. > Why should the user have to know or care whether the mailing list > archives are stored in netnews, berkeley, or tenex format? The user shouldn't know or care, neither the format, nor the absolute location in a filesystem... Things I believe to be true: 1. The issue is to define a satisfactory user-visible namespace, not expose implementation details. But the user-visible namespace *might* use a syntax familiar in *some* filesystem! Even if the mapping to the actual filesystem organization is different. 2. It is highly desirable for the sysadmin to be able to choose where/how to store archive or other data. 3. The user-visible namespace *must* support hierarchy, which means a canonical path syntax must be defined, even though it may be relative to a sysadmin-defined root, or a driver-defined abstract root. 4. We are really searching for a way to select an IMAP driver via the name string syntax that goes across the wire. However, whatever means is chosen to tell a driver that "this name's for you", the requirement to support a hierarchical path (without using netnews dot notation) is still with us. -teg From owner-c-client@cac.washington.edu Mon Jul 12 13:44:42 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16548; Mon, 12 Jul 93 13:44:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18491; Mon, 12 Jul 93 13:44:34 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18485; Mon, 12 Jul 93 13:44:33 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26494; Mon, 12 Jul 93 13:44:23 -0700 Date: Mon, 12 Jul 1993 13:33:31 -0700 (PDT) From: Terry Gray Subject: Re: non-netnews bboard access in c-client/imapd To: John Gardiner Myers Cc: Mark Crispin , c-client Interest List In-Reply-To: <8gEQZ1m00WBw4_TuUY@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993, John Gardiner Myers wrote: > Mark Crispin writes: > > No, because the ambiguity would still exist at the IMAP level, and the whole > > purpose of the ugly syntax is to eliminate the ambiguity. > > Oh boy, it's the old ambiguous/unambiguous namespace argument again. > I mistakenly thought we had gotten this resolved. I believe the ambig/nonambig name issues *have* finally been resolved in the context of a single driver. I don't believe they have been resolved in the context of multiple drivers, as we are facing here. > Exporting an ambiguous/"rubber room" name does not prevent you from > also accepting an implementation-dependent unambiguous name, for > clients that care. I think I agree, though I'm not sure who is doing the exporting. > In the absense of a user who explicitly gives implementation-specific > information, clients and servers should communicate with > ambiguous/"rubber room" names. Otherwise, clients have to make > possibly invalid assumptions about the server implementation. Agreed. > If pine assumes that the IMAP server is a c-client imapd, it's likely > to get very confused when talking to a non-c-client IMAP server. The > CMU IMAP server, for instance, will tell any client trying to use a > mailbox or bboard name with a "/" in it to go jump in a lake. Pine makes no such assumption. In fact, we've worked hard to keep *any* notion of filesystem name syntax out of the Pine code. (OK, so there are a couple of exceptions for DOS, but not in c-client functions.) However, a Pine user can *configure* his/her environment to take advantage of an IMAPd that will make an effort to map a user-provided path name into the actual filesystem. This is especially handy (indeed, essential) in environments such as ours where an IMAP server may also be a timesharing host, and it is a requirement to be able to get at the same mailboxes both locally and remotely. -teg From owner-c-client@cac.washington.edu Mon Jul 12 14:11:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17362; Mon, 12 Jul 93 14:11:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18860; Mon, 12 Jul 93 14:11:49 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18854; Mon, 12 Jul 93 14:11:48 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Mon, 12 Jul 93 17:11:43 EDT Received: via switchmail; Mon, 12 Jul 1993 17:11:42 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 17:11:12 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 17:11:10 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 12 Jul 1993 17:11:08 -0400 (EDT) Message-Id: Date: Mon, 12 Jul 1993 17:11:08 -0400 (EDT) From: John Gardiner Myers Subject: Re: non-netnews bboard access in c-client/imapd To: c-client Interest List In-Reply-To: References: Beak: Is Terry Gray writes: > I believe the ambig/nonambig name issues *have* finally been resolved in > the context of a single driver. I don't believe they have been resolved > in the context of multiple drivers, as we are facing here. I think you've already solved the problem of ambiguity between the bezerk and tenex drivers. Why not apply the same solution to the bboard/netnews instance of the same problem? > I think I agree, though I'm not sure who is doing the exporting. I'm trying to make a statement about interfaces in general, but the particular interface I'm trying to apply this to is a server exporting the IMAP protocol. > 2. It is highly desirable for the sysadmin to be able to choose > where/how to store archive or other data. I see this as a driver-parameter/server-configuration issue. A driver could presumably be given a table like: { "archive.", "~ftp/list-archive/" }, { "", "/usr/spool/bboard/" }, To tell it where to search for folders. >From a human-factors standpoint, I would think users are far more used to the netnews dot notation than the unix pathname notation in the context of bboards. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Mon Jul 12 14:29:12 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17722; Mon, 12 Jul 93 14:29:12 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19077; Mon, 12 Jul 93 14:29:06 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19071; Mon, 12 Jul 93 14:29:04 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA24032; Mon, 12 Jul 93 14:29:03 -0700 Date: Mon, 12 Jul 1993 14:11:45 -0700 (PDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: non-netnews bboard access in c-client/imapd To: Terry Gray Cc: John Gardiner Myers , c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII This is interesting. When you say canonical, do you mean as part of the IMAP standard so that all implementations should be able to deal with the heirarchy or is this for particular drivers? Seems like doing it for particular drivers could lead to interoperbility problems, though I certainly see it as desirable. LL On 12 Jul 1993, Terry Gray wrote: ..... > 3. The user-visible namespace *must* support hierarchy, which means > a canonical path syntax must be defined, even though it may be relative > to a sysadmin-defined root, or a driver-defined abstract root. > > 4. We are really searching for a way to select an IMAP driver via the > name string syntax that goes across the wire. However, whatever means > is chosen to tell a driver that "this name's for you", the > requirement to support a hierarchical path (without using netnews dot > notation) is still with us. > > -teg > > > From owner-c-client@cac.washington.edu Mon Jul 12 16:27:26 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21828; Mon, 12 Jul 93 16:27:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20913; Mon, 12 Jul 93 16:27:19 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20907; Mon, 12 Jul 93 16:27:17 -0700 Received: from Mac-Treister.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA23571; Mon, 12 Jul 93 16:27:15 PDT Date: Mon, 12 Jul 93 16:24:30 -0800 From: Adam Treister To: imap@cac.washington.edu Subject: Re: message state preservation in COPY and APPEND operations Cc: c-client Interest List Message-Id: In-Reply-To: Your message of Mon, 12 Jul 1993 16:04:03 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII Just to chime in quickly, I think the status of flags needs to be preserved across transfer of messages. I can see that its messy to implement, but its "the right thing" as far as the user is concerned. If the user has set keywords, they need to be preserved. I could take it so far as to say that a client may want to be able to add status information to the header in the process of doing the move. Imagine an agent which moves mail from the inbox to a folder without the user actually knowing. It may be beneficial if the agent adds a X-Moved-Because header in the process to include the rule that caused the action. (This may be a bit futuristic, but was the first example that came to mind. I'm sure there are more mundane examples.) It sure seems to me that there is a lot of redundancy between Move, Copy, and Append, and maybe preservation of attributes could be a differentation among these commands. (The implication is that Copy is creating a new message, which may not have attributes set, but Move should not change the message in the process) Adam -------------------------------------------------- Adam Treister Polya Hall 205, Stanford CA 94305 - (415) 725-9449 -------------------------------------------------- From owner-c-client@cac.washington.edu Mon Jul 12 16:45:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22254; Mon, 12 Jul 93 16:45:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21163; Mon, 12 Jul 93 16:45:25 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21155; Mon, 12 Jul 93 16:45:23 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA28429; Mon, 12 Jul 93 16:45:19 -0700 Date: Mon, 12 Jul 1993 16:39:37 -0700 (PDT) From: Laurence Lundblade Subject: Re: message state preservation in COPY and APPEND operations To: Adam Treister Cc: imap@cac.washington.edu, c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Actually I don't think preserving flags on a COPY is always the right thing to do. For example is someone saves a messages with the \DELETE flag on, the flag should probably not be copied. The user probably is saving the message from the next expunge. The best solution would, I believe, enable you to set the flags as you wish on all the operations without having to actually open the mailbox. That is, the behavior should be left up to the user interface, and not imposed by IMAP. LL On 12 Jul 1993, Adam Treister wrote: > Just to chime in quickly, I think the status of flags needs to be preserved > across transfer of messages. I can see that its messy to implement, but > its "the right thing" as far as the user is concerned. If the user has set > keywords, they need to be preserved. > > I could take it so far as to say that a client may want to be able to add > status information to the header in the process of doing the move. Imagine > an agent which moves mail from the inbox to a folder without the user > actually knowing. It may be beneficial if the agent adds a X-Moved-Because > header in the process to include the rule that caused the action. (This > may be a bit futuristic, but was the first example that came to mind. I'm > sure there are more mundane examples.) > > It sure seems to me that there is a lot of redundancy between Move, Copy, > and Append, and maybe preservation of attributes could be a differentation > among these commands. (The implication is that Copy is creating a new > message, which may not have attributes set, but Move should not change the > message in the process) > > Adam > -------------------------------------------------- > Adam Treister > Polya Hall 205, Stanford CA 94305 - (415) 725-9449 > -------------------------------------------------- > > > From owner-c-client@cac.washington.edu Mon Jul 12 22:05:19 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27265; Mon, 12 Jul 93 22:05:19 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02954; Mon, 12 Jul 93 22:05:10 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02948; Mon, 12 Jul 93 22:05:06 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA00359; Mon, 12 Jul 93 22:05:04 -0700 Date: Mon, 12 Jul 1993 21:51:38 -0700 (PDT) From: Mark Crispin Subject: Re: message state preservation in COPY and APPEND operations To: Laurence Lundblade Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993 16:39:37 -0700 (PDT), Laurence Lundblade wrote: > The best solution would, I believe, enable you to set the flags as you wish > on all the operations without having to actually open the mailbox. That > is, the behavior should be left up to the user interface, and not imposed > by IMAP. This, I think, is the crux of the problem. Anything that I do in c-client/IMAP is imposed on the user interfaces, even when that choice may be considered wrong by the user interface. I think that is worse than the error of omission, which in this case is simply not to copy the user flags in any message copying operation and let the user interface decide which flags, if any, it wishes to be preserved. However, assuming that it is decided that IMAP should preserve the message state. Let's also assume that we have settled on the following: 1) internal date is NOT copied 2) user flags (keywords) are NOT copied 3) system flags are copied Then that leaves us with the problem of APPEND. We can extend APPEND to have a flags argument. However, that leaves the question of what to do when the server returns BAD because it's a server written for the previous spec. I consider it to be of *utmost* importance to have consistant behavior across all variants of IMAP. Differences in version should be differences in functionality, not differences in fundamental behavior. If we have a case in which APPEND may not preserve the flags in certain cases but would in others, then the user interface is going to have to have code to cover both of these cases, and to do something manually to fix things up. Or the user will have to be told ``that's just tough, sometimes your flags won't be preserved, and there's no way of telling when that will happen.'' I don't consider that to be a desirable situation. Can anyone give a scenario in which consistent behavior is presented to the user? I feel that dropping flags is a minor inconvenience compared to having totally random behavior. Please, when you answer this, don't try to convince me that saving flags would be a nice thing to do. We're all in agreement about this (I think). Try to convince me that we can solve the technical problem of inconsistant behavior. -- Mark -- From owner-c-client@cac.washington.edu Mon Jul 12 23:37:14 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28390; Mon, 12 Jul 93 23:37:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23773; Mon, 12 Jul 93 23:37:06 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23767; Mon, 12 Jul 93 23:37:05 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04966; Mon, 12 Jul 93 23:37:02 -0700 Date: Mon, 12 Jul 1993 23:31:19 -0700 (PDT) From: Terry Gray Subject: Re: non-netnews bboard access in c-client/imapd To: John Gardiner Myers Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993, John Gardiner Myers wrote: > I think you've already solved the problem of ambiguity between the > bezerk and tenex drivers. Why not apply the same solution to the > bboard/netnews instance of the same problem? Not all of us are convinced that saying you can never have a Berzerk folder ending in the string ".txt" is an acceptable solution... > From a human-factors standpoint, I would think users are far more used > to the netnews dot notation than the unix pathname notation in the > context of bboards. The reason I find this unacceptable is that it precludes having file names with dots in them. I believe such names must be allowed, or we need not bother with this exercise at all. (Remember, I believe a major objective of this activity is to be able to make *existing* anonymous ftp archives available via IMAP.) -teg From owner-c-client@cac.washington.edu Tue Jul 13 00:01:29 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28645; Tue, 13 Jul 93 00:01:29 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23877; Tue, 13 Jul 93 00:01:22 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23871; Tue, 13 Jul 93 00:01:21 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05087; Tue, 13 Jul 93 00:01:19 -0700 Date: Mon, 12 Jul 1993 23:45:51 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: non-netnews bboard access in c-client/imapd To: Laurence Lundblade Cc: John Gardiner Myers , c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII LL, About the same time you wrote your msg, I was having some second thoughts about the canonical path syntax issue... I still believe that IMAP must not preclude hierarchical naming syntax; but whether it is both feasible and desirable to define a *canonical* syntax for hierarchy is less clear to me. As John and others have pointed out, we want to keep the protocol (and even its implementation) as free of OS dependencies as possible. As I understand it, IMAP views a hierarchical path name as simply a string name with some possibly funny characters in it. This allows IMAP to deal with "/foo/bar" and "\foo\bar" with equal facility. This seems like a win. Now we also want to distinguish between a namespace recognized by the news driver and a namespace recognized by a different (in this case, Bky) driver. So there are really two issues: 1. Should a canonical path syntax be defined, or leave well-enough alone and keep hierarchy in the "eye of the beholder"? Proably the latter, unless we can really convince ourselves that the former is both feasible and provides some important advantages over the latter. 2. How to differentiate driver namespaces. (An old, old, problem!) We can: a. Leave this to each driver, but with the expectation that a globally unique namespace can be contrived by appropriate link order (so if Berzerk wants to look for "/" so be it...) b. Leave it to each driver, but don't attempt to identify any globally unique namespace across drivers. (John's favorite; my least favorite.) c. Define in IMAP some characteristic of "typical" path names that can be used to select the appropriate driver (e.g. the presence or absence of a "/" or "\".) d. Define some meta-syntax in an IMAP name that can be used to select drivers. Options b and c strike me as the least attractive; option d seems doable but clumsy, leaving option a as the least of several evils in my book. Are there any other options? -teg On Mon, 12 Jul 1993, Laurence Lundblade wrote: > This is interesting. When you say canonical, do you mean as part of the > IMAP standard so that all implementations should be able to deal with the > heirarchy or is this for particular drivers? Seems like doing it for > particular drivers could lead to interoperbility problems, though I > certainly see it as desirable. > > LL > > > On 12 Jul 1993, Terry Gray wrote: > > ..... > > > 3. The user-visible namespace *must* support hierarchy, which means > > a canonical path syntax must be defined, even though it may be relative > > to a sysadmin-defined root, or a driver-defined abstract root. > > > > 4. We are really searching for a way to select an IMAP driver via the > > name string syntax that goes across the wire. However, whatever means > > is chosen to tell a driver that "this name's for you", the > > requirement to support a hierarchical path (without using netnews dot > > notation) is still with us. > > > > -teg > > > > > > > > > From owner-c-client@cac.washington.edu Tue Jul 13 11:11:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14225; Tue, 13 Jul 93 11:11:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29288; Tue, 13 Jul 93 11:11:28 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29282; Tue, 13 Jul 93 11:11:26 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA07250; Tue, 13 Jul 93 11:11:24 -0700 Date: Tue, 13 Jul 1993 10:57:32 -0700 (PDT) From: Laurence Lundblade Subject: Re: message state preservation in COPY and APPEND operations To: Mark Crispin Cc: IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, I don't have any great technical solutions for you, but here's some other suggestions. OK, I understand the problem better now. For APPEND I was thinking that it was recent enough and not so widely implemented that we might be able to afford an incompatible change. Stated another way, I was thinking that the amount of inconsistent behavior experienced by users would be small when considering that IMAP (esp APPEND) is at the beginning of it's life now. I infer that Mark doesn't agree with this. I'd like to hear what other folks on this list think. On COPY, I believe this was under-specifed in RFC-1176 so it's not clear whether the correct behavior is to copy flags or not. If that's the case, then we may have random behavior amongst the existing servers right now and nothing to loose. I suggest that we tighten the spec now as Mark recently suggested. (Note: A user program can set the flags on the source message, copy the message, then reset the flags to get the destination flags set as desired without too much trouble and the overhead of opening the destination mailbox). LL On 12 Jul 1993, Mark Crispin wrote: > On Mon, 12 Jul 1993 16:39:37 -0700 (PDT), Laurence Lundblade wrote: > > The best solution would, I believe, enable you to set the flags as you wish > > on all the operations without having to actually open the mailbox. That > > is, the behavior should be left up to the user interface, and not imposed > > by IMAP. > > This, I think, is the crux of the problem. > > Anything that I do in c-client/IMAP is imposed on the user interfaces, even > when that choice may be considered wrong by the user interface. I think that > is worse than the error of omission, which in this case is simply not to copy > the user flags in any message copying operation and let the user interface > decide which flags, if any, it wishes to be preserved. > > However, assuming that it is decided that IMAP should preserve the message > state. Let's also assume that we have settled on the following: > 1) internal date is NOT copied > 2) user flags (keywords) are NOT copied > 3) system flags are copied > > Then that leaves us with the problem of APPEND. We can extend APPEND to have > a flags argument. However, that leaves the question of what to do when the > server returns BAD because it's a server written for the previous spec. > > I consider it to be of *utmost* importance to have consistant behavior across > all variants of IMAP. Differences in version should be differences in > functionality, not differences in fundamental behavior. > > If we have a case in which APPEND may not preserve the flags in certain cases > but would in others, then the user interface is going to have to have code to > cover both of these cases, and to do something manually to fix things up. Or > the user will have to be told ``that's just tough, sometimes your flags won't > be preserved, and there's no way of telling when that will happen.'' > > I don't consider that to be a desirable situation. > > Can anyone give a scenario in which consistent behavior is presented to the > user? I feel that dropping flags is a minor inconvenience compared to having > totally random behavior. > > Please, when you answer this, don't try to convince me that saving flags would > be a nice thing to do. We're all in agreement about this (I think). Try to > convince me that we can solve the technical problem of inconsistant behavior. > > -- Mark -- > > > From owner-c-client@cac.washington.edu Tue Jul 13 11:16:29 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14348; Tue, 13 Jul 93 11:16:29 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29361; Tue, 13 Jul 93 11:16:18 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from blacks.jpl.nasa.gov by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29355; Tue, 13 Jul 93 11:16:16 -0700 Received: from localhost.jpl.nasa.gov by blacks.jpl.nasa.gov (4.1/SMI-4.1) id AA04915; Tue, 13 Jul 93 11:04:15 PDT Message-Id: <9307131804.AA04915@blacks.jpl.nasa.gov> To: Mark Crispin Cc: John Gardiner Myers , c-client@cac.washington.edu, dank@blacks.jpl.nasa.gov Subject: Re: non-netnews bboard access in c-client/imapd In-Reply-To: Your message of "Mon, 12 Jul 93 12:40:52 PDT." Date: Tue, 13 Jul 93 11:04:15 MDT From: dank@blacks.jpl.nasa.gov I agree that implementation details should be hidden- seems like the right way to avoid namespace clashes is to add a way to "mount" various information sources at arbitrary points in the namespace a la /etc/fstab in sunos. From owner-c-client@cac.washington.edu Tue Jul 13 14:21:42 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21020; Tue, 13 Jul 93 14:21:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02284; Tue, 13 Jul 93 14:21:35 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02276; Tue, 13 Jul 93 14:21:32 -0700 Received: from ssrg-ipc-5.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA17439; Tue, 13 Jul 93 14:21:29 PDT Date: Tue, 13 Jul 1993 13:03:49 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: Re: message state preservation in COPY and APPEND operations To: Laurence Lundblade Cc: Mark Crispin , IMAP Interest List , c-client Interest List In-Reply-To: Laurence Lundblade's message of Tue, 13 Jul 1993 10:57:32 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > OK, I understand the problem better now. For APPEND I was > thinking that it was recent enough and not so widely > implemented that we might be able to afford an incompatible > change. Stated another way, I was thinking that the amount of > inconsistent behavior experienced by users would be small when considering > that IMAP (esp APPEND) is at the beginning of it's life now. I infer > that Mark doesn't agree with this. I'd like to hear what > other folks on this list think. IMAP has been around for quite a long time. The changes not too long ago regarding CREATE and it's relation to MOVE/COPY already broke compatibility on clients, unless you pull some real hacks to parse telemetry messages and use that to determine behaviour. This makes the exact text of the error messages an (unofficial) part of the protocol. If behaviour is changed for APPEND, let's at least use the same back door for negotiating differences. I agree, there probably aren't many APPEND implementations out there, but there might be a few. If it is to be changed, the sooner, the better; while the count of affected clients is still reasonably low.... mike From owner-c-client@cac.washington.edu Wed Jul 14 22:35:40 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25033; Wed, 14 Jul 93 22:35:40 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15532; Wed, 14 Jul 93 22:35:23 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15526; Wed, 14 Jul 93 22:35:21 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA03865; Wed, 14 Jul 93 22:35:19 -0700 Date: Wed, 14 Jul 1993 21:44:14 -0700 (PDT) From: Mark Crispin Subject: Re: non-netnews bboard access in c-client/imapd To: Terry Gray Cc: Laurence Lundblade , John Gardiner Myers , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 12 Jul 1993 23:45:51 -0700 (PDT), Terry Gray wrote: > I still believe that IMAP must not preclude hierarchical naming syntax; > but whether it is both feasible and desirable to define a *canonical* > syntax for hierarchy is less clear to me. As John and others have pointed > out, we want to keep the protocol (and even its implementation) as free of > OS dependencies as possible. I think we are all in violent agreement on this point. > As I understand it, IMAP views a hierarchical path name as simply a > string name with some possibly funny characters in it. This allows IMAP > to deal with "/foo/bar" and "\foo\bar" with equal facility. This is essentially correct. IMAP has no knowledge of hierarchy. > This seems like a win. Now we also want to distinguish between a > namespace recognized by the news driver and a namespace recognized by > a different (in this case, Bky) driver. This is where we have the disagreement. One religion says that it is important to divide the namespace, because it is a problem if two different drivers both believe that the same name is valid, and that this situation must be prevented at all cost. The other religion says that if this situation arises, it is a user error, and is not worth worrying about. > 1. Should a canonical path syntax be defined, or leave well-enough alone > and keep hierarchy in the "eye of the beholder"? Proably the latter, > unless we can really convince ourselves that the former is both > feasible and provides some important advantages over the latter. Certainly the latter. I, as Official Devil's Advocate (or perhaps just Official Devil?), would be very hard to convince on the feasibility issue. No need to talk about the advantages, they're fairly obvious. I remember having to do with TOPS-10/TOPS-20/ITS/UNIX filename mapping issues many years ago. It was surprisingly obvious to a human what the ``right'' mapping was. The only problem, it wasn't possible to express that in any rational rule set that could be implemented in software. > 2. How to differentiate driver namespaces. (An old, old, problem!) > We can: > a. Leave this to each driver, but with the expectation that a > globally unique namespace can be contrived by appropriate link > order (so if Berzerk wants to look for "/" so be it...) > b. Leave it to each driver, but don't attempt to identify any > globally unique namespace across drivers. (John's favorite; > my least favorite.) > c. Define in IMAP some characteristic of "typical" path names > that can be used to select the appropriate driver (e.g. the > presence or absence of a "/" or "\".) > d. Define some meta-syntax in an IMAP name that can be used to > select drivers. > > Options b and c strike me as the least attractive; option d seems doable > but clumsy, leaving option a as the least of several evils in my book. I don't quite understand option (a). There are some implicit link order rules; in particular, any drivers which support the concept of INBOX must come before bezerk or mmdf, since bezerk/mmdf always accept the name INBOX (I haven't quite addressed how these two will fight it out yet...). I think that it is a terrible idea to change link order on the fly or anything like that; ideally, all software should use as close to the same order as possible to keep some semblance of consistant behavior. I personally favor option (b). I see option (c) as a kludge to prevent option (d), and find option (d) to be the least attractive of all. From owner-c-client@cac.washington.edu Thu Jul 15 19:49:43 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26932; Thu, 15 Jul 93 19:49:43 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05041; Thu, 15 Jul 93 19:49:35 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05035; Thu, 15 Jul 93 19:49:32 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Thu, 15 Jul 93 22:49:24 EDT Received: via switchmail; Thu, 15 Jul 1993 22:49:22 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 15 Jul 1993 22:48:35 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 15 Jul 1993 22:48:32 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 15 Jul 1993 22:48:29 -0400 (EDT) Message-Id: Date: Thu, 15 Jul 1993 22:48:29 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Re: message state preservation in COPY and APPEND operations Cc: IMAP Interest List In-Reply-To: References: Beak: Is Mark Crispin writes: > Then that leaves us with the problem of APPEND. We can extend APPEND to have > a flags argument. However, that leaves the question of what to do when the > server returns BAD because it's a server written for the previous spec. The client then has to fall back to using APPEND without the flags argument. The message will be inserted without the flags set, but this is then the same situation you have when you do a COPY on a server written for the "don't copy flags" interpretation of the previous spec. > I consider it to be of *utmost* importance to have consistant behavior across > all variants of IMAP. Differences in version should be differences in > functionality, not differences in fundamental behavior. I'm not quite sure why the inability to preserve flags is a difference in "fundamental behavior" instead of a difference in "functionality." As it is now, you have inconsistent behavior WITHIN a given version of c-client. Whether or not you can even use user-defined flags varies between mailbox to mailbox, depending on what the underlying storage format is. Even if we do decide that flags should be preserved, there are some cases where servers that support fine-grained access control will want to fail to preserve them. If a user is allowed to COPY/APPEND a message into a folder, yet is not allowed to do a SET FLAGS on that folder, the server should not preserve the flags on the inserted message. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Thu Jul 15 20:44:29 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27450; Thu, 15 Jul 93 20:44:29 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05284; Thu, 15 Jul 93 20:44:23 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05278; Thu, 15 Jul 93 20:44:21 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for c-client@cac.washington.edu; Thu, 15 Jul 93 23:44:12 EDT Received: via switchmail; Thu, 15 Jul 1993 23:44:11 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 15 Jul 1993 23:42:47 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 15 Jul 1993 23:42:45 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 15 Jul 1993 23:42:40 -0400 (EDT) Message-Id: Date: Thu, 15 Jul 1993 23:42:40 -0400 (EDT) From: John Gardiner Myers To: c-client@cac.washington.edu Subject: Re: non-netnews bboard access in c-client/imapd In-Reply-To: References: Beak: is Not Terry Gray writes: > Not all of us are convinced that saying you can never have a Berzerk > folder ending in the string ".txt" is an acceptable solution... I have a bezerk mailbox named "foo.txt". Seems to work fine, though I had to create it by hand. The drivers are presumably able to check appropriate magic numbers before accepting names. This admittedly might not perform all that well. > The reason I find [netnews dot notation] unacceptable is that it > precludes having file names with dots in them. Not at all. Remember, in the IMAP world, hierarchy is in the eyes of the beholder. In the mailbox namespace, the bezerk driver can simulate the netnews dot notation using flat files in a single directory. It can do the same in the bboard namespace as long as a leading "/" is not required. Consider my previous search table: { "archive.", "~ftp/list-archive/" }, { "", "/usr/spool/bboard/" }, In ~ftp/list-archive/, you can have the mailboxes "c-client", "c-client.1992", "c-client.1991", "imap", "imap.1992", "imap.1991", etc. > (Remember, I believe a major objective of this activity is to be > able to make *existing* anonymous ftp archives available via IMAP.) To get best results, an archive site is going to have to structure their archive in an IMAP-friendly way and/or spend time configuring their IMAP server. I think this is to be expected. An archive site can alternatively spend minimal effort and have the archives exported via IMAP with unix pathname format names. The ugliness of the names will be compensated for by their trivial conversion between the FTP and IMAP namespaces. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Fri Jul 16 10:30:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12778; Fri, 16 Jul 93 10:30:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11470; Fri, 16 Jul 93 10:30:26 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11464; Fri, 16 Jul 93 10:30:24 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA26795; Fri, 16 Jul 93 10:30:18 -0700 Date: Fri, 16 Jul 1993 10:21:07 -0700 (PDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: Nested mailboxes To: IMAP Interest List Cc: Adam Treister , Jamey Maze , c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I pretty much agree that keeping the hierarchy in the "eye of the beholder" is the best thing. The main advantage of having hierarchy is being able to navigate it: be at one level, get a list at that level, change levels (pwd, ls, cd). Unless we add this functionality to IMAP there's not much to gain by defining hierarchy. Well, actually that's not entirely true. Netnews groups have a hierarchy and there are no NNTP commands to navigate it, but user agents can navigate it because they know the format of the name space. If a hierarchy were defined for the IMAP name space clients could navigate it with the existing protocol, though it would be inefficient for large collections. They would have to get the entire list of all entries in the name space and then navigate it locally. This doesn't seem very practical especially for small clients and large lists. My biggest concern about leaving the hierarchy in the "eye of the beholder" without standardizing it is that specific implementations of client-server pairs will adopt some convention about the name space. They then will only be able to operate well with each other and not other clients or servers. LL From owner-c-client@cac.washington.edu Fri Jul 16 14:22:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21895; Fri, 16 Jul 93 14:22:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15032; Fri, 16 Jul 93 14:19:46 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from dkuug.dk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15026; Fri, 16 Jul 93 14:19:42 -0700 Received: from infotek.dk by dkuug.dk with UUCP id AA11438 (5.65c8/IDA-1.4.4j for cac.washington.edu!c-client); Fri, 16 Jul 1993 23:19:02 +0200 Date: Fri, 16 Jul 1993 23:19:02 +0200 From: plate@infotek.dk Message-Id: <199307162119.AA11438@dkuug.dk> Subject: unsubscribe Content-Type: text Content-Length: 48 Apparently-To: c-client@cac.washington.edu X-Charset: ASCII X-Char-Esc: 29 Please unsubscribe mee:plate@infotek.dk Thanks From owner-c-client@cac.washington.edu Sat Jul 17 10:30:05 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07889; Sat, 17 Jul 93 10:30:05 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00391; Sat, 17 Jul 93 10:29:58 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from intercon.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00385; Sat, 17 Jul 93 10:29:56 -0700 Received: from clint.intercon.com by intercon.com via SMTP id AA05106 (Sendmail 911016.SGI/930401.RS); Sat, 17 Jul 93 13:29:54 -0400 X-Mailer: InterCon TCP/Connect II 1.2b7 Message-Id: <9307171334.AA41933@clint.intercon.com> Date: Sat, 17 Jul 1993 13:34:41 -0500 From: Clint Heiden To: c-client@cac.washington.edu Subject: Re: unsubscribe > Errors-To: owner-c-client@cac.washington.edu > Sender: owner-c-client@cac.washington.edu > Date: Fri, 16 Jul 1993 23:19:02 +0200 > From: plate@infotek.dk > Message-Id: <199307162119.AA11438@dkuug.dk> > Subject: unsubscribe > Content-Type: text > Content-Length: 48 > Apparently-To: c-client@cac.washington.edu > X-Charset: ASCII > X-Char-Esc: 29 > > Please unsubscribe mee:plate@infotek.dk > Thanks > Could you please do the same for me. Thank you very much. Regards, Clint Heiden clint@intercon.com From owner-c-client@cac.washington.edu Sat Jul 17 11:47:36 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08896; Sat, 17 Jul 93 11:47:36 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00672; Sat, 17 Jul 93 11:47:29 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00666; Sat, 17 Jul 93 11:47:28 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07215; Sat, 17 Jul 93 11:47:22 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA03771; Sat, 17 Jul 93 11:47:17 -0700 Date: Sat, 17 Jul 1993 11:25:09 -0700 (PDT) From: Mark Crispin Subject: administrivia To: c-client Interest List , IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There have been a few messages recently requesting [un]subscription to these lists, that have been sent to the entire list. Please remember that the e-mail addresses for all adminstrative requests are: c-client-request@cac.washington.edu imap-request@cac.washington.edu The -request suffix is important. Without that suffix, your message is automatically posted to the entire list. From owner-c-client@cac.washington.edu Thu Aug 5 10:23:06 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03833; Thu, 5 Aug 93 10:23:06 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06410; Thu, 5 Aug 93 10:22:51 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from longball.pnl.gov by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06404; Thu, 5 Aug 93 10:22:50 -0700 Received: by longball.pnl.gov (AIX 3.2/UCB 5.64/4.03) id AA40191; Thu, 5 Aug 1993 10:21:58 -0700 Date: Thu, 5 Aug 1993 10:21:58 -0700 From: d3e482@longball.pnl.gov (JT Simmelink) Message-Id: <9308051721.AA40191@longball.pnl.gov> To: c-client@cac.washington.edu Subject: c-client makefile for AIX 3.2 Cc: I'm looking for a c-client makefile for AIX version 3.2. Is there one available at this time? Jeff Simmelink Battelle PNL, Richland WA Voice: (509) 375-2795, Fax: (509) 375-6703 E-mail: jt_simmelink@pnl.gov From owner-c-client@cac.washington.edu Thu Aug 5 10:31:30 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04112; Thu, 5 Aug 93 10:31:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24824; Thu, 5 Aug 93 10:31:22 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24816; Thu, 5 Aug 93 10:31:20 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00247; Thu, 5 Aug 93 10:30:31 -0700 Date: Thu, 5 Aug 1993 10:28:25 -0700 (PDT) From: David L Miller Subject: Re: c-client makefile for AIX 3.2 To: JT Simmelink Cc: c-client@cac.washington.edu In-Reply-To: <9308051721.AA40191@longball.pnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The current IMAP distribution at ftp.cac.washington.edu (mail/imap.tar.Z) includes an AIX 3.2 version of c-client. -- |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) University of Washington, Networks & Distributed Computing 4545 15th Ave NE, Seattle WA 98105, USA On Thu, 5 Aug 1993, JT Simmelink wrote: > I'm looking for a c-client makefile for AIX version 3.2. Is there one available at this time? > > > Jeff Simmelink > Battelle PNL, Richland WA > Voice: (509) 375-2795, Fax: (509) 375-6703 > E-mail: jt_simmelink@pnl.gov > From owner-c-client@cac.washington.edu Thu Aug 5 11:00:20 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05187; Thu, 5 Aug 93 11:00:20 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06620; Thu, 5 Aug 93 11:00:14 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06614; Thu, 5 Aug 93 11:00:12 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA28377; Thu, 5 Aug 93 11:00:06 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA23854; Thu, 5 Aug 93 10:59:57 -0700 Date: Thu, 5 Aug 1993 10:59:17 -0700 (PDT) From: Mark Crispin Subject: re: c-client makefile for AIX 3.2 To: JT Simmelink Cc: c-client Interest List In-Reply-To: <9308051721.AA40191@longball.pnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 5 Aug 1993 10:21:58 -0700, JT Simmelink wrote: > I'm looking for a c-client makefile for AIX version 3.2. Is there one available at this time? Yes, there is one in the current version, mail/imap.tar.Z on ftp.cac.washington.edu. From owner-c-client@cac.washington.edu Mon Aug 23 08:41:38 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05715; Mon, 23 Aug 93 08:41:38 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15831; Mon, 23 Aug 93 08:41:18 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15824; Mon, 23 Aug 93 08:41:14 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA04236; Mon, 23 Aug 93 17:41:05 +0200 Message-Id: <9308231541.AA04236@nada.kth.se> To: IMAP Interest List , c-client Interest List Cc: psv@nada.kth.se, ojarnef@admin.kth.se Subject: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: Your message of "Mon, 12 Jul 1993 21:51:38 PDT." Date: Mon, 23 Aug 1993 17:41:04 +0200 From: Peter Svanberg There are in my opinion two time stamps which could be interesting for an IMAP client user to use: * send date - the time and date when the author of the message sent it; i.e. the "Date" field in an 822 message Why: As a search constraint when a send date is known. If a message B was sent before a message A, B can't be a comment to A, for example. * arrival date - the date and time when the message was delivered to me, i.e. to the IMAP server Why: As a search constraint when a read date is known. If a user knows to have read a certain message at time T (or later), then that message must have arrived before T. My view of a typical usage of the mailbox concept in IMAP - for personal correspondence - is that the user gets all incoming mail to INBOX, reads them, deletes some and stores others in different mailboxes (as the folders in MH). This storage is done occasionally. RFC 1176 (and the current IMAP2bis draft) specifies: > INTERNALDATE The date and time the message was written to > the mailbox. Some persons on this list has argued that this must be interpreted as what could be called the "storage time" in the above scenario, i.e. at what moment the user happen to take time to tidy up in her INBOX. I don't see why this time stamp would ever be interesting to know, at least not more important than the other two dates. Perhaps there are such examples, in other scenarios. Could anyone tell me? I'm not aware of the history of the INTERNALDATE specification but in my opinion you _could_ interpret it as meaning arrival date. (Or at least that this was what the specifier had in mind, but expressed it vague.) My suggestion is that INTERNALDATE is clarified in IMAP2bis to mean arrival date. I don't know how this is best specified, perhaps: INTERNALDATE The date and time this message was delivered to a mailbox on this IMAP server (via non-IMAP services) Would this give any compatibility problems? As servers have done differently over time, maybe not? My description above also implies that searching on send date is definitely important. Has this been considered? --- Peter Svanberg, NADA, KTH Email: psv@nada.kth.se Dept of Num Analysis and Comp. Science, Royal Institute of Technology Phone: +46 8 790 71 40 S-100 44 Stockholm, SWEDEN Fax: +46 8 790 09 30 From owner-c-client@cac.washington.edu Mon Aug 23 10:00:15 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08565; Mon, 23 Aug 93 10:00:15 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13848; Mon, 23 Aug 93 10:00:04 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13835; Mon, 23 Aug 93 09:59:57 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA06595; Mon, 23 Aug 93 13:00:17 -0400 Message-Id: <9308231700.AA06595@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <10575-0@apache.twg.com>; Mon, 23 Aug 1993 09:59:41 -0700 From: "David Herron" Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: Peter Svanberg (Non Receipt Notification Requested) (IPM Return Requested) Cc: IMAP Interest List (Non Receipt Notification Requested) (IPM Return Requested), c-client Interest List (Non Receipt Notification Requested) (IPM Return Requested), ojarnef@admin.kth.se (Non Receipt Notification Requested) (IPM Return Requested) Date: Mon, 23 Aug 93 9:59:39 PDT In-Reply-To: Your message of Mon, 23 Aug 1993 17:41:04 +0200.<9308231541.AA04236@nada.kth.se> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 22 TEXT , 4 TEXT >From: Peter Svanberg > >* send date - the time and date when the author of the > message sent it; i.e. the "Date" field in an 822 message > >Why: As a search constraint when a send date is known. If a >message B was sent before a message A, B can't be a comment to >A, for example. er... that's assuming the system clocks at A and B are accurate with respect to one another. >* arrival date - the date and time when the message was > delivered to me, i.e. to the IMAP server > >Why: As a search constraint when a read date is known. If a >user knows to have read a certain message at time T (or later), >then that message must have arrived before T. Again relying on accurate system clocks. Also mail may get delayed by random amounts in transmission even if one is well connected to the network. <- David Herron (work) (home) <- <- All hard work brings a profit, but mere talk leads only to poverty. <- Proverbs 14:23 From owner-c-client@cac.washington.edu Mon Aug 23 15:15:32 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23105; Mon, 23 Aug 93 15:15:32 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18072; Mon, 23 Aug 93 15:15:23 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18057; Mon, 23 Aug 93 15:14:56 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA19838; Mon, 23 Aug 93 15:14:37 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00323; Mon, 23 Aug 93 15:14:26 -0700 Date: Mon, 23 Aug 1993 13:10:03 -0700 (PDT) From: Mark Crispin Subject: re: Dates in IMAP (Re: message state preservation in COPY ...) To: Peter Svanberg Cc: IMAP Interest List , c-client Interest List , psv@nada.kth.se, ojarnef@admin.kth.se In-Reply-To: <9308231541.AA04236@nada.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thank you for your comments. On most UNIX-based systems (and on the TOPS-20 system that preceeded it), the ``date/time the message was written to the mailbox'' is an easily available piece of information. On UNIX, this is the date/time in the ``From '' header in mbox-format mailboxes. In mh-format, it's the file write time. This information is generally quite readily available at the time the mailbox is scanned to find messages, making it ideal for any sort of fast date/time dependent activities. One problem which comes up with parsing dates is the various formats which dates may be. UNIX mbox-format has 20 (possibly 28) different formats of ``From '' line, mostly variations in the date/time format, of which 4 or 5 are in common usage. But that's the easy part. The much harder problem is processing the date/times that appear in Date: header lines. If everyone would follow the rules in RFC 822 it would be easy; unfortunately many people do not. So, on top of having to find the Date: header line (which involves actually doing an RFC 822 header parse), you have to worry about doing something reasonable with non-conforming Date headers. It would be attractive if there was some type of searching based upon the Date: header line date (what you call the ``send date''). There are three issues here: 1) reliably understanding the Date: as noted above. 2) getting the Date: quickly as noted above. 3) modifications to SEARCH It was the first two problems that caused a punt on the ``send date'' back in 1986. The third problem is introduced by the necessity of compatibility with the past. If you specify a search that uses the ``send date'', what do you do with a server which has not yet implemented that set of extensions. This is a Pandora's box, since other excellent suggestions have been made for extensions to SEARCH. I am of the opinion that incrementally extending SEARCH is a terrible idea because it will create a plethora of different levels of searching capability. Rather, it would be better to preserve the current level of searching as a basic level, and then define a new extended level that gets a complete set of new capabilities. There is some IMSP interaction here that should be considered too. The other two problems pale by comparison, I think. If someone insists upon sending bogons like: Date: 5/3/93 1:23 BST the software cannot be blamed for whatever interpretation it may make (May 3 or March 5? 1:23 AM or PM? British Summer Time or Bering Standard Time?). The bogon date problem has ameliorated quite a bit since 1986 though. Searching based upon the Date: header will always, I suspect, be quite a bit slower than the internal date, but educated users would be aware of this. From owner-c-client@cac.washington.edu Tue Aug 24 04:26:56 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06205; Tue, 24 Aug 93 04:26:56 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20949; Tue, 24 Aug 93 04:26:46 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20943; Tue, 24 Aug 93 04:26:42 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA14901; Tue, 24 Aug 93 13:19:06 +0200 Message-Id: <9308241119.AA14901@nada.kth.se> To: Mark Crispin Cc: IMAP Interest List , c-client Interest List , ojarnef@admin.kth.se Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: Your message of "Mon, 23 Aug 1993 13:10:03 PDT." Date: Tue, 24 Aug 1993 13:19:05 +0200 From: Peter Svanberg Quoting: Mark Crispin > > Thank you for your comments. Hmm, the presentation part of my message got lost: I am a Unix and Mac systems administrator and programmer and (as such) a heavy email user, having lots of opinions on how email usage could be more effective and nice. I and my colleague Olle Jarnefors have discussed some aspects of the IMAP2bis protocol and will try to express our opinions in a few messages on this list before the WG meeting. So, hopefully it will come more. > Rather, it would be better to preserve the current level of > searching as a basic level, and then define a new extended > level that gets a complete set of new capabilities. There is > some IMSP interaction here that should be considered too. : > The bogon date problem has ameliorated quite a bit since 1986 > though. : > Searching based upon the Date: header will always, I suspect, > be quite a bit slower than the internal date, but educated > users would be aware of this. I infer from this that you think searching with "send date", inspite of its problems, could be put in the extended search level. Correct? _If_ the "send date" is considered important for the client and the user, the server could relieve the client from the parsing problem (as is already done with other parts) through for example "RFC-822-ing" it. But what is your view of my suggestion on clarifying INTERNALDATE and the implications of that to (at least) the date preservation of COPY? Is there _any_ motivation for keeping a "storage date"? --- Peter Svanberg, NADA, KTH Email: psv@nada.kth.se Dept of Num An & CS, Royal Inst of Tech Phone: +46 8 790 71 40 S-100 44 Stockholm, SWEDEN Fax: +46 8 790 09 30 From owner-c-client@cac.washington.edu Tue Aug 24 18:31:57 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00748; Tue, 24 Aug 93 18:31:57 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25582; Tue, 24 Aug 93 18:31:28 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25574; Tue, 24 Aug 93 18:31:26 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA21803; Tue, 24 Aug 93 18:31:20 -0700 Date: Tue, 24 Aug 1993 18:26:21 -0700 (PDT) From: Mark Crispin Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: Peter Svanberg Cc: IMAP Interest List , c-client Interest List , ojarnef@admin.kth.se In-Reply-To: <9308241119.AA14901@nada.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, I think that a date criteria based upon the RFC-822 Date: header (that is, the ``send date'' as you call it) would be something reasonable to include in a future extended SEARCH. Dates are not preserved in COPY. What makes you think they would be? -- Mark -- From owner-c-client@cac.washington.edu Tue Aug 24 19:35:13 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01693; Tue, 24 Aug 93 19:35:13 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25802; Tue, 24 Aug 93 19:35:05 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25796; Tue, 24 Aug 93 19:35:02 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA07809; Wed, 25 Aug 93 04:35:00 +0200 Message-Id: <9308250235.AA07809@nada.kth.se> To: Mark Crispin Cc: IMAP Interest List , c-client Interest List , ojarnef@admin.kth.se Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: Your message of "Tue, 24 Aug 1993 18:26:21 PDT." Date: Wed, 25 Aug 1993 04:34:59 +0200 From: Peter Svanberg Quoting: Mark Crispin > Dates are not preserved in COPY. What makes you think they would be? My thoughts about how it will be used (is what makes me think so). In the debate about preservation, you said: > Arguably, this behavior [not preserving] is justified; the > copy of the message is a separate instance of the message, and > the state could be thought of as being associated with the > instance instead of with the message. For example, you can > define the internal date as being ``when the message was placed > in this mailbox'' as opposed to ``when the user received this > message''. > > However, to end users of applications such as Pine, the loss > of seen status when a message is copied from one folder to > another is a bug. In my scenario, the "copy" of the message is in fact _the_ message, moved from INBOX for storage. If then the internal date is not preserved, it becomes what I called a "storage date", which I still can't see any use of. Furthermore, as this is the date used in SEARCH, the search by date functionality becomes almost useless. What's wrong? My scenario and/or usage of COPY? Then please show me how _you_ think it would be used, and how my usage is made possible. --- Peter Svanberg, Nada, KTH From owner-c-client@cac.washington.edu Wed Aug 25 08:39:02 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15992; Wed, 25 Aug 93 08:39:02 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28751; Wed, 25 Aug 93 08:38:53 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from csgrad.cs.vt.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28739; Wed, 25 Aug 93 08:38:17 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA12410; Wed, 25 Aug 1993 11:37:07 -0400 Date: Wed, 25 Aug 1993 11:35:40 -0400 (EDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: re: Dates in IMAP (Re: message state preservation in COPY ...) To: Mark Crispin Cc: Peter Svanberg , IMAP Interest List , c-client Interest List , psv@nada.kth.se, ojarnef@admin.kth.se In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Just thought I'd mention that Pine does parse the Date: field. It uses some heuristics and is generally successful. The message date displayed in Pine's index is from a full parse of the Date: field. In thousands of messages I've seen in Pine I can only think of less than 5 or so that had dates so bad you couldn't parse them. It also uses the parse date field for sorting by date, though the lack of consist time zone usage sometimes causes problems. Laurence Lundblade lgl@csgrad.cs.vt.edu 703-552-2537 Virginia Tech -- Blacksburg, Virginia On Mon, 23 Aug 1993, Mark Crispin wrote: > .... > > The much harder problem is processing the date/times that appear in Date: > header lines. If everyone would follow the rules in RFC 822 it would be easy; > unfortunately many people do not. So, on top of having to find the Date: > header line (which involves actually doing an RFC 822 header parse), you have > to worry about doing something reasonable with non-conforming Date headers. > > It would be attractive if there was some type of searching based upon the > Date: header line date (what you call the ``send date''). There are three > issues here: > 1) reliably understanding the Date: as noted above. > 2) getting the Date: quickly as noted above. > 3) modifications to SEARCH > From owner-c-client@cac.washington.edu Wed Aug 25 10:00:19 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19032; Wed, 25 Aug 93 10:00:19 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13168; Wed, 25 Aug 93 10:00:05 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13159; Wed, 25 Aug 93 09:59:59 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA29423; Wed, 25 Aug 93 12:58:58 -0400 Message-Id: <9308251658.AA29423@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <10346-0@apache.twg.com>; Wed, 25 Aug 1993 09:59:38 -0700 From: "David Herron" Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: Peter Svanberg (Non Receipt Notification Requested) (IPM Return Requested) Cc: Mark Crispin (Non Receipt Notification Requested) (IPM Return Requested), IMAP Interest List (Non Receipt Notification Requested) (IPM Return Requested), c-client Interest List (Non Receipt Notification Requested) (IPM Return Requested), ojarnef@admin.kth.se (Non Receipt Notification Requested) (IPM Return Requested) Date: Wed, 25 Aug 93 9:59:34 PDT In-Reply-To: Your message of Wed, 25 Aug 1993 04:34:59 +0200.<9308250235.AA07809@nada.kth.se> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 22 TEXT , 4 TEXT Peter Svanberg writes: >Quoting: Mark Crispin > >> Dates are not preserved in COPY. What makes you think they would be? > >In my scenario, the "copy" of the message is in fact _the_ >message, moved from INBOX for storage. If then the internal >date is not preserved, it becomes what I called a "storage >date", which I still can't see any use of. Furthermore, as this >is the date used in SEARCH, the search by date functionality >becomes almost useless. Peter's scenario matches with mine. (Given accuracy and synchronization of time stamps...) Copying messages around should preserve the contents of the message. It should be a *copy* of the message, not a new instance. (I hadn't ever seen this detail in previous readings of IMAP... I saw `copy' and thought it would only copy, not munge while copying). I fail to see any logic in a munging copy. Care to elaborate? <- David Herron (work) (home) <- <- All hard work brings a profit, but mere talk leads only to poverty. <- Proverbs 14:23 From owner-c-client@cac.washington.edu Wed Aug 25 11:34:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22372; Wed, 25 Aug 93 11:34:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14940; Wed, 25 Aug 93 11:34:31 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14920; Wed, 25 Aug 93 11:33:58 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA26428; Wed, 25 Aug 93 11:33:54 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA04069; Wed, 25 Aug 93 11:30:05 -0700 Date: Wed, 25 Aug 1993 11:14:31 -0700 (PDT) From: William Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: David Herron Cc: Peter Svanberg , Mark Crispin , IMAP Interest List , c-client Interest List , Non Receipt Notification Requested In-Reply-To: David Herron's message of Wed, 25 Aug 93 9:59:34 PDT: <9308251658.AA29423@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think the idea behind recreating for bsd style mail boxes the "From .." line during a COPY, from which the "storage" or internal date is determined is that a SEARCH ON/SINCE/BEFORE date means since, before or after the message *arrived in the selected mailbox.* Thus, the "From .." lines are always in chronological order. If one preserved this line from the original INBOX, then this order is essentially random. As Mark mentioned, mh like folders avoid this difficulty by using the write date of the folder. The current approach for bsd and tenex style internal dates has historical precedence going back about a couple of decades, and certainly, one can argue that the current implementation gives a consistency across all mailboxes. I personally prefer this approach. And agree with Mark that one should consider new date searches in the new extended search command. Bill From owner-c-client@cac.washington.edu Wed Aug 25 12:08:33 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23639; Wed, 25 Aug 93 12:08:33 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15513; Wed, 25 Aug 93 12:08:24 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15494; Wed, 25 Aug 93 12:07:59 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA27067; Wed, 25 Aug 93 12:07:56 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA04083; Wed, 25 Aug 93 12:04:08 -0700 Date: Wed, 25 Aug 1993 12:01:41 -0700 (PDT) From: William Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: Bill_Yeager@camis.stanford.edu Cc: David Herron , Peter Svanberg , Mark Crispin , IMAP Interest List , c-client Interest List , Non Receipt Notification Requested In-Reply-To: William Yeager's message of Wed, 25 Aug 1993 11:14:31 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > SEARCH ON/SINCE/BEFORE date > > means since, before or after Yes, yes, I meant "means on, since or before" here. Sorry :-). I just got back from an hour+ of tennis, it was 80F, and my brain is in a slightly marginal state. Bill From owner-c-client@cac.washington.edu Wed Aug 25 13:51:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26955; Wed, 25 Aug 93 13:51:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17104; Wed, 25 Aug 93 13:51:15 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17096; Wed, 25 Aug 93 13:51:11 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA04469; Wed, 25 Aug 93 16:50:39 -0400 Message-Id: <9308252050.AA04469@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <15124-0@apache.twg.com>; Wed, 25 Aug 1993 13:50:50 -0700 From: "David Herron" Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: IMAP Interest List (Non Receipt Notification Requested) (IPM Return Requested), c-client Interest List (Non Receipt Notification Requested) (IPM Return Requested) Date: Wed, 25 Aug 93 13:50:48 PDT In-Reply-To: Your message of Wed, 25 Aug 1993 11:14:31 -0700 (PDT). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 19 TEXT To clarify .. I may have been mistaken about what I was replying to. (I no longer have the message handy to check) I took the quote from Mark as saying that COPY creates a new instance and modifies the date in Date: not the one in From. Since the From line is ridiculous (messages should be stored in a directory with one message per file) and in any case is not *part* of the message so I don't care much about what is done with it. If it is where you wish to store a time stamp for when it was appended to the folder, be my guest. Does it also change the return address that's stored on the From line? (Doesn't have to but it might be interesting to record the old folder name..) Does it preserve old From lines? (Doesn't have to) Having the Date: field independantly searchable from the storage date is what should be done. David From owner-c-client@cac.washington.edu Wed Aug 25 14:12:34 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27889; Wed, 25 Aug 93 14:12:34 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17431; Wed, 25 Aug 93 14:12:23 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17419; Wed, 25 Aug 93 14:12:00 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA29830; Wed, 25 Aug 93 14:11:59 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA04160; Wed, 25 Aug 93 14:08:10 -0700 Date: Wed, 25 Aug 1993 14:07:22 -0700 (PDT) From: William Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: David Herron Cc: IMAP Interest List , c-client Interest List In-Reply-To: David Herron's message of Wed, 25 Aug 93 13:50:48 PDT: <9308252050.AA04469@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Having the Date: field independantly searchable from the storage > date is > what should be done. I think there will be a consensus on this one. Bill From owner-c-client@cac.washington.edu Wed Aug 25 14:20:11 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28256; Wed, 25 Aug 93 14:20:11 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00941; Wed, 25 Aug 93 14:20:02 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00925; Wed, 25 Aug 93 14:19:39 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA22422; Wed, 25 Aug 93 14:19:29 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA08330; Wed, 25 Aug 93 14:19:20 -0700 Date: Wed, 25 Aug 1993 14:17:37 -0700 (PDT) From: Mark Crispin Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: Bill_Yeager@camis.stanford.edu Cc: David Herron , IMAP Interest List , c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 25 Aug 1993 14:07:22 -0700 (PDT), William Yeager wrote: > > Having the Date: field independantly searchable from the storage > > date is > > what should be done. > > I think there will be a consensus on this one. I agree. The delay is not on whether or not this is a good idea, but in getting together a full list of searching extensions. There is enough problem with multiple levels of support in IMAP software as it is without adding more complex levels. From owner-c-client@cac.washington.edu Wed Aug 25 16:43:49 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04365; Wed, 25 Aug 93 16:43:49 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01753; Wed, 25 Aug 93 16:43:40 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01747; Wed, 25 Aug 93 16:43:36 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19216; Thu, 26 Aug 93 01:43:34 +0200 Message-Id: <9308252343.AA19216@nada.kth.se> To: IMAP Interest List , c-client Interest List Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: Your message of "Wed, 25 Aug 1993 13:50:48 PDT." <9308252050.AA04469@eco.twg.com> Date: Thu, 26 Aug 1993 01:43:33 +0200 From: Peter Svanberg William Yeager wrote: > I think the idea behind recreating for bsd style mail boxes the > "From .." line during a COPY, from which the "storage" or > internal date is determined is that a > > SEARCH ON/SINCE/BEFORE date > > means since, before or after the message *arrived in the > selected mailbox.* Thus, the "From .." lines are always in > chronological order. If one preserved this line from the > original INBOX, then this order is essentially random. But isn't the message number enough for the chronology? One more time (I _want_ to know how you are thinking): What you are saying is that you consider it more interesting to search on (an hence more likely that you know) when a certain message was _stored_ in the mailbox, than when it _arrived_ to you? In my mail usage I often store messages in a very un-chronological mode - suddenly I can find some old messages in my "unsorted" folder which I move to another folder, putting them after more recent messages. Is that so unusual? If I later search in that folder, with your approach I will have to remember when those old messages were stored. > As Mark > mentioned, mh like folders avoid this difficulty by using the > write date of the folder. (I suppose you meant "of the file".) This is unimportant in MH, as it uses the Date:-field for sorting and searching. Quoting: "David Herron" > > Since the From line is ridiculous (messages > should be stored in a directory with one message per file) and in any case > is not *part* of the message so I don't care much about what is done with it. > If it is where you wish to store a time stamp for when it was appended > to the folder, be my guest. So you don't care about searching? (This i the date used for that.) --- Peter Svanberg, Nada, KTH From owner-c-client@cac.washington.edu Wed Sep 8 17:36:51 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27686; Wed, 8 Sep 93 17:36:51 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21922; Wed, 8 Sep 93 17:36:16 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21916; Wed, 8 Sep 93 17:36:07 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA14213; Wed, 8 Sep 93 17:34:50 PDT Date: Wed, 8 Sep 93 17:34:35 -0800 From: Adam Treister To: mrc@cac.washington.edu Subject: My C-client Search Fetches Extra Envs Cc: c-client@cac.washington.edu Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Mark, (or anyone with a good answer): I'm having a pb: Mailstrom goes off to fetch all envelopes at places where it shouldn't, eg: close mailbox or iconify window. Whats happening is that the client is doing a search (on close, it searches for deleted messages to decide if it should ask if the user wants to expunge) and the search is requiring a run thru the cache to check the searched flag. Is there another way to know if there were hits, without fetching extra envelopes, while still not mucking into c-client's layer? (Granted, much of the delay is that I'm dumping the envelopes in my debug window and this slows things down alot, but in the case of big mailboxes, its important to only fetch the minimum amount.) Adam ------------------- Here are Mailstrom's Search and GetElement routines: short Mailbox :: Search(char *criteria) { short i, numFound; if (!stream) return(0); mail_search (stream, criteria); numFound = 0; for (i = 1; i <= NMSGS(stream); i ++) { MESSAGECACHE *element = GetElement(i); if (element->searched) numFound ++; } return(numFound); } /********************************************************/ MESSAGECACHE* Mailbox :: GetElement(long msgNo) { BODY *body; ENVELOPE *env; MESSAGECACHE *element; ASSERT(msgNo != 0); if (msgNo AND stream) { env = mail_fetchstructure (stream,msgNo,&body); element = mail_elt(stream,msgNo); return(element); } else return NULL; } From owner-c-client@cac.washington.edu Wed Sep 8 21:16:30 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00806; Wed, 8 Sep 93 21:16:30 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23568; Wed, 8 Sep 93 21:16:21 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23562; Wed, 8 Sep 93 21:16:20 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA15444; Wed, 8 Sep 93 21:16:15 -0700 Date: Wed, 8 Sep 1993 21:07:06 -0700 (PDT) From: Mark Crispin Subject: re: My C-client Search Fetches Extra Envs To: Adam Treister Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Adam - The newest version of the IMAP toolkit, just installed on the CAC ftp archive, offers a c-client has the ability to turn off prefetch of envelopes when doing an IMAP search when caching is enabled. To use this facility, make sure you #include imap2.h as well as mail.h, and do something like mail_parameters (mail_open (NIL,"{x/imap2}",OP_PROTOTYPE),SET_PREFETCH,NIL); early in your program. The mail_open() call returns the prototype stream that you then feed to mail_parameters; you don't need to worry about calling mail_close() on it. Something like mail_parameters (mail_open (NIL,"{x/imap2}",OP_PROTOTYPE),SET_PREFETCH, (void *) T); will re-enable search prefetching of envelopes. -- Mark -- From owner-c-client@cac.washington.edu Thu Sep 9 11:02:57 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17264; Thu, 9 Sep 93 11:02:57 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02170; Thu, 9 Sep 93 11:02:44 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02163; Thu, 9 Sep 93 11:02:41 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA28496; Thu, 9 Sep 93 11:02:37 PDT Date: Thu, 9 Sep 93 11:02:15 -0800 From: Adam Treister To: c-client@cac.washington.edu Subject: TestInclusion funuction for c-client Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Mark is so responsive is providing functionality, that I just have to keep asking.... Its pretty easy to have the client support filtered views by doing a search right after mail_open and adding the hits to a local list. Now I'm wondering how arrival of new messages, and update of potentially several views onto the Inbox will work. (Can one assume that only the Inbox could receive unsolicited additional messages?) It would be useful to have a function to test if a particular message is a hit for a given search string. EG: Boolean TestInclusion(long msgNo,char *criteria); This would send a SEARCH criteria to the server, and watch if msgNo came back in the results, hopefully without affecting the element->searched fields. This can be as easily accomplished at the app level, but does seem a good candidate for migration to the c-client level. Adam From owner-c-client@cac.washington.edu Thu Sep 9 19:42:11 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02303; Thu, 9 Sep 93 19:42:11 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10206; Thu, 9 Sep 93 19:41:36 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10200; Thu, 9 Sep 93 19:41:33 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id WAA14903; Thu, 9 Sep 1993 22:41:30 -0400 Received: via switchmail; Thu, 9 Sep 1993 22:41:30 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 9 Sep 1993 22:40:15 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 9 Sep 1993 22:40:13 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 9 Sep 1993 22:40:11 -0400 (EDT) Message-Id: <0gXyY=600WBw4pEYUt@andrew.cmu.edu> Date: Thu, 9 Sep 1993 22:40:11 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Re: TestInclusion funuction for c-client In-Reply-To: References: Beak: is Not One can most definitely *not* assume that only INBOX can receive unsolicited additional messages. What you might want to do is for each view filter perform a SEARCH command restricted near the additional messages (using RECENT and/or SINCE) and add the new hits to your view. _.John From owner-c-client@cac.washington.edu Thu Sep 9 19:45:04 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02327; Thu, 9 Sep 93 19:45:04 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03610; Thu, 9 Sep 93 19:44:47 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03604; Thu, 9 Sep 93 19:44:46 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA16837; Thu, 9 Sep 93 19:44:41 -0700 Date: Thu, 9 Sep 1993 19:44:04 -0700 (PDT) From: Mark Crispin Subject: Re: TestInclusion funuction for c-client To: John Gardiner Myers Cc: c-client Interest List In-Reply-To: <0gXyY=600WBw4pEYUt@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Sep 1993 22:40:11 -0400 (EDT), John Gardiner Myers wrote: > One can most definitely *not* assume that only INBOX can receive > unsolicited additional messages. > > What you might want to do is for each view filter perform a SEARCH > command restricted near the additional messages (using RECENT and/or > SINCE) and add the new hits to your view. John says almost exactly what I was going to say. From owner-c-client@cac.washington.edu Thu Sep 23 19:10:46 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11950; Thu, 23 Sep 93 19:10:46 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24165; Thu, 23 Sep 93 19:10:37 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24153; Thu, 23 Sep 93 19:10:04 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA01335; Thu, 23 Sep 93 19:10:02 -0700 Date: Thu, 23 Sep 1993 19:00:47 -0700 (PDT) From: Mark Crispin Subject: IMAP toolkit 3.0 frozen and formally released To: c-client Interest List , IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII In conjunction with the 3.85 release of Pine: Version 3.0 of the IMAP toolkit is now frozen. The final version may be found on ftp.cac.washington.edu:mail/imap-3.0.tar.Z Work has now started on 3.1 of the IMAP toolkit. Some of the planned features for 3.1 in the next few months are: . support for the new IMAP2bis draft specification including disconnected use support . makefile control of mail_link() operations including control of driver precedence . outgoing mail queue for DOS (for disconnected use) . integration of tenex and DOS MTX formats & no more special meaning of *.txt file names . support for directory traversal Other features are planned; these are what are at the top of the list From owner-c-client@cac.washington.edu Tue Sep 28 12:46:54 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29846; Tue, 28 Sep 93 12:46:54 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18666; Tue, 28 Sep 93 12:46:37 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18660; Tue, 28 Sep 93 12:46:33 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA06561; Tue, 28 Sep 1993 15:46:24 -0400 Received: via switchmail; Tue, 28 Sep 1993 15:46:19 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 28 Sep 1993 15:45:39 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 28 Sep 1993 15:45:23 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 28 Sep 1993 15:45:06 -0400 (EDT) Message-Id: Date: Tue, 28 Sep 1993 15:45:07 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Kerberos diffs for 3.0 c-client Beak: Is Here are the Kerberos authentication diffs for the 3.0 c-client. Some assembley required, especially if you're not compiling on a sun with gcc. Compile with the KERBEROS macro defined. You probably *don't* want to compile with ANDREW defined. These diffs include an interface change to server_login() which Mark hasn't picked up yet. diff -cr ./makefile.sun /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/makefile.sun *** ./makefile.sun Wed Jan 8 02:18:11 1992 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/makefile.sun Tue Sep 28 13:29:21 1993 *************** *** 35,44 **** all: rm -rf systype ANSI/c-client/Makefile non-ANSI/c-client/Makefile ! ln -s non-ANSI systype cd systype/c-client; ln -s makefile.sun Makefile ! cd ms;make ! cd ipopd;make cd imapd;make clean: --- 35,44 ---- all: rm -rf systype ANSI/c-client/Makefile non-ANSI/c-client/Makefile ! ln -s ANSI systype cd systype/c-client; ln -s makefile.sun Makefile ! # cd ms;make ! # cd ipopd;make cd imapd;make clean: diff -cr ./ANSI/c-client/imap2.c /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/imap2.c *** ./ANSI/c-client/imap2.c Wed Sep 8 23:31:22 1993 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/imap2.c Tue Sep 28 14:31:51 1993 *************** *** 48,53 **** --- 48,60 ---- #include "osdep.h" #include "imap2.h" #include "misc.h" + #ifdef KERBEROS + #include "kerberos.h" + #endif /* KERBEROS */ + + #ifdef ANDREW + static char *defaulthost="hogtown.andrew.cmu.edu"; + #endif /* Driver dispatch used by MAIL */ *************** *** 103,109 **** --- 110,120 ---- DRIVER *map_valid (char *name) { + #ifdef ANDREW + return &imapdriver; + #else /* ANDREW */ return mail_valid_net (name,&imapdriver,NIL,NIL); + #endif /* ANDREW */ } *************** *** 376,388 **** --- 387,416 ---- MAILSTREAM *map_open (MAILSTREAM *stream) { long i,j; + #ifdef KERBEROS + char username[MAILTMPLEN],pwd[3*MAILTMPLEN],tmp[MAILTMPLEN]; + #else char username[MAILTMPLEN],pwd[MAILTMPLEN],tmp[MAILTMPLEN]; + #endif NETMBX mb; char *s; IMAPPARSEDREPLY *reply = NIL; /* return prototype for OP_PROTOTYPE call */ if (!stream) return &imapproto; + #ifdef ANDREW + if (!mail_valid_net_parse (stream->mailbox,&mb)) { + strcpy(mb.host, defaulthost); + if (*stream->mailbox == '*') { + mb.bbdflag = 1; + strcpy(mb.mailbox, stream->mailbox+1); + } + else { + strcpy(mb.mailbox, stream->mailbox); + } + } + #else ANDREW mail_valid_net_parse (stream->mailbox,&mb); + #endif /* default mailbox name */ if (!*mb.mailbox) strcpy (mb.mailbox,mb.bbdflag ? "general" : "INBOX"); if (LOCAL) { /* if stream opened earlier by us */ *************** *** 446,457 **** --- 474,505 ---- strcpy (username,"anonymous"); strcpy (pwd,*lhostn ? lhostn : "foo"); } + #ifdef KERBEROS + else if (i == 0) { + kerberos_login(mb.host, username, pwd, tmp); + } + #endif /* KERBEROS */ else mm_login (tcp_host (LOCAL->tcpstream),username,pwd,i); /* abort if he refuses to give a password */ if (*pwd == '\0') i = map_maxlogintrials; else { /* send "LOGIN username pwd" */ + #ifdef KERBEROS if (imap_OK (stream,reply = imap_send (stream,"LOGIN",username, + pwd))) { + if (i == 0) { + if (!tmp[0]) { + mm_log("Unable to check authentication of server", WARN); + } + else if (strncmp(reply->text, tmp, strlen(tmp))) { + mm_log("Server failed to authenticate itself", WARN); + } + } + break; + } + #else + if (imap_OK (stream,reply = imap_send (stream,"LOGIN",username, pwd))) break; + #endif /* output failure and try again */ mm_log (reply->text,WARN); /* give up now if connection died */ diff -cr ./ANSI/c-client/kerberos.c /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/kerberos.c *** ./ANSI/c-client/kerberos.c Tue Sep 28 15:31:13 1993 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/kerberos.c Tue Sep 28 14:57:47 1993 *************** *** 0 **** --- 1,391 ---- + #ifdef KERBEROS + #include + #include + #include + #include + #include + #include "mail.h" + #include "osdep.h" + #include "imap2.h" + #include "kerberos.h" + + static des_cblock session; /* Our session key */ + static des_key_schedule schedule; /* Schedule for our session key */ + + /* Table for converting binary values to and from hexadecimal */ + static char hex[] = "0123456789abcdef"; + static char dec[256] = { + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 0 - 15 */ + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16 - 37 */ + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* ' ' - '/' */ + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 0, 0, 0, 0, 0, /* '0' - '?' */ + 0,10,11,12,13,14,15, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* '@' - 'O' */ + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 'P' - '_' */ + 0,10,11,12,13,14,15, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* '`' - 'o' */ + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 'p' - DEL */ + }; + + /* + * Convert a KTEXT to an ascii string. + * Accepts: ktext + * Returnss: a pointer to the result, or null pointer on malloc failure + * The caller is responsible for freeing the returned value. + */ + static char *ktext_to_str(KTEXT ktext) + { + char *result, *p; + int i; + + p = result = malloc(ktext->length*2+1); + if (!result) return 0; + + for (i=0; ilength; i++) { + *p++ = hex[(ktext->dat[i]>>4)&0xf]; + *p++ = hex[(ktext->dat[i])&0xf]; + } + *p++ = '\0'; + return result; + } + + /* + * Convert string to a ktext. + * Accepts: string to convert + * ktext to put result in + * Returns: T on success, NIL on failure + */ + static int str_to_ktext(char *str,KTEXT ktext) + { + int i, len; + + len = strlen(str); + if (len&1) return NIL; + len /= 2; + if (len > MAX_KTXT_LEN) return NIL; + + ktext->length = len; + ktext->mbz = 0; + + for (i=0; *str; i++, str += 2) { + ktext->dat[i] = (dec[str[0]]<<4) + dec[str[1]]; + } + return T; + } + + /* + * Kerberos-authenticated server log in + * Accepts: user name string + * password string + * pointer to char pointer. The char pointer is set to the + * text we want returned in the reply message. + * Returns: T if login ok, NIL otherwise + */ + int kerberos_server_login(char *user,char *pass,char **reply) + { + static char lrealm[REALM_SZ] = ""; + KTEXT_ST authent; + char instance[INST_SZ]; + AUTH_DAT kdata; + int code; + static char replybuf[256]; + char *p; + + /* Convert pass to authent */ + if (str_to_ktext(pass, &authent) == NIL) { + *reply = "Invalid Kerberos authenticator"; + return NIL; + } + + /* Verify authenticator */ + strcpy(instance, "*"); + code = krb_rd_req(&authent, "imap", instance, 0L, &kdata, ""); + if (code) { + strcpy(replybuf, krb_err_txt[code]); + *reply = replybuf; + return NIL; + } + + /* Check authorization of the Kerberos user */ + if (kuserok(&kdata, user)) { + if (strcmp(kdata.pname, "imap") || + (!(*lrealm) && krb_get_lrealm(lrealm, 1) == KFAILURE) || + strcmp(kdata.prealm, lrealm)) { + strcpy(replybuf, "Permission denied."); + *reply = replybuf; + return NIL; + } + } + + /* Save the session key */ + bcopy(kdata.session, session, sizeof(des_cblock)); + des_key_sched(session, schedule); + + /* Construct the response for mutual authentication */ + authent.length = sizeof(des_cblock); + bzero(authent.dat, sizeof(des_cblock)); + *((long *)authent.dat) = htonl(kdata.checksum + 1); + des_ecb_encrypt(authent.dat, authent.dat, schedule, 1); + + /* Convert response to string and place in buffer */ + p = ktext_to_str(&authent); + if (p) { + *replybuf = '['; + strcpy(replybuf+1, p); + strcat(replybuf, "] User "); + strcat(replybuf, user); + strcat(replybuf, " logged in"); + free(p); + } + else { + /* XXX Out of memory */ + exit(1); + } + + *reply = replybuf; + return T; + } + + /* + * Kerberos build password + * Accepts: host name + * buffer to store user name in + * buffer to store password in + * optional buffer to store expected return token in + * Returns: T on success, NIL on failure + */ + int kerberos_login(char *host,char *user,char *pwd, char *token) + { + struct hostent *host_name; + char hostname[MAILTMPLEN]; + char phost[MAILTMPLEN]; + KTEXT_ST authent; + int checksum; + char *pass; + int code; + int i; + CREDENTIALS cr; + Key_schedule key_s; + + *pwd = '\0'; + + if (krb_get_tf_fullname(TKT_FILE, user, (char *)0, (char *)0)) { + return NIL; + } + + /* Canonicalize hostname */ + /* The domain literal form is used (rather than simply the dotted decimal + as with other Unix programs) because it has to be a valid "host name" + in mailsystem terminology. */ + /* look like domain literal? */ + if (host[0] == '[' && host[i = (strlen (host))-1] == ']') { + strcpy (hostname,host+1); /* yes, copy without brackets */ + hostname[i-1] = '\0'; + } + /* note that Unix requires lowercase! */ + else if (host_name = gethostbyname (lcase (strcpy (hostname,host)))) + strcpy (hostname,host_name->h_name); + + + /* + * Build an authenticator. + */ + checksum = time(0) ^ getpid(); + strcpy(phost, krb_get_phost(hostname)); + code = krb_mk_req(&authent, "imap", phost, + krb_realmofhost(hostname), checksum); + if (code) return NIL; + + pass = ktext_to_str(&authent); + if (!pass) return NIL; + + /* Send Kerberos-format LOGIN command */ + sprintf(pwd, "%s%s", KERBEROS_IDENT, pass); + free(pass); + if (!token) return T; + *token = '\0'; + + /* + * Build expected mutual authentication reply. + */ + if (code = krb_get_cred("imap", phost, krb_realmofhost(hostname),&cr)) { + return T; + } + des_key_sched(cr.session,key_s); + authent.length = sizeof(des_cblock); + bzero(authent.dat, sizeof(des_cblock)); + *((long *)authent.dat) = htonl(checksum + 1); + des_ecb_encrypt(authent.dat, authent.dat, key_s, 1); + pass = ktext_to_str(&authent); + if (pass) { + sprintf(token, "[%s]", pass); + free(pass); + } + return T; + } + + static use_key(char *user,char *instance,char *realm,des_cblock key,des_cblock returned_key) + { + bcopy (key, returned_key, sizeof(des_cblock)); + return 0; + } + + kerberos_verify_password(char *user,char *passwd) + { + + int result; + des_cblock key; + char realm[REALM_SZ]; + char cell[REALM_SZ]; + int i; + char buf[1024]; + + if (krb_get_lrealm(realm,1)) return NIL; + + /* First try Kerberos string-to-key */ + des_string_to_key(passwd, key); + + result = krb_get_in_tkt(user, "", realm, + "krbtgt", realm, 1, use_key, NULL, key); + + if (result == 0) { + bzero(key, sizeof(key)); + if (krb_get_cred("krbtgt", realm, realm, buf)) { + /* no ticket means we got an error packet with "0" error code */ + return NIL; + } + bzero(buf, sizeof(buf)); + dest_tkt(); + return T; + } + + /* Now try andrew string-to-key */ + strcpy(cell, realm); + for (i = 0; cell[i]; i++) { + if (isupper(cell[i])) cell[i] = tolower(cell[i]); + } + afs_string_to_key(passwd, &key, cell); + + result = krb_get_in_tkt(user, "", realm, + "krbtgt", realm, 1, use_key, NULL, key); + + bzero(key, sizeof(key)); + + if (result == 0) { + if (krb_get_cred("krbtgt", realm, realm, buf)) { + /* no ticket means we got an error packet with "0" error code */ + return NIL; + } + bzero(buf, sizeof(buf)); + dest_tkt(); + return T; + } + + return NIL; + } + + /* andrewstk.c -- afs string to key function + * + * Code taken from AuthMan from University of Michigan + */ + + extern void des_fixup_key_parity(); + extern unsigned long des_cbc_cksum(); + + /* forward declarations */ + void afs_transarc_StringToKey(); + void transarc_StringToKey(); + int transarc_passwd_to_key(); + char *crypt(); + void des_fixup_key_parity(); + + void afs_cmu_StringToKey(); + void athena_StringToKey(); + int athena_passwd_to_key(); + + /* This defines the Andrew string_to_key function. It accepts a password + * string as input and converts its via a one-way encryption algorithm to a DES + * encryption key. It is compatible with the original Andrew authentication + * service password database. + */ + + void + afs_cmu_StringToKey (str, cell, key) + char *str; + char *cell; /* cell for password */ + des_cblock *key; + { char password[8+1]; /* crypt is limited to 8 chars anyway */ + int i; + int passlen; + + bzero (key, sizeof(des_cblock)); + bzero( (void *)password, sizeof( password )); + + strncpy (password, cell, 8); + passlen = strlen (str); + if (passlen > 8) passlen = 8; + + for (i=0; i sizeof(password)) passlen = sizeof(password); + + bcopy ("kerberos", ivec, 8); + bcopy ("kerberos", temp_key, 8); + des_fixup_key_parity ((void *)temp_key); + des_key_sched (temp_key, schedule); + des_cbc_cksum (password, ivec, passlen, schedule, ivec); + + bcopy (ivec, temp_key, 8); + des_fixup_key_parity ((void *)temp_key); + des_key_sched (temp_key, schedule); + des_cbc_cksum (password, (void *)key, passlen, schedule, ivec); + + des_fixup_key_parity (key); + } + + afs_string_to_key(str, key, cell) + char *str; + des_cblock *key; + char *cell; /* cell for password */ + { + if (strlen(str) > 8) + afs_transarc_StringToKey (str, cell, key); + else + afs_cmu_StringToKey (str, cell, key); + } + + #endif /* KERBEROS */ diff -cr ./ANSI/c-client/kerberos.h /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/kerberos.h *** ./ANSI/c-client/kerberos.h Tue Sep 28 15:31:13 1993 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/kerberos.h Tue Sep 28 15:37:08 1993 *************** *** 0 **** --- 1,6 ---- + /* Passwords starting with this string indicate a Kerberos login attempt */ + #define KERBEROS_IDENT "@KERBEROS:" + + int kerberos_server_login(char *user,char *pass,char **reply); + int kerberos_login(char *host,char *user,char *pwd, char *token); + diff -cr ./ANSI/c-client/makefile.sun /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/makefile.sun *** ./ANSI/c-client/makefile.sun Tue Sep 28 15:31:13 1993 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/makefile.sun Tue Sep 28 14:49:31 1993 *************** *** 0 **** --- 1,96 ---- + # Program: Portable C client makefile -- SUN-OS version + # + # Author: Mark Crispin + # Networks and Distributed Computing + # Computing & Communications + # University of Washington + # Administration Building, AG-44 + # Seattle, WA 98195 + # Internet: MRC@CAC.Washington.EDU + # + # Date: 11 May 1989 + # Last Edited: 25 January 1993 + # + # Copyright 1993 by the University of Washington + # + # Permission to use, copy, modify, and distribute this software and its + # documentation for any purpose and without fee is hereby granted, provided + # that the above copyright notice appears in all copies and that both the + # above copyright notice and this permission notice appear in supporting + # documentation, and that the name of the University of Washington not be + # used in advertising or publicity pertaining to distribution of the software + # without specific, written prior permission. This software is made + # available "as is", and + # THE UNIVERSITY OF WASHINGTON DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, + # WITH REGARD TO THIS SOFTWARE, INCLUDING WITHOUT LIMITATION ALL IMPLIED + # WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND IN + # NO EVENT SHALL THE UNIVERSITY OF WASHINGTON BE LIABLE FOR ANY SPECIAL, + # INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + # LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, TORT + # (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF OR IN CONNECTION + # WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + + + CFLAGS = -g -DKERBEROS -DANDREW -I/usr/local/include + LDFLAGS = /usr/local/lib/libkrb.a /usr/local/lib/libdes.a #-ldl + CC = gcc + + mtest: mtest.o c-client.a + echo $(CFLAGS) > CFLAGS + echo $(LDFLAGS) > LDFLAGS + $(CC) $(CFLAGS) -o mtest mtest.o c-client.a $(LDFLAGS) + + clean: + rm -f *.o mtest c-client.a osdep.* CFLAGS LDFLAGS + + mtest.o: mail.h smtp.h nntp.h misc.h osdep.h + + c-client.a: mail.o bezerk.o tenex2.o mbox.o mh.o imap2.o news.o nntpclient.o \ + phile.o dummy.o smtp.o nntp.o rfc822.o misc.o osdep.o sm_unix.o \ + kerberos.o + rm -f c-client.a + ar rc c-client.a mail.o bezerk.o tenex2.o mbox.o mh.o imap2.o news.o \ + nntpclient.o phile.o dummy.o smtp.o nntp.o rfc822.o misc.o osdep.o \ + sm_unix.o kerberos.o + ranlib c-client.a + + mail.o: mail.h misc.h osdep.h + + bezerk.o: mail.h bezerk.h rfc822.h misc.h osdep.h + + tenex.o2: mail.h tenex2.h rfc822.h misc.h osdep.h + + mbox.o: mail.h mbox.h bezerk.h misc.h osdep.h + + mh.o: mail.h mh.h rfc822.h misc.h osdep.h + + imap2.o: mail.h imap2.h misc.h osdep.h + + news.o: mail.h news.h misc.h osdep.h + + nntpclient.o: mail.h nntp.h nntpclient.h misc.h rfc822.h news.h smtp.h osdep.h + + dummy.o: mail.h dummy.h misc.h osdep.h + + smtp.o: mail.h smtp.h rfc822.h misc.h osdep.h + + nntp.o: mail.h nntp.h smtp.h rfc822.h misc.h osdep.h + + rfc822.o: mail.h rfc822.h misc.h + + misc.o: mail.h misc.h osdep.h + + sm_unix.o: mail.h misc.h osdep.h + + osdep.o: mail.h osdep.h os_sun.c + $(CC) $(CFLAGS) -c os_sun.c + mv os_sun.o osdep.o + + osdep.h: os_sun.h + rm -f osdep.h + ln os_sun.h osdep.h + + # A monument to a hack of long ago and far away... + love: + @echo 'not war?' + diff -cr ./ANSI/c-client/os_sun.c /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/os_sun.c *** ./ANSI/c-client/os_sun.c Tue Sep 28 15:31:13 1993 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/os_sun.c Tue Sep 28 13:29:28 1993 *************** *** 0 **** --- 1,680 ---- + /* + * Program: Operating-system dependent routines -- SUN-OS version + * + * Author: Mark Crispin + * Networks and Distributed Computing + * Computing & Communications + * University of Washington + * Administration Building, AG-44 + * Seattle, WA 98195 + * + * Date: 11 May 1989 + * Last Edited: 2 November 1992 + * + * Copyright 1992 by the University of Washington + * + * Permission to use, copy, modify, and distribute this software and its + * documentation for any purpose and without fee is hereby granted, provided + * that the above copyright notice appears in all copies and that both the + * above copyright notice and this permission notice appear in supporting + * documentation, and that the name of the University of Washington not be + * used in advertising or publicity pertaining to distribution of the software + * without specific, written prior permission. This software is made + * available "as is", and + * THE UNIVERSITY OF WASHINGTON DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, + * WITH REGARD TO THIS SOFTWARE, INCLUDING WITHOUT LIMITATION ALL IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND IN + * NO EVENT SHALL THE UNIVERSITY OF WASHINGTON BE LIABLE FOR ANY SPECIAL, + * INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, TORT + * (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF OR IN CONNECTION + * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + * + */ + + /* TCP input buffer */ + + #define BUFLEN 8192 + + + /* TCP I/O stream (must be before osdep.h is included) */ + + #define TCPSTREAM struct tcp_stream + TCPSTREAM { + char *host; /* host name */ + char *localhost; /* local host name */ + int tcpsi; /* input socket */ + int tcpso; /* output socket */ + int ictr; /* input counter */ + char *iptr; /* input pointer */ + char ibuf[BUFLEN]; /* input buffer */ + }; + + + #include "mail.h" + #include "osdep.h" + #include + #include + #include + #include + #include + #include + extern int errno; /* just in case */ + #include + #include + #include "misc.h" + #ifdef KERBEROS + #include "kerberos.h" + #endif /* KERBEROS */ + + extern int sys_nerr; + extern char *sys_errlist[]; + + /* Write current time in RFC 822 format + * Accepts: destination string + */ + + char *days[] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}; + + void rfc822_date (date) + char *date; + { + int zone; + char *zonename; + struct tm *t; + struct timeval tv; + struct timezone tz; + gettimeofday (&tv,&tz); /* get time and timezone poop */ + t = localtime (&tv.tv_sec); /* convert to individual items */ + zone = t->tm_gmtoff/60; /* get timezone from TZ environment stuff */ + zonename = t->tm_zone; + /* and output it */ + sprintf (date,"%s, %d %s %d %02d:%02d:%02d %+03d%02d (%s)", + days[t->tm_wday],t->tm_mday,months[t->tm_mon],t->tm_year+1900, + t->tm_hour,t->tm_min,t->tm_sec,zone/60,abs (zone) % 60,zonename); + } + + /* Get a block of free storage + * Accepts: size of desired block + * Returns: free storage block + */ + + void *fs_get (size) + size_t size; + { + void *block = malloc (size); + if (!block) fatal ("Out of free storage"); + return (block); + } + + + /* Resize a block of free storage + * Accepts: ** pointer to current block + * new size + */ + + void fs_resize (block,size) + void **block; + size_t size; + { + if (!(*block = realloc (*block,size))) fatal ("Can't resize free storage"); + } + + + /* Return a block of free storage + * Accepts: ** pointer to free storage block + */ + + void fs_give (block) + void **block; + { + free (*block); + *block = NIL; + } + + + /* Report a fatal error + * Accepts: string to output + */ + + void fatal (string) + char *string; + { + mm_fatal (string); /* output the string */ + syslog (LOG_ALERT,"IMAP C-Client crash: %s",string); + abort (); /* die horribly */ + } + + /* Copy string with CRLF newlines + * Accepts: destination string + * pointer to size of destination string + * source string + * length of source string + */ + + char *strcrlfcpy (dst,dstl,src,srcl) + char **dst; + unsigned long *dstl; + char *src; + unsigned long srcl; + { + long i,j; + char *d = src; + /* count number of LF's in source string(s) */ + for (i = srcl,j = 0; j < srcl; j++) if (*d++ == '\012') i++; + if (i > *dstl) { /* resize if not enough space */ + fs_give ((void **) dst); /* fs_resize does an unnecessary copy */ + *dst = (char *) fs_get ((*dstl = i) + 1); + } + d = *dst; /* destination string */ + /* copy strings, inserting CR's before LF's */ + while (srcl--) switch (*src) { + case '\015': /* unlikely carriage return */ + *d++ = *src++; /* copy it and any succeeding linefeed */ + if (srcl && *src == '\012') { + *d++ = *src++; + srcl--; + } + break; + case '\012': /* line feed? */ + *d++ ='\015'; /* yes, prepend a CR, drop into default case */ + default: /* ordinary chararacter */ + *d++ = *src++; /* just copy character */ + break; + } + *d = '\0'; /* tie off destination */ + return *dst; /* return destination */ + } + + + /* Length of string after strcrlfcpy applied + * Accepts: source string + * length of source string + */ + + unsigned long strcrlflen (s) + STRING *s; + { + unsigned long pos = GETPOS (s); + unsigned long i = SIZE (s); + unsigned long j = i; + while (j--) switch (SNX (s)) {/* search for newlines */ + case '\015': /* unlikely carriage return */ + if (j && (CHR (s) == '\012')) { + SNX (s); /* eat the line feed */ + j--; + } + break; + case '\012': /* line feed? */ + i++; + default: /* ordinary chararacter */ + break; + } + SETPOS (s,pos); /* restore old position */ + return i; + } + + /* Server log in + * Accepts: user name string + * password string + * optional place to return home directory + * Returns: T if password validated, NIL otherwise + */ + + long server_login (user,pass,home,reply) + char *user; + char *pass; + char **home; + char **reply; + { + struct passwd *pw = getpwnam (lcase (user)); + /* no entry for this user or root */ + if (!(pw && pw->pw_uid)) return NIL; + /* validate password */ + #ifdef KERBEROS + if (strncmp(pass, KERBEROS_IDENT, strlen(KERBEROS_IDENT)) == 0) { + if (kerberos_server_login(user, pass+strlen(KERBEROS_IDENT), reply) == NIL) return NIL; + } + else if (strcmp (pw->pw_passwd,(char *) crypt (pass,pw->pw_passwd)) == 0) { + /* OK */ + } + else { + if (kerberos_verify_password(user, pass) == NIL) return NIL; + } + #else /* KERBEROS */ + if (strcmp (pw->pw_passwd,(char *) crypt (pass,pw->pw_passwd))) return NIL; + #endif /* KERBEROS */ + setgid (pw->pw_gid); /* all OK, login in as that user */ + initgroups (user,pw->pw_gid); /* initialize groups */ + setuid (pw->pw_uid); + /* note home directory */ + #ifdef ANDREW + { + char *hd = myhomedir(); + (void) mkdir(hd, 0700); + } + #endif /* ANDREW */ + if (home) *home = myhomedir(); + return T; + } + + /* Return my user name + * Returns: my user name + */ + + char *uname = NIL; + + char *myusername () + { + return uname ? uname : (uname = cpystr (getpwuid (geteuid ())->pw_name)); + } + + + /* Return my home directory name + * Returns: my home directory name + */ + + char *hdname = NIL; + + char *myhomedir () + { + #ifdef ANDREW + char buf[80]; + if (hdname) return hdname; + sprintf(buf, "/usr/user/mbox/%s", myusername()); + return hdname = cpystr(buf); + #else + return hdname ? hdname : (hdname = cpystr (getpwuid (geteuid ())->pw_dir)); + #endif + } + + + /* Build status lock file name + * Accepts: scratch buffer + * file name + * Returns: name of file to lock + */ + + char *lockname (tmp,fname) + char *tmp; + char *fname; + { + int i; + sprintf (tmp,"/tmp/.%s",fname); + for (i = 6; i < strlen (tmp); ++i) if (tmp[i] == '/') tmp[i] = '\\'; + return tmp; /* note name for later */ + } + + /* TCP/IP open + * Accepts: host name + * contact port number + * Returns: TCP/IP stream if success else NIL + */ + + TCPSTREAM *tcp_open (host, port) + char *host; + int port; + { + TCPSTREAM *stream = NIL; + int sock; + char *s; + struct sockaddr_in sin; + struct hostent *host_name; + char hostname[MAILTMPLEN]; + char tmp[MAILTMPLEN]; + /* The domain literal form is used (rather than simply the dotted decimal + as with other Unix programs) because it has to be a valid "host name" + in mailsystem terminology. */ + /* look like domain literal? */ + if (host[0] == '[' && host[(strlen (host))-1] == ']') { + strcpy (hostname,host+1); /* yes, copy number part */ + hostname[(strlen (hostname))-1] = '\0'; + if ((sin.sin_addr.s_addr = inet_addr (hostname)) != -1) { + sin.sin_family = AF_INET; /* family is always Internet */ + strcpy (hostname,host); /* hostname is user's argument */ + } + else { + sprintf (tmp,"Bad format domain-literal: %.80s",host); + mm_log (tmp,ERROR); + return NIL; + } + } + + else { /* lookup host name, note that brain-dead Unix + requires lowercase! */ + strcpy (hostname,host); /* in case host is in write-protected memory */ + if ((host_name = gethostbyname (lcase (hostname)))) { + /* copy address type */ + sin.sin_family = host_name->h_addrtype; + /* copy host name */ + strcpy (hostname,host_name->h_name); + /* copy host addresses */ + memcpy (&sin.sin_addr,host_name->h_addr,host_name->h_length); + } + else { + sprintf (tmp,"No such host as %.80s",host); + mm_log (tmp,ERROR); + return NIL; + } + } + + /* copy port number in network format */ + if (!(sin.sin_port = htons (port))) fatal ("Bad port argument to tcp_open"); + /* get a TCP stream */ + if ((sock = socket (sin.sin_family,SOCK_STREAM,0)) < 0) { + sprintf (tmp,"Unable to create TCP socket: %s",strerror (errno)); + mm_log (tmp,ERROR); + return NIL; + } + /* open connection */ + if (connect (sock,(struct sockaddr *)&sin,sizeof (sin)) < 0) { + sprintf (tmp,"Can't connect to %.80s,%d: %s",hostname,port, + strerror (errno)); + mm_log (tmp,ERROR); + return NIL; + } + /* create TCP/IP stream */ + stream = (TCPSTREAM *) fs_get (sizeof (TCPSTREAM)); + /* copy official host name */ + stream->host = cpystr (hostname); + /* get local name */ + gethostname (tmp,MAILTMPLEN-1); + stream->localhost = cpystr ((host_name = gethostbyname (tmp)) ? + host_name->h_name : tmp); + /* init sockets */ + stream->tcpsi = stream->tcpso = sock; + stream->ictr = 0; /* init input counter */ + return stream; /* return success */ + } + + /* TCP/IP authenticated open + * Accepts: host name + * service name + * Returns: TCP/IP stream if success else NIL + */ + + TCPSTREAM *tcp_aopen (host,service) + char *host; + char *service; + { + #ifdef ANDREW + return NIL; + #else + TCPSTREAM *stream = NIL; + struct hostent *host_name; + char hostname[MAILTMPLEN]; + int i; + int pipei[2],pipeo[2]; + /* The domain literal form is used (rather than simply the dotted decimal + as with other Unix programs) because it has to be a valid "host name" + in mailsystem terminology. */ + /* look like domain literal? */ + if (host[0] == '[' && host[i = (strlen (host))-1] == ']') { + strcpy (hostname,host+1); /* yes, copy without brackets */ + hostname[i-1] = '\0'; + } + /* note that Unix requires lowercase! */ + else if (host_name = gethostbyname (lcase (strcpy (hostname,host)))) + strcpy (hostname,host_name->h_name); + /* make command pipes */ + if (pipe (pipei) < 0) return NIL; + if (pipe (pipeo) < 0) { + close (pipei[0]); close (pipei[1]); + return NIL; + } + if ((i = fork ()) < 0) { /* make inferior process */ + close (pipei[0]); close (pipei[1]); + close (pipeo[0]); close (pipeo[1]); + return NIL; + } + if (i) { /* parent? */ + close (pipei[1]); /* close child's side of the pipes */ + close (pipeo[0]); + } + else { /* child */ + dup2 (pipei[1],1); /* parent's input is my output */ + dup2 (pipei[1],2); /* parent's input is my error output too */ + close (pipei[0]); close (pipei[1]); + dup2 (pipeo[0],0); /* parent's output is my input */ + close (pipeo[0]); close (pipeo[1]); + /* now run it */ + execl ("/usr/ucb/rsh","rsh",hostname,"exec",service,0); + _exit (1); /* spazzed */ + } + + /* create TCP/IP stream */ + stream = (TCPSTREAM *) fs_get (sizeof (TCPSTREAM)); + /* copy official host name */ + stream->host = cpystr (hostname); + /* get local name */ + gethostname (hostname,MAILTMPLEN-1); + stream->localhost = cpystr ((host_name = gethostbyname (hostname)) ? + host_name->h_name : hostname); + stream->tcpsi = pipei[0]; /* init sockets */ + stream->tcpso = pipeo[1]; + stream->ictr = 0; /* init input counter */ + return stream; /* return success */ + #endif /* ANDREW */ + } + + /* TCP/IP receive line + * Accepts: TCP/IP stream + * Returns: text line string or NIL if failure + */ + + char *tcp_getline (stream) + TCPSTREAM *stream; + { + int n,m; + char *st,*ret,*stp; + char tmp[2]; + char c = '\0'; + char d; + /* make sure have data */ + if (!tcp_getdata (stream)) return NIL; + st = stream->iptr; /* save start of string */ + n = 0; /* init string count */ + while (stream->ictr--) { /* look for end of line */ + d = *stream->iptr++; /* slurp another character */ + if ((c == '\015') && (d == '\012')) { + ret = (char *) fs_get (n--); + memcpy (ret,st,n); /* copy into a free storage string */ + ret[n] = '\0'; /* tie off string with null */ + return ret; + } + n++; /* count another character searched */ + c = d; /* remember previous character */ + } + /* copy partial string from buffer */ + memcpy ((ret = stp = (char *) fs_get (n)),st,n); + /* get more data from the net */ + if (!tcp_getdata (stream)) return NIL; + /* special case of newline broken by buffer */ + if ((c == '\015') && (*stream->iptr == '\012')) { + stream->iptr++; /* eat the line feed */ + stream->ictr--; + ret[n - 1] = '\0'; /* tie off string with null */ + } + /* else recurse to get remainder */ + else if (st = tcp_getline (stream)) { + ret = (char *) fs_get (n + 1 + (m = strlen (st))); + memcpy (ret,stp,n); /* copy first part */ + memcpy (ret + n,st,m); /* and second part */ + fs_give ((void **) &stp); /* flush first part */ + fs_give ((void **) &st); /* flush second part */ + ret[n + m] = '\0'; /* tie off string with null */ + } + return ret; + } + + /* TCP/IP receive buffer + * Accepts: TCP/IP stream + * size in bytes + * buffer to read into + * Returns: T if success, NIL otherwise + */ + + long tcp_getbuffer (stream,size,buffer) + TCPSTREAM *stream; + unsigned long size; + char *buffer; + { + unsigned long n; + char *bufptr = buffer; + while (size > 0) { /* until request satisfied */ + if (!tcp_getdata (stream)) return NIL; + n = min (size,stream->ictr);/* number of bytes to transfer */ + /* do the copy */ + memcpy (bufptr,stream->iptr,n); + bufptr += n; /* update pointer */ + stream->iptr +=n; + size -= n; /* update # of bytes to do */ + stream->ictr -=n; + } + bufptr[0] = '\0'; /* tie off string */ + return T; + } + + + /* TCP/IP receive data + * Accepts: TCP/IP stream + * Returns: T if success, NIL otherwise + */ + + long tcp_getdata (stream) + TCPSTREAM *stream; + { + fd_set fds; + FD_ZERO (&fds); /* initialize selection vector */ + if (stream->tcpsi < 0) return NIL; + while (stream->ictr < 1) { /* if nothing in the buffer */ + FD_SET (stream->tcpsi,&fds);/* set bit in selection vector */ + /* block and read */ + if ((select (stream->tcpsi+1,&fds,0,0,0) < 0) || + ((stream->ictr = read (stream->tcpsi,stream->ibuf,BUFLEN)) < 1)) { + close (stream->tcpsi); /* nuke the socket */ + if (stream->tcpsi != stream->tcpso) close (stream->tcpso); + stream->tcpsi = stream->tcpso = -1; + return NIL; + } + stream->iptr = stream->ibuf;/* point at TCP buffer */ + } + return T; + } + + /* TCP/IP send string as record + * Accepts: TCP/IP stream + * string pointer + * Returns: T if success else NIL + */ + + long tcp_soutr (stream,string) + TCPSTREAM *stream; + char *string; + { + return tcp_sout (stream,string,(unsigned long) strlen (string)); + } + + + /* TCP/IP send string + * Accepts: TCP/IP stream + * string pointer + * byte count + * Returns: T if success else NIL + */ + + long tcp_sout (stream,string,size) + TCPSTREAM *stream; + char *string; + unsigned long size; + { + int i; + fd_set fds; + FD_ZERO (&fds); /* initialize selection vector */ + if (stream->tcpso < 0) return NIL; + while (size > 0) { /* until request satisfied */ + FD_SET (stream->tcpso,&fds);/* set bit in selection vector */ + if ((select (stream->tcpso+1,0,&fds,0,0) < 0) || + ((i = write (stream->tcpso,string,size)) < 0)) { + puts (strerror (errno)); + close (stream->tcpsi); /* nuke the socket */ + if (stream->tcpsi != stream->tcpso) close (stream->tcpso); + stream->tcpsi = stream->tcpso = -1; + return NIL; + } + size -= i; /* count this size */ + string += i; + } + return T; /* all done */ + } + + /* TCP/IP close + * Accepts: TCP/IP stream + */ + + void tcp_close (stream) + TCPSTREAM *stream; + { + + if (stream->tcpsi >= 0) { /* no-op if no socket */ + close (stream->tcpsi); /* nuke the socket */ + if (stream->tcpsi != stream->tcpso) close (stream->tcpso); + stream->tcpsi = stream->tcpso = -1; + } + /* flush host names */ + fs_give ((void **) &stream->host); + fs_give ((void **) &stream->localhost); + fs_give ((void **) &stream); /* flush the stream */ + } + + + /* TCP/IP get host name + * Accepts: TCP/IP stream + * Returns: host name for this stream + */ + + char *tcp_host (stream) + TCPSTREAM *stream; + { + return stream->host; /* return host name */ + } + + + /* TCP/IP get local host name + * Accepts: TCP/IP stream + * Returns: local host name + */ + + char *tcp_localhost (stream) + TCPSTREAM *stream; + { + return stream->localhost; /* return local host name */ + } + + /* Copy memory block + * Accepts: destination pointer + * source pointer + * length + * Returns: destination pointer + */ + + char *memmove (s,ct,n) + char *s; + char *ct; + int n; + { + bcopy (ct,s,n); /* they should have this one */ + return ct; + } + + + /* Return implementation-defined string corresponding to error + * Accepts: error number + * Returns: string for that error + */ + + char *strerror (n) + int n; + { + return (n >= 0 && n < sys_nerr) ? sys_errlist[n] : NIL; + } diff -cr ./ANSI/c-client/os_sun.h /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/os_sun.h *** ./ANSI/c-client/os_sun.h Tue Sep 28 15:31:13 1993 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/c-client/os_sun.h Tue Sep 28 13:29:29 1993 *************** *** 0 **** --- 1,80 ---- + /* + * Program: Operating-system dependent routines -- SUN-OS version + * + * Author: Mark Crispin + * Networks and Distributed Computing + * Computing & Communications + * University of Washington + * Administration Building, AG-44 + * Seattle, WA 98195 + * Internet: MRC@CAC.Washington.EDU + * + * Date: 11 May 1989 + * Last Edited: 4 December 1992 + * + * Copyright 1992 by the University of Washington + * + * Permission to use, copy, modify, and distribute this software and its + * documentation for any purpose and without fee is hereby granted, provided + * that the above copyright notice appears in all copies and that both the + * above copyright notice and this permission notice appear in supporting + * documentation, and that the name of the University of Washington not be + * used in advertising or publicity pertaining to distribution of the software + * without specific, written prior permission. This software is made + * available "as is", and + * THE UNIVERSITY OF WASHINGTON DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, + * WITH REGARD TO THIS SOFTWARE, INCLUDING WITHOUT LIMITATION ALL IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND IN + * NO EVENT SHALL THE UNIVERSITY OF WASHINGTON BE LIABLE FOR ANY SPECIAL, + * INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, TORT + * (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, ARISING OUT OF OR IN CONNECTION + * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + * + */ + + #define MAILFILE "/usr/spool/mail/%s" + #define ACTIVEFILE "/usr/lib/news/active" + #define NEWSSPOOL "/usr/spool/news" + #define NEWSRC strcat (strcpy (tmp,myhomedir ()),"/.newsrc") + #define NFSKLUDGE + + #include + #include + #include + #include + #include /* needed for writev() prototypes */ + + extern char *strerror (); + extern char *memmove (); + + + /* Dummy definition overridden by TCP routines */ + + #ifndef TCPSTREAM + #define TCPSTREAM void + #endif + + /* Function prototypes */ + + void rfc822_date (char *date); + void *fs_get (size_t size); + void fs_resize (void **block,size_t size); + void fs_give (void **block); + void fatal (char *string); + char *strcrlfcpy (char **dst,unsigned long *dstl,char *src,unsigned long srcl); + unsigned long strcrlflen (STRING *s); + long server_login (char *user,char *pass,char **home,char **reply); + char *myusername (); + char *myhomedir (); + char *lockname (char *tmp,char *fname); + TCPSTREAM *tcp_open (char *host,int port); + TCPSTREAM *tcp_aopen (char *host,char *service); + char *tcp_getline (TCPSTREAM *stream); + long tcp_getbuffer (TCPSTREAM *stream,unsigned long size,char *buffer); + long tcp_getdata (TCPSTREAM *stream); + long tcp_soutr (TCPSTREAM *stream,char *string); + long tcp_sout (TCPSTREAM *stream,char *string,unsigned long size); + void tcp_close (TCPSTREAM *stream); + char *tcp_host (TCPSTREAM *stream); + char *tcp_localhost (TCPSTREAM *stream); diff -cr ./ANSI/imapd/Makefile /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/imapd/Makefile *** ./ANSI/imapd/Makefile Fri Jan 10 20:49:34 1992 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/imapd/Makefile Tue Sep 28 13:29:56 1993 *************** *** 37,42 **** --- 37,43 ---- CFLAGS = -I$C `cat $C/CFLAGS` LDFLAGS = $C/c-client.a `cat $C/LDFLAGS` + CC=gcc imapd: C-CLIENT imapd.o $(CC) $(CFLAGS) -o imapd imapd.o $(LDFLAGS) diff -cr ./ANSI/imapd/imapd.c /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/imapd/imapd.c *** ./ANSI/imapd/imapd.c Thu Sep 23 02:45:08 1993 --- /afs/andrew.cmu.edu/usr7/jm36/proj/imap/imap-3.0/ANSI/imapd/imapd.c Tue Sep 28 15:38:43 1993 *************** *** 147,153 **** --- 147,155 ---- void (*f) () = NIL; mail_link (&tenexdriver); /* install the Tenex mail driver */ mail_link (&bezerkdriver); /* install the Berkeley mail driver */ + #ifndef ANDREW mail_link (&imapdriver); /* install the IMAP driver */ + #endif mail_link (&newsdriver); /* install the netnews driver */ mail_link (&nntpdriver); /* install the NNTP driver */ mail_link (&philedriver); /* install the file driver */ *************** *** 232,243 **** struct passwd *pwd; fs_give ((void **) &user); fs_give ((void **) &pass); /* two arguments */ if (!((user = cpystr (snarf (&arg))) && (pass = cpystr (snarf (&arg))))) response = misarg; else if (arg) response = badarg; /* see if username and password are OK */ ! else if (server_login (user,pass,&home,argc,argv)) state = SELECT; /* nope, see if we allow anonymous */ else if (!stat ("/etc/anonymous.newsgroups",&sbuf) && !strcmp (user,"anonymous") && (pwd = getpwnam ("nobody"))) { --- 234,249 ---- struct passwd *pwd; fs_give ((void **) &user); fs_give ((void **) &pass); + lsterr = NULL; /* two arguments */ if (!((user = cpystr (snarf (&arg))) && (pass = cpystr (snarf (&arg))))) response = misarg; else if (arg) response = badarg; /* see if username and password are OK */ ! else if (server_login (user,pass,&home,&lsterr)) { ! state = SELECT; ! if (lsterr) response = altwin; ! } /* nope, see if we allow anonymous */ else if (!stat ("/etc/anonymous.newsgroups",&sbuf) && !strcmp (user,"anonymous") && (pwd = getpwnam ("nobody"))) { *************** *** 248,253 **** --- 254,260 ---- /* run user's init */ dorc (strcat (strcpy (tmp,myhomedir ()),"/.imaprc")); } + else if (lsterr) response = lose; else response = "%s NO Bad %s user name and/or password\015\012"; } else response = "%s BAD Command unrecognized/login please: %s\015\012"; From owner-c-client@cac.washington.edu Tue Sep 28 14:46:36 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04742; Tue, 28 Sep 93 14:46:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20911; Tue, 28 Sep 93 14:46:23 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20905; Tue, 28 Sep 93 14:46:21 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id RAA07997; Tue, 28 Sep 1993 17:46:17 -0400 Received: via switchmail; Tue, 28 Sep 1993 17:46:16 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 28 Sep 1993 17:46:00 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 28 Sep 1993 17:45:36 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 28 Sep 1993 17:45:30 -0400 (EDT) Message-Id: Date: Tue, 28 Sep 1993 17:45:30 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Re: Kerberos diffs for 3.0 c-client In-Reply-To: References: Beak: is Not The diffs I provided included an old version of strcrlfcpy() inside os_sun.c. This needs to be replaced with an up-to-date version from one of the other os_* files in the 3.0 distribution. _.John From owner-c-client@cac.washington.edu Wed Sep 29 13:27:00 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18374; Wed, 29 Sep 93 13:27:00 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09078; Wed, 29 Sep 93 13:26:38 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09072; Wed, 29 Sep 93 13:26:33 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18645-2>; Wed, 29 Sep 1993 14:23:17 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Wed, 29 Sep 93 14:12 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0oi7zs-000cw8C; Wed, 29 Sep 93 14:19 MDT Date: Wed, 29 Sep 1993 14:19:34 -0600 From: Steve Hole Subject: Re: Kerberos diffs for 3.0 c-client To: John Gardiner Myers Cc: c-client@cac.washington.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks very much for the patches John. Cheers. Steve. From owner-c-client@cac.washington.edu Tue Oct 12 16:16:19 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28801; Tue, 12 Oct 93 16:16:19 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17865; Tue, 12 Oct 93 16:16:04 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17859; Tue, 12 Oct 93 16:16:02 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id TAA12093; Tue, 12 Oct 1993 19:15:51 -0400 Received: via switchmail; Tue, 12 Oct 1993 19:15:49 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 19:15:34 -0400 (EDT) Received: via niftymail; Tue, 12 Oct 1993 19:15:26 -0400 (EDT) Date: Tue, 12 Oct 1993 19:15:25 -0400 (EDT) From: Chris Newman Subject: Use of \DELETED in c-client To: imap@cac.washington.edu, c-client@cac.washington.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750467725.21131.0@nifty.andrew.cmu.edu> The current c-client netnews driver's use of \DELETED is dangerous and violates the specification. The specification states: "The EXPUNGE command permanently removes all messages with the \DELETED flag set from the currently selected mailbox." and "\DELETED Message is "deleted" for removal by later EXPUNGE" I read this as: The \DELETED flag does nothing until an EXPUNGE is issued, at which point the messages must be permanently removed from the mailbox. The c-client allows \DELETED to be set, and does not permanently remove the messages from the mailbox when EXPUNGE is issued. Either the c-client or the spec needs to be changed (I vote c-client). To quote John Myers: "As I've mentioned in a previous message, this is a dangerous model. It trains users to type "d" instead of "n" and will cause messages to inadvertently disappear when users walk into a mailbox to which they have delete access." That said, my understanding is that Pine users want both a per-session \SEEN state (what the \SEEN flag is used for in the netnews driver), and a permanent \SEEN state (what the \DELETED flag is used for). I'm curious why just a permanent \SEEN state (using the \SEEN flag) wouldn't suffice? - Chris From owner-c-client@cac.washington.edu Tue Oct 12 16:46:11 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29952; Tue, 12 Oct 93 16:46:11 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21263; Tue, 12 Oct 93 16:45:53 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21253; Tue, 12 Oct 93 16:45:51 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id TAA06947; Tue, 12 Oct 1993 19:45:47 -0400 Received: via switchmail; Tue, 12 Oct 1993 19:45:46 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 19:44:28 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 19:44:17 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 12 Oct 1993 19:44:12 -0400 (EDT) Message-Id: Date: Tue, 12 Oct 1993 19:44:12 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Re: Use of \DELETED in c-client In-Reply-To: <750467725.21131.0@nifty.andrew.cmu.edu> References: <750467725.21131.0@nifty.andrew.cmu.edu> Beak: Is To add another relevant paragraph I sent to the imap list: "That design is based on the narrow view that mail and news are fundamentally different, distinguishable things which users process with different methodologies. CMU considers the two to be two extremes of the same sort of object which should be proecessed using the same tools and methodologies. We have both sorts of objects intermixed in our system and we have several objects that are neither one nor the other." This observation is backed up by the fact that Pine "knows" the difference between mail and news and behaves differently depending on how the macro IS_NEWS evaluates. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Tue Oct 12 16:53:01 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00270; Tue, 12 Oct 93 16:53:01 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18078; Tue, 12 Oct 93 16:52:49 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18066; Tue, 12 Oct 93 16:52:47 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA02308; Tue, 12 Oct 93 16:52:42 -0700 Date: Tue, 12 Oct 1993 16:42:21 -0700 (PDT) From: Mark Crispin Subject: re: Use of \DELETED in c-client To: Chris Newman , c-client Interest List In-Reply-To: <750467725.21131.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Chris - A separate message discusses my contention that the IMAP protocol is not violated by c-client's usage of the \Deleted flag to mark .newsrc updates. Until recently, c-client used the \Seen flag to mark .newsrc updates, much as you suggested. This was changed to the \Deleted flag. Terry will undoubtably offer a more detailed explanation, but in short the reasoning is this: What we call ``read'' in mail and what we call ``read'' in news are fundamentally different concepts. In news, there is the extra semantic that what has been ``read'' is no longer part of the set of interesting messages that appears in the user's view by default. This is done because in some newsgroups, there may be thousands of messages. In traditional newsreaders, reading and view-removal are closely tied together. People who use such simple tools as rn read news in a fundamentally different way from how they read mail. In a basic sense, the way that messages in mail are removed from the view is by the mechanism of deletion and expunge. Simply reading the messages does not remove them from the view. The change to c-client enables this model of the world. It is not necessarily the one I would have picked, but it is an interesting model and it has received some initial positive responses. -- Mark -- From owner-c-client@cac.washington.edu Tue Oct 12 16:53:00 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00268; Tue, 12 Oct 93 16:53:00 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18072; Tue, 12 Oct 93 16:52:48 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18064; Tue, 12 Oct 93 16:52:46 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA02304; Tue, 12 Oct 93 16:52:41 -0700 Date: Tue, 12 Oct 1993 16:24:24 -0700 (PDT) From: Mark Crispin Subject: re: Use of \DELETED in c-client To: Chris Newman , IMAP Interest List Cc: c-client Interest List In-Reply-To: <750467725.21131.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Chris - I would like to take this discussion off the IMAP list. Follow-ups about whether this c-client behavior is a good idea or a bad idea should be directed to the c-client list. It is my opinion that the behavior of c-client's news driver with \Deleted does not conflict with the IMAP specification. This message concerns that issue only. A message directed to the c-client list only will address the reasons why c-client behaves the way it does. The news driver only responds to BBOARD class opens. On the August 30-31 meeting, it was observed that bboards imply a type of read-only access in which certain operations (CREATE, APPEND) are not meaningful at all. Certain other operations are either restricted in effect (STORE), or fundamentally meaningless (EXPUNGE) and execute as a no-op. Because EXPUNGE is a fundamentally meaningless operation on a BBOARD, the semantics of \Deleted as it applies to EXPUNGE become moot. \Deleted is simply a status, nothing more. There may need to be some additional clarifying wording in the IMAP specification: . An attempt to EXPUNGE when it is meaningless (as opposed to an error in expunging) should be treated as a no-op (respond with OK, not NO). For example, it is meaningless to expunge a read-only mailbox or a bboard. . Some additional discussion on what bboards actually mean may be needed in the description of the BBOARD command. -- Mark -- From owner-c-client@cac.washington.edu Wed Oct 13 09:39:24 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21272; Wed, 13 Oct 93 09:39:24 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29499; Wed, 13 Oct 93 08:30:06 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29468; Wed, 13 Oct 93 08:29:00 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id LAA04473; Wed, 13 Oct 1993 11:28:50 -0400 Received: via switchmail; Wed, 13 Oct 1993 11:28:46 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 13 Oct 1993 11:28:34 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 13 Oct 1993 11:28:28 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 13 Oct 1993 11:28:24 -0400 (EDT) Message-Id: Date: Wed, 13 Oct 1993 11:28:24 -0400 (EDT) From: John Gardiner Myers Subject: Re: Use of \DELETED in c-client To: c-client Interest List In-Reply-To: References: Beak: Is Mark Crispin writes: > The news driver only responds to BBOARD class opens. The news driver also responds to SELECT class opens where the first character of the mailbox name is '*'. Pine knows about this and will switch into "news mode" if the first character of a normal-namespace mailbox is '*'. > What we call ``read'' in mail and what we call ``read'' in news are > fundamentally different concepts. In news, there is the extra semantic that > what has been ``read'' is no longer part of the set of interesting messages > that appears in the user's view by default. This is done because in some > newsgroups, there may be thousands of messages. This is the view that "because we currently use different tools for mail and news, they are fundamentally different concepts." At CMU, we have had great success in removing these blinders. Newsgroups do not have a monopoly on "thousands of messages". For instance, my primary mailbox has 3873 messages at the moment. There are also "shared mailboxes" with thousands of messages. What we call "read" in mail and what we call "read" in news are the same concept. They are both per-user, per-message bits which automatically change state when the user views a message. The user usually also has a separate ability to change state from "read" to "unread" or "unread" to "read". There are two useful modes for reading messages. One is the "read new messages" mode where you are only interested in new messages and wish to have a view which is restricted to new messages. Another is a "browse" mode, where you want to see all messages. Traditional newsreaders such as rn tend to only support the first mode. It is particularly painful to try to browse an already-read newsgroup with rn--you either slog through message-by-message or you have to mark everything as unread and start over. Traditional mail readers tended to only support "browse" mode because there was only one mailbox that ever got new messages. When you start getting multiple inboxes and shared mailboxes, the "read new messages" mode becomes necessary for dealing with mail. > The change to c-client enables this model of the world. It is > not necessarily the one I would have picked, but it is an > interesting model and it has received some initial positive > responses. The change to c-client was not necessary for this model of the world. Clients can switch into a mode where \Seen messages are removed from the user's view without the help of the server. What the change does is require this model of the world. Either the client or the user has to know that the server is in "news mode" and change their behavior appropriately. As we've mentioned before, it is extremely dangerous to require the user to change their behavior. The change also provides a strong disincentive for clients to be able to provide the "read new messages" mode for mail, since they would have to do it differently than they do for news. Having clients know as much detail about the peculiarities of the c-client imapd as Pine does is going to lead to serious interoperation problems. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Wed Oct 13 14:35:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02401; Wed, 13 Oct 93 14:35:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06719; Wed, 13 Oct 93 14:34:59 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06713; Wed, 13 Oct 93 14:34:53 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18634-1>; Wed, 13 Oct 1993 15:34:41 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Wed, 13 Oct 93 15:31 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0onDuH-000cvoC; Wed, 13 Oct 93 15:38 MDT Date: Wed, 13 Oct 1993 15:38:37 -0600 From: Steve Hole Subject: re: Use of \DELETED in c-client To: Mark Crispin Cc: c-client Interest List Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 12 Oct 1993 17:42:21 -0600 Mark Crispin wrote: > From: Mark Crispin > Date: Tue, 12 Oct 1993 17:42:21 -0600 > Subject: re: Use of \DELETED in c-client > To: Chris Newman , > c-client Interest List > > Chris - > > A separate message discusses my contention that the IMAP protocol is not > violated by c-client's usage of the \Deleted flag to mark .newsrc updates. Agreed. > Until recently, c-client used the \Seen flag to mark .newsrc updates, > much as you suggested. This was changed to the \Deleted flag. Terry will > undoubtably offer a more detailed explanation, but in short the reasoning is > this: > > What we call ``read'' in mail and what we call ``read'' in news are > fundamentally different concepts. In news, there is the extra semantic that > what has been ``read'' is no longer part of the set of interesting messages > that appears in the user's view by default. This is done because in some > newsgroups, there may be thousands of messages. > > In traditional newsreaders, reading and view-removal are closely tied > together. People who use such simple tools as rn read news in a fundamentally > different way from how they read mail. > > In a basic sense, the way that messages in mail are removed from the view > is by the mechanism of deletion and expunge. Simply reading the messages does > not remove them from the view. Well, I think that we are coming to the nub of the rub (so to speak). I think that John, Chris and I fundamentally disagree with this view. Perhaps we should take it up with Terry? Anyway, I contend that view removal does not and should not have anything to do with the physical manipulation of the messages. \Delete implies physical deletion. Changing the view to sort filter out \Seen messages is entirely different. I agree that filtering is a more difficult problem for client interfaces to solve. We spent a lot of time on it, and it still isn't quite complete. It is beautiful when you can do it though. Having paid the price I can understand why simple work arounds would be of interest. So, the remaining problem is this. Can we get the \Seen flag interpretation for News back to its original form. I guess that I can live with the \Deleted form *as well*, but the \Seen must work right for ECSMail. Terry, your thoughts please? Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Wed Oct 13 14:44:33 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02706; Wed, 13 Oct 93 14:44:33 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06968; Wed, 13 Oct 93 14:44:21 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06962; Wed, 13 Oct 93 14:44:20 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17595; Wed, 13 Oct 93 14:44:04 -0700 Date: Wed, 13 Oct 1993 14:41:56 -0700 (PDT) From: Terry Gray Subject: re: Use of \DELETED in c-client To: Steve Hole Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Steve, I'm hoping to be able to offer some thoughts on this topic shortly (by the end of the day?) -teg From owner-c-client@cac.washington.edu Thu Oct 14 16:18:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14057; Thu, 14 Oct 93 16:18:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27822; Thu, 14 Oct 93 16:18:20 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27812; Thu, 14 Oct 93 16:18:17 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18637-1>; Thu, 14 Oct 1993 17:18:11 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Thu, 14 Oct 93 16:58 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0onbjp-000cvoC; Thu, 14 Oct 93 17:05 MDT Date: Thu, 14 Oct 1993 17:05:23 -0600 From: Steve Hole Subject: Some problems with the imapd-3.0 (Pine 3.87) release To: Mark Crispin Cc: c-client@CAC.Washington.EDU Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Mark. We have found some problems with the imapd-3.0 release that is distributed with Pine 3.87. As far as I know, this is the definitive version of the imapd-3.0 release? (1) The behaviour of a mail_find_all (FIND ALL *) has changed for the Bezerk driver. It now return a list of every file that is matched by the pattern, without checking to see if they are valid folders. This is causing us some problems with our new folder subscription mechanism because it will include non-mail folder files in the list. We have provided a mechanism for users to access folders in (potentially) any place on the server in which they have access. If they get binaries and such in the folder list, then the potential problems are obvious. The bottom line is that we pretty much like the way it worked before. What we would like to see specifically is: * bezerk_find_all() should perform bezerk_is_valid() on any potential match before including it in the list of matches sent to the client. * 0 length files should match *regardless* of whether they have a ".txt" suffix or not. (2) The behaviour of mail_find is not what we expected for the Bezerk driver. If you do a bezerk_find() and there is no subscription database, then it does a call to bezerk_find_all() - returning all of the folders that are returned by (1). This completely defeats our subscription mechanism where we wish to present a list of subscribed folders on one side and a list of unsubscribed but available folders on the other side. News and Dawz do the right thing. Also, the Bezerk driver will (correctly) create a subscription database if it does not exist on the first subscription. We would like: * bezerk_find to return an empty list if there is no subscription database - just like News and Dawz do. * bezerk_find to return only the contents of the subscription database if it does exist. This is the way that it works now, I'm just trying to be complete. I can see how some of the changes have evolved with new the new version of Pine. I suspect that some of the changes that we have seen were required by Pine. If so, perhaps there are some work arounds that we can do? We would be perfectly happy to make these changes and send them off to you in the form of patches Mark. What do you think? Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Thu Oct 14 22:31:52 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24223; Thu, 14 Oct 93 22:31:52 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02946; Thu, 14 Oct 93 22:31:33 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02940; Thu, 14 Oct 93 22:31:31 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA06084; Thu, 14 Oct 93 22:31:23 -0700 Date: Thu, 14 Oct 1993 19:18:26 -0700 (PDT) From: Mark Crispin Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Steve Hole Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Steve - mail_find*() behavior has changed several times in c-client, as we tried various schemes and found which worked and which didn't work. It's been changed several times. We weren't aware that you (or anyone else outside of UW) were using it, or we would have made sure you were informed of what was going on. We discovered so many problems in find handling (only the really major ones are discussed here) that we didn't think anyone could use it! ;-) The orignal find handling was: find use subscription list (null results if no subscription list) findall do directory scan with validation Pine doesn't use subscription lists yet, so it used findall. This didn't work out. The problem was, checking for mailbox validity via the _valid() routine turned out to be a big performance lose. Substantial amounts of time was expended in that code. The next means of find handling was: find if a subscription list exists, use it, else do directory scan without validation (``fast finding'') findall do directory scan with validation The idea here was to leave findall as a thorough validating find, but have something fast for regular find (and let the few people who use subscription lists win). Then came the killer: the new arbitrary file driver (phile), which essentially meant that there was no such thing as a ``file'' that was not a mailbox. That brings us to the current, transitional means of find handling: find if a subscription list exists, use it, else do findall findall do directory scan without validation However, that is only until all old versions of Pine (mostly PC-Pine) that used mail_find() (3.84 and 3.85) become extinct. Hopefully this will not be long. The planned final version is: find use subscription list (null results if no subscription list) findall do directory scan without validation There are no plans to re-attempt any validation that it is really a mailbox object, since the concept of a filesystem object that cannot be referenced as a mailsystem object is becoming extinct in c-client. The fact that the validation was horribly slow is just one more nail in the coffin... In 3.1 of the c-client/IMAP toolkit, the transition is well under way. Among some of the things which have already happened are: 1) the special extension of Tenex format is now .TxT 2) an MTX driver for UNIX, compatible with the format used on DOS, is in the works and probably will replace the Tenex driver eventually (or the Tenex driver will be used just to read in old cmm files). It uses the special extension of .MTX 3) work is underway to eliminate special extensions entirely; that is, to deal with the zero-length file problem in a different way. This isn't quite what you've asked for, but I think it's probably an improvement over what you're dealing with now with the transitional code. Please take a look at the 3.1 toolkit since this is closer to what is in Pine 3.87 than the 3.0 toolkit. In particular, the unfavorable interaction with subscriptions will go away. Not clear yet, but it's likely that a 4.0 toolkit will be sooner than later; that's going to be the version that supports the IMAP2bis Proposed Standard when that happens. I hope this message is good news for you... -- Mark -- From owner-c-client@cac.washington.edu Fri Oct 15 19:58:38 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29231; Fri, 15 Oct 93 19:58:38 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19687; Fri, 15 Oct 93 19:57:59 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19681; Fri, 15 Oct 93 19:57:55 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18669-1>; Fri, 15 Oct 1993 20:57:45 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Fri, 15 Oct 93 09:56 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0onrdH-000cvoC; Fri, 15 Oct 93 10:03 MDT Date: Fri, 15 Oct 1993 10:03:38 -0600 From: Steve Hole Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Mark Crispin Cc: c-client Interest List Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 14 Oct 1993 20:18:26 -0600 Mark Crispin wrote: > From: Mark Crispin > Date: Thu, 14 Oct 1993 20:18:26 -0600 > Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release > To: Steve Hole > Cc: c-client Interest List > > Pine doesn't use subscription lists yet, so it used findall. This didn't > work out. The problem was, checking for mailbox validity via the > _valid() routine turned out to be a big performance lose. Substantial > amounts of time was expended in that code. This is true. It kind of worries me that somebody can select a file as a folder when it really isn't one, but I guess we can live with that. It's too bad that we couldn't provide some sort of feedback to the user on type, but I don't see how without looking inside. Even if we were to start writing and looking for a folder magic number, it would require some sort of conversion on existing folders. > There are no plans to re-attempt any validation that it is really a > mailbox object, since the concept of a filesystem object that cannot be > referenced as a mailsystem object is becoming extinct in c-client. The fact > that the validation was horribly slow is just one more nail in the coffin... Ok. I think that some of the more clever users will find out that they can cause problems by writing to files that are not folders. In general, the performance win should be worth it, though. I guess we'll find out. > In 3.1 of the c-client/IMAP toolkit, the transition is well under way. > Among some of the things which have already happened are: > 1) the special extension of Tenex format is now .TxT > 2) an MTX driver for UNIX, compatible with the format used on DOS, is in the > works and probably will replace the Tenex driver eventually (or the Tenex > driver will be used just to read in old cmm files). It uses the special > extension of .MTX > 3) work is underway to eliminate special extensions entirely; that is, to > deal with the zero-length file problem in a different way. > Hmm ... new drivers. We have some ideas for a new driver as well that I would like to discuss with you. I will send an outline of my thoughts in a separate message. > This isn't quite what you've asked for, but I think it's probably an > improvement over what you're dealing with now with the transitional code. > Please take a look at the 3.1 toolkit since this is closer to what is in Pine > 3.87 than the 3.0 toolkit. In particular, the unfavorable interaction with > subscriptions will go away. The key requirement for us is that a mail_find() return a nil list if there is no subscription database. Otherwise our subscription interface will simply not work. Does the 3.1 server do this now? If not, can it be modified to do so? We actually have already modified the 3.0 release that came with pine to do this. Will it cause a problem for the latest release of Pine? > Not clear yet, but it's likely that a 4.0 toolkit will be sooner than > later; that's going to be the version that supports the IMAP2bis Proposed > Standard when that happens. > > I hope this message is good news for you... I think it is. We really need the subscription stuff to work right because we want to release v2.2 next week, and it supports subscription. We will have to distribute a modified version of imapd I guess in order to support it. If that will not adversely affect Pine, then I don't mind doing that until version 3.1 is snapped off. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Fri Oct 15 20:36:55 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29848; Fri, 15 Oct 93 20:36:55 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19985; Fri, 15 Oct 93 20:36:33 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19979; Fri, 15 Oct 93 20:36:28 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26528; Fri, 15 Oct 93 20:36:20 -0700 Date: Fri, 15 Oct 1993 20:22:58 -0700 (PDT) From: Terry Gray Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Steve Hole Cc: Mark Crispin , pine@cac.washington.edu, c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Oct 1993, Steve Hole wrote: > > I hope this message is good news for you... > > I think it is. We really need the subscription stuff to work right because > we want to release v2.2 next week, and it supports subscription. We will > have to distribute a modified version of imapd I guess in order to support > it. If that will not adversely affect Pine, then I don't mind doing that > until version 3.1 is snapped off. Steve, It's a transition problem. Pine 3.87 and later will not use FIND, therefore they will happily ignore .mailboxlist files. I *think* Pine 3.07 and earlier will also happily ignore .mailboxlist. (Can one of the Pine team confirm or deny this?) The problem is with 3.85, which when confronted with a a null .mailboxlist happily asserts to the user that all of his/her folders are gone... Fortunately, 3.85 was superceded fairly quickly, so maybe the incompatible installed base is fairly small. I think it makes sense for you to release an IMAPd with the modified FIND behavior, and we should accelerate that change in our code, to reduce compatibility problems with ECSmail 2.2. You will need to tell your clients who have trouble with Pine to upgrade to Pine 3.87 or later, and we'll need to tell our users who have trouble with ECSmail to upgrade IMAPd. Pine guys, does that seem right? (If I'm wrong about 3.07, the problem is much bigger, and we need to consider further.) Sorry about this... we normally try to warn and/or seek consensus on incompatible IMAP changes, but this one slipped by. There is still an open question of how much cross-client interoperability we really have in listing folders... -teg From owner-c-client@cac.washington.edu Sat Oct 16 11:15:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11170; Sat, 16 Oct 93 11:15:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24918; Sat, 16 Oct 93 11:14:59 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24912; Sat, 16 Oct 93 11:14:50 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18605-1>; Sat, 16 Oct 1993 12:14:42 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Sat, 16 Oct 93 11:55 MDT Received: by isasun-1.edm.isac.ca (Smail3.1.28.1 #1) id m0ooFtH-000cvoC; Sat, 16 Oct 93 11:58 MDT Date: Sat, 16 Oct 1993 11:52:56 -0600 From: Steve Hole Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Terry Gray Cc: Mark Crispin , pine@cac.washington.edu, c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 15 Oct 1993, Terry Gray wrote: > I think it makes sense for you to release an IMAPd with the modified FIND > behavior, and we should accelerate that change in our code, to reduce > compatibility problems with ECSmail 2.2. OK, I will make the necessary changes this weekend. I will forward the patches to you, but the change is so simple, I expect that you won't really need them. > You will need to tell your clients who have trouble with Pine to upgrade > to Pine 3.87 or later, and we'll need to tell our users who have trouble > with ECSmail to upgrade IMAPd. I just put the modified IMAP out at the same time with a TTL notice on it for imapd-3.1. That should make it clear to most. > Pine guys, does that seem right? (If I'm wrong about 3.07, the problem > is much bigger, and we need to consider further.) > > Sorry about this... we normally try to warn and/or seek consensus on > incompatible IMAP changes, but this one slipped by. There is still an > open question of how much cross-client interoperability we really have in > listing folders... No problem. I know that we didn't really tell anybody what we were doing and, as Mark said, nobody was previously making use of the subscription mechanisms before now. Thanks for the help guys. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Sat Oct 16 13:00:18 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12387; Sat, 16 Oct 93 13:00:18 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12395; Sat, 16 Oct 93 13:00:07 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12386; Sat, 16 Oct 93 13:00:00 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA00703; Sat, 16 Oct 93 12:59:54 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA14074; Sat, 16 Oct 93 12:59:45 -0700 Date: Sat, 16 Oct 1993 12:56:45 -0700 (PDT) From: Mark Crispin Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Steve Hole Cc: Terry Gray , pine@cac.washington.edu, c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Steve - I haven't yet had the chance to digest the most recent messages on this thread. I think we should have a bit of discussion first as to what these changes are, if you're talking about going beyond the calls to findall from find (which are interim and will probably be removed from IMAP toolkit 3.1 real soon now). Of course, if that's exactly what the change is, no problem; consider the poke to remove the interim code ``received, loud and clear''! ;-) -- Mark -- From owner-c-client@cac.washington.edu Sun Oct 17 01:01:31 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20100; Sun, 17 Oct 93 01:01:31 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28994; Sun, 17 Oct 93 01:01:08 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28956; Sun, 17 Oct 93 01:00:04 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15667; Sun, 17 Oct 93 01:00:03 -0700 Date: Sat, 16 Oct 1993 23:35:56 -0700 (PDT) From: Terry Gray Subject: More on /SEEN and /DELETED... (sigh!) To: imap@cac.washington.edu, c-client@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, At last, I have completed reviewing the recent /SEEN and /DELETED thread. I'm sending this response to both the imap and c-client lists, as I think some of the issues relate to both. In this set of messages, there seem to have been four major themes: 1. Are per-session flags useful? If so, how should they be implemented? 2. What are IMAP "BBOARDS", anyway? 3. What different classes of mailboxes and flag sets are there? 4. What have those UW guys been smoking? (Clearly they are a bunch of idiots for challenging the traditional news reading paradigm that messages should automatically disappear after one reading.) I'd like to make brief comments on the first three, then concentrate my fire on item 4... -------------------------------------------------------------------------- TOPIC 1: Per-session flags. I'm actually not a big fan of per-session flags. I would not violently oppose their existence, but I would tend to avoid using them if I could, on the grounds that flags that are not preserved across sessions tend to confuse users. Note that the questions of where *persistent* flags might be stored (with the mailbox, or in an auxiliary file) and who manages them (server or client) are completely orthogonal to the question of whether or not transient (per-session) flags should exist. -------------------------------------------------------------------------- TOPIC 2: BBOARDS... what are they *really*? I think of BBOARDS as a way of defining an alternate namespace. The problem is that having precisely *two* namespaces defined in IMAP can't possibly be the right general solution. It is either too few or one too many. I personally believe that BBOARDS needs to be re-thought in the context of namespace selection, especially for non-filesystem namespaces. We need a clean way to either (a) select amongst possibly many drivers and their namespaces, or (b) cleverly map a diversity of them so that we can pretend we only have one namespace. It would not break my heart if the present BBOARDS construct was superseded or obsoleted. -------------------------------------------------------------------------- TOPIC 3. Classes of mailboxes; private vs. global flags. Here are my assumptions: -A Mailbox = [Msg Data + Global Flags] OR [Msg Data + Private Flags] -Global (per-mailbox) flags may or may not be shared. -Private (per-user) flags, if they exist, are never shared. -A user views a mailbox EITHER with Global or Private flags, NEVER both. -A user with RW/EXPUNGE rights will use Global flags, never Private flags. -Global and Private flag sets may include any defined IMAP flag, however... -Implementation constraints may limit which flags can actually be stored. Given these assumptions, we can now identify several classes of interesting mailboxes. I propose a taxonomy based on three questions: 1. Is message store RW? (In particular, does user have expunge rights?) 2. Are Global (per-mailbox) flags shared? 3. Do Private (per-user) flags exist? (At all? Partially? Fully?) (Note: in speaking of RW or RO, I'm talking about access rights, not transient RO failure modes.) Not all combinations make sense, and given fine-grain access controls, one can identify even more cases. However, the following decision tree leads to four mailbox categories that I believe do make sense, and in fact are all in common use: MESSAGE STORE IS RW? / \ Yes No / \ GLOBAL FLAGS SHARED? PRIVATE FLAGS EXIST? / \ / \ Yes No Yes No / \ / \ MAILBOX TYPE: 1 2 3 4 In words, these mailbox classes can be characterized as follows: 1. A shared mailbox. Multiple users may set and see common msg state. 2. Standard personal mailbox. 3. "Pseudo-personal" mailbox. An RO archive plus private flags. 4. A RO mailbox/archive, with no provision for user to record pers. state. Type 1 assumes a mailbox format that supports concurrent flag update, but otherwise is identical to standard personal mailboxes except for access rights. Type 3 and 4 mailboxes are what we normally think of as "Shared but ReadOnly", and where typically the user does not have control over when a message disappears, nor expunge rights. It is not required that the message store in question be ReadOnly for everyone, only to the user in question. All of these mailbox types are in common use; however, C-client doesn't yet support a fully general type 3 "pseudo personal" mailbox. It does support a limited form of this for news, via the .newsrc file. Note that using .newsrc is purely a concession to interoperability with existing newsreaders, and it would have been better if we could have just ignored .newsrc files and used a more general private flag implementation for any Type 3 "pseudo personal" mailbox (which we need to invent anyway). Some of you have made assumptions that differ from my own. In particular: that certain flags are inherently per-mailbox or per-user; that a user in a particular session might see a combination of Global and Private flags; and that a set of Private flags can in any way affect anyone else's view of a mailbox --or worse, lead to inadvertent expunging of messages. In contrast to those views, I've attempted to identify a mailbox framework which both corresponds to common practice and avoids the criticisms that legitimately follow from some of the alternative assumptions. The case of "pseudo personal" mailboxes (RO message stores + Private flags) is the most relevant to this discussion, so perhaps my most important assertions concern those private flags: -By definition they are not shared. -They only apply to shared-but-RO message stores. -They can have no effect on any other user. -They can include any valid IMAP flag (subject to implementation limits). -They are never "mixed" with a potentially-existing global flag set. My basic contention is that for a particular mailbox session, the MUA must choose between using [1] the possibly-shared set of "per-mailbox" flags (if the user has RW mailbox access), and [2] (if available) a private set of "per-user" flags that are invisibile to anyone else. This "one or the other" restriction follows from my strongly-held belief that no flag is inherently only per-user or per-mailbox, plus the observation that IMAP provides no facilities for manipulating both "per-user" and "per-maibox" flag sets as separate entities. -------------------------------------------------------------------------- TOPIC 4: Use of /DELETED for news... In teaching our MUA to read news, we chose to use the one bit available in a .newsrc to denote /deleted rather than /seen. Evidently this decision has proven controversial. Please read the entire message before reacting :) John Myers: this is a dangerous model. It trains users to type "d" instead of "n" and will cause messages to inadvertently disappear when users walk into a mailbox to which they have delete access. I think John's adamant abhorrence of what we are doing is based on the assumption that /deleted is necessarily a global (per mailbox) flag, rather than a per-user flag. If we were talking about global (per mailbox) /deleted flags, wherein one user could naively mark /deleted, and perhaps inadvertently expunge, a message out from under another user, I would agree that Pine's behavior is dangerous... but we are not. News is one example of what I called a "Type 3, pseudo personal" mailbox, wherein sharing flag state amongst users is neither necessary nor desirable, and wherein the normal user is powerless to actually make messages disappear from *other* people's views. That is, by definition the user of private flags does not have expunge rights on the shared message store (although one could theoretically simulate "personal expunge" via private flags). Furthermore, I disagree with the implicit assertion that there are no dangers associated with applying the traditional "news model" to personal mailboxes, or even to news! Messages magically and implicitly disappear, simply by looking at them once! I've happily lived with this behavior for well over a decade, so I was truly unprepared for how "wrong" this model now seems to me, since having had a chance to use the other paradigm. That design is based on the narrow view that mail and news are fundamentally different, distinguishable things which users process with different methodologies. Nothing could be further from the truth. This design decision was a *direct* result of trying to blur the distinctions between the mail and news worlds. This observation is backed up by the fact that Pine "knows" the difference between mail and news and behaves differently depending on how the macro IS_NEWS evaluates. Some of the differences are constraints imposed by using existing .newsrc file structure for recording private flags, rather than being fundamental news vs. mail differences, which we completely agree should be minimized. As we've mentioned before, it is extremely dangerous to require the user to change their behavior. If you are starting from the mail reader perspective, as Pine must necessarily do, there is no change in user behavior. To adopt the traditional newsreader view, in contrast, would very definitely require a change in Pine users' behavior. The "per-user \Deleted for news" model does not generalize. As it trains users to do dangerous things, it would be hard to convince me to support it It doesn't generalize and is dangerous if and *only* if you accept John's premise that /DELETED is inherently global, a notion I can't agree with in the context of Type 3 (RO + private flags) mailboxes. What *is* inherently "per mailbox" for all classes of mailbox is the existence or non-existence of a particular message, but that's not the same thing. If one were to define /DELETED as invalid for private flag state, we would need another flag to indicate a particular user's personal disinterest in a particular message, since I utterly and totally reject the notion of using /seen to mean this. Further, I see no value to a global /Deleted flag in a Type 3 (pseudo personal) mailbox --more or less by definition. Accordingly, I consider the traditional newsreading paradigm of "see it once, then it disappears", to be dangerous if applied to personal mailboxes. (Therefore, "it would be hard to convince me to support it". But to not apply the same paradigm to both mail and news introduces the very modality that John incorrectly accuses us of.) Steve Hole: Apparently, the \Deleted flag is used to indicate that a News message "has been seen and shouldn't show up in the list". No, not at all. It is used to indicate that the user is no longer interested in the message. Whether or not it shows up in a particular index view is a separate question. Anyway, I contend that view removal does not and should not have anything to do with the physical manipulation of the messages. \Delete implies physical deletion. Changing the view to sort filter out \Seen messages is entirely different. I completely *agree* that views based on flag state are distinct from what actually exists on disk. From a user's perspective, the available views DEFINE their REALITY, regardless of what exists or doesn't exist on disk. Indeed, even whether or not a message exists to a user (say after an expunge) can be implemented in one bit! I claim that the statement "\Delete implies physical deletion" reflects your own personal bias about a particular implementation strategy. It has no foundation in either database theory or filesystem practice. (Consider, for example, what happens when you delete a filesystem object when its link count is >1 ) I really don't see how anyone can say that "deleting" a News message to make it disappear is consistent with the way that it works when processing private mail OR with conventional news readers. It is much better just to filter the message list view to show or not show read messages. This is exactly the way that many newsreaders work. Well, OK. I'll say it. Or more precisely, I'll say that Pine's current behavior is *completely* consistent between mail and news with respect to the /deleted flag, and that as far as I can tell, this has proven to be a definite win. As Steve said "Consistency is *very* important." Again, the /deleted flag reflects the user's explicit disinterest in a message. It is the only flag available to the user for indicating this. Whether messages so marked "disappear" is a function of the current view. One might choose a view where these messages are hidden, but that is a distinct issue. Defining a *view* that excludes certain messages is not at all the same as *marking* those messages as uninteresting. In contrast, "I really don't see how anyone can say" that an implicitly- set /seen flag should imply the user's explicit disinterest in a message, which is indeed --and unfortunately-- "exactly the way that many newsreaders work." And which is why Steve and Chris' suggestion to just use /seen and suppress those messages from the current view is exactly backwards from my perspective. (It also clutters the UI, because now you MUST implemnent an "UNSEE" command... now there's a real intuitive concept, right?) SUMMARY: In traditional newsreaders, a message "disappears from view" *implicitly*, simply by having looked at it once. One must take explicit action to make it re-appear. In all the mailers I've used, the opposite is true. A message never disappears from view without *explicit* action by the user. This might not be strictly true in XLView, (I can imagine view definitions that would emulate newsreader behavior) but even there, one has a Delete button to explicitly mark a message as no longer interesting. Using /deleted as the way to denote disinterest in a message for both mail and news is completely reasonable as long as you realize that the flags for Type 2 and 3 mailboxes are not shared across users. (And as for sharing /deleted state in Type 1 mailboxes, "it's a feature!" ) In building a tool that deals with both mail and news, the choices are: 1. Emulate *mailer* behavior for both mail and news 2. Emulate (old) *newsreader* behavior for both mail and news 3. Have inconsistent (modal) behavior, for each. Surely we can do better than condemning the user to option #3! Equally clearly, a mailer that is being taught to read news cannot abandon its traditional mailreading behavior. For Pine, that leaves only option #1. Newsrc files and flag preservation... Part of the perceived mail-news dichotemy is actually an artifact of having a news infrastructure that only permits a single "flag bit" in the personal state database (the absence or presence of an article number in one's .newsrc). This limitation has nothing to do with news per se, but it is a real-world constraint that tends to force us into modality whenever accessing news (in conjunction with a newsrc). In our case, the modality manifests itself as ignoring /seen state in newsgroups. If tool interoperability was irrelevant, we could ignore .newsrc files and invent a new mechanism that would preserve all interesting flags, suitable for any kind of Type 3 (pseudo personal) mailbox. We need to invent this mechanism anyway for other Type 3 mailboxes, but alas, in our case, compatible use of the existing .newsrc files was considered essential. But let's return to First Principles. From the user view, we need a clear way of letting the user explicitly declare that a message is no longer of interest. In Pine, you do that with the "D" key, which is associated with the word "deleted". Strictly speaking, that word is misleading (both in our UA and in the protocol flag definition) since nothing has been deleted yet. Maybe the "D" should mean "dismiss" or "drop" or "dullsville"... the point is that this is the way a user tells the system that she *probably* doesn't want to see that message again. Not at all the same as N, for "show me the next message". In the case of news, since we wanted to use the existing .newsrc framework, we had to choose what the meaning of an entry in the .newsrc was going to mean. There was effectively one bit per message to manipulate. We could choose one and only one flag to be preserved across sessions. Would it be the "seen" flag or the "deleted/dismissed/dropped/dull" flag? We actually tried it both ways. Now having used both models, I'm pretty convinced that the present behavior (saving the "D" state in .newsrc) is best. In fact, although I still use trn a lot, I find myself using Pine's (very incomplete) newsreading abilities more and more just because of the "mail like" paradigm: messages don't implicitly "disappear", they stay around until I "dismiss" them. I like this behavior a lot, even without having the code to *hide* /deleted messages in place yet. (And when we do, rest assured it will work uniformly for both mail and news. This code does exist in test versions of Pine.) CONCLUSION: This 40+ message discussion has surfaced a number of interesting issues. Unfortunately, my response seems to have become almost as long as all those messages put together... :) (Sorry!) Some issues I don't claim to have any good answer for yet (e.g. namespace selection and the role of BBOARDS). But I think this idea of message flag *scope* (whether a flag is private/personal or shared/global) for different classes of mailboxes is fundamental and crucial. The controversy over Pine's (and c-client's) newsreading behavior revolves around these three issues: -the meaning of /deleted as compared to /seen -the relative importance of /deleted vs. /seen, if only one can be saved. -whether or not /deleted is inherently global, and therefore "unsafe" The case of a RO message store + private flags, which news is an example of, I've dubbed a (type 3) "pseudo personal" mailbox, wherein the message data bits are shared RO but flags (including /deleted) are not shared. Private (per-user) /deleted state is only sensible ("safe") when the user is unable to expunge the actual mailbox message data, as defined above. To insist that /deleted must be global in all cases leaves us without a reasonable way for a particular user to record their personal disinterest in a shared RO message; hence we postulate the Type 3 mailbox scenario wherein one person's full suite of flags is of no interest to anyone else, and cannot affect anyone else. Finally, I hope you will all keep an open mind to the idea that an *implicit* /SEEN flag should *not* be taken as prima facia evidence that the user has lost interest in a message, a state that I believe is more appropriately denoted by an *explicit* /DELETED flag. That's it for now. Cheers... -teg From owner-c-client@cac.washington.edu Sun Oct 17 08:07:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25536; Sun, 17 Oct 93 08:07:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01216; Sun, 17 Oct 93 08:07:11 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01210; Sun, 17 Oct 93 08:07:08 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id LAA02132; Sun, 17 Oct 1993 11:07:05 -0400 Received: via switchmail; Sun, 17 Oct 1993 11:07:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 17 Oct 1993 11:05:55 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 17 Oct 1993 11:05:48 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Sun, 17 Oct 1993 11:05:42 -0400 (EDT) Message-Id: <0gkJx6C00WBwQCMkRI@andrew.cmu.edu> Date: Sun, 17 Oct 1993 11:05:42 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU, imap@cac.washington.edu Subject: Re: More on /SEEN and /DELETED... (sigh!) In-Reply-To: References: Beak: is Not [There are both protocol and c-client issues here] Terry Gray writes: > -A user views a mailbox EITHER with Global or Private flags, NEVER both. In the Cyrus imapd, the \Seen and \Recent flags are always "Private" and all other flags are always "Global". Given this model is useful (for example, user wants to track their own reading progress through a "trouble ticket" mailbox), desired, and corresponds to what we veiw existing practice, and given the observation that Terry mentions no specific problems with this model, I think it's a bit premature to assume it out of existence. To paraphrase Terry, I think his four mailbox classes are "too few or too many." I think it's best to state that whether any given flag is preserved on a per-user or per-mailbox basis is an implementation detail. I do, however, believe it is useless or silly for certain flags to be preserved on a certain basis. Whether or not the user may change the preserved state of any given flag is an entirely different matter. > John Myers: > > this is a dangerous model. It trains users to type "d" instead > of "n" and will cause messages to inadvertently disappear when > users walk into a mailbox to which they have delete access. > > I think John's adamant abhorrence of what we are doing is based on the > assumption that /deleted is necessarily a global (per mailbox) flag, > rather than a per-user flag. Terry completely misses the reason I consider the use of \Deleted for news dangerous. Given there are both "Type 1" and "Type 3" mailboxes, and given that there might not be a line in the namespace which says "all these over here are Type 1 and all those over there are Type 3," the user trained by c-client's handling of \Deleted in news to type "d" when they are "no longer interested" in a message will do so when reading the "Type 1" mailbox. They will then inadvertently physically remove messages before other users of the shared mailbox can read them. > Furthermore, I disagree with the implicit assertion that there are no > dangers associated with applying the traditional "news model" to personal > mailboxes, or even to news! Messages magically and implicitly disappear, > simply by looking at them once! I've happily lived with this behavior for > well over a decade, so I was truly unprepared for how "wrong" this model > now seems to me, since having had a chance to use the other paradigm. Messages "magically and implicitly disappear" due to the view you selected? One might as well use the same arguments against kill files. "The other paradigm" assumes that "Type 1" mailboxes with multiple readers don't exist. > Nothing could be further from the truth. This design decision was a > *direct* result of trying to blur the distinctions between the mail and > news worlds. I'd say you botched it, given all the places IS_NEWS is used in Pine. > Some of the differences are constraints imposed by using existing .newsrc > file structure for recording private flags, rather than being fundamental > news vs. mail differences, which we completely agree should be minimized. Things IS_NEWS affects, from my reading of the code: * Whether three 'n' commands cause a CHECK command * On 'n' command, whether to prompt to ``View next news group'' * On 'd' command, whether to prompt to ``View next group'' * Whether the 'x' command is named "eXclude" or "eXpunge" * On 'x' command, whether to error with "eXclude of deleted news not implemented yet." * On '&' command, whether the error message is "Unexclude command not implemented yet" or "Unexclude not available for mail folders" * Whether opening a mailbox announces it as a "News group" or a "Folder" * Whether or not the titlebar says "(READONLY)" * Whether or not un-\Seen messages are marked as "NEW" in the bar status * Whether or not TAB will stop on un-\Seen messages * On TAB command, whether to say "No more undeleted messages" or "No more new messages" Only the last three can be considered as having anything to do with the way c-client handles .newsrc files. Even they could go away if the .newsrc mapped to \Seen instead of \Deleted. The fact that Pine will only offer the user the ability to view the next mailbox in "news mode" is a clear example of Pine considering News and Mail as fundamentally different. > If you are starting from the mail reader perspective, as Pine must > necessarily do, there is no change in user behavior. The user must shift the meaning of 'D' from "physically delete this message" to "don't show me this message, for now". You're also assuming that users always delete their mail when they read it. If you start from CMU mail reader perspective, there is a definite change in user behavior. > To adopt the > traditional newsreader view, in contrast, would very definitely require a > change in Pine users' behavior. Traditionally, users haven't read their mail in "show me only the new messages" mode because they only ever had one mailbox which had new messages delivered to it. Treating mail as news is an easy paradigm shift and "browse mode" is useful for people who like the traditional mail model. > I claim that the statement > "\Delete implies physical deletion" reflects your own personal bias about > a particular implementation strategy. It has no foundation in either > database theory or filesystem practice. (Consider, for example, what > happens when you delete a filesystem object when its link count is >1 ) \Deleted has a specific definition in the IMAP protocol specification. That definition specifically mentions "removal by later EXPUNGE". EXPUNGE "permanently removes all messages with the \Deleted flag set". > Again, the /deleted flag reflects the user's explicit disinterest in a > message. Again, your interpretation of the \Deleted flag does not correspond to its definition in the IMAP protocol specificiation. > In contrast, "I really don't see how anyone can say" that an implicitly- > set /seen flag should imply the user's explicit disinterest in a message, > which is indeed --and unfortunately-- "exactly the way that many newsreaders > work." And which is why Steve and Chris' suggestion to just use /seen and > suppress those messages from the current view is exactly backwards from my > perspective. It seems very intuitive for a command "show me the new messages" to imply that the user is explicitly disinterested in messages with the \Seen flag set. > (It also clutters the UI, because now you MUST implemnent an > "UNSEE" command... now there's a real intuitive concept, right?) It's about as intuitive as "UNDELETE". A UI should enable the user to set or clear any non-special flag. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Sun Oct 17 15:36:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00754; Sun, 17 Oct 93 15:36:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03520; Sun, 17 Oct 93 15:36:35 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03514; Sun, 17 Oct 93 15:36:34 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id SAA07706; Sun, 17 Oct 1993 18:36:31 -0400 Received: via switchmail; Sun, 17 Oct 1993 18:36:30 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Sun, 17 Oct 1993 18:36:10 -0400 (EDT) Received: via niftymail; Sun, 17 Oct 1993 18:36:02 -0400 (EDT) Date: Sun, 17 Oct 1993 18:35:59 -0400 (EDT) From: Chris Newman Subject: Re: More on /SEEN and /DELETED... (sigh!) To: imap@cac.washington.edu, c-client@cac.washington.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750897359.27688.0@nifty.andrew.cmu.edu> Here are a couple scenerios which show why Terry's different interpretation of /DELETED for netnews and mail is dangerous: The secretary for the athletic department office is administering a publicly readable athletic bboard which is fully read-write to athletic department administrators. A message with a major error is posted to the bboard and he wishes to remove it. He goes to the bboard, deletes the message, and expunges the bboard. The message disappears from his view. Then he continues to get complaints about this message and is confused. He had, after all, removed it the same way he would remove it from his mailbox. Now suppose Jane User is reading a mailbox for her project group. She's gotten used to hitting "d" to remove messages from her view. So when she's read a message, she hits "d" to remove it from her view. Her client, as usual, expunges the messages when she leaves the folder. But now, none of the other people in her group can see that message because its gone. She did the same thing she does in news, and it doesn't remove the message there. She is confused and her project is set back a few days. ---------- These two examples show why "/DELETED" must either mean "flag for removal" or "hide". It must not have different meanings in different mailboxes/bboards. However, Terry has argued eloquently that a "hide" concept is useful and I _personally_ wouldn't object to adding an extra optional flag for it. I do object strongly to equating the "hide" concept with "/DELETED" as I believe it would confuse and endanger users. - Chris From owner-c-client@cac.washington.edu Sun Oct 17 15:44:41 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00850; Sun, 17 Oct 93 15:44:41 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03570; Sun, 17 Oct 93 15:44:29 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03564; Sun, 17 Oct 93 15:44:27 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27292; Sun, 17 Oct 93 15:44:26 -0700 Date: Sun, 17 Oct 1993 15:44:16 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: More on /SEEN and /DELETED... To: imap@cac.washington.edu Cc: c-client@CAC.Washington.EDU In-Reply-To: <0gkJx6C00WBwQCMkRI@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sun, 17 Oct 1993, John Gardiner Myers wrote: > > -A user views a mailbox EITHER with Global or Private flags, NEVER both. > > In the Cyrus imapd, the \Seen and \Recent flags are always "Private" > and all other flags are always "Global". Given this model is useful > (for example, user wants to track their own reading progress through a > "trouble ticket" mailbox), desired, and corresponds to what we veiw > existing practice, and given the observation that Terry mentions no > specific problems with this model, I think it's a bit premature to > assume it out of existence. My intent was not to preclude other scenarios; only to explain the basis for my own thinking. In a shared mailbox situation, one can make a case for presenting either a "private view" or "global view" of \seen, and even \recent. In fact, one (not me) *could* even argue for showing both, but we don't have the machinery in IMAP to deal with both simultaneously. Given the differences in opinion about which flags should be considered private, and which global, how can we proceed? I suppose the best we can do is adopt a laissez faire "implementation dependent" stance. The downside of that there will be surprises for users. The clients should all *work*, but what the flags actually mean, in terms of scope, will differ from one server to the next. > Terry completely misses the reason I consider the use of \Deleted for > news dangerous. I don't think so; at least John's next paragraph is consistent with what I understood his objection to be... > Given there are both "Type 1" and "Type 3" mailboxes, and given that > there might not be a line in the namespace which says "all these over > here are Type 1 and all those over there are Type 3," the user trained > by c-client's handling of \Deleted in news to type "d" when they are > "no longer interested" in a message will do so when reading the "Type > 1" mailbox. They will then inadvertently physically remove messages > before other users of the shared mailbox can read them. One could as easily argue that C-client's handling of \deleted for *conventional* personal mailboxes is dangerous! And it is!! After all, in a personal mailbox, an individual gets to mark a msg as deleted (or uninteresting), and since they have expunge rights, actually make it go away. Forget about news, what happens when such a *mail* user begins using a shared mailbox? Exactly the same thing that happens when people share files in any system: either they talk, or have a locking protocol, or sooner or later, somebody gets burned. [Small aside to illustrate the point: in 1976 people from 18 Arpanet sites around the US were collaborating on a major report, using MIT-Multics as the file repository. Much gnashing of teeth ensued when one team member unilateraly copied the files to BBN-TENEX for spell checking, then copied them back a few days later --obliterating much intervening work.] I don't believe that allowing \deleted for news makes this problem any worse than it already is, but I do think that there is an opportunity for improving IMAP here: it would be nice if clients could find out if a mailbox was being shared, and/or sharable, so the UI could take pains to warn users that their actions could affect multiple users. > Messages "magically and implicitly disappear" due to the view you > selected? One might as well use the same arguments against kill > files. Not at all. Kill files are the result of *explicit* action by the user. > "The other paradigm" assumes that "Type 1" mailboxes with multiple > readers don't exist. Not at all. Unless John wishes to legislate "normal" unshared personal mailboxes out of existence as well (and of course he doesn't), this argument makes no sense to me. > > Nothing could be further from the truth. This design decision was a > > *direct* result of trying to blur the distinctions between the mail and > > news worlds. > > I'd say you botched it, given all the places IS_NEWS is used in Pine. Reality sometimes lags intent, and Pine is still "work in progress", especially with respect to newsreading. News is the first, but not the last, case of having an inherently ReadOnly message store with private flag state. Some of the current Pine behavior, in particular having N prompt for the next news group, but not the next mail folder, is clearly wrong and will be changed. In many of the other cases where "IS_NEWS" is used, a macro named something like IS_IMMUTABLE would have been better, since NEWS is only one of possibly many classes of immutable mailboxes. > > If you are starting from the mail reader perspective, as Pine must > > necessarily do, there is no change in user behavior. > > The user must shift the meaning of 'D' from "physically delete > this message" to "don't show me this message, for now". Incorrect, both with respect to the "from" and the "to"... A "D" does *not* mean "physically delete this message", no matter what the protocol spec might say. We all know that "D" has absolutely no effect on the message other than to signal *intent* by associating a flag with that message. If we want "D" to *really* mean "delete data", then we should eliminate Expunge from the protocol, and the notion of a \deleted flag becomes nonsensical, as it becomes a flag associated with a message that no longer exists. [NB: Even if we keep the \deleted "statement of intent" separate from the action of expunging, which I certainly support, we still must decide what \deleted means for immutable mailboxes. A *global* \deleted flag for an immutable message store makes no sense to me.] Nor does "D" mean "don't show me this message for now", although that could be a *side effect* of the currently defined view. [NB: An important part of this debate has to do with the relationship between *flags* and *views*... Although views are often defined in terms of flags, the concepts are distinct and we must avoid blurring them.] > You're also > assuming that users always delete their mail when they read it. I'm clueless as to why John said this... it certainly is not true. > Traditionally, users haven't read their mail in "show me only the new > messages" mode because they only ever had one mailbox which had new > messages delivered to it. Treating mail as news is an easy paradigm > shift and "browse mode" is useful for people who like the traditional > mail model. Conversely, I would claim the CMU community has not used "browse" mode for news only because of limitations in the CMU system, namely that it only keeps a single pointer, delimiting old and new. I have no problem with having different "view modes" and being able to apply them uniformly to mail and news. But I have a real problem with overloading the /seen flag to imply "no future interest in this msg". > > Again, the /deleted flag reflects the user's explicit disinterest in a > > message. > > Again, your interpretation of the \Deleted flag does not correspond to > its definition in the IMAP protocol specificiation. The protocol spec reflects a traditional terminology that was *never* precisely accurate, and doesn't translate perfectly to the world of immutable mailboxes and private flag sets that we are now trying to extend IMAP and c-client to cover. Either we forbid \deleted from being used on immutable mailboxes, in which case we need to invent another flag that would be redundant in the RW case, or we try to find an "enhanced" interpretation of the existing flag that can work for both RO and RW mailboxes. > It seems very intuitive for a command "show me the new messages" to > imply that the user is explicitly disinterested in messages with the > \Seen flag set. It is important (to me, anyway) that we keep the concepts of "message attribute" and "current view" distinct, because I see the lifetime of a particular message *attribute* being generally different than the persistence of a current view. Both are changeable at will, but they are not identical. So I have *no* problem with being able to say "just show me new messages right now"... but I object to the idea that this transient "bulk" definition of what's interesting at the moment has anything to do with a per-message *explicit* declaration that a particular message is of no future interest. > > (It also clutters the UI, because now you MUST implemnent an > > "UNSEE" command... now there's a real intuitive concept, right?) > > It's about as intuitive as "UNDELETE". Not *quite* that intuitive. :) But I certainly wouldn't want to defend delete/undelete very vigorously, since the common interpretation of those words is clearly not what happens in fact. Probably too late to pick a better word, though. -teg From owner-c-client@cac.washington.edu Sun Oct 17 16:00:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01008; Sun, 17 Oct 93 16:00:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03634; Sun, 17 Oct 93 16:00:39 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03628; Sun, 17 Oct 93 16:00:38 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id TAA07892; Sun, 17 Oct 1993 19:00:35 -0400 Received: via switchmail; Sun, 17 Oct 1993 19:00:35 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Sun, 17 Oct 1993 19:00:12 -0400 (EDT) Received: via niftymail; Sun, 17 Oct 1993 19:00:09 -0400 (EDT) Date: Sun, 17 Oct 1993 19:00:08 -0400 (EDT) From: Chris Newman Subject: Terry's assumptions about mailboxes To: c-client@cac.washington.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750898808.27688.0@nifty.andrew.cmu.edu> Terry suggests the following assumptions: >Here are my assumptions: > -A Mailbox = [Msg Data + Global Flags] OR [Msg Data + Private Flags] How about, the mailbox administrator(s) use global flags and the mailbox readers use private flags? A useful scenerio, IMHO. > -Global (per-mailbox) flags may or may not be shared. Agreed. > -Private (per-user) flags, if they exist, are never shared. Agreed. > -A user views a mailbox EITHER with Global or Private flags, NEVER both. A bboard with several administrators that read the bboard probably will want private \SEEN flags for the administrators, while sharing the other flags. > -A user with RW/EXPUNGE rights will use Global flags, never Private flags. What about a user with RW but not EXPUNGE rights? How about a user with EXPUNGE but not APPEND rights? What about the several administrators that read the bboard separately (e.g. a club bboard with several officers who have RW/EXPUNGE rights)? > -Global and Private flag sets may include any defined IMAP flag, however... > -Implementation constraints may limit which flags can actually be stored. Agreed. - Chris From owner-c-client@cac.washington.edu Sun Oct 17 17:00:20 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01661; Sun, 17 Oct 93 17:00:20 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03946; Sun, 17 Oct 93 17:00:09 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03931; Sun, 17 Oct 93 16:59:45 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28249; Sun, 17 Oct 93 16:59:42 -0700 Date: Sun, 17 Oct 1993 16:05:13 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: More on /SEEN and /DELETED... To: Chris Newman Cc: imap@cac.washington.edu, c-client@cac.washington.edu In-Reply-To: <750897359.27688.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Chris, I believe that both of your scenarios represent misunderstandings of the model I advocate, and also illustrate the danger of blurring the distinction between "message attributes" and "current view". Let me try to explain why... On Sun, 17 Oct 1993, Chris Newman wrote: > Here are a couple scenerios which show why Terry's different interpretation of > /DELETED for netnews and mail is dangerous: > > The secretary for the athletic department office is administering a > publicly readable athletic bboard which is fully read-write to > athletic department administrators. A message with a major error is > posted to the bboard and he wishes to remove it. He goes to the > bboard, deletes the message, and expunges the bboard. The message > disappears from his view. Then he continues to get complaints about > this message and is confused. He had, after all, removed it the same > way he would remove it from his mailbox. In my model, the \deleted flag is only private if the user does *not* have expunge rights. So in this case, both the flag and the subsequent expunge would have had global scope and there would be no problem. The message really would be gone. > Now suppose Jane User is reading a mailbox for her project group. > She's gotten used to hitting "d" to remove messages from her view. So > when she's read a message, she hits "d" to remove it from her view. > Her client, as usual, expunges the messages when she leaves the > folder. But now, none of the other people in her group can see that > message because its gone. She did the same thing she does in news, > and it doesn't remove the message there. She is confused and her > project is set back a few days. The mistake in this scenario is postulating that the user's motivation for hitting "d" is to simply remove messages from the current view. (Pine users certainly don't have this idea, since hitting "d" does not remove a message from the current view. Expunge does.) As you know by now, it has never occurred to me that D would or could be construed as purely for transient view control. Especially since, like you, I consider it perfectly reasonable to postulate a *current* view that suppresses /seen for either news or mail, without having to type "d". So the objection to "D" being applied to news is based on fear that the user would not realize that "D" really associates a persistent attribute with the message, rather than simply hiding the message, (assuming that "D"s are hidden in some views). I claim that to the extent this might be true, the problem already exists with personal mailboxes, and is not significantly exacerbated by applying "D" to news as well as mail. I think we can agree that we must in all cases avoid leading users "down the garden path" of believing that flags do nothing but control views. That's why I think it so important to clearly delineate message state from views. > These two examples show why "/DELETED" must either mean "flag for > removal" or "hide". It must not have different meanings in different > mailboxes/bboards. However, Terry has argued eloquently that a "hide" > concept is useful and I _personally_ wouldn't object to adding an > extra optional flag for it. I do object strongly to equating the "hide" > concept with "/DELETED" as I believe it would confuse and endanger > users. For the reasons I cite above, I too object to equating "deleted" with "hide", but I do not see any conflict in equating "deleted" with "of no future interest". Neither "Deleted" nor "of no future interest" should imply "hidden", lest we find ourselves in yet another terminology perversion, wherein we allow definition of a view to temporarily display that which is hidden! Suppose you accept my thesis that it is useful to have a flag to let the user explicitly denote a message as having no future interest, and that this message state is orthogonal to the current view definition. Now suppose that for whatever reason, we don't want to use "deleted" to mean "no future interest", so we need a new flag. My objections would be that in a Read/Write/Expungable mailbox, the new flag is superfluous, and that any new flag requires extra machinery to display and manipulate. Here's what we would have: MAILBOX TYPE: RWE RO \marked-for-deletion OK Contradiction \uninteresting Redundant OK Given that the "danger of deleted" concern seems to be partly a result of an incorrect assumption about the connection between flags and views, and partly an intrinsic and long-standing problem that occurs whenever a private mailbox user moves into a shared mailbox arena, does it really make sense to have a different, but oh-so-similar flag? -teg p.s. I don't mean to imply that I'm not concerned about inadvertent deletion of messages in shared mailboxes; I am, but I see that as a preexisting problem that is neither solved nor worsened by either of our positions. From owner-c-client@cac.washington.edu Sun Oct 17 18:35:31 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02954; Sun, 17 Oct 93 18:35:31 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18379; Sun, 17 Oct 93 18:35:16 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18373; Sun, 17 Oct 93 18:35:14 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA02339; Sun, 17 Oct 93 18:35:05 -0700 Date: Sun, 17 Oct 1993 18:20:42 -0700 (PDT) From: Mark Crispin Reply-To: Mark Crispin Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Steve Hole Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 15 Oct 1993, Steve Hole wrote: > This is true. It kind of worries me that somebody can select a file as a > folder > when it really isn't one, but I guess we can live with that. Do you understand that the dichotomy between ``file'' and ``folder'' is intended to vanish? A ``file'' now looks like a folder with one ``message'' in it. Can you suggest why you wouldn't want ECS Mail users to have this capability? [One obvious way of having distributed address books is to have a well-known folder name for the address book...] > Ok. I think that some of the more clever users will find out that they can > cause problems by writing to files that are not folders. At the present time, files-as-folders can't be written to. But, that is supposed to change in the future (obviously, it has to if that's how address books are accessed!). > Hmm ... new drivers. We have some ideas for a new driver as well that I > would like to discuss with you. I will send an outline of my thoughts in > a separate message. By all means, please do! The current drivers more or less do nothing other than deal with extant UNIX-based mailstore technology. They have little or nothing to do with what I would consider a ``good'' mailstore technology! It's for this reason that the new linkage mechanism was invented. > The key requirement for us is that a mail_find() return a nil list if there > is no subscription database. This change has *just* appeared in the sources; essentially, elimination of the two else clauses in dummy_find() and dummy_find_bboards(). It is not in the imapd distributed with Pine 3.87, although Pine 3.87 can be used with an imapd with this change. Only my two machines have this change installed right now. I suggest, as a *temporary* workaround, that you treat results from mail_find() that begin with "." and ".." as being equivalent to ``no subscription database presently exists.'' This will allow you to interact with the currently released set of servers without requiring you to supply a modified version. I'm sorry you have to deal with this wart, but hopefully it'll be easy to excise one we're all sure that Pine 3.8[456] are extinct and Pine 3.87 (or greater) rules... ;-) > We will > have to distribute a modified version of imapd I guess in order to support > it. If that will not adversely affect Pine, then I don't mind doing that > until version 3.1 is snapped off. Will my suggested workaround enable you to avoid this? -- Mark -- From owner-c-client@cac.washington.edu Sun Oct 17 21:10:28 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04762; Sun, 17 Oct 93 21:10:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05690; Sun, 17 Oct 93 21:10:17 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05684; Sun, 17 Oct 93 21:10:16 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01205; Sun, 17 Oct 93 21:10:14 -0700 Date: Sun, 17 Oct 1993 20:38:46 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: Terry's assumptions about mailboxes To: Chris Newman Cc: c-client@cac.washington.edu In-Reply-To: <750898808.27688.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Well, looks like I'm 3 for 6 in your book... (our Seahawks should do as well! :) I've deleted the 3 assumptions we agree on, and now offer a few comments on the other 3... On Sun, 17 Oct 1993, Chris Newman wrote: > Terry suggests the following assumptions: > > >Here are my assumptions: > > -A Mailbox = [Msg Data + Global Flags] OR [Msg Data + Private Flags] > > How about, the mailbox administrator(s) use global flags and the > mailbox readers use private flags? A useful scenerio, IMHO. I'm guessing that you are proposing this as an *addition* to the above, rather than as a replacement. If so, it's not needed, because I meant to imply that my two alternatives apply to a particular session, and are not mutually exclusive across all users, or even across sequential roles of one user. More difficult for me to accept is the case of "Mailbox = [Msg Data + Some Global Flags + Some Private Flags]" because I don't know how to manage this level of state complexity in a consistent way and surprise-free way, unless each flag is defined as *either* private *or* global, (which I really *wish* I could convince myself was reasonable, since it simplifies the problem.) > > -A user views a mailbox EITHER with Global or Private flags, NEVER both. > > A bboard with several administrators that read the bboard probably > will want private \SEEN flags for the administrators, while sharing > the other flags. I agree that private \seen flags can be useful (though I hold that global \seen can also be useful). I'm struggling with how we would keep track of the fully general case. A message is marked answered; did I answer it, or did someone else on the team? Likewise SEEN, FLAGGED, etc... How does the user know, for any given flag in any given mailbox, what its scope is? Also, how does the client know when to look for a client-maintained file of private flags, e.g. .newsrc, or its mailbox equivalent for, say, a remote message archive? > > -A user with RW/EXPUNGE rights will use Global flags, never Private flags. > > What about a user with RW but not EXPUNGE rights? How about a user > with EXPUNGE but not APPEND rights? What about the several > administrators that read the bboard separately (e.g. a club bboard > with several officers who have RW/EXPUNGE rights)? My assumptions do not preclude multiple users with expunge rights. (But if multiple people do have expunge rights, they better also have a common vision of who expunges and when!) I agree that one could meaningfully have the ability to store, say, a Flagged flag without having expunge rights. But that leads either to (a) asserting that some flags are inherently global, the others inherently private --which I still can't convince myself is true, or (b) the dilemma of having arbitrary mixtures of private and global flags --which I don't know how to manage, especially when in some cases the private flags will be maintained by the server, and in other cases by the client. As a simplifying assumption, I was hoping we could key on expunge rights to determine whether to look for (and use) private flags. If that won't work, we need to tighten-up our thinking caps one more notch... -teg From owner-c-client@cac.washington.edu Sun Oct 17 21:38:45 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05167; Sun, 17 Oct 93 21:38:45 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05831; Sun, 17 Oct 93 21:38:37 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05825; Sun, 17 Oct 93 21:38:31 -0700 Received: by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA22043; Sun, 17 Oct 93 21:38:30 PDT Date: Sun, 17 Oct 93 21:38:30 PDT From: mtm@CAMIS.Stanford.EDU (Mike Macgirvin) Message-Id: <9310180438.AA22043@CAMIS.Stanford.EDU> To: gray@cac.washington.edu, steve@edm.isac.ca Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release Cc: MRC@CAC.Washington.EDU, c-client@CAC.Washington.EDU, pine@cac.washington.edu Re: FIND, etc. and .mailboxlist behaviour -- Please keep the rest of us informed what direction things go. Thanks. mike From owner-c-client@cac.washington.edu Sun Oct 17 23:22:42 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06370; Sun, 17 Oct 93 23:22:42 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19443; Sun, 17 Oct 93 23:22:32 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19437; Sun, 17 Oct 93 23:22:26 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA02651; Sun, 17 Oct 93 23:22:14 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA20896; Sun, 17 Oct 93 23:22:05 -0700 Date: Sun, 17 Oct 1993 23:11:42 -0700 (PDT) From: Mark Crispin Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Mike Macgirvin Cc: gray@cac.washington.edu, steve@edm.isac.ca, c-client@CAC.Washington.EDU, pine@cac.washington.edu In-Reply-To: <9310180438.AA22043@CAMIS.Stanford.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mike - In brief (modulo things like mh folders, non-netnews bboards, etc.): . mail_find() contents of .mailboxlist non-bboard entires . mail_find_bboards() contents of .newsrc + .mailboxlist bboard entries . mail_find_all() contents of directory . mail_find_all_bboards() contents of netnews ACTIVE file I have just removed the compatibility code for Pine 3.8[456] that made mail_find() call mail_find_all() if there was no .mailboxlist file. The imapd that is distributed with Pine 3.87 has this compatibility code, but Pine 3.87 does not need it. -- Mark -- From owner-c-client@cac.washington.edu Mon Oct 18 07:41:30 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15386; Mon, 18 Oct 93 07:41:30 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21323; Mon, 18 Oct 93 07:41:16 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21317; Mon, 18 Oct 93 07:41:14 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id KAA09667; Mon, 18 Oct 1993 10:41:09 -0400 Received: via switchmail; Mon, 18 Oct 1993 10:41:09 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 10:40:30 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 10:40:21 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.cortland.andrew.cmu.edu.pmax.ul4 via MS.5.6.cortland.andrew.cmu.edu.pmax_ul4; Mon, 18 Oct 1993 10:39:58 -0400 (EDT) Message-Id: <4gkeeyO00WAqQ0tyZW@andrew.cmu.edu> Date: Mon, 18 Oct 1993 10:39:58 -0400 (EDT) From: Wallace Colyer To: imap@cac.washington.edu Subject: Re: More on /SEEN and /DELETED... Cc: imap@cac.washington.edu, c-client@cac.washington.edu In-Reply-To: References: First, I should say, if the seen flag in the .newsrc means seen, I think the IMAPD should honor the meaning, but since that doesn't seem like it is going to fly.... I see three different actions here: SEEN DELETED and a third which I will call BURPLYBLOOP I disagree is Terry with respect to the meaning of DELETED. To me, DELETED means marked for deletion, and when I say deletion I mean physical removal from the mail store. I think it is VERY important for this to have a consistant meaning. Why, because otherwise people are required to know what the state of the mailstore is when they use this flag. When I mark a message for deletion, I expect the EXPUNGE operation to physically remove the message so that no one else can see it. To have any other action on the DELETED flag, to me, is inherently dangerous. In netnews, if I am allowed to delete the message I expect the server to send out a cancel and remove it from the local store (I like who ever said this earlier). DELETED could be a personal flag and when I do an EXPUNGE operation it may only delete the things I have marked for deletion, but the CMU Cyrus IMAPD will certainly implement it as global. The SEEN flag is marked when I have seen the message. My message viewer may choose to not show me the message after I have seen it. A good message view will allow that option as one view, but allow me other views to see the other messages in the folder. The BURPLYBLOOP flag says, "Don't show me the message". Here I am not deleting the message. I am not marking it as seen, because I may or may not have seen it. I am saying, when BURPLYBLOOP is set, don't show me the message. This gives the clients all the options in the world to handle this as desired and causes no negative behavior. They can choose to show me BURPLYBLOOP marked messages, SEEN messages, and DELETED messages, or any combination of those and other state. I further support the prevailing view that the current method of using DELETED is very very very dangerous. From owner-c-client@cac.washington.edu Mon Oct 18 07:47:34 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15539; Mon, 18 Oct 93 07:47:34 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21354; Mon, 18 Oct 93 07:47:25 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21348; Mon, 18 Oct 93 07:47:24 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id KAA10118; Mon, 18 Oct 1993 10:47:21 -0400 Received: via switchmail; Mon, 18 Oct 1993 10:47:20 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 10:45:40 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 10:45:38 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 18 Oct 1993 10:45:34 -0400 (EDT) Message-Id: Date: Mon, 18 Oct 1993 10:45:34 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Re: More on /SEEN and /DELETED... In-Reply-To: References: Beak: Is Terry Gray writes: > One could as easily argue that C-client's handling of \deleted for > *conventional* personal mailboxes is dangerous! And it is!! After all, > in a personal mailbox, an individual gets to mark a msg as deleted (or > uninteresting), and since they have expunge rights, actually make it go > away. You've got to be kidding. When a user marks a message in a personal mailbox as deleted, they really want the message to go away. As long as this model is kept consistent, they will only mark messages in shared mailboxes when they really want the message to be permanently removed. There is also the minor fact that personal mailboxes are generally in their own part of the namespace. CMU has had this model (delete means really delete, UI doesn't go through pains to identify folders as "shared") for years and has had no problems that I am aware of. The redefinition of "\Deleted" as "uninteresting" is part of the c-client news philosophy and is part of what we find so dangerous. "Uninteresting" is an attribute of the user's view, not of the message. > > Messages "magically and implicitly disappear" due to the view you > > selected? One might as well use the same arguments against kill > > files. > > Not at all. Kill files are the result of *explicit* action by the user. Selecting an "unseen only" view and reading messages are explicit actions by the user. > > "The other paradigm" assumes that "Type 1" mailboxes with multiple > > readers don't exist. > > Not at all. Unless John wishes to legislate "normal" unshared personal > mailboxes out of existence as well (and of course he doesn't), this > argument makes no sense to me. Then how, using your paridgm, do you mark a shared "Type 1" mailbox as being uninteresting to you, but without actually removing the message. > In many of the other cases where "IS_NEWS" is > used, a macro named something like IS_IMMUTABLE would have been better, > since NEWS is only one of possibly many classes of immutable mailboxes. There is already a separate READONLY_FOLDER macro, which didn't get used. Put another way the uses: * Whether or not un-\Seen messages are marked as "NEW" in the bar status * Whether or not TAB will stop on un-\Seen messages * On TAB command, whether to say "No more undeleted messages" or "No more new messages" Were made necessary because c-client changed the mapping of .newsrc from \Seen to \Deleted. Every other client is going to have to have this knowledge of this difference between "mail" and "news", or they're not going to interoperate with the c-client imapd. > > The user must shift the meaning of 'D' from "physically delete > > this message" to "don't show me this message, for now". > > Incorrect, both with respect to the "from" and the "to"... > > A "D" does *not* mean "physically delete this message", no matter what > the protocol spec might say. We all know that "D" has absolutely no > effect on the message other than to signal *intent* by associating a flag > with that message. You're picking nits. To reword, ``The user must shift the meaning of 'D' from "intend to physically delete this message on later expunge" to "don't show me this message for now."'' > [NB: Even if we keep the \deleted "statement of intent" separate from the > action of expunging, which I certainly support, we still must decide what > \deleted means for immutable mailboxes. A *global* \deleted flag for an > immutable message store makes no sense to me.] For immutable mailboxes, \Deleted means "intend to physically delete this message on later expunge." The fact that the mailbox is immutable doesn't matter. What does COPY mean when the destination is an immutable mailbox? > Nor does "D" mean "don't show me this message for now", although that > could be a *side effect* of the currently defined view. You're using this "side effect" as a fundamental reason for changing the definition of \Deleted. > Conversely, I would claim the CMU community has not used "browse" mode for > news only because of limitations in the CMU system, namely that it only > keeps a single pointer, delimiting old and new. The CMU system still allows users to go back and view messages which had previously been marked as old. > But I have a real problem with overloading the /seen flag > to imply "no future interest in this msg". It doesn't imply that, it implies "not interested in this message when looking for new messages." > > Again, your interpretation of the \Deleted flag does not correspond to > > its definition in the IMAP protocol specificiation. > > The protocol spec reflects a traditional terminology that was *never* > precisely accurate, and doesn't translate perfectly to the world of > immutable mailboxes and private flag sets that we are now trying to extend > IMAP and c-client to cover. Either we forbid \deleted from being used on > immutable mailboxes, in which case we need to invent another flag that > would be redundant in the RW case, or we try to find an "enhanced" > interpretation of the existing flag that can work for both RO and RW > mailboxes. You certainly haven't reached a consensus for "enhancing" the interpretation of the existing \Deleted flag. Last I checked, it was 1 for, 3 against. This "enhancement" of the meaning is actualy an incompatible change which we consider extremely dangerous. > So I have *no* problem with being able to say "just show > me new messages right now"... but I object to the idea that this transient > "bulk" definition of what's interesting at the moment has anything to do > with a per-message *explicit* declaration that a particular message is of > no future interest. I don't understand. How is this any different when applied to \Deleted? > A message is marked answered; did I answer it, or > did someone else on the team? Likewise SEEN, FLAGGED, etc... How does the > user know, for any given flag in any given mailbox, what its scope is? I consider this one of the key problems with Chris' suggestion that flags be private or global depending on the user's access. I believe that for a given flag in a given mailbox, it should be private for everybody or global to everybody. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Mon Oct 18 09:03:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17721; Mon, 18 Oct 93 09:03:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11351; Mon, 18 Oct 93 09:03:03 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11345; Mon, 18 Oct 93 09:03:01 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id MAA04262; Mon, 18 Oct 1993 12:02:57 -0400 Received: via switchmail; Mon, 18 Oct 1993 12:02:56 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 12:02:53 -0400 (EDT) Received: via niftymail; Mon, 18 Oct 1993 12:02:47 -0400 (EDT) Date: Mon, 18 Oct 1993 12:02:37 -0400 (EDT) From: Chris Newman Subject: Re: Terry's assumptions about mailboxes To: c-client@cac.washington.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750960157.10184.0@nifty.andrew.cmu.edu> Terry Gray writes: > More difficult for me to accept is the case of > "Mailbox = [Msg Data + Some Global Flags + Some Private Flags]" > because I don't know how to manage this level of state complexity in a > consistent way and surprise-free way, unless each flag is defined as > *either* private *or* global, (which I really *wish* I could convince > myself was reasonable, since it simplifies the problem.) Well, this is exactly what the Cyrus imapd is going to do. \SEEN is always going to be private because we've found global \SEEN to be useless in practice. \DELETED is always going to be global so that every user knows which messages EXPUNGE will remove. The other flags are going to be global because we don't consider them important enough to merit the high cost of per-user storage. Since flag behavior won't change between different mailbox types, I don't believe Cyrus users will be surprised. I think the answer is that every good server implementation should be internally consistant about global vs. local flags. > Also, how does the client know when to look for a client-maintained file > of private flags, e.g. .newsrc, or its mailbox equivalent for, say, a > remote message archive? I believe we all agree this problem needs to be solved. This is why CMU has suggested that the FLAGS reply exclude non-permanent flags. If the flag isn't in the FLAGS reply, then the client can look for a client-maintained file. > I agree that one could meaningfully have the ability to store, say, a > Flagged flag without having expunge rights. But that leads either to (a) > asserting that some flags are inherently global, the others inherently > private --which I still can't convince myself is true, or (b) the dilemma > of having arbitrary mixtures of private and global flags --which I don't > know how to manage, especially when in some cases the private flags > will be maintained by the server, and in other cases by the client. I suspect private vs. global is ultimately a religious issue and thus must be implementation specific. > As a simplifying assumption, I was hoping we could key on expunge rights > to determine whether to look for (and use) private flags. If that won't > work, we need to tighten-up our thinking caps one more notch... It certainly won't work with the Cyrus imapd. You can have "seen" rights which permit storing \SEEN info on the server without having "delete" rights which permit storing the \DELETED flag and EXPUNGE. - Chris From owner-c-client@cac.washington.edu Mon Oct 18 09:25:45 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18456; Mon, 18 Oct 93 09:25:45 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11855; Mon, 18 Oct 93 09:25:35 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11849; Mon, 18 Oct 93 09:25:34 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11475; Mon, 18 Oct 93 09:25:23 -0700 Date: Mon, 18 Oct 1993 09:06:16 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: More on /SEEN and /DELETED... To: John Gardiner Myers Cc: c-client@CAC.Washington.EDU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII John, The good news is that at least *some* of our difference still seems to be a result of misunderstandings rather than convictions... :) On Mon, 18 Oct 1993, John Gardiner Myers wrote: > Terry Gray writes: > > One could as easily argue that C-client's handling of \deleted for > > *conventional* personal mailboxes is dangerous! > > You've got to be kidding. This statement says to me that I have totally failed to communicate and/or you have totally failed to understand what I'm trying to say. I was not kidding. > When a user marks a message in a personal mailbox as deleted, they > really want the message to go away. This is precisely what is meant by "D" in Pine in all cases, news and mail. The only difference between the the two is whether or not you can later successfully expunge the messages you marked for deletion. To account for that possibility, I attempted, obviously unwisely, to redefine the "deleted" term so it didn't sound so contradictory in the RO case (or more precisely, in the "no expunge rights" case.) But from the user's perspective, the motivation for typing "D" is identical in both the mail case and the news case. It is totally consistent. It means "delete it (if you can), I'm done with it". > As long as this model is kept > consistent, they will only mark messages in shared mailboxes when they > really want the message to be permanently removed. It is precisely because Pine does keep this absolute consistency in usage that the claim of it's behavior being dangerous is bogus. > There is also the minor fact that personal mailboxes are generally in > their own part of the namespace. Shareability and RO-ness are, and should be, orthogonal to location. > CMU has had this model (delete means really delete, UI doesn't go > through pains to identify folders as "shared") for years and has had > no problems that I am aware of. The only difference between the CMU and UW models is that apparently you don't permit someone to mark a message as "deleted" if they don't have expunge rights. The essence of my --apparently ultra controversial-- position is that I believe it is useful to let someone mark a message as deleted even if they do not have the right to expunge it. If you *do* let people delete even without expunge rights, then exactly what is it that you are unhappy about in our position? > The redefinition of "\Deleted" as "uninteresting" is part of the > c-client news philosophy and is part of what we find so dangerous. > "Uninteresting" is an attribute of the user's view, not of the message. The "intend to delete" flag that we call \Deleted has always been an attribute of the user's view of the message in exactly the same sense. Whether that intent is actionable depends on having expunge rights. > > > Messages "magically and implicitly disappear" due to the view you > > > selected? One might as well use the same arguments against kill > > > files. > > > > Not at all. Kill files are the result of *explicit* action by the user. > > Selecting an "unseen only" view and reading messages are explicit > actions by the user. Agreed. What I object to is not having the ability to differentiate between \seen and \deleted for purposes of my current view. That is, I want the ability to mark news messages that I'm done with as \deleted, just as I would a mail message --even if I don't have expunge rights. > Then how, using your paridgm, do you mark a shared "Type 1" mailbox as > being uninteresting to you, but without actually removing the message. In a type 1 mailbox, the state is shared by definition, so when I mark a message as \deleted it has global effect. The next expunge nails it. > > In many of the other cases where "IS_NEWS" is > > used, a macro named something like IS_IMMUTABLE would have been better, > > since NEWS is only one of possibly many classes of immutable mailboxes. > > There is already a separate READONLY_FOLDER macro, which didn't get used. Unfortunately, there are cases where folders become RO due to errors or transient locking phenomena. I *think* the UA needs to distinguish between the transient RO case and the RO-because-of-access-restrictions case, but I'd be pleased to be wrong on that. There may also be cases where the READONLY_FOLDER macro should have been used... > Put another way the uses: > > * Whether or not un-\Seen messages are marked as "NEW" in the bar status > * Whether or not TAB will stop on un-\Seen messages > * On TAB command, whether to say > "No more undeleted messages" or "No more new messages" > > Were made necessary because c-client changed the mapping of .newsrc > from \Seen to \Deleted. Every other client is going to have to have > this knowledge of this difference between "mail" and "news", or > they're not going to interoperate with the c-client imapd. These are all a result of having only one bit to play with in the .newsrc, and having decided that it was more useful to store /deleted than /seen. These are not fundamental news vs. mail issues. A richer .newsrc structure would eliminate this issue. > You're picking nits. To reword, ``The user must shift the meaning of > 'D' from "intend to physically delete this message on later expunge" > to "don't show me this message for now."'' NO NO NO!!! "D" does *not* mean "don't show me this message for now". The "D" means "I'm done with it forever. Make it go away --if you can!". One's current view may or may not include messages so marked. > What does COPY mean when the destination is an immutable mailbox? If you don't have the rights to do the copy, you get an error, just like if you don't have the rights to do an expunge, you get an error. > > Nor does "D" mean "don't show me this message for now", although that > > could be a *side effect* of the currently defined view. > > You're using this "side effect" as a fundamental reason for changing the > definition of \Deleted. Definitely not. Again, the issue is whether or not it is sensible to mark a message as \Deleted even when you don't have expunge rights. I claim it is, you apparently feel otherwise. > You certainly haven't reached a consensus for "enhancing" the > interpretation of the existing \Deleted flag. Last I checked, it was > 1 for, 3 against. This "enhancement" of the meaning is actualy an > incompatible change which we consider extremely dangerous. Look at it this way: all I've been trying to say throughout this entire debate is that I want to be able to mark a news message as deleted, and have that mean *exactly* the same thing as it would in the case of a mail message, regardless of the fact that a subsequent expunge might fail or be forbidden. (Which of course might happen in the mail case as well.) I'm not yet sure whether my attempt to explain this position via the semantics of word "deleted" was just terribly ineffective, or whether you guys really believe it is a terrible idea to allow someone to set a \Deleted flag in cases where they don't have expunge rights. > > A message is marked answered; did I answer it, or > > did someone else on the team? Likewise SEEN, FLAGGED, etc... How does the > > user know, for any given flag in any given mailbox, what its scope is? > > I consider this one of the key problems with Chris' suggestion that > flags be private or global depending on the user's access. I can see how to deal with the case where they were *all* global or *all* private for a given session... but the mix-n-match scenario really scares me. Your and Chris' suggestion about the server telling the client what flags it lets the client set might give the UA enough info to somehow present each flag's scope, but I haven't yet thought of a way to do that "elegantly" > I believe > that for a given flag in a given mailbox, it should be private for > everybody or global to everybody. I agree that our problem would be much simpler if we could do this, but when I look at each flag and try to decide if there are any that are meaningless in either a private or a global context, I don't see any silly states. Also, to legislate that certain flags are inherently private has far-reaching implementation consequences since there are servers that don't have the concept of "private flags". -teg From owner-c-client@cac.washington.edu Mon Oct 18 09:34:41 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19076; Mon, 18 Oct 93 09:34:41 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12096; Mon, 18 Oct 93 09:34:29 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12086; Mon, 18 Oct 93 09:34:20 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29155; Mon, 18 Oct 93 09:34:18 -0700 Date: Mon, 18 Oct 1993 09:23:44 -0700 (PDT) From: Michael Seibel Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Terry Gray Cc: Steve Hole , Mark Crispin , pine@cac.washington.edu, c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Word from the pine team is that versions 3.07 and earlier built all folder lists by hand (actually sniffing local directories). All pine versions, including pc-pine, since 3.80 use c-client provided tools (i.e., find, find_all) for putting together folder lists. The conversion strategy sound right from here, as well. -mikes From owner-c-client@cac.washington.edu Mon Oct 18 10:23:37 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20779; Mon, 18 Oct 93 10:23:37 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13157; Mon, 18 Oct 93 10:23:20 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13151; Mon, 18 Oct 93 10:23:17 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13764; Mon, 18 Oct 93 10:23:15 -0700 Date: Mon, 18 Oct 1993 10:13:37 -0700 (PDT) From: Terry Gray Subject: Re: Terry's assumptions about mailboxes To: Chris Newman Cc: c-client@cac.washington.edu In-Reply-To: <750960157.10184.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Oct 1993, Chris Newman wrote: > Well, this is exactly what the Cyrus imapd is going to do. \SEEN is > always going to be private because we've found global \SEEN to be > useless in practice. My experience differs. Both private and global \seen convey useful information... global \seen lets one quickly identify which messages have as yet been unread by *anyone*... > \DELETED is always going to be global so that > every user knows which messages EXPUNGE will remove. Yes, if you have expunge rights, your \deleted flag *must* be global. -teg From owner-c-client@cac.washington.edu Mon Oct 18 10:30:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20975; Mon, 18 Oct 93 10:30:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13311; Mon, 18 Oct 93 10:30:29 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13305; Mon, 18 Oct 93 10:30:25 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id NAA05525; Mon, 18 Oct 1993 13:30:16 -0400 Received: via switchmail; Mon, 18 Oct 1993 13:29:57 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 13:29:39 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 13:29:34 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.cortland.andrew.cmu.edu.pmax.ul4 via MS.5.6.cortland.andrew.cmu.edu.pmax_ul4; Mon, 18 Oct 1993 13:29:14 -0400 (EDT) Message-Id: <4gkh9e200WAqI0tz9L@andrew.cmu.edu> Date: Mon, 18 Oct 1993 13:29:14 -0400 (EDT) From: Wallace Colyer To: c-client@CAC.Washington.EDU, Terry Gray Subject: Re: More on /SEEN and /DELETED... Cc: c-client@CAC.Washington.EDU In-Reply-To: References: Let me pose some simple questions which I think Chris asked earlier. First, let me state my assumption that you cannot assume that netnews is the only thing in the bboard namespace and netnews may exist in the mailbox namespace as well. How do I delete a message from my personal view not not from everyone's view when I am in a shared folder? How do I delete a message permanently from a mailstore so no one can see it? Is it based on whether I perform the expunge command? If so, how do I delete some messages from my personal view and some from the permanent mailstore? -Wallace From owner-c-client@cac.washington.edu Mon Oct 18 11:26:03 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23153; Mon, 18 Oct 93 11:26:03 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14600; Mon, 18 Oct 93 11:25:44 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14594; Mon, 18 Oct 93 11:25:42 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15954; Mon, 18 Oct 93 11:25:39 -0700 Date: Mon, 18 Oct 1993 10:32:14 -0700 (PDT) From: Terry Gray Subject: Re: More on /SEEN and /DELETED... To: Wallace Colyer Cc: c-client@CAC.Washington.EDU In-Reply-To: <4gkh9e200WAqI0tz9L@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Oct 1993, Wallace Colyer wrote: > First, let me state my assumption that you cannot assume that netnews is > the only thing in the bboard namespace and netnews may exist in the > mailbox namespace as well. Agreed. We are just talking about the relationship between \DELETED and expunge rights, and those are orthogonal to both namespace and whether we are dealing with "news" or "mail". > How do I delete a message from my personal view not not from everyone's > view when I am in a shared folder? You don't, at least not if you have expunge rights to that shared folder, because if you can expunge, your \deleted flag *must* be global. (Whether \deleted should be global --or even allowed-- when you do *not* have expunge rights is a separate, and more interesting, question.) > How do I delete a message permanently from a mailstore so no one can see it? "In the normal way"... :) Again, *if* you have expunge rights... > Is it based on whether I perform the expunge command? If so, how do I > delete some messages from my personal view and some from the permanent > mailstore? If you have the *right* to expunge, the \deleted flag is necessarily global, so in that case there is no distinction between "personal view" and what happens to the permanent mailstore. My premise is that \DELETED should be *consistently* available to the user to indicate that s/he is done with the message and intends, if it is within his/her power, to have that message go away. Clearly, in a shared mailbox case, *if* the user has expunge rights, their \DELETED flag *must* be global. So that leads us to the case of *not* having expunge rights. What about \deleted then? Three choices: 1. \deleted is disallowed (an error) 2. \deleted is global 3. \deleted is private Chris' last message suggests that Cyrus chooses option #1, tying whether or not you can set \deleted to whether or not you have expunge rights. Example of where #2 would be useful: I work for you, and we share a trouble tracking folder. You don't completely trust me :) so you don't give me expunge rights, but you want an easy way to see whether I think a case is closed. When I finish a case I mark it deleted. You review my work, and if you agree let the \deleted stand. Periodically you expunge. Note that Answered, while useful, does not imply that the case is closed. Example of where #3 is useful: You have access to a remote message archive, but no access rights other than read. You'd like to keep track of which messages you've seen, of course, but in addition, you'd like to be able to use \deleted as you always do, to indicate that you are forever done with the msg and would like it deleted --even if you are unable to enforce that intent. To forbid this case as an error forces a user-behavior change... In all the cases the user would normally say "delete" s/he now gets an error. (It's true that, even if we allow the private \deleted for this case, a subsequent expunge will generate an error, but that happens in case #2 as well.) By allowing users to set \deleted in this situation, we can come very close to providing the semantics of a private mailbox, without actually having to replicate the message archive (or deal with getting updates). Not being able to expunge seems a small price to pay for this benefit. -teg From owner-c-client@cac.washington.edu Mon Oct 18 12:33:07 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25634; Mon, 18 Oct 93 12:33:07 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22947; Mon, 18 Oct 93 12:32:51 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22941; Mon, 18 Oct 93 12:32:49 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA07169; Mon, 18 Oct 1993 15:32:47 -0400 Received: via switchmail; Mon, 18 Oct 1993 15:32:45 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 15:32:20 -0400 (EDT) Received: via niftymail; Mon, 18 Oct 1993 15:32:16 -0400 (EDT) Date: Mon, 18 Oct 1993 15:32:12 -0400 (EDT) From: Chris Newman Subject: Re: More on /SEEN and /DELETED... To: c-client@CAC.Washington.EDU In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750972732.10184.0@nifty.andrew.cmu.edu> Terry Gray writes: > The essence of my --apparently ultra controversial-- > position is that I believe it is useful to let someone mark a message as > deleted even if they do not have the right to expunge it. I think this is a dangerous garden-path scenerio. Here's an example: Jane User uses the FOOBAR client which always does an EXPUNGE on exit. She learns that hitting 'd' in her mail folder makes the message go away. She also learns that hitting 'd' in non-mail folders doesn't make the message go away. She then joins a group project with a group RW/E folder. Because it's another non-mail folder she assumes she can hit 'd' and the message won't go away. She has never encountered a case where hitting 'd' makes the message disappear for other people, so she assumes it won't. FOOBAR issues its EXPUNGE and the message goes away. Note what you have happening here. Your proposal forces Jane to make distinctions between different types of mailboxes. She made a reasonable assumption which caused the loss of important work. In order to understand what happened, she needs to learn that 'd' does different things based on "EXPUNGE" rights -- which is not a simple concept. So what's wrong with the scenerio: A) Your proposal is dangerous and forces users to distinguish between different mailbox object types. B) Jane was stupid for not understanding "EXPUNGE" rights. She needs to learn how to properly distinguish different mailbox object types before she can be allowed to use a c-client program. C) FOOBAR client was designed wrong (what should be fixed?). - Chris From owner-c-client@cac.washington.edu Mon Oct 18 12:49:08 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25994; Mon, 18 Oct 93 12:49:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15942; Mon, 18 Oct 93 12:48:54 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15936; Mon, 18 Oct 93 12:48:53 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17942; Mon, 18 Oct 93 12:48:51 -0700 Date: Mon, 18 Oct 1993 12:36:14 -0700 (PDT) From: Terry Gray Subject: Re: More on /SEEN and /DELETED... To: Chris Newman Cc: c-client@CAC.Washington.EDU In-Reply-To: <750972732.10184.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Chris, Your argument that my model forces users to make distinctions between different mailbox types is bogus because the same concerns apply to the CMU model (e.g. just having or not having delete rights in general.) The fact is, there *are* differences in access rights, and these differences result in errors, which result in changes in user behavior. This is true whether \delete is forbidden, as you prefer, or whether just expunge is forbidden. If your view prevails, it means that c-client will be far less useful for supporting the "pseudo personal" mailbox case (where the remote message archive is totally RO.) -teg From owner-c-client@cac.washington.edu Mon Oct 18 13:16:59 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27122; Mon, 18 Oct 93 13:16:59 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23313; Mon, 18 Oct 93 13:16:49 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23307; Mon, 18 Oct 93 13:16:47 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA03062; Mon, 18 Oct 93 13:16:35 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA23464; Mon, 18 Oct 93 13:16:27 -0700 Date: Mon, 18 Oct 1993 12:36:01 -0700 (PDT) From: Mark Crispin Subject: Re: More on /SEEN and /DELETED... To: Wallace Colyer Cc: c-client@CAC.Washington.EDU, Terry Gray In-Reply-To: <4gkh9e200WAqI0tz9L@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mind you, Terry and I don't agree 100% on these issues. I have a completely different perspective, based in part from dealing with this stuff for 7 years and having a set of ``seat-of-the-pants feelings''. I've been trying to stay mostly out of this issue, until it reaches the ``what does this mean when it is implemented in c-client?'' point... ;-) But some of your questions were interesting enough to deserve answers from my perspective. On Mon, 18 Oct 1993 13:29:14 -0400 (EDT), Wallace Colyer wrote: > First, let me state my assumption that you cannot assume that netnews is > the only thing in the bboard namespace and netnews may exist in the > mailbox namespace as well. Agreed. > How do I delete a message from my personal view not not from everyone's > view when I am in a shared folder? > How do I delete a message permanently from a mailstore so no one can see it? > Is it based on whether I perform the expunge command? If so, how do I > delete some messages from my personal view and some from the permanent > mailstore? These questions are based upon a presumption of a unity of shared folders. This doesn't exist in c-client. Instead, c-client has several different types of shared folders, with different classes of access: 1) BBoards: (in the IMAP sense, or ``blurdybloops'' if you prefer) 1a) Netnews. Per-user \Deleted flags, \Recent flags begin after the highest-numbered \Deleted flag, other flags are per-session. 1b) Non-netnews mailbox formatted. All flags are per-session. \Recent set for all messages. File may have initial settings for the per- session flags, but user can't change them. 1c) Non-formatted objects. Presented as a single message with no flags initially set. Any flags are per-session. Note that with BBoards, there is a commonality in that there are no shared flags that the user can set. At best, he can set a per-user flag. Also, EXPUNGE is always meaningless with a BBoard; as CMU says, they are second class citizens (and useless for them). 2) Shared Mailboxes: 2a) read/write mailbox formatted. Flags are global. 2b) read-only mailbox formatted. Similar to 1b) case. 2c) read-only non-formatted objects. Similar to 1c) case. 2d) read/write non-formatted objects. No definition yet. We have talked about per-user flags with mailboxes, but don't do anything about it yet. It is important to realize that although you CAN access bboard objects in the mailbox namespace by prepending a * to the name, this is an internal convenience for c-client only. It does not mean that bboards are considered inside the c-client namespace. It may have been a mistake to have a separate bboard namespace, but, at the time this decision was made, it was presented to me as a *given* that the namespace is separate. My own givens were that it was unreasonable to issue an error message where there was something arguably useful to do for the user. It quickly became clear that in many cases, the only useful you could do was set a per-session flag. I still dispute the claim that it is wrong to have per-session flags as a capability; it is entirely up to the user interface to decide whether or not users may have access to these. There is also a question about whether or not it is right to recycle the meaning of \Deleted in the BBoard namespace as Terry has done. I believe that it is ``not wrong''; that a fair and reasonable case can be made to do so. I have my own opinions about whether or not ``not wrong'' imply ``right'', but they are irrelevant to this discussion. So far, he arguments against this use of \Deleted presume that this is taking place in the mailbox namespace. It is not. It can not. This also pretty well debunks the CMU claim of danger. They need never encounter the need to support this in their servers, because they don't use the bboard namespace. If, for compatibility sake, they decided to support the bboard namespace in their servers, they could change the \Deleted request in that namespace to a request in the mailbox namespace that makes more sense. Similarly, if they were to support the bboard namespace in their clients for compatibility with our servers, they would undoubtably choose to hide the fact that a \Deleted flag is set. As I see the REAL problem, the question is one of determining access rights. In a more sophisticated application, you want to make a determination of what kind of object you are dealing with and what are your access rights to that object. The present Pine gets along with the bboard/mailbox namespace switch and the read-only switch to subdivide mailboxes; that is, it deals with three different access right entities. The present Pine doesn't distinguish between shared read/write mailboxes and private read/write mailboxes. It is not hard to imagine more sophisticated choices being made than what Pine uses (after all, I did list 7 different kinds of shared mailboxes, of which 6 are supported now by c-client!), but I don't think that pulling a capability that some people think isn't useful isn't the way to go about enabling those choices. I probably find myself alone in defending c-client's current model. I want to caution folks, though; don't forget that whatever we end up with has to be implementable! c-client differs from Cyrus in a very fundamental way; it is intended to interoperate with whatever crufty infrastructure may already be in place. Cyrus has the luxury of starting from scratch (and yes, I covet that luxury!). I have heard a number of things in this discussion which would be quite difficult to implement in the c-client context, or which would introduce interoperability problems. From owner-c-client@cac.washington.edu Mon Oct 18 13:46:18 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27964; Mon, 18 Oct 93 13:46:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17063; Mon, 18 Oct 93 13:45:49 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17057; Mon, 18 Oct 93 13:45:45 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id QAA08281; Mon, 18 Oct 1993 16:45:43 -0400 Received: via switchmail; Mon, 18 Oct 1993 16:45:42 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 16:45:04 -0400 (EDT) Received: via niftymail; Mon, 18 Oct 1993 16:44:59 -0400 (EDT) Date: Mon, 18 Oct 1993 16:44:55 -0400 (EDT) From: Chris Newman Subject: Re: More on /SEEN and /DELETED... To: Terry Gray Cc: c-client@CAC.Washington.EDU In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750977095.10184.0@nifty.andrew.cmu.edu> Terry Gray writes: > Your argument that my model forces users to make distinctions between > different mailbox types is bogus because the same concerns apply to the > CMU model (e.g. just having or not having delete rights in general.) I don't think it's bogus. Users are used to have options "grayed out" or rejected because they "don't have permission". The problem comes when a user takes an action which is successful, but does different things in different situations. > If your view prevails, it means that c-client will be far less useful for > supporting the "pseudo personal" mailbox case (where the remote message > archive is totally RO.) I have already stated that the concept you suggest is useful -- I'm just opposed to overloading \DELETED. >From what I understand of your _intent_ for use of \DELETED in netnews, may I suggest adding a user flag "hidden" which means the user is not interested in seeing the message again? All you have to do is lobby client makers to have a default view of "UNKEYWORD hidden" and you get what you want. If you wait for NSEARCH, you could even add a \HIDDEN system flag. - Chris From owner-c-client@cac.washington.edu Mon Oct 18 14:10:00 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28831; Mon, 18 Oct 93 14:10:00 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23623; Mon, 18 Oct 93 14:09:46 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23617; Mon, 18 Oct 93 14:09:44 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id RAA05506; Mon, 18 Oct 1993 17:09:34 -0400 Received: via switchmail; Mon, 18 Oct 1993 17:09:26 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 18 Oct 1993 17:08:10 -0400 (EDT) Received: via niftymail; Mon, 18 Oct 1993 17:08:06 -0400 (EDT) Date: Mon, 18 Oct 1993 17:08:06 -0400 (EDT) From: Chris Newman Subject: Per-session flags To: c-client@CAC.Washington.EDU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750978486.10184.0@nifty.andrew.cmu.edu> Mark contends that it is "not wrong" to have per-session flags. I believe there are two cases here: 1) If the client can't find out which flags are per-session and which are stored, then per-session flags are "wrong". Take the \Seen example. The client either presents the server \Seen which may not persist and thus could confuse users, or it would always keep it's own \Seen which breaks mobility. 2) If the client can find out which flags are per-session, I claim that per-session flags are "useless". The reason is that a smart client will store local state for the flags it can't store on the server, and a less-smart client will present no state, to prevent user confusion (e.g. "Hello, computer help line. There's this message that I've seen before, but my mail program says I haven't seen it! What's broken?"). - Chris From owner-c-client@cac.washington.edu Mon Oct 18 14:41:42 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29900; Mon, 18 Oct 93 14:41:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18177; Mon, 18 Oct 93 14:41:27 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18171; Mon, 18 Oct 93 14:41:25 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21707; Mon, 18 Oct 93 14:41:20 -0700 Date: Mon, 18 Oct 1993 14:11:31 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: More on /SEEN and /DELETED... To: Chris Newman Cc: c-client@CAC.Washington.EDU In-Reply-To: <750977095.10184.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Chris, I believe your argument is: that because Pine treats D the same for mail and news, when users encounter a shared mailbox with RWE access, they will continue to use D with possibly dangerous results. Take news out of the equation above and you'll see the inconsistency of that argument. Anyone who uses a personal mailbox (where I presume deletion is permitted) will be potentially dangerous given a shared mailbox with RWE access, unless they are suitably educated. There is nothing greyed-out, but the number of people affected by the "formerly harmless" action could be very different. As to a separate flag... two points: -I'm not eager to embrace this solution because I fear it adds needless cruft to the user-interface and/or protocol. -Such a flag should not be called "hidden" because "hiddenness" is a property of the current view, not an attribute of a message. Consider again the case of a shared mailbox, where an underling marks a message as deleted when s/he is done with it, for subsequent review by a superior who has expunge rights. The need is not for a "hidden" flag, but something that conveys "doneness" or "dismissal", which is exactly what our users convey with "D". To have both a \dismissed and a \deleted flag seems like it would be needlessly confusing, if not error prone. I suspect if we had both flags available we would probably use "D Dismiss" --> \dismissed universally, since the difference between \deleted and "expunged" has *always* caused some confusion. Then we would change the eXpunge prompt to say "Delete messages marked as Dismissed?"... then we could invent a 2nd version of expunge for greater efficiency... :) Seriously, I could live with that outcome; it just seems unnecessary to me. -teg On Mon, 18 Oct 1993, Chris Newman wrote: > Terry Gray writes: > > Your argument that my model forces users to make distinctions between > > different mailbox types is bogus because the same concerns apply to the > > CMU model (e.g. just having or not having delete rights in general.) > > I don't think it's bogus. Users are used to have options "grayed out" > or rejected because they "don't have permission". The problem comes > when a user takes an action which is successful, but does different > things in different situations. > > > If your view prevails, it means that c-client will be far less useful for > > supporting the "pseudo personal" mailbox case (where the remote message > > archive is totally RO.) > > I have already stated that the concept you suggest is useful -- I'm > just opposed to overloading \DELETED. > > From what I understand of your _intent_ for use of \DELETED in > netnews, may I suggest adding a user flag "hidden" which means the > user is not interested in seeing the message again? All you have to > do is lobby client makers to have a default view of "UNKEYWORD hidden" > and you get what you want. If you wait for NSEARCH, you could even > add a \HIDDEN system flag. > > - Chris > From owner-c-client@cac.washington.edu Tue Oct 19 06:18:38 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18238; Tue, 19 Oct 93 06:18:38 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27919; Tue, 19 Oct 93 06:18:12 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27913; Tue, 19 Oct 93 06:18:11 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id JAA04293; Tue, 19 Oct 1993 09:18:08 -0400 Received: via switchmail; Tue, 19 Oct 1993 09:18:07 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Tue, 19 Oct 1993 09:17:39 -0400 (EDT) Received: via niftymail; Tue, 19 Oct 1993 09:17:31 -0400 (EDT) Date: Tue, 19 Oct 1993 09:17:25 -0400 (EDT) From: Chris Newman Subject: Re: More on /SEEN and /DELETED... To: c-client@CAC.Washington.EDU In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <751036645.10184.0@nifty.andrew.cmu.edu> Terry Gray writes: > I believe your argument is: that because Pine treats D the same for mail > and news, when users encounter a shared mailbox with RWE access, they will > continue to use D with possibly dangerous results. Not really. My argument is if users learn they can hit "d" (delete) without losing the message, then they may hit "d" on a message they don't want to lose, expecting it to stay around. The problem is having "d" be a non-destructive operation in some circumstances, but not others. I think this problem would apply to all clients (particularly those which EXPUNGE without asking the user), not just Pine. > Take news out of the equation above and you'll see the inconsistency of > that argument. Anyone who uses a personal mailbox (where I presume > deletion is permitted) will be potentially dangerous given a shared > mailbox with RWE access, unless they are suitably educated. There is > nothing greyed-out, but the number of people affected by the "formerly > harmless" action could be very different. When you hit "d" in a personal mailbox (on a client with auto-expunge), the message is removed forever. Nobody can ever see it again. In addition, delete is a well known concept not limited to computers. I claim users will not be confused if "d" does the same thing in RWE group mailboxes. Do Macintosh users who throw a program in the trash when on a server machine still expect other users to see that program? No. I believe the situation is equivalent. > Consider again the case of a shared mailbox, where an underling marks a > message as deleted when s/he is done with it, for subsequent review by a > superior who has expunge rights. Let's look a little closer at this example. Suppose the underling is marking messages with \DELETED (global flag) at the same time that her superior is looking at the folder and about to switch to another folder. When the superior's client issues an EXPUNGE, it will remove the messages without chance of review. Therefore I claim this is an unuseful scenerio. If she can set \DELETED, it means messages could be removed without her superior seeing them. Thus \DELETED and EXPUNGE rights are equivalent when there is a global \DELETED flag. She should probably use either "\FLAGGED" or a user flag like "review" to flag the message for review by her superior. > The need is not for a "hidden" flag, but something that conveys >"doneness" or "dismissal", which is exactly what our users convey with >"D". I suspect if you polled your non-technical users about what "D" means, that you would be surprised by the results. There is a need for a separate "slated for permanent removal" flag, namely \DELETED. What you seem to desire (in the case of netnews) is a "No-longer-interesting" flag. I think the term "dismiss" is misleading because it implies both possible deletion and possible change of the view. > I suspect if we had both flags available we would probably use "D Dismiss" > --> \dismissed universally, since the difference between \deleted and > "expunged" has *always* caused some confusion. Then we would change the > eXpunge prompt to say "Delete messages marked as Dismissed?"... then we > could invent a 2nd version of expunge for greater efficiency... :) Do you want to be prompted with "Delete messages marked as Dismissed?" every time you leave a netnews group where you've "dismissed" a message? If a cancel message is sent out for every message you've hit "d" on in netnews, would you be getting your desire? Unless your answer is "yes" for both these questions, then your use of "\DELETED" in netnews really means "no-longer-interesting" which is a very different concept from "flag for permanent removal". - Chris From owner-c-client@cac.washington.edu Tue Oct 19 09:06:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21824; Tue, 19 Oct 93 09:06:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00214; Tue, 19 Oct 93 09:05:42 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00206; Tue, 19 Oct 93 09:05:39 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08941; Tue, 19 Oct 93 09:05:31 -0700 Date: Tue, 19 Oct 1993 08:24:49 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: More on /SEEN and /DELETED... To: Chris Newman Cc: c-client@CAC.Washington.EDU In-Reply-To: <751036645.10184.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 19 Oct 1993, Chris Newman wrote: > Terry Gray writes: > > I believe your argument is: that because Pine treats D the same for mail > > and news, when users encounter a shared mailbox with RWE access, they will > > continue to use D with possibly dangerous results. > > Not really. My argument is if users learn they can hit "d" (delete) > without losing the message, then they may hit "d" on a message they > don't want to lose, expecting it to stay around. The problem is > having "d" be a non-destructive operation in some circumstances, but > not others. I think this problem would apply to all clients > (particularly those which EXPUNGE without asking the user), not just > Pine. It's not a problem *if* the fact that it is non-destructive in some cases does not alter people's motivation for using it, i.e. if it *always* represents the *intention* to delete. My view has been that people will use D when they are done with the message, and this behavior would be consistent regardless of whether or not a subsequent expunge succeeded. Having said that, would you agree that this is essentially a UI design issue, and that your concern would completely go away if (for the EXPUNGE-IS-NOT-ALLOWED class of mailboxes) the key label was something less "final-sounding" than "Delete" ?? > Do Macintosh users who throw a program > in the trash when on a server machine still expect other users to see > that program? No. I believe the situation is equivalent. It's a good analogy, which I agree weakens the case for using \deleted as an inter-user communication mechanism. Likewise, I agree that clients with auto-expunge are not well-suited for trying to do this in a shared environment. Note that the trashcan metaphor may strengthen my case about user behavior modification in the RO case, since I'm pretty certain I've gotten the Mac error "Can't empty the trash" a time or two in my life, and that never caused me to change the way I use Delete (I mean, the way I put things in the trash :). But I'm willing to stop pretending to be a psychologist if you agree that a change in key label for the no-expunge case solves the problem. > She should probably use either "\FLAGGED" or a user flag like "review" > to flag the message for review by her superior. This is very different from how I'd like to use \FLAGGED... but maybe a user flag is a better answer for the shared case. > > The need is not for a "hidden" flag, but something that conveys > >"doneness" or "dismissal", which is exactly what our users convey with > >"D". > > I suspect if you polled your non-technical users about what "D" means, > that you would be surprised by the results. I don't doubt that "delete" means "delete" to most folks, I just doubt that using the "Delete" word in the no-expunge case will cause people to remap the word in there minds to mean something different. Pine is careful to use the phrase "Marked as Deleted" in order to reduce the inherent confusion between "delete" and "expunge", and Pine users have no basis for the idea that marking a message with "D" might make it disappear from the current view without further action, so they don't do "D" to simply make something disappear from the current view. > Do you want to be prompted with "Delete messages marked as Dismissed?" > every time you leave a netnews group where you've "dismissed" a > message? This would never happen. Remember that you don't want to prompt for expunge if you don't have expunge rights. (And note that these issues apply to any RO archive, not just news.) > If a cancel message is sent out for every message you've hit > "d" on in netnews, would you be getting your desire? No, which I expect you knew. My mindset is that people will normally behave in a personal context, and it is important for the UI to explicitly warn them when an action has global implications that may affect many people. This would be true for either posting or cancelling. -teg From owner-c-client@cac.washington.edu Tue Oct 19 11:41:58 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26726; Tue, 19 Oct 93 11:41:58 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03349; Tue, 19 Oct 93 11:41:35 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03343; Tue, 19 Oct 93 11:41:32 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA29603; Tue, 19 Oct 93 11:41:31 PDT Date: Tue, 19 Oct 93 11:41:11 -0800 From: Adam Treister To: Terry Gray Subject: Re: More on /SEEN and /DELETED... Cc: Chris Newman , c-client@CAC.Washington.EDU Message-Id: In-Reply-To: Your message of Tue, 19 Oct 1993 08:24:49 -0700 (PDT) Content-Type: TEXT/plain; charset=US-ASCII > Pine is careful to use the phrase "Marked as Deleted" in > order to reduce the inherent confusion between "delete" > and "expunge", and Pine users have no basis for the idea > that marking a message with "D" might make it disappear > from the current view without further action, so they > don't do > "D" to simply make something disappear from the current > view. In my mind, "Marked as Deleted" confuses the issue more. Is it deleted or just marked as deleted. Its its deleted, then what's expunge? As similar as the concept is to the trash can on the mac, users have a tough time understanding whats up. I find the Delete / Expunge issue is the hardest part of writing an imap client. I am trying to shield the user from this feature entirely, largely because of imap's remapping message numbers on the expunge (so I want to do it when the client is about to close down a mailbox), but also because the user doesn't care about storage, just presentation. My current thinking in Mailstrom is to support a Hide Deleted Messages option, so that when the user "hits d", the message disappears. I used to be actually removing the message from my view (but not the mailbox), but that made the ability to reshow the messages difficult. Now, I'm changing it so that, internally, hiding the message is just setting the row height of that message to 0. This allows me to later restore the original row height and bring messages back. The important point is that as I read my mail and delete messages, I want to see the list shrinking, but I may also want to look at all those messages again. Its also my intention to support a "Deleted Messages" folder so that hitting the delete button will actually MOVE the message to the deleted-messages folder, setting the delete flag in the process. That folder can have a process invisible to the user, which searches for messages that have been there over N days, and delete and expunge them without user interaction. For the user, this is a big gain, they can get back deleted, expunged messages 30 or 60 days after they trashed it. I'd like to see this be a server/system feature aot just something in my client. (Yes that means I should cross post to IMAP list) It also makes sense to have the expiration occur on the server side, regardless of whether or not the client has been run. As I recall, IMSP is planning to support a "Sent-Messages" folder as a standard element (ala Inbox). What about raising "Deleted-Messages" to that level? Adam From owner-c-client@cac.washington.edu Tue Oct 19 13:21:02 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00150; Tue, 19 Oct 93 13:21:02 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00353; Tue, 19 Oct 93 13:20:50 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00347; Tue, 19 Oct 93 13:20:49 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id QAA10764; Tue, 19 Oct 1993 16:20:46 -0400 Received: via switchmail; Tue, 19 Oct 1993 16:20:46 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 19 Oct 1993 16:20:05 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 19 Oct 1993 16:20:00 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 19 Oct 1993 16:19:55 -0400 (EDT) Message-Id: <8gl4jfi00WBwECc7Zc@andrew.cmu.edu> Date: Tue, 19 Oct 1993 16:19:55 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Re: More on /SEEN and /DELETED... In-Reply-To: References: Beak: Is Adam Treister writes: > I am trying to shield the user from this feature entirely, largely because of > imap's remapping message numbers on the expunge (so I want to do it when the > client is about to close down a mailbox) An IMAP server can (and the Cyrus IMAP server WILL) send * n EXPUNGE notifications when processing *any* command other than FETCH, STORE, or SEARCH. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Tue Oct 19 13:32:22 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00486; Tue, 19 Oct 93 13:32:22 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00464; Tue, 19 Oct 93 13:32:12 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00458; Tue, 19 Oct 93 13:32:10 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA05720; Tue, 19 Oct 93 13:32:04 -0700 Date: Tue, 19 Oct 1993 13:26:47 -0700 (PDT) From: Mark Crispin Subject: Re: More on /SEEN and /DELETED... To: Adam Treister Cc: Terry Gray , Chris Newman , c-client@CAC.Washington.EDU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 19 Oct 93 11:41:11 -0800, Adam Treister wrote: > I find the Delete / Expunge issue is the hardest part of writing an imap > client. > I am trying to shield the user from this feature entirely, largely because > of > imap's remapping message numbers on the expunge (so I want to do it when the > client is about to close down a mailbox) You can get expunge events even when you didn't issue an EXPUNGE, because some other process expunged the mailbox. It is not safe to assume that this won't happen in the middle of your session, so you have to deal with the renumbering. Instead of thinking of message n as ``message number n'', think of it as being ``the nth extant message''. From owner-c-client@cac.washington.edu Wed Oct 20 09:04:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26079; Wed, 20 Oct 93 09:04:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18416; Wed, 20 Oct 93 09:03:48 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18410; Wed, 20 Oct 93 09:03:47 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id MAA13724; Wed, 20 Oct 1993 12:03:42 -0400 Received: via switchmail; Wed, 20 Oct 1993 12:03:41 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 20 Oct 1993 12:02:22 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 20 Oct 1993 12:02:14 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 20 Oct 1993 12:02:11 -0400 (EDT) Message-Id: Date: Wed, 20 Oct 1993 12:02:11 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Re: More on /SEEN and /DELETED... In-Reply-To: References: Beak: Is Terry Gray writes: > It's not a problem *if* the fact that it is non-destructive in some cases > does not alter people's motivation for using it, i.e. if it *always* > represents the *intention* to delete. My view has been that people will > use D when they are done with the message, and this behavior would be > consistent regardless of whether or not a subsequent expunge succeeded. Your model that "people use D when they are done with the message" is fundamentally inconsistent and interacts dangerously with the IMAP model of "\Deleted causes message to be permanently removed upon EXPUNGE". "User disinterest" is inherently a per-user concept, "permanent removal" is inherently a global concept. > Having said that, would you agree that this is essentially a UI design > issue, and that your concern would completely go away if (for the > EXPUNGE-IS-NOT-ALLOWED class of mailboxes) the key label was something > less "final-sounding" than "Delete" ?? Changing the label does not get rid of the interaction. Changing the label to paper over the "permanent removal" interaction is dangerous. If you want a different label and set of sementics, use a different flag. > I don't doubt that "delete" means "delete" to most folks, I just doubt > that using the "Delete" word in the no-expunge case will cause people to > remap the word in there minds to mean something different. If it has different semantics, it will cause users to remap the concept. Mark Crispin writes: > My own givens were that it was unreasonable to issue an error message where > there was something arguably useful to do for the user. I would have to disagree with this. In user interfaces, it is better to present a simple, clear model and to provide immediate feedback when the user strays from that model than it is to provide every possible feature the user might want. I believe this concept has some application to protocols as well. Systems, such as the DWIM LISP's, which attempt to provide some possibly-useful interpretation to everything they're fed are generally reviled. > So far, he arguments against this use of \Deleted presume that this > is taking place in the mailbox namespace. It is not. It can not. > > This also pretty well debunks the CMU claim of danger. They need never > encounter the need to support this in their servers, because they don't use > the bboard namespace. Our arguments don't presume that this takes place in the SELECT namespace. Our arguments presume this creates a model that the users will carry over to objects in the SELECT namespace. While we won't be using servers which have objects which exist only in the BBOARD namespace, we will be using clients which necessarily will know how to deal with objects in the BBOARD namespace. To the extent where objects in the BBOARD namespace are not merely second-class citizens but strange beasts, this will cause interoperability problems. Clients like Pine will not deal well with news-like objects which exist in the SELECT namespace. Other clients will have the choice of not handling news-like objects in the SELECT namespace well, not handling the BBOARD namepace well, or having a lot of compatibility code to handle/hide the semantic differences between the two. > As I see the REAL problem, the question is one of determining access rights. This is an interesting problem. One solution would be for IMAP to pick up IMSP's GETACL, but there's the question of whether the access right bits in IMSP are sufficiently fine-grained. > The present Pine doesn't distinguish between > shared read/write mailboxes and private read/write mailboxes. Neither does the Cyrus imapd. One way of stating the CMU model is "everything is a shared mailbox, though the name 'INBOX' is magic." From owner-c-client@cac.washington.edu Wed Oct 20 16:30:16 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13048; Wed, 20 Oct 93 16:30:16 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28439; Wed, 20 Oct 93 16:30:04 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28429; Wed, 20 Oct 93 16:29:56 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18731>; Wed, 20 Oct 1993 17:29:45 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Wed, 20 Oct 93 16:43 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0opmIi-000cwBC; Wed, 20 Oct 93 16:46 MDT Date: Wed, 20 Oct 1993 16:46:29 -0600 From: Steve Hole Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Mark Crispin Cc: c-client@cac.washington.edu, pine@cac.washington.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Oct 1993 00:11:42 -0600 Mark Crispin wrote: > From: Mark Crispin > Date: Mon, 18 Oct 1993 00:11:42 -0600 > Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release > To: Mike Macgirvin > Cc: gray@cac.washington.edu, steve@edm.isac.ca, c-client@cac.washington.edu, > pine@cac.washington.edu > > Mike - > > In brief (modulo things like mh folders, non-netnews bboards, etc.): > . mail_find() contents of .mailboxlist non-bboard entires > . mail_find_bboards() contents of .newsrc + .mailboxlist bboard entries > . mail_find_all() contents of directory > . mail_find_all_bboards() contents of netnews ACTIVE file This is 100% acceptable to us. > I have just removed the compatibility code for Pine 3.8[456] that made > mail_find() call mail_find_all() if there was no .mailboxlist file. The imapd > that is distributed with Pine 3.87 has this compatibility code, but Pine 3.87 > does not need it. What release is this in. Is this part of the 3.1 stuff. If so, then I will go and get it all tonight. Thanks Mark. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Wed Oct 20 16:30:50 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13095; Wed, 20 Oct 93 16:30:50 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28452; Wed, 20 Oct 93 16:30:35 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28445; Wed, 20 Oct 93 16:30:31 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA09238; Wed, 20 Oct 93 16:30:29 PDT Date: Wed, 20 Oct 93 16:30:11 -0800 From: Adam Treister To: c-client@CAC.Washington.EDU Subject: Expunge Nightmares (was Re: More on /SEEN and /DELETED...) Message-Id: In-Reply-To: Your message of Wed, 20 Oct 93 16:24:31 -0800 Content-Type: TEXT/plain; charset=US-ASCII > Instead of thinking of message n as ``message number > n'', think of it as being ``the nth extant message''. Doesn't this imply order and contiguity? Mailstrom contains views that are a subset of a folder, and not necessarily in the same order as the server stores them. The current version of Mailstrom treats the address of the Message Object as the "primary key", so I won't have to remap, but whenever I get an expunge message, I'll have to still do a lot of list traversals to determine which of my views contain the message. Now that I look at, I may indeed have to change every views instance of every object! As I read the c-client, imap_expunged is called when an unsolicited * EXPUNGE 12 arrives. It frees up its element's memory and then calls mail_expunged, which further destroys the element, clears its msgno and recycles the element. expunged then calls mm_expunged sending my app the fact that msgno 12 is now gone. Mailstrom's Message object doesn't store the msgno; it stores the MESSAGECACHE *element, and asks c-client for msgno via the element. I guess I could recognize the element that used to belong to 12, cuz it'll now have a msgno of 0, but it'd be nicer if I got called before the element gets wiped. I'm trying to avoid storing the 12 in my Message object, because that would necessitate changing all instances > 12. Can I store my Message in the element so mm_expunged can call: element->messageObj->Remove(); What is the rationale for remapping all msgno's on every expunge? Sure it makes for some easy lookup, but it would be easier to use a hash table to find row number from message number, than to change every reference to message number in every table, message, and reply. Any chance we could get message numbers to stay static for the life of the connection, or even the message. Adam From owner-c-client@cac.washington.edu Wed Oct 20 16:37:23 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13492; Wed, 20 Oct 93 16:37:23 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08479; Wed, 20 Oct 93 16:37:12 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08473; Wed, 20 Oct 93 16:37:01 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07728; Wed, 20 Oct 93 16:36:42 -0700 Date: Wed, 20 Oct 1993 16:34:51 -0700 (PDT) From: Mark Crispin Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Steve Hole Cc: Mark Crispin , c-client Interest List , pine@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 20 Oct 1993 16:46:29 -0600, Steve Hole wrote: > This is 100% acceptable to us. Great. I'm glad that we were finally able to collapse the kludge tower. > What release is this in. Is this part of the 3.1 stuff. If so, then I > will go and get it all tonight. This is in the current mail/imap-3.1.tar.Z distribution. Be advised that this is a snapshot; 3.1 is still subject to change. However, this is expected to be in all future 3.1 versions as well as all future versions. From owner-c-client@cac.washington.edu Wed Oct 20 16:39:35 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13562; Wed, 20 Oct 93 16:39:35 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08495; Wed, 20 Oct 93 16:39:25 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08489; Wed, 20 Oct 93 16:39:23 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07736; Wed, 20 Oct 93 16:39:21 -0700 Date: Wed, 20 Oct 1993 16:37:04 -0700 (PDT) From: Mark Crispin Subject: re: Expunge Nightmares (was Re: More on /SEEN and /DELETED...) To: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I sent a message to Adam on this, but briefly, the solution to Adam's problem is to use elt locking. An elt has a lock count, which is decremented each time mail_free_elt() is called. Only elt's whose lock count (or share count if you prefer) has reached zero are actually freed. An elt whose msgno element is set to 0 is one that has been expunged and no longer refers to an extant message. The msgno of an elt is always current with the latest expunge status. That is why elt's have a msgno element. In other words, the mechanism that Adam asks for is already there. From owner-c-client@cac.washington.edu Wed Oct 20 16:49:24 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13683; Wed, 20 Oct 93 16:49:24 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28808; Wed, 20 Oct 93 16:49:12 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28802; Wed, 20 Oct 93 16:49:06 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA09642; Wed, 20 Oct 93 16:49:04 PDT Date: Wed, 20 Oct 93 16:48:46 -0800 From: Adam Treister To: c-client@cac.washington.edu Subject: Re: Expunge Nightmares (was Re: More on /SEEN and /DELETED...) Message-Id: In-Reply-To: Your message of Wed, 20 Oct 1993 16:30:33 -0700 (PDT) Content-Type: TEXT/plain; charset=US-ASCII Mark, > I am afraid it is too late to change the way > expunge works. If you write your code the right way, > using elt pointers (and elt locks) instead of message > numbers, you shouldn't have a problem. That is why the > msgno is stored in the elt in the first place! Thanks for the locking info. That'll help. Aren't there also some race conditions: A00123 STORE 4 +Flags \DELETED * EXPUNGE 3 * 4 Store (FLAGS (\Seen \Deleted)) A00123 OK Do I know that the Delete preceded the expunge? Or could the server have already done the expunge and just be waiting to tell me? Do I have to handle the Store notification before the Expunge notification? Or will the server return: * 3 Store (FLAGS (\Seen \Deleted)) in which case I have to handle the Expunge first. Adam From owner-c-client@cac.washington.edu Wed Oct 20 16:56:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13916; Wed, 20 Oct 93 16:56:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28912; Wed, 20 Oct 93 16:56:34 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28898; Wed, 20 Oct 93 16:56:28 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18622>; Wed, 20 Oct 1993 17:56:14 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Wed, 20 Oct 93 17:38 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0opnAN-000cwBC; Wed, 20 Oct 93 17:42 MDT Date: Wed, 20 Oct 1993 17:41:57 -0600 From: Steve Hole Subject: Re: Terry's assumptions about mailboxes To: Chris Newman Cc: c-client@cac.washington.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 18 Oct 1993 10:02:37 -0600 Chris Newman wrote: > From: Chris Newman > Date: Mon, 18 Oct 1993 10:02:37 -0600 > Subject: Re: Terry's assumptions about mailboxes > To: c-client@cac.washington.edu > > > > Also, how does the client know when to look for a client-maintained file > > of private flags, e.g. .newsrc, or its mailbox equivalent for, say, a > > remote message archive? > > I believe we all agree this problem needs to be solved. This is why > CMU has suggested that the FLAGS reply exclude non-permanent flags. > If the flag isn't in the FLAGS reply, then the client can look for a > client-maintained file. How about if we were to expand the subscription database to include state information for each of the mailboxes that the user has subscribed to. This is pretty much the way it works now with News. Why couldn't we just generalize to say that the per-user subscription database always be the source for this type of information. Any implementation (driver in the c-client) would be required to maintain a subscription database for the mailboxes that it managed. News would use the .newsrc, mail would use whatever. If there were no subscriptions, there would be no server maintained state information. It would then be up to the client to manage state or simply ignore it. I think it is time that we really had a look forward to the long term goal for mailbox storage and management on the server. One of the design goals should be to be as backwardly compatible as possible, but we are going to have to start cutting some strings soon. Especially when we start talking about mail storage without a corresponding host user account (no UNIX user id). God, I hope this made sense - I am quite tired. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Wed Oct 20 17:16:01 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14817; Wed, 20 Oct 93 17:16:01 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08773; Wed, 20 Oct 93 17:15:51 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08767; Wed, 20 Oct 93 17:15:49 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07826; Wed, 20 Oct 93 17:15:43 -0700 Date: Wed, 20 Oct 1993 17:14:12 -0700 (PDT) From: Mark Crispin Subject: Re: Expunge Nightmares (was Re: More on /SEEN and /DELETED...) To: Adam Treister Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Adam: The IMAP2bis draft clarifies that an unsolicited EXPUNGE response must not be sent in response to a FETCH, STORE, or SEARCH request, because of this race condition. Unsolicited EXPUNGE responses may be sent in response to other requests. -- Mark -- From owner-c-client@cac.washington.edu Wed Oct 20 17:46:18 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16187; Wed, 20 Oct 93 17:46:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00271; Wed, 20 Oct 93 17:45:15 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00260; Wed, 20 Oct 93 17:45:01 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18739>; Wed, 20 Oct 1993 18:43:51 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Wed, 20 Oct 93 18:28 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0opnw7-000cwBC; Wed, 20 Oct 93 18:31 MDT Date: Wed, 20 Oct 1993 18:31:17 -0600 From: Steve Hole Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release To: Mark Crispin Cc: Mark Crispin , c-client Interest List , pine@cac.washington.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 20 Oct 1993 17:34:51 -0600 Mark Crispin wrote: > From: Mark Crispin > Date: Wed, 20 Oct 1993 17:34:51 -0600 > Subject: re: Some problems with the imapd-3.0 (Pine 3.87) release > To: Steve Hole > Cc: Mark Crispin , > c-client Interest List , > pine@cac.washington.edu > > This is in the current mail/imap-3.1.tar.Z distribution. Be advised that this > is a snapshot; 3.1 is still subject to change. However, this is expected to > be in all future 3.1 versions as well as all future versions. Good enough. Just so long as we can get a base to put into CVS. Then we can manage our local patches and such very easily. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2 From owner-c-client@cac.washington.edu Wed Oct 20 22:37:15 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23327; Wed, 20 Oct 93 22:37:15 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10101; Wed, 20 Oct 93 22:37:05 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10095; Wed, 20 Oct 93 22:37:02 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA08658; Wed, 20 Oct 93 22:36:54 -0700 Date: Wed, 20 Oct 1993 22:32:30 -0700 (PDT) From: Mark Crispin Subject: Re: Terry's assumptions about mailboxes To: Steve Hole Cc: Chris Newman , c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 20 Oct 1993 17:41:57 -0600, Steve Hole wrote: > How about if we were to expand the subscription database to include state > information for each of the mailboxes that the user has subscribed to. Clever idea, but what do we do for mailboxes which aren't subscribed? One of the real ball-and-chains that c-client faces is the whole ``try to be compatible with other crufty software'' constraints it faces. In many ways, I am green with envy towards the CMU guys, since they have the freedom to do what they want without such constraints. Even when I work on new drivers, I still have to worry about such things; if I add some wonderful new capability for a new driver, I have to think about how to add it for the other drivers which have to worry about the crufties. In other words, it's a common denominator, although I am trying to have the highest common denominator possible. It does mean avoiding primes... ;-) From owner-c-client@cac.washington.edu Wed Oct 27 10:51:03 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27191; Wed, 27 Oct 93 10:51:03 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15650; Wed, 27 Oct 93 10:50:31 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15644; Wed, 27 Oct 93 10:50:29 -0700 Received: from mcs-ss1-1.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA03653; Wed, 27 Oct 93 10:50:28 PDT Date: Wed, 27 Oct 1993 10:18:38 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: coupla' client issues To: mrc@camis.stanford.edu Cc: yeager@camis.stanford.edu, c-client@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII This is kinda' convoluted, so bear with me --- I'm implementing several of the mailbox management features such as CREATE/DELETE/RENAME and the logistics are a bit crazy ... The c-client functions which implement these features require an open "MAILSTREAM *", and the current code I have (which works) runs through our internal list of open streams, and tries to match on the host on which the operation is desired. Otherwise the operation is dissallowed. But this is a bit inconvenient at the user level when one wants to do mailbox management on different hosts; because they aren't told until after the fact that they have to open something on each desired host before they can do routine management stuff. I guess I'm trying to push a case for a function which opens a connection (and authenticates if neccessary) -without- doing a SELECT, for the sole purpose of supplying an open stream to do this management stuff. The alternative, I guess is to just mail_open INBOX, but it seems like it would be an unnecssary burden in the case where somebody just wants to rename one of their mailboxes on host2, but otherwise, they're working from host1. Is there perhaps a better way to go about this? A related issue, is it legal to delete/rename an open mailbox? The IMAP2bis draft doesn't appear to mention this. Are there any gotcha's that the client side should account for? Such as, is the mailstream still valid in the case of delete ? (probably not), and should the mailstream be refreshed (closed and re-opened) in the case of rename, so as to maintain consistency ? mike From owner-c-client@cac.washington.edu Wed Oct 27 12:41:25 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA00801; Wed, 27 Oct 93 12:41:25 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22922; Wed, 27 Oct 93 12:41:10 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22916; Wed, 27 Oct 93 12:41:09 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA04507; Wed, 27 Oct 93 12:40:57 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01801; Wed, 27 Oct 93 12:40:48 -0700 Date: Wed, 27 Oct 1993 12:32:53 -0700 (PDT) From: Mark Crispin Subject: re: coupla' client issues To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: yeager@camis.stanford.edu, c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mike - Are you saying that mail_create(), mail_delete(), and mail_rename() don't automatically open an IMAP connection as necessary if a MAILSTREAM argument isn't supplied? If so, I think you're working with an old or buggy version of c-client. I think what you want is already there and working in current versions; just supply a NIL argument for the MAILSTREAM argument. My feeling on the question of delete/rename of an open mailbox is that it should be avoided. I don't think it's a good idea to specify this behavior in IMAP2bis, since I'm not sure it is reasonable to require an implementation to enforce either possible behavior (permit it or refuse it). I consider the behavior in this circumstance to be undefined in c-client, and suggest that if your main program can avoid it happening, it should do so. But, if you feel that it should be defined in IMAP2bis, by all means bring it up on the IMAP list. I'll argue against a definition on the basis of implementation difficulty (it'll be hard to make either completely right in the c-client based stuff), but that doesn't mean that a definition won't happen. It depends upon what other people, especially other implementors, feel! ;-) -- Mark -- From owner-c-client@cac.washington.edu Wed Oct 27 13:40:32 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA02270; Wed, 27 Oct 93 13:40:32 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19308; Wed, 27 Oct 93 13:40:10 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19300; Wed, 27 Oct 93 13:40:07 -0700 Received: from mcs-ss1-1.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA08594; Wed, 27 Oct 93 13:32:27 PDT Date: Wed, 27 Oct 1993 12:42:19 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: re: coupla' client issues To: Mark Crispin Cc: yeager@camis.stanford.edu, c-client Interest List In-Reply-To: Mark Crispin's message of Wed, 27 Oct 1993 12:32:53 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > Are you saying that mail_create(), mail_delete(), and > mail_rename() don't automatically open an IMAP connection as > necessary if a MAILSTREAM argument isn't supplied? > just supply a NIL argument for the MAILSTREAM argument. Gee, I never tried ... Thanks. > My feeling on the question of delete/rename of an open > mailbox is that it should be avoided. That's why I asked. It will involve a bit of extra checking, but for the same reason as I wasn't aware a stream would be opened automatically, I like to err on the side of paranoia. > But, if you feel that it should be defined in IMAP2bis, > by all means bring it up on the IMAP list. I'll argue against > a definition on the basis of implementation difficulty (it'll > be hard to make either completely right in the c-client based > stuff), but that doesn't mean that a definition won't happen. > It depends upon what other people, especially other > implementors, feel! ;-) From an end-user perspective, the underlying "system" would be a lot more invisible if delete/rename on open mailboxes were the same as any other mailboxes. But this doesn't have to a protocol level decision. It can be implemented on the client end by shutting the stream if necessary prior to the operation, and re-opening in the case of rename. But the fact that the behaviour is undefined (and possibly dangerous) is something that implementors should be aware of. mike From owner-c-client@cac.washington.edu Wed Oct 27 13:47:56 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA02477; Wed, 27 Oct 93 13:47:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19493; Wed, 27 Oct 93 13:47:43 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19487; Wed, 27 Oct 93 13:47:42 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA09107; Wed, 27 Oct 93 13:47:39 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA08512; Wed, 27 Oct 93 13:42:32 -0700 Date: Wed, 27 Oct 1993 13:41:00 -0700 (PDT) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: re: coupla' client issues To: Mike_Macgirvin@camis.stanford.edu Cc: Mark Crispin , yeager@camis.stanford.edu, c-client Interest List In-Reply-To: Mike Macgirvin's message of Wed, 27 Oct 1993 12:42:19 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > From an end-user perspective, the underlying "system" would be a > lot more invisible if delete/rename on open mailboxes were the > same as any other > mailboxes. I'm on Mark's side here. I'd categorically vote no. I guess that's what comes from having implemented an imapserver. The subtle problems that might arise sort of make me nauseous. Bill From owner-c-client@cac.washington.edu Wed Oct 27 16:46:23 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08080; Wed, 27 Oct 93 16:46:23 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23625; Wed, 27 Oct 93 16:46:09 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23619; Wed, 27 Oct 93 16:46:07 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id TAA12142; Wed, 27 Oct 1993 19:46:04 -0400 Received: via switchmail; Wed, 27 Oct 1993 19:46:03 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 27 Oct 1993 19:44:01 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 27 Oct 1993 19:43:50 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 27 Oct 1993 19:43:45 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 19:43:45 -0400 (EDT) From: John Gardiner Myers To: c-client@CAC.Washington.EDU Subject: Re: coupla' client issues In-Reply-To: References: Beak: is Not I haven't written the code yet, but I was planning on having the Cyrus imapd "* BYE" any client which had open a mailbox being renamed or deleted. The exception would be INBOX--on a rename, it would appear as if someone had deleted and expunged all messages in the mailbox. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-c-client@cac.washington.edu Wed Oct 27 23:06:09 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14110; Wed, 27 Oct 93 23:06:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27685; Wed, 27 Oct 93 23:05:57 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27679; Wed, 27 Oct 93 23:05:54 -0700 Received: by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA20028; Wed, 27 Oct 93 23:05:52 PDT Date: Wed, 27 Oct 93 23:05:52 PDT From: mtm@CAMIS.Stanford.EDU (Mike Macgirvin) Message-Id: <9310280605.AA20028@CAMIS.Stanford.EDU> To: mrc@CAMIS.Stanford.EDU Subject: uname Cc: c-client@cac.washington.edu, yeager@CAMIS.Stanford.EDU I'd like to request that the global "uname" be changed in the os_*.c modules, as it conflicts with a !@#$% function name in one of the X11 libs (libXmu.a) which we need for building. The global storage is followed immediately by a function to return its value, leaving the choice of its label hopefully irrelevant. It could alternatively be made static. I've called it "myuname" locally. mike From owner-c-client@cac.washington.edu Wed Oct 27 23:12:42 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14205; Wed, 27 Oct 93 23:12:42 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26379; Wed, 27 Oct 93 23:12:30 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26373; Wed, 27 Oct 93 23:12:28 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA05269; Wed, 27 Oct 93 23:12:16 -0700 Date: Wed, 27 Oct 1993 23:11:24 -0700 (PDT) From: Mark Crispin Subject: re: uname To: Mike Macgirvin Cc: c-client Interest List , yeager@CAMIS.Stanford.EDU In-Reply-To: <9310280605.AA20028@CAMIS.Stanford.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 27 Oct 93 23:05:52 PDT, Mike Macgirvin wrote: > I'd like to request that the global "uname" be changed in the > os_*.c modules. This will happen in the next release of the 3.1 toolkit. I am doing a major rewrite for blackbox mail service. From owner-c-client@cac.washington.edu Wed Oct 27 23:14:19 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14230; Wed, 27 Oct 93 23:14:19 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27774; Wed, 27 Oct 93 23:14:10 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27768; Wed, 27 Oct 93 23:14:06 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18932-1>; Thu, 28 Oct 1993 00:13:51 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Wed, 27 Oct 93 16:16 MDT Received: from 58.22.2.115 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0osJDY-000cvpC; Wed, 27 Oct 93 16:19 MDT Date: Wed, 27 Oct 1993 17:19:45 -0600 From: Joel King Subject: re: coupla' client issues To: Mark Crispin Cc: Mike_Macgirvin@CAMIS.Stanford.EDU, yeager@CAMIS.Stanford.EDU, c-client Interest List Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 27 Oct 1993 13:32:53 -0600 Mark Crispin wrote: > From: Mark Crispin > Date: Wed, 27 Oct 1993 13:32:53 -0600 > Subject: re: coupla' client issues > To: Mike_Macgirvin@CAMIS.Stanford.EDU > Cc: yeager@CAMIS.Stanford.EDU, > c-client Interest List > > Mike - > > Are you saying that mail_create(), mail_delete(), and mail_rename() don't > automatically open an IMAP connection as necessary if a MAILSTREAM argument > isn't supplied? > > If so, I think you're working with an old or buggy version of c-client. Yes. An earlier version of ECSMail was based on imap2.3 and we had to fudge this quite a bit. I had to make sure a "sentmail" folder existed in the local (DOS) folder storage area in order to open local folders. For remote folders, I opened "inbox". > I think what you want is already there and working in current versions; just > supply a NIL argument for the MAILSTREAM argument. I have just converted ECSMail to use c-client version 3.0 and I am pleased that I can now supply NIL stream arguments and things will work well. There are just a few problems I encountered: - A map_open() on a BBOARD with a NIL stream argument requires a "mailbox" in the form: {xxxx}*name whereas a map_subscribe_bboard() does not like the "*" - it add's it's own somewhere along the line, resulting in the server receiving a SUBSCRIBE on a bboard with a name like "**name". Is it possible to use a consistent rule here? I have a single routine that formats a "remote" name before calling any of the mail_* functions. - Liberal use of automatic arrays of size MAILTMPLEN wreaks havoc on the small stack available in a typical DOS/WINDOWS application. This is expecially severe in imap3.0 since "mail_open()" is now called with OP_HALFOPEN, sometimes recursively, to get a stream for the above mail_*() operations. Is it possible to allocate these internally from the heap instead of from the stack?? - There were some other problems we encountered with the dawz driver - mainly du to the fact that we may have an open local folder (DAWZ) and drag messages to it. Since DAWZLOCAL keeps an open file handle to the folder, we had to close and re-open the file anytime messages were added/expunged and "dawz_ping()' resulted in a "dawz_parse()". Other problems we had were some strange read/write problems which we haven't yet figured out. joel (Joel King, joel@edm.isac.ca) From owner-c-client@cac.washington.edu Thu Oct 28 14:15:49 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA02872; Thu, 28 Oct 93 14:15:49 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01256; Thu, 28 Oct 93 14:15:30 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01250; Thu, 28 Oct 93 14:15:28 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA06454; Thu, 28 Oct 93 14:15:14 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA06131; Thu, 28 Oct 93 14:15:06 -0700 Date: Thu, 28 Oct 1993 14:05:34 -0700 (PDT) From: Mark Crispin Subject: re: coupla' client issues To: Joel King Cc: Mike_Macgirvin@CAMIS.Stanford.EDU, yeager@CAMIS.Stanford.EDU, c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 27 Oct 1993 17:19:45 -0600, Joel King wrote: > - A map_open() on a BBOARD with a NIL stream > argument requires a "mailbox" in the form: > {xxxx}*name > whereas a map_subscribe_bboard() does not like the > "*" - it add's it's own somewhere along the line, > resulting in the server receiving a SUBSCRIBE on a > bboard with a name like "**name". > Is it possible to use a consistent rule here? > I have a single routine that formats a "remote" > name before calling any of the mail_* functions. The explanation for this is that there is no separate bboard_open(). If there were, its definition would be: MAILSTREAM *bboard_open (MAILSTREAM *oldstream,char *name,long options) { char tmp[MAILTMPLEN]; sprintf (tmp,"*%s",name); return mail_open (oldstream,tmp,options); } The * is only how c-client internally compresses the separate bboard namespace into the mail namespace. You should think of those two namespaces as being logically separate. > - Liberal use of automatic arrays of size MAILTMPLEN > wreaks havoc on the small stack available in a > typical DOS/WINDOWS application. This is > expecially severe in imap3.0 since "mail_open()" > is now called with OP_HALFOPEN, sometimes > recursively, to get a stream for the above > mail_*() operations. Is it possible to allocate > these internally from the heap instead of from the > stack?? I have fixed the egregiously bad stack use with OP_HALFOPEN in the latest (as yet unreleased) code, I think. > - There were some other problems we encountered with > the dawz driver - mainly du to the fact that we may > have an open local folder (DAWZ) and drag messages > to it. Since DAWZLOCAL keeps an open file handle to > the folder, we had to close and re-open the > file anytime messages were added/expunged and > "dawz_ping()' resulted in a "dawz_parse()". Other > problems we had were some strange read/write > problems which we haven't yet figured out. In other words, you're saying that if you append to an open file through another file handle, you may get this kind of bad behavior? This sounds like a bug/misfeature in DOS. I wonder if dawz can help by detecting a stream argument in dawz_append() (right now it's only used to pass back a value to mm_critical()) and seeing if it references the same file as the open stream. If so, it could then use that file handle. It would require some main program kludgery to take advantage of it, but it's hard to imagine anything being worse than what you already have to do. What do you think? Don'cha just love these Fisher-Price operating systems??? ;-) -- Mark -- From owner-c-client@cac.washington.edu Fri Oct 29 01:14:00 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15533; Fri, 29 Oct 93 01:14:00 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19326; Fri, 29 Oct 93 01:13:47 -0700 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19320; Fri, 29 Oct 93 01:13:45 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18709-1>; Fri, 29 Oct 1993 02:13:29 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Fri, 29 Oct 93 01:39 MDT Received: from 58.22.2.115 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0osoTi-000cw0C; Fri, 29 Oct 93 01:42 MDT Date: Fri, 29 Oct 1993 02:42:27 -0600 From: Joel King Subject: re: coupla' client issues To: Mark Crispin Cc: Mike_Macgirvin@CAMIS.Stanford.EDU, yeager@CAMIS.Stanford.EDU, c-client Interest List Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 28 Oct 1993 15:05:34 -0600 Mark Crispin wrote: > > > - There were some other problems we encountered with > > the dawz driver - mainly du to the fact that we may > > have an open local folder (DAWZ) and drag messages > > to it. Since DAWZLOCAL keeps an open file handle to > > the folder, we had to close and re-open the > > file anytime messages were added/expunged and > > "dawz_ping()' resulted in a "dawz_parse()". Other > > problems we had were some strange read/write > > problems which we haven't yet figured out. > > In other words, you're saying that if you append to an open file through > another file handle, you may get this kind of bad behavior? This sounds like > a bug/misfeature in DOS. What else can we expect from DOS. I wonder if dawz can help by detecting a stream > argument in dawz_append() (right now it's only used to pass back a value to > mm_critical()) and seeing if it references the same file as the open stream. > If so, it could then use that file handle. > I thought of this very thing but the new dawz_append() would still need to handle the case where the stream is NULL (of course). Currently the calling program checks if there is a currently open stream with this mailbox name and pass that stream to *_append() so this would work. > Joel King ISA Corporation, Edmonton. Internet: joel@edm.isac.ca  From owner-c-client@cac.washington.edu Mon Nov 1 10:24:05 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15269; Mon, 1 Nov 93 10:24:05 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00458; Mon, 1 Nov 93 10:18:18 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00452; Mon, 1 Nov 93 10:18:14 -0800 Received: from mcs-ss1-1.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA12094; Mon, 1 Nov 93 10:18:11 PST Date: Mon, 1 Nov 1993 09:50:16 -0800 (PST) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: more c-client sugg's To: mrc@camis.stanford.edu Cc: c-client@cac.washington.edu, yeager@camis.stanford.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII It would be a little less disconcerting to users if they didn't get the message "Mailbox is empty" when opening the pseudo mailbox "" for CREATE/DELETE/RENAME when called with a NIL mailstream. They don't know that it is this pseudo mailbox which is being reported, instead of their mailbox target. In the case of a rename, it can lead to premature heart failure. Even on a create/delete, they are told "Mailbox is empty" -prior- to the success message. In our application, we now allow an auto create on mailbox "subscription". Where somebody is just subscribing a known existant mailbox, it again can lead to coronary arrest, because the create should fail, but they aren't expecting it to say anything about being empty.... Now -we- know it's not `their' empty mailbox, but they don't. I also can't easily filter these messages at the application level, because there are other instances where it is important to know the mailbox is empty. mike From owner-c-client@cac.washington.edu Mon Nov 1 10:38:34 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15781; Mon, 1 Nov 93 10:38:34 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23413; Mon, 1 Nov 93 10:38:14 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23407; Mon, 1 Nov 93 10:38:12 -0800 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA10700; Mon, 1 Nov 93 10:38:10 -0800 Date: Mon, 1 Nov 1993 10:34:40 -0800 (PST) From: Mark Crispin Subject: Re: more c-client sugg's To: Mike Macgirvin Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mike - In the next version of IMAP toolkit 3.1, half-open IMAP opens will not report the ``Mailbox is empty'' condition. You can make this fix to your own copy by looking for where the message is generated in c-client/imap2.c and adding stream->halfopen to the OR along with stream->silent. Present estimate of a new toolkit 3.1 is later this week. There is a fairly major redesign of mailbox driver selection logic that is almost finished, modulo the handling of empty mailboxes and non-existant INBOXes which still isn't set up perfectly for the new world. -- Mark -- From owner-c-client@cac.washington.edu Wed Nov 3 12:34:13 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14855; Wed, 3 Nov 93 12:34:13 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11279; Wed, 3 Nov 93 12:33:45 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from HPP.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11273; Wed, 3 Nov 93 12:33:44 -0800 Received: from camis.Stanford.EDU by HPP.Stanford.EDU (4.1/inc-1.0) id AA13038; Wed, 3 Nov 93 12:33:40 PST Date: Wed, 3 Nov 1993 12:04:53 -0800 (PST) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: NNTP & [HOLES] To: mrc@camis.stanford.edu Cc: c-client@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I'm working with the NNTP stuff in the c-client, and would like to request that the number of [HOLES] found be returned as an element (i.e. a new element) of the MAILSTREAM. Currently, this number is passed back to the application via an mm_notify() message, but as this happens in the process of doing a mail_open(), I don't yet have the return stream pointer in my list of control structures. So there's a catch-22, because until mail_open() returns, I don't have knowledge of the MAILSTREAM which is passed to mm_notify(). Therefore I can't figure out which mailbox reported the holes and set their control structures accordingly. The chicken way out, supplying an allocated MAILSTREAM to mail_open(), isn't guaranteed according to my interpretation of the docs. "an attempt is made to reuse oldstream"; i.e. the attempt could fail, and I could still end up with a new pointer that I have no knowledge of. The information is important, because the number of holes can be in the tens of thousands, while the number of actual messages can be quite low, resulting in the possibility of massive over-allocation of resources. mike From owner-c-client@cac.washington.edu Wed Nov 3 16:02:43 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA20594; Wed, 3 Nov 93 16:02:43 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10764; Wed, 3 Nov 93 16:02:29 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10758; Wed, 3 Nov 93 16:02:27 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA00308; Wed, 3 Nov 93 16:02:22 -0800 Date: Wed, 3 Nov 1993 15:58:54 -0800 (PST) From: Mark Crispin Subject: re: NNTP & [HOLES] To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mike - The [HOLES] condition should be nearly extinct in the most recent version of c-client, if not totally extinct. No known NNTP server will trigger it today. Make sure you have the version of c-client whose nntpclient.c module tries the XHDR command if LISTGROUP fails. -- Mark -- From owner-c-client@cac.washington.edu Wed Nov 3 21:56:52 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA25666; Wed, 3 Nov 93 21:56:52 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19594; Wed, 3 Nov 93 21:56:36 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from HPP.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19588; Wed, 3 Nov 93 21:56:35 -0800 Received: from camis.Stanford.EDU by HPP.Stanford.EDU (4.1/inc-1.0) id AA17980; Wed, 3 Nov 93 21:56:34 PST Date: Wed, 3 Nov 1993 21:36:25 -0800 (PST) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: re: NNTP & [HOLES] To: Mark Crispin Cc: c-client Interest List In-Reply-To: Mark Crispin's message of Wed, 3 Nov 1993 15:58:54 -0800 (PST): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > Mike - > > The [HOLES] condition should be nearly extinct in the > most recent version of c-client, if not totally extinct. No > known NNTP server will trigger it today. Make sure you have > the version of c-client whose nntpclient.c module > tries the XHDR command if LISTGROUP fails. > > -- Mark -- ..Didn't think I was -that- far out of date ;-) Thanks, the holes are gone. I was having nightmares trying to deal with them, so it's a good thing. In the most recent nntpclient.c, though; none of the servers I know of recognize the "MODE READER" command which is used by the c-client on an NNTP open; and the nntp_mopen() call fails if this command is unsuccessful. I imagine this just sets some modal stuff based on who's accessing the server, but it's just a guess, and things seem to work fine here without issuing it. I can't find mention of it in my NNTP docs. Is it dangerous to comment out this line? Pointers to a recent nntp server would be appreciated also. Latest I can find is 1.5.11 which is running; although I was able to find the LISTGROUP patch via gopher. I've heard rumours of 1.6, but gopher can't find it, and archie has been down this evening. mike From owner-c-client@cac.washington.edu Thu Nov 4 15:11:08 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14259; Thu, 4 Nov 93 15:11:08 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18927; Thu, 4 Nov 93 15:10:47 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18913; Thu, 4 Nov 93 15:09:48 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA01075; Thu, 4 Nov 93 15:09:42 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA03300; Thu, 4 Nov 93 15:09:36 -0800 Date: Thu, 4 Nov 1993 14:51:42 -0800 (PST) From: Mark Crispin Subject: MacMS compatibility with IMAP2bis To: IMAP Interest List Cc: c-client Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII If all goes well, the next version of the IMAP toolkit will include an imapd that fully supports MacMS, including MacMS' interpretation of the proper behavior of the COPY command. The problem is that MacMS depends upon an older interpretation of the meaning of a COPY command in IMAP2, one that automatically creates a non-existant mailbox instead of giving an error. MacMS uses an undocumented command to trigger special behavior in an IMAP server. I believe I have written the special code that is based upon this trigger that will automatically create non-existant mailboxes when you try to copy to another mailbox (I've asked SUMEX to check it out to be sure that interoperability has been achieved). Unless this undocumented MacMS-only command is used, the IMAP server will do the correct IMAP2bis interpretation of COPY. The behavior of the IMAP2bis APPEND command is not changed. If MacMS is changed to use APPEND, it can be changed to conform to IMAP2bis... ;-) -- Mark -- From owner-c-client@cac.washington.edu Thu Nov 4 15:18:12 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14488; Thu, 4 Nov 93 15:18:12 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18970; Thu, 4 Nov 93 15:17:55 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18964; Thu, 4 Nov 93 15:17:53 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA01088; Thu, 4 Nov 93 15:17:46 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA03324; Thu, 4 Nov 93 15:17:39 -0800 Date: Thu, 4 Nov 1993 15:13:58 -0800 (PST) From: Mark Crispin Subject: re: NNTP & [HOLES] To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Grumble!! ;-) This MODE READER stuff was added a short while back, because it appears that in some NNTP server configurations it's mandatory to get the NNTP server in the right state. In the latest development sources, I've changed things so that it sends the MODE READER command but completely ignores any response from it. I hope to have a new mail/imap.tar.Z in a few days; right now all my sources are very broken. Sorry for the problems. I HATE protocols whose reality is not reflected by the RFC's. Well, this'll just push getting UID support into the IMAP toolkit so the option will exist to punt on NNTP entirely... ;-) -- Mark -- From owner-c-client@cac.washington.edu Fri Nov 19 12:41:32 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14151; Fri, 19 Nov 93 12:41:32 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07956; Fri, 19 Nov 93 12:40:37 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from watsun.cc.columbia.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07950; Fri, 19 Nov 93 12:40:34 -0800 Received: by watsun.cc.columbia.edu (5.59/FCB/jba) id AA07910; Fri, 19 Nov 93 15:40:26 EST Date: Fri, 19 Nov 93 15:40:24 EST From: Ben Fried To: c-client@cac.washington.edu Subject: shared version of c-client? Message-Id: Has anyone done the work to generate a shared version of the c-client library under SunOS? Ben From owner-c-client@cac.washington.edu Tue Nov 30 07:10:54 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA29257; Tue, 30 Nov 93 07:10:54 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19490; Tue, 30 Nov 93 07:10:21 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from dxmint.cern.ch by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19484; Tue, 30 Nov 93 07:10:19 -0800 Received: from afcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23926; Tue, 30 Nov 1993 16:10:11 +0100 Received: by afcern.cern.ch; id AA07824; Tue, 30 Nov 1993 16:10:10 +0100 Date: Tue, 30 Nov 1993 16:03:33 +0100 (MET) From: Sandeep Mangla Subject: Making the C-client on DEC AXP - OSF/1 To: c-client@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear C-client developer, I've been trying to make the Xlview distribution ( from Sumex-aim.Stanford.edu ) on my usual platform : a DEC AXP, running OSF/1 v1.3. Evrything makes out of the box except, ... the C-client ! I tried using the SVR4 makefile but again, everything except the os-dependent part (i.e. os_sv4.c ) compiles rightaway. Would you please tell me how to make the C-client on my m/c ? Sincerely, Sandeep Mangla. From owner-c-client@cac.washington.edu Tue Nov 30 09:19:44 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA02823; Tue, 30 Nov 93 09:19:44 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20315; Tue, 30 Nov 93 09:19:18 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20309; Tue, 30 Nov 93 09:19:17 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA16932; Tue, 30 Nov 93 09:19:10 -0800 Date: Tue, 30 Nov 1993 09:16:04 -0800 (PST) From: Mark Crispin Subject: re: Making the C-client on DEC AXP - OSF/1 To: Sandeep Mangla Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII There wasn't enough information in your message to determine the cause of your problem. However, c-client has an OSF/1 port. You should be using the OSF makefile, not the SVR4 makefile. I am not surprised to hear that the SV4 port does not build with OSF/1; that is why there's a separate OSF port! The OSF port is in the ANSI sources tree; in the IMAP 3.2 toolkit on ftp.cac.washington.edu (file mail/imap-3.2.tar.Z via anonymous), you will find it in the directory imap-3.2/ANSI/c-client after you uncompress and untar it. -- Mark -- From owner-c-client@cac.washington.edu Tue Nov 30 09:28:31 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03235; Tue, 30 Nov 93 09:28:31 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02183; Tue, 30 Nov 93 09:28:05 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02175; Tue, 30 Nov 93 09:28:03 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07484; Tue, 30 Nov 93 09:27:56 -0800 Date: Tue, 30 Nov 1993 09:27:54 -0800 (PST) From: David L Miller Subject: Re: Making the C-client on DEC AXP - OSF/1 To: Sandeep Mangla Cc: c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The current c-client distribution includes an "osf" port. It is available from ftp.cac.washington.edu in the /mail/imap.tar.Z file. |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) University of Washington, Networks & Distributed Computing 4545 15th Ave NE, Seattle WA 98105, USA On Tue, 30 Nov 1993, Sandeep Mangla wrote: > Dear C-client developer, > > I've been trying to make the Xlview distribution ( from > Sumex-aim.Stanford.edu ) on my usual platform : a DEC AXP, > running OSF/1 v1.3. Evrything makes out of the box except, ... > the C-client ! I tried using the SVR4 makefile but again, > everything except the os-dependent part (i.e. os_sv4.c ) compiles > rightaway. > > Would you please tell me how to make the C-client on my m/c ? > > Sincerely, > Sandeep Mangla. > > From owner-c-client@cac.washington.edu Wed Dec 8 10:13:35 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16094; Wed, 8 Dec 93 10:13:35 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09491; Wed, 8 Dec 93 10:12:35 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09485; Wed, 8 Dec 93 10:12:31 -0800 Received: from mcs-ss1-1.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA03497; Wed, 8 Dec 93 10:12:15 PST Date: Wed, 8 Dec 1993 09:48:19 -0800 (PST) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: mail_subscribe et al To: mrc@camis.stanford.edu Cc: c-client@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII In using mail_subscribe() and friends for the first time (anticipating the day when xlview and pine can use the same support files) I ran across a few anomolies... mail_subscribe() , mail_unsubscribe() : The host component is stripped from the passed mailbox name before adding/removing to/from .mailboxlist -- I guess this is sorta' OK, but in a multpile mailhost world it would be nicer to preserve the name which is passed, host and all. Perhaps this is the reason for IMSP. In XLView we try to host qualify anything that isn't direct file access; so if there's a server connection, there's a host component. Is there any way to consolidate ours and Pine's view of the mailbox world? Is it possible, through recursion, to get the host part added to the file? Such as mail_subscribe(NIL,"{host.domain}{host.domain}mailbox"); or will this recurse on the stream open and leave us right back where we started? (Haven't tried). mail_subscribe_bboard(), mail_unsubscribe_bboard() : Curious as to why we have to strip the leading "*" character so it can be tacked back on again... i.e. let's say I'm trying to subscribe to "*{nntpserver/nntp}alt.sources"; I have to point mail_subscribe_bboard() at "{nntpserver/nntp}alt.sources" so it can tack on an asterisk of its own. Anyway, this works; but I'm just a little puzzled why the extra kludginess is needed. mike From owner-c-client@cac.washington.edu Wed Dec 8 22:14:54 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA06078; Wed, 8 Dec 93 22:14:54 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13530; Wed, 8 Dec 93 22:14:36 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13524; Wed, 8 Dec 93 22:14:34 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA28237; Wed, 8 Dec 93 22:14:23 -0800 Date: Wed, 8 Dec 1993 22:10:32 -0800 (PST) From: Mark Crispin Subject: re: mail_subscribe et al To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: mrc@camis.stanford.edu, c-client@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > mail_subscribe() , mail_unsubscribe() : > > The host component is stripped from the passed mailbox name > before adding/removing to/from .mailboxlist I think you are confused. If you give mail_subscribe() an IMAP name it will do a subscription on the *server*, not the client. In other words, mail_subscribe (NIL,"{foo}bar.zap"); will add ``bar.zap'' to the .mailboxlist on host foo. If you want to add an IMAP name to the client subscription list (e.g. as a glue pointer to that IMAP server), you need to use sm_subscribe(). > mail_subscribe_bboard(), mail_unsubscribe_bboard() : > Curious as to why we have to strip the leading "*" character so it can > be tacked back on again... i.e. let's say I'm trying to subscribe to > "*{nntpserver/nntp}alt.sources"; I have to point mail_subscribe_bboard() at > "{nntpserver/nntp}alt.sources" so it can tack on an asterisk of its own. This is going to change, most likely incompatably, due to the deletion of bboards from the IMAP spec at the Houston IETF. From owner-c-client@cac.washington.edu Fri Dec 10 13:10:34 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA20132; Fri, 10 Dec 93 13:10:34 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23678; Fri, 10 Dec 93 13:10:13 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23672; Fri, 10 Dec 93 13:10:11 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.6.4/8.6.4) id QAA27751 for c-client@cac.washington.edu; Fri, 10 Dec 1993 16:10:08 -0500 Received: via switchmail; Fri, 10 Dec 1993 16:10:07 -0500 (EST) Received: from nifty.andrew.cmu.edu via qmail ID ; Fri, 10 Dec 1993 16:08:22 -0500 (EST) Received: via niftymail; Fri, 10 Dec 1993 16:07:53 -0500 (EST) Date: Fri, 10 Dec 1993 16:07:41 -0500 (EST) From: Chris Newman Subject: Proposal for c-client API for IMSP To: c-client@cac.washington.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <755557661.22724.0@nifty.andrew.cmu.edu> Here is my current outline for a c-client API for IMSP/options/address-books. It's designed around the concept of a "SUPPORTSTREAM" which is conceptually equivalent to an IMSP connection. It allows for multiple separate option and address book drivers in an implementation along the lines of c-client's multiple mailbox drivers -- thus allowing for both remote and local storage of options and address books. I've got the basic framework implemented am and working on the IMSP drivers. The option support is based on a the simple key string/value string option functionality provided by IMSP. The address book support is based on IMSP's relatively general address book. The model is that each address book is a set of keys (names) and each key (name) has a set of field-data pairs. This allows users to put phone numbers, snail-mail addresses, etc. into their address books. Distribution-lists are just another address book entry with multiple values in the email field. I'd appreciate it if client implementors would let me know if this should suffice for address book/option support. - Chris Newman ------------------------ *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* IMSP client API --------------- by Chris Newman draft 12/10/93 1.0 Status of this document --------------------------- This is a draft of this document, and is subject to change. 1.1 Introduction ---------------- Interactive Mail Support Protocol (IMSP) provides support services for a set of IMAP servers. Some of these services such as options and address books are disjoint from IMAP services. Other services such as the FIND and SUBSCRIBE services are designed to replace similar, but more limited services in IMAP. Because of the latter type of service, it is desirable to have the IMSP client API well integrated with the current c-client IMAP library, preferably in such a way that a new combined c-client/IMSP library can be linked against an existing c-client Mail User Agent (MUA) and automatically take advantage of IMSP's expanded service. When possible, this API will use c-client functionality. For example, IMSP error messages will be displayed using the mm_log callback, and login credentials will be obtained via the mm_login callback. 2.0 Datatypes ------------- 1) A "support stream" structure. It needs to specify address book drivers, option drivers, a list of open address books, a cached mailbox list and a list of c-client MAILSTREAMs. A replacement for the c-client mail_open() will be needed which takes a support stream instead of a MAILSTREAM to recycle. This type will be referred to as "SUPPORTSTREAM". 2) A key-value pair array which is useful for specifying a list of field-data pairs for an address book entry. This structure is made up of two string pointers as follows: typedef struct keyvalue { char *key, *value; } keyvalue; 3) An "address book" access descriptor. This type may refer to either a local file or an IMSP server and IMSP address book name pair. This will be referred to as type "abook". 4) An "address book driver" that contains calls to manage all the address book functions listed below. This will be referred to as type "abookdriver". 5) An "options driver" that contains calls to manage all the option functions listed below. This will be referred to as type "optiondriver". 3.0 IMSP/SUPPORTSTREAM connection control ----------------------------------------- SUPPORTSTREAM *support_new(void) This returns a pointer to a new support stream. void support_done(SUPPORTSTREAM *s); This closes the support stream and releases all memory or other resources associated with it. This will close any associated address book pointers or and possibly MAILSTREAMS. void support_add_adriver(SUPPORTSTREAM *s, abookdriver *d); This adds the specified address book driver to the SUPPORTSTREAM. Returns error status. void support_add_odriver(SUPPORTSTREAM *s, optiondriver *d); This adds the specified option driver to the SUPPORTSTREAM. Returns error status. int imsp_open(SUPPORTSTREAM *s, char *hostname); This attempts to open an IMSP connection to the specified hostname. If a connection is successfully opened, then the IMSP address book and option drivers will automatically be added as the first SUPPORTSTREAM drivers. This will use c-client's mm_login() callback to get the username and password as needed. Returns error status. 4.0 MAILSTREAM support ---------------------- MAILSTREAM *mailbox_open(SUPPORTSTREAM *s, char *name, char *options); This should be used instead of mail_open() in c-client. It will open the specified mailbox using the SUPPORTSTREAM/IMSP as appropriate. This will also set the driver for the MAILSTREAM such that find/create/rename/delete and other routines superceeded by IMSP are handled properly. void mailbox_close(MAILSTREAM *m); This will close and "free" the MAILSTREAM m. The library may keep m open and recycle it on future mailbox_open() calls. 5.0 Options ----------- void mm_option(SUPPORTSTREAM *s, char *option, char *value, int read_write_flag); This is the callback used whenever a "* OPTION" from the server is processed, or an option is read from a local option file. The option and value parameters will point to strings representing the option name and its value respectively. The read_write_flag will be non-zero if the option may be modified by the client. int option_get(SUPPORTSTREAM *s, char *pattern); This will call mm_option for all the options matching the specified pattern (using wildcards as in the IMSP specification). Returns error status. int option_lock(SUPPORTSTREAM *s, char *option); This will lock the specified option, and may call mm_option to update its value. Returns error status. void option_unlock(SUPPORTSTREAM *s, char *option); This will unlock the specified option. int option_set(SUPPORTSTREAM *s, char *option, char *value); This will set the value for the specified option. This may also call mm_option with the new value. Returns error status. 5.1 Discussion of Options ------------------------- The user interface is expected to call option_lock() on read-write options before displaying them in a context where the user may modify them. If a lock fails on an option with "already locked" status the user should be asked if they want to "break the lock" before a call to option_set(). option_lock() is an advisory lock and will not be enforced by the API. Since options are per-user, an "already locked" error indicates the user has another active client showing options in a modifiable context. 6.0 Address books ----------------- void mm_addressbook(SUPPORTSTREAM *s, char *abook_name); This callback is passed the name of a valid address book. void mm_address(abook ab, char *name, fielddata *fdata, int count); This callback is passed the name of an entry in the specified address book, and a list of field/data pairs. The fdata & count arguments are 0 except in response to an explicit fetch command. If fdata is non-zero, mm_address is expected to make sure it is freed. int abook_find(SUPPORTSTREAM *s, char *pattern); This calls mm_addressbook for each address book on the specified connection that matches the pattern and is readable by the current user. Returns error status. abook *abook_open(SUPPORTSTREAM *s, char *abook_name); This "opens" the specified address book, returning an abook structure to access its contents. For IMSP, this will not generate any protocol requests. If abook_name is NULL, the default address book (specified by the IMSP login name of the current user for the IMSP driver) will be used. Returns NULL on failure. void abook_close(abook *ab); This "closes" the specified address book and releases any resources it uses. int abook_getlist(abook *ab); This calls mm_address() for each address in the specified address book. Returns error status. int abook_search(abook *ab, char *pattern, keyvalue *criteria, long number_of_criteria); This calls mm_address() for each address in the specified address book that matches the pattern and criteria. The criteria is specified as defined in the IMSP specification, and may be NULL if number_of_criteria is 0. Returns error status. int abook_fetch(abook *ab, char *name); This calls mm_address() for with the field data pairs for the specified address book entry. Returns error status. int abook_lock(abook *ab, char *name); This places an advisory lock on the specified address book entry. Returns error status. void abook_unlock(abook *ab, char *name); This removes an advisory lock from the specified entry. int abook_store(abook *ab, char *name, keyvalue *field_data, long number_of_field_data_pairs); This stores the field_data in the specified address book entry. number_of_field_data_pairs must be at least 1. Returns error status. int abook_delete(abook *ab, char *name); This deletes the specified address book entry. Returns error status. char *abook_expand(abook *ab, char *name); This will return a CRLF separated list of email addresses for the specified address book entry. It will return NULL on failure. Note that an address book entry need not have any email field. Clients must not use the email field returned by abook_fetch() -- they must call this function. This function may "open" other address books to expand address references via the "members" field of the address book. 6.1 Address book access control ------------------------------- void mm_abookacl(abook *ab, char *identifier, char *rights); Callback used to specify access rights. The "identifier" parameter will be NULL if this is the result of a "MYACL". int abook_getacl(abook *ab, int myrights); If myrights is 1, this will call mm_abookacl with the rights for the current user, otherwise it will call mm_abookacl for each entry in the access control list. Returns error status. int abook_setacl(abook *ab, char *identifier, char *rights); This sets the access control rights for "identifier" to "rights". May call mm_abookacl() with the actual rights set. Returns error status. 6.2 Discussion of Address books ------------------------------- A utility function to convert ACL rights strings to/from bit-vectors will be provided. The user interface is expected to call abook_lock() before displaying the contents of an address book entry is a context where the user may modify it. From owner-c-client@cac.washington.edu Wed Dec 15 09:32:06 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA01608; Wed, 15 Dec 93 09:32:06 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08391; Wed, 15 Dec 93 11:33:25 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Lindy.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08385; Wed, 15 Dec 93 11:33:24 -0800 Received: from mac-treister.stanford.edu by lindy.Stanford.EDU (4.1/4.7); Wed, 15 Dec 93 11:33:23 PST Date: Wed, 15 Dec 93 11:33:33 -0800 From: Adam Treister To: c-client@cac.washington.edu Subject: Cross Server Message Transfer Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Has anyone implemented a client which can move/copy messages between folders on different machines (including the client)? The current calls take a path but not a host. I can't imagine its too hard for the client to fetch and then append, but I want to do it in on the c-client level, so its usable by all and transparent to the MUA whether the folder is local, remote etc. Should the arguments be URLs? Adam Treister From owner-c-client@cac.washington.edu Wed Dec 15 13:02:49 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08517; Wed, 15 Dec 93 13:02:49 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23681; Wed, 15 Dec 93 15:36:07 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23675; Wed, 15 Dec 93 15:36:05 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA01445; Wed, 15 Dec 93 15:35:58 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA08662; Wed, 15 Dec 93 15:35:51 -0800 Date: Wed, 15 Dec 1993 14:20:09 -0800 (PST) From: Mark Crispin Subject: re: Cross Server Message Transfer To: Adam Treister Cc: c-client Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Adam - Pine offers the capability of transfer of messages between folders on different machines, including third-party transfers (IMAP server to another IMAP server). As you surmised, this is done by a client fetch and then an append. This technique always works, no matter where the source and destination may be. copy/move only work under the following two conditions: 1) if the source mailbox is local, then the destination must also be local and of the same folder type (driver) as the source. 2) if the source mailbox is remote, then: 2a) if the destination is specified as local, it is local to the source (not to the client) and may be subject to folder format considerations (as with the local source case). 2b) if the destination is specified as remote, then the server must have an IMAP client, use c-client syntax, and must have enough information to obtain access authorization to the remote server. These are a lot of ifs. In general, I recommend the client fetch/mail technique and would tend to deprecate the copy/move techniques except as an efficiency hack in those cases when the client absolutely knows that these functions will work. I would go even further, and to say that copy/move should be used ONLY when mail is stored in only one place, whether local or a single server. They do not scale to the general case. This is why append was created. -- Mark -- From owner-c-client@cac.washington.edu Fri Dec 17 11:00:01 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23959; Fri, 17 Dec 93 11:00:01 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15611; Fri, 17 Dec 93 11:01:48 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Lindy.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15605; Fri, 17 Dec 93 11:01:46 -0800 Received: from mac-treister.stanford.edu by lindy.Stanford.EDU (4.1/4.7); Fri, 17 Dec 93 11:01:44 PST Date: Fri, 17 Dec 93 11:01:53 -0800 From: Adam Treister To: Chris Newman Subject: Re:Proposal for c-client API for IMSP Cc: c-client@cac.washington.edu Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Chris, I read over your proposal last night, and am in general agreement all the way down the line. A few requests tho' 1) I'll probably write object wrappers around the address book and options calls. So my mm_address callback will look something like this: void mm_address(abook ab, char *name, fielddata *fdata, int count) { AddressBookObject* obj = EXTRACT_PARENT(ab); obj->ProcessCallback(name, fdata, count); } To do this, I need to bury my object pointer in your structures. So I'd like to see the open calls support a "parent" pointer. abook *abook_open(SUPPORTSTREAM *s, char *abook_name, void* parent); MAILSTREAM *mailbox_open(SUPPORTSTREAM *s, char *name, char *options, void* parent); 2) keyvalue > typedef struct keyvalue { > char *key, *value; > } keyvalue; The keyvalue pairs are general enough to do anything we want, but there are a few extra conventions that would make things easier on the client. a) a "list" keyvalue to enable atomic processing of multiple elements b) a "tagged" keyvalue to allow order-independent grammars to be defined. Both of these are in Apple's Object Model, which is architecturally very similar. I could build anything out of your keyvalue, but it makes things a lot easier to add a few more low level tools to the box. I think this necessitates reserving a few keys so the toolbox can recognize them and process accordingly. In addition to LIST and TAG, I can see gains to reserving ADDRESS and ADDRESSBOOK as keys to facillitate representation of distribution lists, and hierarchical address books. 3) My final comment is that this model fits my needs for most any application that wants location-independence! Do you know of any reason why an application that is not using IMAP could not use IMSP and this API to provide the address book and options functionality? Adam From owner-c-client@cac.washington.edu Tue Dec 28 21:37:14 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04145; Tue, 28 Dec 93 21:37:14 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA09474; Tue, 28 Dec 93 21:37:31 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA09468; Tue, 28 Dec 93 21:37:29 -0800 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.23) id AA26303; Tue, 28 Dec 93 21:37:27 -0800 Received: by twinsun.com (4.1/SMI-4.1) id AA28728; Tue, 28 Dec 93 21:19:23 PST Received: from ford.airco.co.jp by air.airco.co.jp (4.1/6.4J.6) id AA16725; Tue, 28 Dec 93 14:54:28 JST Received: by ford.airco.co.jp (4.1/6.4J.6) id AA01028; Tue, 28 Dec 93 14:39:58 JST Date: Tue, 28 Dec 93 14:39:58 JST From: makr@airco.co.jp (Mark Keasling) Return-Path: Message-Id: <9312280539.AA01028@ford.airco.co.jp> To: c-client@cac.washington.edu Subject: Question about Imapd and PC interaction Hi folks, I am having a problem with the imapd when connection is made through the network from a PC (using Cameleon). If the PC hangs and is rebooted (occurs frequently), the imapd doesn't terminate but hangs around for a few minutes waiting to timeout. If the user, reruns the application from the PC, the mailbox that it was reading is now read-only. If the imapd is connected to a Unix box and the application crashes or is killed, the imapd terminates immediately. I'm wondering if the Pine people (or anyone else for that matter) have had a similar experience and if so how they solved it. I think it may be that the ethernet board or network software isn't configured properly or some such PC thing, but since I have virtually no PC experience, I really haven't got a clue as to how to approach the problem let alone fix it. I would especially appreciate any bits of wisdom thrown my way. Happy Holidays, makr -- Mark Keasling AIR Company LTD, Nishikawa Mitsui Bldg, 1-3-14 Kitahama, Chuo-ku, Osaka 541 email: makr%airco.co.jp phone: +1 81 6201 4307 fax: +1 81 6201 2107 From owner-c-client@cac.washington.edu Tue Dec 28 22:28:42 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04467; Tue, 28 Dec 93 22:28:42 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA09619; Tue, 28 Dec 93 22:28:55 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA09613; Tue, 28 Dec 93 22:28:35 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07669; Tue, 28 Dec 93 22:28:22 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA18572; Tue, 28 Dec 93 22:28:14 -0800 Date: Tue, 28 Dec 1993 22:24:46 -0800 (PST) From: Mark Crispin Subject: re: Question about Imapd and PC interaction To: Mark Keasling Cc: c-client Interest List In-Reply-To: <9312280539.AA01028@ford.airco.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On UNIX-based systems, when a TCP programs quits the operating system sends a close (TCP reset) to the other end. This causes an imapd to exit. This doesn't happen on toy computers such as PC's or Macs, especially when they are rebooted. imapd in this case has no way of knowing that the other end went away. Hence the difference between the two types of clients. imapd has a 30-minute inactivity timeout, after which it exists. In modern versions of c-client and imapd, if a second session tries to open the mailbox, it grabs the read/write lock away from the previous session and the previous session becomes read-only on a snapshot of the mailbox. From owner-c-client@cac.washington.edu Wed Jan 19 09:39:31 1994 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA00231; Wed, 19 Jan 94 09:39:31 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA01644; Wed, 19 Jan 94 09:43:59 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA01637; Wed, 19 Jan 94 09:43:57 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.6.4/8.6.4) id MAA12647; Wed, 19 Jan 1994 12:43:46 -0500 Received: via switchmail; Wed, 19 Jan 1994 12:43:45 -0500 (EST) Received: from nifty.andrew.cmu.edu via qmail ID ; Wed, 19 Jan 1994 12:43:33 -0500 (EST) Received: via niftymail; Wed, 19 Jan 1994 12:43:24 -0500 (EST) Date: Wed, 19 Jan 1994 12:43:23 -0500 (EST) From: Chris Newman Subject: Re: Re:Proposal for c-client API for IMSP To: Adam Treister In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: c-client@cac.washington.edu Message-Id: <759001403.22147.0@nifty.andrew.cmu.edu> I forgot to get to this message over the holidays... In message , Adam Treister writes: > Chris, > > I read over your proposal last night, and am in general agreement all the way > down the line. A few requests tho' > > 1) I'll probably write object wrappers around the address book and options > calls. So my mm_address callback will look something like this: > > void mm_address(abook ab, char *name, fielddata *fdata, int count) > { > AddressBookObject* obj = EXTRACT_PARENT(ab); > obj->ProcessCallback(name, fdata, count); > } > > To do this, I need to bury my object pointer in your structures. So I'd > like to see the open calls support a "parent" pointer. > > abook *abook_open(SUPPORTSTREAM *s, char *abook_name, void* parent); > > MAILSTREAM *mailbox_open(SUPPORTSTREAM *s, char *name, char *options, void* > parent); A good idea, although I'm not sure referring to it as "parent" is the right thing to do. For flexability, why don't I just make it a generic data void pointer (e.g. void *data). > 2) keyvalue > > > typedef struct keyvalue { > > char *key, *value; > > } keyvalue; > > The keyvalue pairs are general enough to do anything we want, but there are a > few extra conventions that would make things easier on the client. > > a) a "list" keyvalue to enable atomic processing of multiple elements > b) a "tagged" keyvalue to allow order-independent grammars to be defined. > > Both of these are in Apple's Object Model, which is architecturally very > similar. I could build anything out of your keyvalue, but it makes things a > lot easier to add a few more low level tools to the box. I think this > necessitates reserving a few keys so the toolbox can recognize them > and process accordingly. I don't really understand what you're asking for here. The IMSP model for an address book is that each address book entry is a set of keyvalue pairs (in an arbitrary order). What would the values of a "list" or "tagged" keyvalue be? Could you give me an example of their use? Does this merit IMSP spec or API level support, or would it work as a client convention? > In addition to LIST and TAG, I can see gains to reserving ADDRESS and > ADDRESSBOOK as keys to facillitate representation of distribution lists, and > hierarchical address books. The IMSP spec reserves "email" for a CRLF separated list of email addresses, and "members" for a CRLF separated list of names of other address book entries. The purpose of the abook_expand() API call is to ensure that all clients resolve both the "email" and "members" fields correctly. At present, I think burying address books in address book entries is getting a bit too complex. Since address book entry keys are arbitrary, this can always be added as a convention or later feature if there is demand. > 3) My final comment is that this model fits my needs for most any > application that wants location-independence! Do you know of any > reason why an application that is not using IMAP could not use IMSP > and this API to provide the address book and options functionality? The only tricky part is to keep the options namespace from getting confused. Otherwise, I'd say yes. In fact, one of the reasons for separating the IMSP functionality from IMAP is that it provides services that are potentially useful to non-IMAP protocols (POP2, POP3, NNTP, etc). - Chris From owner-c-client@cac.washington.edu Wed Jan 19 10:51:46 1994 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA01910; Wed, 19 Jan 94 10:51:46 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA02740; Wed, 19 Jan 94 10:56:11 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from Lindy.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA02734; Wed, 19 Jan 94 10:56:09 -0800 Received: from mac-treister.stanford.edu by lindy.Stanford.EDU (4.1/4.7); Wed, 19 Jan 94 10:56:05 PST Date: Wed, 19 Jan 94 10:55:51 -0800 From: Adam Treister To: Chris Newman Subject: Re: Re:Proposal for c-client API for IMSP Cc: c-client@cac.washington.edu Message-Id: In-Reply-To: Your message <759001403.22147.0@nifty.andrew.cmu.edu> of Wed, 19 Jan 1994 12:43:23 -0500 (EST) Content-Type: TEXT/plain; charset=US-ASCII #1 Adam: > > To do this, I need to bury my object pointer in your > structures. So I'd > > like to see the open calls support a "parent" > pointer. > > > > abook *abook_open(SUPPORTSTREAM *s, char *abook_name, > void* parent); > > > > MAILSTREAM *mailbox_open(SUPPORTSTREAM *s, char *name, > char *options, void* > > parent); > Chris: > A good idea, although I'm not sure referring to it as > "parent" is the right thing to do. For flexability, why > don't I just make it a generic data void pointer (e.g. > void *data). No argument...Would a pointer by any other name, not dereference so sweet? #2 Adam: > > The keyvalue pairs are general enough to do anything > we want, but there are a > > few extra conventions that would make things easier on > the client. > > > > a) a "list" keyvalue to enable atomic processing of > multiple elements > > b) a "tagged" keyvalue to allow order-independent > grammars to be defined. > > > > Both of these are in Apple's Object Model, which is > architecturally very > > similar. I could build anything out of your keyvalue, > but it makes things a > > lot easier to add a few more low level tools to the > box. I think this > > necessitates reserving a few keys so the toolbox can > recognize them > > and process accordingly. > Chris: > I don't really understand what you're asking for here. > The IMSP model for an address book is that each address > book entry is a set of keyvalue pairs (in an arbitrary > order). What would the values of a > "list" or "tagged" keyvalue be? Could you give me an > example of their use? Does this merit IMSP spec or API > level support, or would it work as a client convention? I don't know if I can do this one justice, in the limited time I have but its a case where the anticipated modes of usage may justify another layer of complexity in the structures. I've included some typedefs from Apples AppleEvent structures in the hope that it'll give an example. (Read new Inside Mac volume on InterApplication Communication, for more explanation on their usage) I guess this is a convention since the client would be requesting a double, but the second element would be a list. But by having conventions in place, we can offer cross client functionality like Get_Fax_Number(treister) or How_Many_Names_In_List(c-client), that without some sort of standard, each client would only be able to provide for records it created. ------------------ Taken from AppleEvent.h ------------- (these are all 4 byte codes defined by apple, eg 'TEXT', 'aevt', 'quit' --Adam) typedef unsigned long AEEventClass; typedef unsigned long AEEventID; typedef unsigned long AEKeyword; typedef ResType DescType; struct AEDesc { DescType descriptorType; Handle dataHandle; }; typedef struct AEDesc AEDesc; struct AEKeyDesc { AEKeyword descKey; AEDesc descContent; }; typedef struct AEKeyDesc AEKeyDesc; typedef AEDesc AEAddressDesc; /* an AEDesc which contains address data */ typedef AEDesc AEDescList; /* a list of AEDesc's is a special kind of AEDesc */ typedef AEDescList AERecord; /* AERecord is a list of keyworded AEDesc's */ typedef AERecord AppleEvent; /* an AERecord that contains an AppleEvent */ > > The IMSP spec reserves "email" for a CRLF separated list > of email addresses, and "members" for a CRLF separated > list of names of other address book entries. The > purpose of the abook_expand() API call is to ensure that > all clients resolve both the "email" and "members" > fields correctly. No argument these are the most important cases, but there are other lists that mailstrom uses, that in theory should be shared across clients. eg: (Preferred-Fonts (Browser (Geneva 10 Bold)) (ReadWindow (Courier 12 Plain)) (Telemetry (Monaco 9 plain))). Yes, I can parse these lists myself, but the most effective way to get these things to be cross client is to build it into c-client. Let me close out this subject by recommending that we NOT try to incorporate it into any current versions, but table it for future enhancements. I'm not sure what percentage of users actively use more than one client regularly, AND care that the look and feel is consistant. Chances are its easier to write some utility that translates one clients preference set to another, than it is to agree on universal conventions at this early stage. Adam From owner-c-client@cac.washington.edu Fri Jan 21 07:15:59 1994 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14350; Fri, 21 Jan 94 07:15:59 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08888; Fri, 21 Jan 94 07:15:01 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08879; Fri, 21 Jan 94 07:15:00 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.6.4/8.6.4) id KAA06319; Fri, 21 Jan 1994 10:14:53 -0500 Received: via switchmail; Fri, 21 Jan 1994 10:14:52 -0500 (EST) Received: from nifty.andrew.cmu.edu via qmail ID ; Fri, 21 Jan 1994 10:13:37 -0500 (EST) Received: via niftymail; Fri, 21 Jan 1994 10:13:33 -0500 (EST) Date: Fri, 21 Jan 1994 10:13:33 -0500 (EST) From: Chris Newman Subject: Re: Re:Proposal for c-client API for IMSP To: Adam Treister In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: c-client@cac.washington.edu Message-Id: <759165213.194.0@nifty.andrew.cmu.edu> Adam Treister writes: > I don't know if I can do this one justice, in the limited time I > have but its a case where the anticipated modes of usage may justify > another layer of complexity in the structures. I've included some > typedefs from Apples AppleEvent structures in the hope that it'll > give an example. (Read new Inside Mac volume on InterApplication > Communication, for more explanation on their usage) I'm afraid pointing to apple events as an example isn't going to convince me. When I added them to my basic application skeleton, I found them so complex that I almost decided not to bother supporting them... I wouldn't want that to happen with IMSP. > I guess this is a convention since the client would be requesting a > double, but the second element would be a list. But by having > conventions in place, we can offer cross client functionality like > Get_Fax_Number(treister) or How_Many_Names_In_List(c-client), that > without some sort of standard, each client would only be able to > provide for records it created. I think parsing of user-visible fields beyond "email" and "members" will be a dangerous thing for a client to do. There are all sorts of character set and internationalization issues to worry about (e.g. I believe some countries list their phone numbers in reverse order from what the US does)... > No argument these are the most important cases, but there are other > lists that mailstrom uses, that in theory should be shared across > clients. eg: (Preferred-Fonts (Browser (Geneva 10 Bold)) > (ReadWindow (Courier 12 Plain)) (Telemetry (Monaco 9 plain))). Yes, > I can parse these lists myself, but the most effective way to get > these things to be cross client is to build it into c-client. We definitely need to work out some system for registry of generic options and the prefixes used for client-specific options. - Chris From owner-c-client@cac.washington.edu Mon Jan 24 17:27:11 1994 Return-Path: Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA07602; Mon, 24 Jan 94 17:27:11 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19491; Mon, 24 Jan 94 18:11:47 -0800 Errors-To: owner-c-client@cac.washington.edu Sender: owner-c-client@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19485; Mon, 24 Jan 94 18:11:43 -0800 Received: by scapa.cs.ualberta.ca id <18705>; Mon, 24 Jan 1994 19:11:28 -0700 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Mon, 24 Jan 94 14:03 MST Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0pOYXT-000cxkC; Mon, 24 Jan 94 14:09 MST Date: Mon, 24 Jan 1994 13:09:37 -0700 From: Steve Hole Subject: Re: Re:Proposal for c-client API for IMSP To: Chris Newman Cc: Adam Treister , c-client@cac.washington.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 21 Jan 1994 08:13:33 -0700 Chris Newman wrote: > From: Chris Newman > Date: Fri, 21 Jan 1994 08:13:33 -0700 > Subject: Re: Re:Proposal for c-client API for IMSP > To: Adam Treister > Cc: c-client@cac.washington.edu > > > No argument these are the most important cases, but there are other > > lists that mailstrom uses, that in theory should be shared across > > clients. eg: (Preferred-Fonts (Browser (Geneva 10 Bold)) > > (ReadWindow (Courier 12 Plain)) (Telemetry (Monaco 9 plain))). Yes, > > I can parse these lists myself, but the most effective way to get > > these things to be cross client is to build it into c-client. > > We definitely need to work out some system for registry of generic > options and the prefixes used for client-specific options. I'll buy that. We are developing a hierarchical option model here that will be used in the ECSMail version 3.0. Some of these would be useful in the generic sense I'm sure. I would be happy to contribute this information as part of the startup. Cheers. -- Steve Hole ECS Technical Manager ISA Corporation mail: Steve.Hole@Edm.ISAC.CA Suite 835, 10040 - 104 St. phone: (403) 420-8081 Edmonton, Alberta, Canada fax: (403) 420-8037 T5J 0Z2