From imap-request@cac.washington.edu Mon Aug 31 22:03:18 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19933; Mon, 31 Aug 92 22:03:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21680; Mon, 31 Aug 92 22:03:17 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21672; Mon, 31 Aug 92 22:03:16 -0700 Date: Mon, 31 Aug 1992 21:46:11 -0700 (PDT) From: Mark Crispin Subject: welcome to the IMAP interest list To: IMAP 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 IMAP interest list at the University of Washington. The purpose of this list is for discussion and announcements related to the IMAP2 protocol described by RFC-1176 and updated by the draft IMAP2bis document. 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: IMAP@CAC.Washington.EDU To request addition/deletions to the list, send mail to: IMAP-request@CAC.Washington.EDU Related mailing lists which may be of interest: c-client@CAC.Washington.EDU c-client e-mail software library 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 imap-request@cac.washington.edu Tue Sep 1 04:45:10 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26205; Tue, 1 Sep 92 04:45:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23603; Tue, 1 Sep 92 04:45:08 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23597; Tue, 1 Sep 92 04:45:03 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <19787-4@ppsw1.cam.ac.uk>; Tue, 1 Sep 1992 12:44:50 +0100 Date: Tue, 01 Sep 92 12:44:35 BST From: A Grant To: imap@cac.washington.edu Subject: IMAP2 futures? Message-Id: First, thank you to Mark Crispin for creating this list! I'd like to ask what work is under way, or planned, for the next version of IMAP2. In particular, are there plans for protocol support for: 1. access to the host's quota control mechanism, where one exists 2. password changing (for non-Kerberos sites) 3. forwarding (automatic, i.e. access to '.forward' file or equivalent) ... 4. simple X.500 interface 5. forwarding (user-initiated, i.e. in a session) 6. mail sending (in decreasing order of importance - gap indicates where 'really needed' changes to 'would be nice'). I can provide arguments for each of those on request, and could probably work out upwards-compatible protocol extensions, but I thought I'd check first to see if anyone else agrees. I realise not all servers will want to / be able to provide any of these functions, but many host systems can do, and it would be better to have standardised protocol extensions rather than everyone inventing their own. In particular, we see access to quota control (i.e. simply finding out what percentage of quota has been used) as essential for naive users, since the consequences of exceeding quotas can be utterly confusing. -- Alasdair Grant +44 223 334447 MVS Systems Group / Small Systems Integration Group University Computing Service, A.Grant@ucs.cam.ac.uk Pembroke St., Cambridge CB2 3QG, UK From imap-request@cac.washington.edu Tue Sep 1 14:07:18 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA12245; Tue, 1 Sep 92 14:07:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29395; Tue, 1 Sep 92 14:07:14 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29389; Tue, 1 Sep 92 14:07:12 -0700 Date: Tue, 1 Sep 1992 13:38:30 -0700 (PDT) From: Mark Crispin Subject: re: IMAP2 futures? To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You raise a number of interesting questions: > 1. access to the host's quota control mechanism, where one exists This is difficult to do in any sort of general way. One problem is that different implementations have different interpretations of quotas. On many systems, a quota is really some number of disk records (or clusters of disk records). Users often don't know their real quota; they are told some number of `bytes' or `blocks' but they discover -- to their confusion -- that they are out of quota even though the total number of `bytes' or `blocks' is considerably less. [Anecdote: A system I used 19 years ago gave users a `100 block' quota, saying this was 64,000 characters. However, it actually allocated (and charged!) in clusters of 5 blocks, so the actual limit was 20 files, and only if the files were less than 3200 characters each -- a 3201 character file was charged as 10 blocks.] I agree that some mechanism to give users a handle on their disk quota remotely is necessary. It is important that any mechanism picked *not* be biased towards on particular operating system's strategy, and that the data be useful for a user. Another issue is scoping; IMAP must not be allowed to get `everything but the kitchen sink' put in, or we'll end up with an unwieldy mess. This is one reason why only minimal management was put into IMAP2bis and why the more complex management issues were deferred to the Mail Management Protocol. So, let's put this on the table as a topic. Modern-day c-client does detect and clean up properly when quota problems hit. > 2. password changing (for non-Kerberos sites) I believe that this was going to be considered as part of the Mail Management Protocol developed by CMU. I'd like to hear comments from the CMU hackers on this. I think that an environment in which users do not log into the IMAP server as timesharing users will have to have the Mail Management Protocol layer; the IMAP-only environment is for the `simple' configurations. > 3. forwarding (automatic, i.e. access to '.forward' file or equivalent) This is also a Mail Management Protocol issue for the same reasons. CMU??? > 4. simple X.500 interface This is one of those things that everyone talks about a lot, but it isn't all that clear to me what it implies. X.500 is supposed to solve all our problems but then again X.400 was supposed to do so too. I don't think that `simple' and `X.anything' properly go together. We'll need to do something about this, but I'm taking a `wait and see' attitude until I understand the issues better. > 5. forwarding (user-initiated, i.e. in a session) Could you explain this? I don't quite understand what you mean. Do you mean forwarding a message or altering your mail forwarding or ?? > 6. mail sending This is a frequently asked request. The IETF-REMMAIL group seems to have sputtered out on this question, without achieving closure. There are strong arguments on both sides of the issue. Although I am an `anti', I am sympathetic to the problems the `pro' side faces; however, I have been totally unsuccessful in playing Devil's Advocate for the `pro' side. I suggest a review of the IETF-REMMAIL@UMich.EDU discussion to avoid rehashing the same points over again. It's an emotional topic; the `pro' side is defending what they consider to be the side of simplicity (of a sort) and authentication (again, of a sort), while the `anti' side defends simplicity (of a different sort) and models which are possible only if mail access and mail posting are not coupled. If possible, I would like to see the discussion of this topic take place on IETF-REMMAIL and not here. I am agreeable to letting IMAP follow the concensus of the IETF-REMMAIL group, should they achieve closure on the topic. -- Mark -- From imap-request@cac.washington.edu Tue Sep 1 14:17:10 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA12683; Tue, 1 Sep 92 14:17:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29539; Tue, 1 Sep 92 14:17:07 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29533; Tue, 1 Sep 92 14:17:05 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <27372-0@ppsw1.cam.ac.uk>; Tue, 1 Sep 1992 22:17:00 +0100 Date: Tue, 01 Sep 92 22:16:45 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: In-Reply-To: > > 1. access to the host's quota control mechanism, where one exists > This is difficult to do in any sort of general way. One problem is that > different implementations have different interpretations of quotas. why not return percentage of quota used so far, according to the system (e.g. use the 'quota' command on SunOS) - if the system is inaccurate, that's too bad, but it may be accurate. > Modern-day c-client does detect and clean up properly when quota problems hit. Er, how? Do you mean the c-client in the Washington distribution has agreed a private protocol (e.g. a text in a BAD message) to pass this information on? > > 5. forwarding (user-initiated, i.e. in a session) > Could you explain this? I don't quite understand what you mean. Do you mean > forwarding a message or altering your mail forwarding or ?? I mean sending on a mail message at the server (i.e. in a mailbox) without having it delivered to the client and then sent back via SMTP. Apart from being more efficient, if the user gets a MIME message that breaks their client (e.g. by being humungously large), server-end forwarding might be the only means of passing the message on to the system administrator. Ideally it should accept an attached note, and encapsulate the original mail using MIME. But then you're half way to a 'send mail' function. > > 6. mail sending > I suggest a review of the IETF-REMMAIL@UMich.EDU discussion to avoid rehashing > the same points over again. It's an emotional topic; the `pro' side is > defending what they consider to be the side of simplicity (of a sort) and > authentication (again, of a sort) I guess 'draft message handling' would be more accurate. I wouldn't particularly mind if a client had to extract draft messages out of the IMAP2 server and then post them off using SMTP. What I am trying to get out of is a situation where a user is tied to one system because all their drafts are stored there. Our users want to treat mail like a telephone network - walk up to the nearest PC or Mac and there you are, complete with draft messages, user preferences etc. From imap-request@cac.washington.edu Tue Sep 1 14:21:53 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA12855; Tue, 1 Sep 92 14:21:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29616; Tue, 1 Sep 92 14:21:48 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29608; Tue, 1 Sep 92 14:21:46 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for IMAP@cac.washington.edu; Tue, 1 Sep 92 17:21:43 EDT Received: via switchmail; Tue, 1 Sep 1992 17:21:42 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 1 Sep 1992 17:20:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 1 Sep 1992 17:19:49 -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; Tue, 1 Sep 1992 17:19:33 -0400 (EDT) Message-Id: Date: Tue, 1 Sep 1992 17:19:33 -0400 (EDT) From: John Gardiner Myers To: IMAP Interest List Subject: Re: IMAP2 futures? In-Reply-To: References: Beak: is Not Unfortunately, the CMU hackers have been too bogged down in issues like user surveys, requirements documents, and beginning-of-semester firefighting to get any real progress done on a mail management protocol. AMDS (the Andrew Message Delivery System) has the forwarding information in the "White Pages" user directory component. Users change their mail forwarding with the same mechanism they use to change their office phone number, though many client programs provide more direct support for changing the former than the latter. I tend to share Mark's reluctance about anything with a name starting with "X.". There is a directory service named "CSO/ph" or similar that seems simple. I haven't examined it in detail, but I believe it deserves looking into. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From imap-request@cac.washington.edu Tue Sep 1 18:18:08 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19864; Tue, 1 Sep 92 18:18:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02265; Tue, 1 Sep 92 18:18:03 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02255; Tue, 1 Sep 92 18:17:53 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42603-2>; Tue, 1 Sep 1992 19:17:28 -0600 Received: by isagate.edm.isac.ca (/\==/\ Smail3.1.25.1 #25.2) id ; Tue, 1 Sep 92 18:52 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mPizY-000cuvC; Tue, 1 Sep 92 18:54 MDT Received: by isasun-3.edm.isac.ca (/\==/\ Smail3.1.20.1 #20.1) id ; Tue, 1 Sep 92 18:50 MDT Message-Id: From: steve@edm.isac.ca (Steve Hole) Subject: re: IMAP2 futures? To: imap@cac.washington.edu (IMAP Interest List) Date: Tue, 1 Sep 1992 18:50:29 -0600 X-Mailer: ELM [version 2.3 PL4] Oh boy, are you ready Mark? Joel King, Ken Bobey and I have been saving up for a long time. The ideas are just exploding from us ... so to speak :-). Some of this conversation spills over into the realm of the c-client, so I am also cross posting it to that list as well. > You raise a number of interesting questions: He sure did. > > 1. access to the host's quota control mechanism, where one exists This was explained quite well. It's not something we have worried about a lot, because our sites tend to be disk rich, and the c-client handled write failures due to space adequately. > > 2. password changing (for non-Kerberos sites) > > I believe that this was going to be considered as part of the Mail Management > Protocol developed by CMU. I'd like to hear comments from the CMU hackers on > this. I think that an environment in which users do not log into the IMAP > server as timesharing users will have to have the Mail Management Protocol > layer; the IMAP-only environment is for the `simple' configurations. I have been thinking about this a lot! The whole concept of authentication is becoming a real issue, but I don't think that it should be handled in something as application specific as the Message Management Protocol. The issue of remote server authentication obviously extends beyond MUAs. Any or all distributed applications require this type of authentication, and current host based authentication services will not cut it. The model that we have been working on for the last six months or so was to develop a true Internet MUA. IMAP and the c-client go a long way to realizing that, but do not address the general problem of authentication. That is OK, because they were not designed to do so. To my mind, it should be sufficient for a mail server to provide: 1. A message store that an MTA can deliver to. 2. A message store that can be accessed via a remote MUA. It should not be a requirement for a user to have an account on the mail host just to provide authentication or to identify the user to the MTA as a potential recipient in the local message store. Currently of course, this is not possible because: 1. The mailhost also performs authentication for the remote MUA applications using standard host-based authentication mechanisms. 2. The current run of MTA's depend on local authentication information (the password file) as the routing mechanism for delivery to the local message store. The ideal situation would be to (1) have a host independent repository for mail application authentication and routing information, and (2) to have a common interface for both MTAs and MUAs (and all other distributed applications for that matter) be able to access that host independent information. So the question is: where should the authentication and routing information come from? A good start for authentication would be to kerberize both the IMAPD server and the clients. We have talked about it here, but hadn't gotten to it yet. I had also heard a rumour that Mark has considered kerberizing the c-client - this is a very good idea Mark, and I will happily volunteer our group to perform this task if you would like. While kerberos will handle TCP channel authentication well, it does not appear to me that it is a general enough solution to be useful for routing to message stores and password management - I may be out to lunch on the last part of that statement. I am currently working on a secure access model based on the features of (watch Mark cringe here), the X.500 directory service - specifically the QUIPU X.500 implementation provide with the ISODE software. The Directory was designed to be a general mechanism for providing configuration and authentication information to users and applications. Authentication and security mechanisms comparable to kerberos are provided via the OSISEC (X.509) and the lightweight directory access protocols over TCP/IP. The nice thing about X.500 (and I really don't think that it is comparable to X.400) is that the authentication information about any user can be made available to any application in a host independent manner, but is completely secure from tampering (which cannot necessarily be said about the host based authentication mechanisms :-). There is still a fair amount of work to be done to create a practical application, but it can, and is being done. I expect that ecs will have to support a couple of different authentication mechanisms for now, but I expect that this will be the mechanism of choice in the future. I will be producing a paper that describes the concepts in detail for a conference in late October and will certainly make it available. > > 3. forwarding (automatic, i.e. access to '.forward' file or equivalent) > > This is also a Mail Management Protocol issue for the same reasons. CMU??? Agreed, these are absolutely management functions. Note that most MTAs perform this function quite well, but once again, make use of host based account information to do it. The thing that I am interested in is how the management protocol is going to work. We have been told that there is one in the works, but have heard virtually nothing about it. It occurred to us early on, that many of the management functions like asynchronous notification, automatic reply and forwarding and others (actually the X.400 spec has a good list) required participation by both the MTA and the MUA. We thought that the MTA should react to requested services like forwarding at delivery time (how could the MUA do it ???), but the MUA should control the service. That is, the user will request management functions through the MUA, but some of them will be acted upon by the MTA. In fact, if there was a concept of an active (rather than passive) message store in the Internet model, it should perform these functions. We have thought seriously about implementing an active message store, but have delayed because both the c-client (imapd) and the MTAs *kind of* implement active message store functions. Obviously we were getting into a rats nest. I don't think that the old BSD flat file message store is really a good modern solution to this problem though either. > > > 4. simple X.500 interface > > This is one of those things that everyone talks about a lot, but it isn't all > that clear to me what it implies. X.500 is supposed to solve all our problems > but then again X.400 was supposed to do so too. I don't think that `simple' > and `X.anything' properly go together. We'll need to do something about this, > but I'm taking a `wait and see' attitude until I understand the issues better. Well, I have already identified two uses - authentication and routing configuration information. The problem with X.500 is not that it is too complicated, it is just so powerful people seem to have a hard time figuring out how to use it all at once. The trick is not to use it all at once, just the applicable features. The features that we made use of in authentication and routing can be thought of in the same vein as Sun's NIS (yellow pages). In this case it is application configuration information that is being held and provided by the directory. There is little direct user involvement. There are several other uses that the directory can be put to for MUAs and MTAs as well. The most probable is a white pages service - we have been doing it for some time now. The idea here is to simply look for users, organizations, or applications (yes, applications - perhaps a fax server) that you want to send mail to. As soon as your network gets any size, it becomes impossible to remember what Joe in accountings mail address was. Using a whitepages directory user agent (DUA) inteface, you can very effectively look up an individual, and even get a digitized picture and voice sample along with the information. Our integration with the MUA at this level is simply to have the two applications communicate and exchange the relevant information. The mail address, full name, and title information for example can be copied directly into the address field of an outgoing message, or into a local address book for quick reference in the future. Another use for the directory is to hold mailing lists - both private and public. I guess there are those who will argu that the mailing list should be held by the local message store (or MTA I guess), but there is no capability in the message store to provide or restrict access to this information. All of these features are provided for naturally in the directory. The MTA and MUA just have to be designed to access the information - this is not difficult to do. In fact, routing information in general can be provided by the directory in exactly the same way as MX record info is provided to MTAs now from DNS. > > 5. forwarding (user-initiated, i.e. in a session) > > Could you explain this? I don't quite understand what you mean. Do you mean > forwarding a message or altering your mail forwarding or ?? I think he wants to forward the message to another address simply by issuing an IMAP primitive, not by resending through a local smtp MTA. This is intimately related to the next section, and should be good for a lengthy debate here. I am not sure how I feel about this, except to say that it involves the concept of an active message store entity once again. I think that there is some merit to this suggestion - as I said before there are certain things that really make sense this way. The thing to do maybe is to define all the things that we would like to be able to do INDEPENDENT OF THE PROCESS THAT PERFORMS THEM, then try to assign them to the different roles in a process model. For example, just say "we want ot be able to automatically forward mail to another address", then worry about whether the MUA, MTA or (if there is such a thing) MS actually performs the function. > > 6. mail sending > > If possible, I would like to see the discussion of this topic take place on > IETF-REMMAIL and not here. I am agreeable to letting IMAP follow the > concensus of the IETF-REMMAIL group, should they achieve closure on the topic. Hmm ... for new messages I can see no reason for submitting new messages through the message store, in fact, I can see reasons for not wanting to do it - and forwarding for that matter as well. The question merits discussion however, so I guess I should join this list. Do you have some information on how to get onto it. Cheers all. I hope that I have stimulated some good discussion, but have not offended. It was not my intention to do so. -- Steve Hole Director of Research and Communications ISA Corporation mail: steve@edm.isac.ca Edmonton, Alberta, Canada phone: (403) 420-8081 From imap-request@cac.washington.edu Tue Sep 1 21:17:48 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22619; Tue, 1 Sep 92 21:17:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03337; Tue, 1 Sep 92 21:17:39 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from nttta.NTT.JP by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03329; Tue, 1 Sep 92 21:17:36 -0700 Received: by ntt-sh.ntt.jp (5.59/ntt-sh-04h) with TCP; Wed, 2 Sep 92 13:14:56 JST Received: by mecl-sh.ntt.jp (4.1/MECLSH01) with TCP; Wed, 2 Sep 92 13:17:41 JST Received: by nttmfs.ntt.jp (3.2/NTTcs01b) with TCP; Wed, 2 Sep 92 13:17:40 JST Received: by mahler.ntt.jp (4.1/NTTcs01b) with TCP; Wed, 2 Sep 92 13:17:39 JST Message-Id: <9209020417.AA14419@mahler.ntt.jp> To: imap@cac.washington.edu Subject: Internatinalization for IMAP2 (was: IMAP2 futures? ) Date: Wed, 02 Sep 92 13:17:39 JST From: hitoaki@mahler.ntt.jp What is the policy of internatinalization for IMAP2 ? I think the imprementation of the IMAP2 search facility considerablly affrects the internatinalization of IMAP2. If this facility is not well-designed , IMAP2 can't be multilingual. -hitoaki ------ 日本電信電話株式会社 交換システム研究所 伝達ソフトウェア研究部 電気通信大学 情報工学科 坂本仁明 (hitoaki@mahler.ntt.jp/hitoaki@cs.uec.ac.jp) From imap-request@cac.washington.edu Tue Sep 1 22:57:30 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23992; Tue, 1 Sep 92 22:57:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03740; Tue, 1 Sep 92 22:57:26 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03732; Tue, 1 Sep 92 22:57:25 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02774; Tue, 1 Sep 92 22:57:22 -0700 Date: Tue, 1 Sep 1992 22:49:15 -0700 (PDT) From: Terry Gray Subject: Re: IMAP2 futures? To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Sep 1992, John Gardiner Myers wrote: > AMDS (the Andrew Message Delivery System) has the forwarding > information in the "White Pages" user directory component. Users > change their mail forwarding with the same mechanism they use to > change their office phone number, though many client programs provide > more direct support for changing the former than the latter. If delivery is to a pool of centrally-managed servers, why does the user need to worry about forwarding? Or is this to accommodate folks with departmental hosts? > I tend to share Mark's reluctance about anything with a name starting > with "X.". There is a directory service named "CSO/ph" or similar > that seems simple. I haven't examined it in detail, but I believe it > deserves looking into. I agree that ph should be evaluated before falling into the X. hole (though Michigan claims that X.500 over the new light-weight stack is working well for them), but my question is: why is this an IMAP issue? I would have guessed it was an MUA function. (Actually, pair of functions, as I'm interested in both the usual human-initiated W.P. search for someone's address, plus the ability for the MUA to *validate* addresses --at least local ones-- before sending the msg. It's always annoying to reply to a msg that has a bunch of addresses, one of which is a typo.) -teg From imap-request@cac.washington.edu Wed Sep 2 04:23:07 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29023; Wed, 2 Sep 92 04:23:07 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05310; Wed, 2 Sep 92 04:23:02 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05304; Wed, 2 Sep 92 04:22:59 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <07217-0@ppsw1.cam.ac.uk>; Wed, 2 Sep 1992 12:22:54 +0100 Date: Wed, 02 Sep 92 12:22:36 BST From: A Grant To: imap@cac.washington.edu Subject: Re: IMAP2 futures? Message-Id: In-Reply-To: Terry Gray writes: > If delivery is to a pool of centrally-managed servers, why does the user > need to worry about forwarding? Or is this to accommodate folks with > departmental hosts? Partly. Also users doing spells at other places for the odd 6 months. > I agree that ph should be evaluated before falling into the X. hole > (though Michigan claims that X.500 over the new light-weight stack is > working well for them), but my question is: why is this an IMAP issue? Because IMAP2 _could_ be a way (because it's extensible, and because it already does one major component pretty well, i.e. mail retrieval) to provide advanced mail functions over IP to clients which don't have a full OSI stack. I think the difficulties of X.500 are being exaggerated (and many are fixed in X.500(92)). For example, some sites have _already_ converted their finger daemons to do X.500 lookup. This also provides some X.500 functionality to IP-based clients. However, there is no standard for X.500-over-finger, and it is not integrated with mail. > I would have guessed it was an MUA function. Not sure what you mean here. The MUA isn't going to have an OSI stack (if it was, we'd use P7 rather than IMAP2). So it would have to agree on a private X.500-over-IP protocol to talk to a relay that could do the DUA functions for it. There is no existing standard protocol (unless this Michigan thing is going to become one). If the new protocol has to fit in somewhere, IMAP2 seems as good a place as any, as there are benefits from integrating DUA with MUA, e.g. reverse lookup on addresses in received messages, and use of the Directory to store configuration information. From imap-request@cac.washington.edu Wed Sep 2 22:53:01 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02056; Wed, 2 Sep 92 22:53:01 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16882; Wed, 2 Sep 92 22:50:33 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16876; Wed, 2 Sep 92 22:50:27 -0700 Date: Wed, 2 Sep 1992 22:33:50 -0700 (PDT) From: Mark Crispin Subject: re: IMAP2 futures? To: A Grant Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 01 Sep 92 22:16:45 BST, A Grant wrote: > why not return percentage of quota used so far The question is, what does that mean to the user? Telling me that I am using 45% of my quota tells me nothing about the question of whether or not copying this 50,000 character will will blow me away or not. Note too that other than remote COPY, there is very little that can be done in IMAP to *use* more quota. You can reduce your usage via IMAP, but I question whether telling someone `you are using 95% of your quota' is going to do anything to encourage him to use less. Remember, that statement can be interpreted to mean `you are only using 95% of what you are entitled to.' I think this needs more consideration and input from other individuals. I'm not sure if this is an IMAP issue or not. > > Modern-day c-client does detect and clean up properly when quota problems > > hit. > Er, how? Do you mean the c-client in the Washington distribution has > agreed a private protocol (e.g. a text in a BAD message) to pass this > information on? The /usr/spool/mail operations that could make the mail file larger are checked for a worst case expansion vs. quota and are rejected if it would run out of disk space. If a quota problem hits with COPY, the COPY is completely backed out of and the entire COPY command is rejected with a NO. Remember, the server does not run with privileges and so has to obey the kernel on quotas. > I mean sending on a mail message at the server (i.e. in a mailbox) without > having it delivered to the client and then sent back via SMTP. Apart from > being more efficient, if the user gets a MIME message that breaks their > client (e.g. by being humungously large), server-end forwarding might be > the only means of passing the message on to the system administrator. > Ideally it should accept an attached note, and encapsulate the original > mail using MIME. But then you're half way to a 'send mail' function. Most of us consider `mail forwarding' to mean encapsulating the message within another message. You would be putting user interface and sending within a message. `Remailing' in this fashion may be reasonable though. However, this is merely `for efficiency' since the same resulting function can be accomplished by existing mechanisms. This is a good reason to reject it; any function which by its fundamental nature is optional and exists only for `efficiency' tends not to get implemented widely. You can either end up with a lot of protocol baggage or recognize reality. Most modern protocol design does the latter. > I guess 'draft message handling' would be more accurate. I wouldn't > particularly mind if a client had to extract draft messages out of the > IMAP2 server and then post them off using SMTP. What I am trying to get > out of is a situation where a user is tied to one system because all > their drafts are stored there. Our users want to treat mail like a > telephone network - walk up to the nearest PC or Mac and there you are, > complete with draft messages, user preferences etc. Remote storage of mail drafts is an interesting suggestion and it is certainly something to bring up to the IETF-REMMAIL group. I would support an effort on this, but I don't think it belongs in IMAP under the `avoid too much baggage in IMAP' banner. Also, I'm not convinced drafts belong on the IMAP server as opposed to the `home directory' server. What if the IMAP server is overseas (this is a real world situation for me!)? Putting it in IMAP seems to be false `efficiency'. I think you have some really good ideas, just that you're seeking the wrong place to see them implemented. The stuff you suggest belongs in a distributed mail system just as IMAP does, but it does not (necessarily) belong in IMAP. Please consider bringing it up to the IETF-REMMAIL group. Regards, -- Mark -- From imap-request@cac.washington.edu Wed Sep 2 23:02:13 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02172; Wed, 2 Sep 92 23:02:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16924; Wed, 2 Sep 92 23:00:06 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16915; Wed, 2 Sep 92 22:59:56 -0700 Date: Wed, 2 Sep 1992 22:51:47 -0700 (PDT) From: Mark Crispin Subject: re: Internatinalization for IMAP2 (was: IMAP2 futures? ) To: hitoaki@mahler.ntt.jp Cc: imap@cac.washington.edu In-Reply-To: <9209020417.AA14419@mahler.ntt.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 02 Sep 92 13:17:39 JST, hitoaki@mahler.ntt.jp wrote: > What is the policy of internatinalization for IMAP2 ? > > I think the imprementation of the IMAP2 search facility considerablly > affrects the internatinalization of IMAP2. If this facility is not > well-designed , IMAP2 can't be multilingual. Konnichi ha - I don't remember if you were at the meeting at NTT-ECL in Musashino with Nojima-san last July, but the upshot of this question was that IMAP2bis does not address any of the questions of expanding the search facility. I was not aware of the international character set problem until it was explained to me at this meeting; I now know and understand the problem quite well. You have my promise that any changes to the search facility in IMAP2 will definitely address this question. Changes to search will probably happen in the next wave of extensions to IMAP2 (IMAP2tres????). I think we'll be starting on that once we get our IMAP2bis implementations up to speed. I did request during the meeting, if NTT would experiment a bit so I can learn from NTT of NTT's experience of what would be a good mechanism for search of kanji. I think that the strings have to be labelled with the character sets (using the same name as the charsets for content-type TEXT), and that for the case of ISO-2022-JP the only comparison that makes sense is to convert both strings to Shift-JIS before comparison (otherwise the ESC codes will be troublesome). Also, you can't use case-independent matching with ISO-2022-JP. -- Mark -- From imap-request@cac.washington.edu Thu Sep 3 05:05:05 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07604; Thu, 3 Sep 92 05:05:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18599; Thu, 3 Sep 92 05:02:57 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18593; Thu, 3 Sep 92 05:02:53 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <27507-0@ppsw1.cam.ac.uk>; Thu, 3 Sep 1992 13:02:24 +0100 Date: Thu, 03 Sep 92 13:02:13 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: > Most of us consider `mail forwarding' to mean encapsulating the message within > another message. You would be putting user interface and sending within a > message. `Remailing' in this fashion may be reasonable though. X.400 (which I honestly believe that everyone outside the USA will be using in 10, if not 2 years' time) allows optional added body parts for both kinds of what it calls `forwarding'. For auto-forwarding the text is supplied in a management operation, for manual forwarding a new message is submitted with a parameter referring to "a message that is already in the MS which is to be combined with the submitted message body". But I accept that it is possible to define a private protocol for auto-forwarding control, and to fetch and re-send a manually forwarded message. > I'm not convinced that draft messages belong on the IMAP server as opposed to > `home directory' server. What if the IMAP server is overseas (this is a real > world situation for me!)? Putting it in IMAP seems to be false `efficiency'. I wasn't really thinking of efficiency here. Even within a campus, a user may want to send mail from machines that have do not have a common file system, i.e. for which the only interconnectivity is IP. Having their draft messages in a common pool is _added function_; having the draft-message management functions integrated with other parts of the mail protocol simplifies things and may also add function. E.g. IMAP2's SEARCH and FETCH commands are mostly equally applicable to draft messages; it would be duplication of effort to have identical commands in a separate server. IMAP2 is already ideal for managing a message pool. All it needs is some way to insert and update the drafts. > Please consider bringing it up to the IETF-REMMAIL group. Ok. But I hope readers will forgive me for reminding the list that the effort in implementing mail these days is not in designing protocols, but in writing user-friendly Windows and Mac clients. The fact that the PC POP clients still haven't got IMAP2 support suggests that any wonderful new mail protocol from the IETF will be of little use to the average user for a long time yet, _unless_ it extends an existing protocol. And to me, IMAP2 seems the best candidate. (I think I've made my point - time for someone else to have a go!) -- Alasdair Grant A.Grant@ucs.cam.ac.uk MVS Systems Group / Small Systems Integration Group +44 223 334447 University Computing Service +44 223 334679 (fax) Pembroke St., Cambridge CB2 3QG, UK From imap-request@cac.washington.edu Thu Sep 3 09:31:55 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA14662; Thu, 3 Sep 92 09:31:55 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20814; Thu, 3 Sep 92 09:31:50 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from nexus.yorku.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20804; Thu, 3 Sep 92 09:31:44 -0700 Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9222>; Thu, 3 Sep 1992 12:31:36 -0400 To: imap@cac.washington.edu Subject: Re: re IMAP2 futures? Date: Thu, 3 Sep 1992 12:31:25 -0400 From: davecb@nexus.yorku.ca Message-Id: <92Sep3.123136edt.9222@nexus.yorku.ca> In you write: [in part of a larger discussion on the server function-set] | However, this is merely `for efficiency' since the same resulting function can | be accomplished by existing mechanisms. This is a good reason to reject it; | any function which by its fundamental nature is optional and exists only for | `efficiency' tends not to get implemented widely. You can either end up with | a lot of protocol baggage or recognize reality. Most modern protocol design | does the latter. I too would argue that little of the added functionality belongs in the imap protocol. It is all too easy to discover you're specifying the transitive closure of all the states of all the subsystems, unless you try quite strongly for separation of concerns. Failing to do so ends up in exponential increase in complexity and implementability. Ie, an unused protocol. In concrete terms, it's a bad idea to add too many things to a protocol because you end up trying to add things which interact in wierd and wonderous ways. For examplem renaming a mailbox can result in the state of the MUA suddenly become inconsistant. If the MUA doen't knows the implications of the operations of the mailbox management system, it can trivially fail, to the detriment of the user. This is already possible in standard IMAP: the imap-using MailManager MUA reports the mysterious shrinking of a mailbox when someone inadvertantly uses /bin/mail. It deals with it reasonably, but has no knowlege of why it happened, and can only report the bare fact. To a non-technical user, this means that mail is unreliable: after all, it disappears without warning! As an example of good practice, ftp quite carefully uses separate streams for commands and data, too keep from having to contain its own multiplexor. If one wants a muliplexor, one uses the one at a lower level in the protocol stack. ( This becomes difficult when talking to very single-threaded machines like PCs and my old CP/M-80 box. If one has multitasking and slip, one has a multiplexor. If one has only uucp or kermit, one hasn't. I once did an application that multiplexed over kermit on a single-task cp/m-80 system. At the client end, the coding was horrid: it really had to be aware of too many things at once.) On a multi-tasking machine I would separate the applications as far as possible, and optionally provide a multiplexor and transport layer **if and only if** I couldn't get an adequate one elswhere. Kermit is pretty easy to multiplex, if you must know. Just don't try to do it on a z80 unless you really like pain. --dave From imap-request@cac.washington.edu Thu Sep 3 10:58:12 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17098; Thu, 3 Sep 92 10:58:12 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21814; Thu, 3 Sep 92 10:58:04 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21808; Thu, 3 Sep 92 10:58:02 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Thu, 3 Sep 92 13:57:56 EDT Received: via switchmail; Thu, 3 Sep 1992 13:57:54 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Thu, 3 Sep 1992 13:56:29 -0400 (EDT) Received: via niftymail; Thu, 3 Sep 1992 13:56:24 -0400 (EDT) Date: Thu, 3 Sep 1992 13:56:23 -0400 (EDT) From: Chris Newman Subject: re: IMAP2 futures? To: imap@cac.washington.edu In-Reply-To: References: Message-Id: <715542983.10477.0@nifty.andrew.cmu.edu> In message , A Grant writes: >I wasn't really thinking of efficiency here. Even within a campus, a user >may want to send mail from machines that have do not have a common file >system, i.e. for which the only interconnectivity is IP. Having their draft >messages in a common pool is _added function_; having the draft-message >management functions integrated with other parts of the mail protocol >simplifies things and may also add function. E.g. IMAP2's SEARCH and FETCH >commands are mostly equally applicable to draft messages; it would be >duplication of effort to have identical commands in a separate server. >IMAP2 is already ideal for managing a message pool. All it needs is some >way to insert and update the drafts. It seems to me that the IMAP2bis "APPEND" command could be used to do what you want. Using a convention that the folder called "drafts" holds draft messages, APPEND could be used to add new or updated drafts, and FETCH/PURGE could be used to get them and delete them. APPEND is completely unsuitable, however, for any sort of mail delivery, as it doesn't provide for an envelope. (I think mail delivery is outside the scope of IMAP2, as there are existing simple protocols to do what is necessary). - Chris Newman Computing Services, Carnegie Mellon University From imap-request@cac.washington.edu Thu Sep 3 11:34:28 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18419; Thu, 3 Sep 92 11:34:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22256; Thu, 3 Sep 92 11:34:19 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22250; Thu, 3 Sep 92 11:34:17 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <03515-0@ppsw1.cam.ac.uk>; Thu, 3 Sep 1992 19:34:04 +0100 Date: Thu, 03 Sep 92 19:33:52 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: In-Reply-To: <715542983.10477.0@nifty.andrew.cmu.edu> > It seems to me that the IMAP2bis "APPEND" command could be used to do > what you want. Using a convention that the folder called "drafts" > holds draft messages, APPEND could be used to add new or updated > drafts, and FETCH/PURGE could be used to get them and delete them. What APPEND command? Has IMAP2bis changed in the last few months? Where is the new draft, please? (I got it out of the imap distribution last time.) > APPEND is completely unsuitable, however, for any sort of mail > delivery, as it doesn't provide for an envelope. (I think mail > delivery is outside the scope of IMAP2, as there are existing simple > protocols to do what is necessary). Nobody is asking for mail delivery, just mail submission. Any system that handles draft messages ought to handle the envelope; a user should not have to set up the envelope each time. In other words, a managed draft message should be able to be "ready for sending". If APPEND is not suitable for mail submission, it will not be suitable for managing draft messages. From imap-request@cac.washington.edu Thu Sep 3 12:35:40 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20043; Thu, 3 Sep 92 12:35:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22949; Thu, 3 Sep 92 12:35:32 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22943; Thu, 3 Sep 92 12:35: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 AA05011; Thu, 3 Sep 92 12:35:17 PDT Date: Thu, 3 Sep 1992 10:26:13 -0700 (PDT) From: Mark Crispin Subject: Re: re IMAP2 futures? To: IMAP Interest List In-Reply-To: <92Sep3.123136edt.9222@nexus.yorku.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dave makes some excellent points, and I suggest that everyone re-read his message. Separation of concerns is a vital part of engineering. If we don't keep it firmly in mind, we are very likely to end up with another fiasco like the late unlamented `IMAP3', or even worse, the ARPAnet `new FTP' protocol which was official, documented and unimplemented (as opposed to the real FTP protocol which was unofficial and undocumented except in folklore). I have been told that people where pounding the tables at screaming at each other in the FTP meetings... In the past, I followed a set of criteria when evaluating potential changes to IMAP2. I think these criteria are good and should be continued in future IMAP2 development. Loosely stated, these criteria are listed below. Exceptions and violations have existed; these criteria represent an ideal rather than necessarily reality. But, I think the strength of IMAP2 has been due to my having held to (and occasionally fought for) these ideals, and the weaknesses of IMAP have been when these ideals have been violated. 1) All proposed changes must demonstrate a reason for their existance: a) They must demonstrate that they are useful. b') They must demonstrate that they solve a problem that can not be solved by other means. OR b") The `efficiency' gained by the new functionality is such that the cost of requiring duplicate code in all implementations pales compared to the benefit gained. [This is nearly impossible to prove.] Examples: . A function to play a game of Pac-Man violates 1a. ;-) . A function to set newline conventions violates 1a and 1b (long-winded explanation about why this is a terrible idea available on request) and also 3 and 4 below. . A function to do a remote Finger violates 1b (a Finger protocol exists). . A function to transmit 8-bit data violates 1b (IMAP2bis supports MIME and BASE64 decoding on the fly is easy). It may not even be `efficient' to transmit binary, as those of us who compare FTP transfer speeds over V42bis links between binary and text know very well... 2) All proposed changes must demonstrate that they belong in IMAP as opposed to some other protocol; the function must fit within the scope of IMAP. This necessarily implies that a distributed mail system will use multiple protocols; only the most simple and minimal can expect to do everything it needs with one protocol. Example: . A function to change the user's password remotely belongs elsewhere. This is undeniably a useful function and IMAP *MUST* consider proper interaction with more advanced authentication mechanisms, but maintenance of the authentication system is outside the scope of IMAP. 3) All proposed changes must solve the problem they seek to solve, and not create new ones. The road to bad protocol designed is paved with kludges that solve one problem in one limited case. Example: . I believe that putting mail posting capability into a mail access protocol violates this rule (I acknowledge this is still a controversy). The arguments for this are efficiency and authentication. However, it is not efficient if the access server is in another continent (I use IMAP to Japan all the time!). Nor are access credentials equivalent to posting credentials; a number of cases exist where posting is permitted without access (mail hubs), and access without posting (read-only bboards). What is worse, by allowing posting in the mail access protocol, we create clients that only post using the access protocol (since they don't have enough memory to have multiple means of posting) and that closes a number of doors. UW already has a separate mail hub engine from the mail repository, and this would be precluded by such clients. 4) Multiple protocol states should be avoided, and silly states should be avoided like the plague. This is something that repeatedly comes up in protocol design working groups, as yet another group of inexperienced individuals pressures for modal switches and for mechanism to list the capabilities of an implementation. The archives of various working groups are filled with explanations as to why this is terrible design, and I will not belabor the issue here. Note that even a single mode switch or a version command has been well-toasted; MIME has a `version' setting of 1.0, and it highly likely there will never be any other value permitted. Silly states are something that have received a lot of attention recently due to my efforts. A silly state is one which obeys the protocol, but creates a silly situation. Humans generally avoid silly states in their interactions, but computers and bureaucracies create them all the time. An example of a silly state is that created by a server which answers a `what verbs do you support' by dumping its verb table, even though several of those verbs are served by an error message that says the verb is not implemented. In all cases the server is responding reasonably; it *does* know about the verb so it can say `not implemented' instead of `not recognized'. However, a client which makes decisions based upon its perception of what the server can or cannot do will be misled by the verb table dump. The key point to understand here is that no amount of legislation in the protocol specification is going to prevent silly states if the grammar of the protocol permits it. One of the biggest mistakes in MIME was the ban on recursive encoding (encoding of types MESSAGE and MULTIPART) instead of the use of syntax that would make the concept non-existant. The ban is there for excellent reasons -- I lobbied long and hard for it -- but the fact that the grammar permits it has come to haunt us with PEM. 5) Proposed new capabilities should be interoperable with the past. The base level capability of IMAP2 was defined in RFC-1176 (some say RFC-1064) and software implementing that base level is widely distributed. New capabilities should appear as extensions, and it should be clearly understood what should be done if the capability is not supported. The use of new capabilities should be completely under the client's control; a server should never thrust something unexpected upon an unprepared client. New capabilities should be small and have minimal interaction with other new capabilities; and where such interaction exists (e.g. between FIND and SUBSCRIBE) it should be well-documented. It is crucial that both the client and the server completely implement the enter base level, and that a client attempting to use capabilities beyond the base level is able to do so only with a willing server, and that no server should presume that the use of one extended capability by the client implies the existance of support in the client of another extended capability, and that no client should presume that a successful use of an extended capability with a server implies that the server supports another extended capability. 6) It should be reasonable to expect that any new (or existing supported) implementations will implement *ALL* capabilities, both base and extended; that the `optionality' of an extended capability refers to the fact that we don't have to change all the old implementations; and that any capability which is marginal enough that a new implementation would not want to include it should be rejected on those grounds. The fact that a capability, by not being in the base, is `optional' is not license to add a marginal capability on the grounds that it can be ignored. The penalty of disobeying this rule is a protocol filled with unnecessary and unused clutter. 7) Some amount of latitude is allowed when the benefits clearly outweigh the costs. For example, the new mail management capabilities in IMAP provide that service in the very simple case of a single repository. By design, they are completely inadequate for multiple distributed repositories; that is completely outside the scope of IMAP and belongs in a mail management protocol. 8) It is important that any protocol design recognize the realities of the underlying infrastructure. IMAP2 is a byte-stream protocol and as such runs on top of a reliable byte-stream protocol such as TCP. This imposes various constraints that aren't obvious to novices. It is important to recognize that `reliability' implies error correction and especially flow control, that although these seem to be transparent they do have implications in your higher level protocol design. The CCA Datacomputer protocol of ARPAnet days (R.I.P.) should be a textbook example of how failure to recognize flow control considerations can lead to deadlocks. No service on top of a flow-controlled protocol is truly `asynchronous'. The entire reason for UDP's existance is that it permits asynchronous protocols, albeit at the expense of lost reliability. Regards, -- Mark -- From imap-request@cac.washington.edu Thu Sep 3 13:38:14 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21622; Thu, 3 Sep 92 13:38:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23537; Thu, 3 Sep 92 13:38:08 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA23531; Thu, 3 Sep 92 13:38:01 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA05032; Thu, 3 Sep 92 13:37:55 PDT Date: Thu, 3 Sep 1992 12:35:29 -0700 (PDT) From: Mark Crispin Subject: re: IMAP2 futures? To: A Grant Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi - I don't share your optimism about `everyone outside the USA using X.400 in 10, if not 2 years'. The market has clearly picked RFC mail over X.400, and that is where the interoperable infrastructure is. The X.400 community has cajoled, exhorted, and even threatened in the past 10 years that they are going to take over the world, and it hasn't happened yet. Some people have said that MIME was the final nail in X.400's coffin; I suspect it will occur when a few more PTT's (particularly Deutsche Bundespost) have their fangs pulled. As my boss is fond of pointing out, one must not limit his perspectives by the tools available to him. The present absence of suitable chisels doesn't mean that it is right to enshine screwdrivers as the tool to chisel. A common filesystem certainly does not exist today; but that does not mean that it may not exist tommorrow. More to the point: IMAP's scope *is* likely to expand, but I am not convinced that it should expand in areas where it currently has no presence. It is one thing to talk about expanding IMAP's distributed information retrieval capabilities to objects other than mail; it is quite another for it to become a distributed manager of user file or environment objects. In the former case, you are expanding the scope of objects under a general category and manipulation that currently exists; in the latter, you are creating new categories of objects and new forms of object manipulation. Your point about the delay in IMAP2 support is well-taken, but it suggests something totally different to me than it does to you. POP had an earlier presence, and it remains substantially simpler than IMAP. Both of these are immense benefits. The present interest in IMAP has come about due to an understanding of the limitations of the POP model. However, the more IMAP `goes off the deep end', the more the simplicity of POP remains the more attractive choice. My source files suggests that the cost of implementing IMAP is about twice that of implementing POP; more accurately, my IMAP server source file is about twice the length of my POP server (30K vs 15K). That's a price to bear, but perhaps not too much given the benefits. We don't want to make that ratio worse. As taxing authorities around the world have discovered, you can get a lot more out of people in small increments taken repeatedly over a long period of time than in massive whallops delivered at once... ;-) -- Mark -- From imap-request@cac.washington.edu Fri Sep 4 04:30:36 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10159; Fri, 4 Sep 92 04:30:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29183; Fri, 4 Sep 92 04:26:28 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29177; Fri, 4 Sep 92 04:26:24 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <16420-0@ppsw1.cam.ac.uk>; Fri, 4 Sep 1992 12:26:15 +0100 Date: Fri, 04 Sep 92 12:26:01 BST From: A Grant To: imap@cac.washington.edu Subject: re: IMAP2 futures? Message-Id: In-Reply-To: <715550469.10477.0@nifty.andrew.cmu.edu> Chris Newman @ CMU writes: > IMAP2 is a protocol for remote mailstore access (from what I > understand). Anything which isn't "remote mailstore access" should be > placed in a separate protocol. The idea of placing a message in a > mailstore to be "picked up for delivery" seems like a very backwards > way to do mail submission -- why not contact the transport agent > directly with an appropriate simple protocol (e.g. SMTP)? I'm not suggesting that IMAP2 take over the role of SMTP, just that it provide facilities to (at least) submit the draft messages it manages. If it doesn't have draft message management, there is less reason to support submission. However, integrating retrieval and submission may open the way for extra functions in the future, e.g. marking messages as 'replied-to'. It's what I'd call an 'enabling step' if I was asking my boss to fund it. A lot of people think that 'remote mailstore access' these days means far more than just retrieval. X.400 P7 is IMHO a good _model_ (and believe me, I have read the standards), even if details of the implementation are still flawed. (Half the problem seems to be that people don't understand ASN.1, which is strange, as it is used in a number of Internet protocols.) > I'm used to MUAs that generate the envelope from the headers > automatically Fine. If an IMAP2-managed draft message is 'ready for sending', without user intervention, it makes even less sense to _require_ the MUA to fetch it and submit it. > But then a mailstore isn't suitable for storing of an envelope -- > only for storage of RFC-822 and MIME messages. Why Internet only? My 'mailstore' contains messages from X.400, BITNET, Internet and Greybook hosts. The fact that they are all converted to one format (Greybook) is something that I, as a user, don't need to be aware of. Concrete example: we are looking at providing IMAP2 access to an X.400 message store. I think at least one non-contentious point has come out of this discussion though: that (a) central draft message management is often necessary, and (b) IMAP2, with its SEARCH and FETCH commands and mailbox management, is ideal for draft message management. Would it be possible to have 'DRAFT' and 'SENT' system flags, to be modified only by the IMAP2 server? From imap-request@cac.washington.edu Fri Sep 4 09:58:06 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17975; Fri, 4 Sep 92 09:58:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01819; Fri, 4 Sep 92 09:58:00 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01813; Fri, 4 Sep 92 09:57:58 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 4 Sep 92 12:57:44 EDT Received: via switchmail; Fri, 4 Sep 1992 12:57:42 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Fri, 4 Sep 1992 12:56:09 -0400 (EDT) Received: via niftymail; Fri, 4 Sep 1992 12:56:05 -0400 (EDT) Date: Fri, 4 Sep 1992 12:56:02 -0400 (EDT) From: Chris Newman Subject: re: IMAP2 futures? To: A Grant , imap@cac.washington.edu In-Reply-To: References: Message-Id: <715625762.1430.0@nifty.andrew.cmu.edu> In message , A Grant writes: >Chris Newman @ CMU writes: >I'm not suggesting that IMAP2 take over the role of SMTP, just that it >provide facilities to (at least) submit the draft messages it manages. Ok, suppose I actually wanted to implement some sort of submission via IMAP. There are a few ways to do this: 1) Put part or all of the mail transport agent (MTA) in the IMAP server. This is clearly a *bad thing* as it makes IMAP many times more complex, and makes it less portable (particularly to places where "standard" mail transport systems aren't used). 2) Have the IMAP server contact the MTA and submit the message itself. This causes the IMAP server to have an external dependancy on another machine/service. At CMU, we've found this to be a *very bad thing*. Our system has so many inter-dependancies that if one thing goes down, it usually takes the whole system with it. Our current design goal for replacement systems it to have each service as independant as possible. 3) Have the MTA pick up the message directly from the mailstore. This requires the MTA to understand the mailstore format(s) and to run on the IMAP server. So this is a *bad thing* as it makes the MTA more complex (and less portable), and makes the IMAP server harder to manage and maintain (particularly at large sites with multiple servers). 4) Have the MTA pick up the messages via IMAP. This requires the MTA to understand IMAP protocol, have a dependancy on the IMAP server, and is probably less efficient than sending the message directly to the MTA from the client. So this is also a *bad thing*. I can't think of any other ways to implement submission via IMAP, and all of these are bad solutions. Since the client needs to understand whatever mail submission protocol (e.g. SMTP) is used anyway, it's best to keep the server simple (as Mark advocates). The tiny cost of fetching a draft message from the server for submission by the client is nothing compared to the damage that adding submission to the IMAP server would cause the protocol's simplicity, portability, and manageability. >If it doesn't have draft message management, there is less reason to support >submission. However, integrating retrieval and submission may open the way >for extra functions in the future, e.g. marking messages as 'replied-to'. >It's what I'd call an 'enabling step' if I was asking my boss to fund it. IMAP already has facilities for flag management in a mailstore. A client which wants such bells and whistles merely needs to set the flags in the server after it submits the mail. There's no need to "integrate" retrieval and submission to get such features. >I think at least one non-contentious point has come out of this discussion >though: that (a) central draft message management is often necessary, and >(b) IMAP2, with its SEARCH and FETCH commands and mailbox management, is >ideal for draft message management. Would it be possible to have 'DRAFT' >and 'SENT' system flags, to be modified only by the IMAP2 server? I would classify draft management as a "nice" feature. Something worth doing only if the implementation is trivial. If draft management can be done using APPEND (and perhaps the existing IMAP flag support), it's worth doing, otherwise I'd prefer keeping the server simple. - Chris Computing Services, Carnegie Mellon University From imap-request@cac.washington.edu Fri Sep 4 10:43:26 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19412; Fri, 4 Sep 92 10:43:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02429; Fri, 4 Sep 92 10:43:22 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02419; Fri, 4 Sep 92 10:43:20 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <21785-2@ppsw1.cam.ac.uk>; Fri, 4 Sep 1992 18:42:35 +0100 Date: Fri, 04 Sep 92 18:42:25 BST From: A Grant To: imap@cac.washington.edu Subject: Draft messages etc. (was IMAP2 futures) Message-Id: In-Reply-To: <715625762.1430.0@nifty.andrew.cmu.edu> > The tiny cost of > fetching a draft message from the server for submission by the client > is nothing compared to the damage that adding submission to the IMAP > server would cause the protocol's simplicity, portability, and > manageability. As an Australian working in the UK I know that data traffic does not come for free. I can see myself doing IMAP2 from Oz and wanting to forward the messages in my inbox to UK colleagues, based on contents of header fields. Retrieving 10Mb MIME video messages from half way round the world and sending them back again would be gross! I am not convinced the 'damage' is significant. Good application-layer protocols are extensible and modular. If IMAP2 is so hairy that adding an optional submission 'subset' to it involves major surgery, I'm not sure it has a future. Thankfully, I think it _is_ able to be extended nicely. I see that you (implicitly) accept that there may be a need for IMAP2 to manage draft messages. We can't be the only potential IMAP2 users who see transparent distributed file systems as a long way off. Maybe I'm overestimating the problem. I'd really appreciate it if anyone who's using IMAP2 in a large-scale heterogenous environment could share their experiences. From imap-request@cac.washington.edu Fri Sep 4 10:51:45 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19637; Fri, 4 Sep 92 10:51:45 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02533; Fri, 4 Sep 92 10:51:41 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from nexus.yorku.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA02527; Fri, 4 Sep 92 10:51:39 -0700 Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9217>; Fri, 4 Sep 1992 13:51:27 -0400 To: A Grant To: imap@cac.washington.edu Subject: Re: Draft messages etc. (was IMAP2 futures) In-Reply-To: Your message of "Fri, 04 Sep 92 13:42:25 EDT." Date: Fri, 4 Sep 1992 13:51:19 -0400 From: davecb@nexus.yorku.ca Message-Id: <92Sep4.135127edt.9217@nexus.yorku.ca> **Any** protocol get hairy when it tries to deal with any two distinct kind of things. SMTP has a serious problem because of the different time-behavior of HELO/RCPT/MAIL/VRFY versus DATA: DATA takes variable and unbounded time. The others take fixed and mutually-predictable times. As a result even simple things get arbitrarily hard easily. (My hack is to read the data part line by line, with timeouts, and make sure every message uses a **separate process**. Otherwise I can lock up all of mail waiting for a single ill-structured message) --dave From imap-request@cac.washington.edu Fri Sep 4 12:20:06 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22019; Fri, 4 Sep 92 12:20:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03396; Fri, 4 Sep 92 12:19:55 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from Ikkoku-Kan.Panda.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03390; Fri, 4 Sep 92 12:19:48 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NeXT-1.0 (From Sendmail 5.52)/UW-NDC/Panda Revision: 2.27.MRC ) id AA00915; Fri, 4 Sep 92 12:19:42 PDT Date: Fri, 4 Sep 1992 11:57:59 -0700 (PDT) From: Mark Crispin Subject: re: Draft messages etc. (was IMAP2 futures) To: A Grant Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I probably have more experience with international IMAP (and IMAP over slow speed links -- I'm on a SLIP line from my NeXT at home right now) than anyone else. I certainly don't want my drafts sent over the SLIP link to the IMAP server. I have a perfectly good local filesystem for my drafts. Nor do I even want my outgoing mail going to the IMAP server. I have a perfectly good mailer daemon on my machine that can do this pain and suffering in the background. I especially don't want my outgoing mail making two international hops when I am sending domestic mail, just because I happen to be talking to a foreign IMAP server. I'd undoubtably feel differently if my primary machine was my Mac (or a PC) instead of my NeXT. I trust the Mac filesystem much less than the NeXT, and background mailers on a Mac are still more fantasy than reality. Yet, even on the Mac, some of these principles apply. I want my outgoing mail going to a domestic machine regardless of whether or not I am talking to a foreign IMAP server. That's part of the problem -- different individuals in different environments have different needs. How do we solve the needs of one group without causing trouble to other individuals? The problem with adding an `optional submission subset' to IMAP is: . it will make IMAP hairy -- we seek to avoid this . it will create applications which *only* use the `optional' submission mechanism. This is a REAL threat -- the POP world is already filled with POP applications which DO NOT WORK unless the POP server supports the unofficial and undocumented `optional' submission mechanism of Berkeley popper. The bottom line is: `simple solutions' usually create new problems. We're not telling you "no, you can't do what you want"; we're telling you "no, your proposed solution is not the right one." We agree with all your stated needs completely. It just doesn't belong in IMAP. On the other hand, it is undoubtably related to IMAP, and belongs as part of a sister protocol to IMAP. We have already identified Mail Management as one sister protocol. I think that authenticated transport is probably going to be part of a different sister. Let's start thinking about these siblings and not allow IMAP's focus to be blurred. By the way, I think that a good deal of the problem with the 10MB MIME video message forwarding can be solved by appropriate use of external-data in MIME. It seems that people have realized that sending a 1000 person mailing list a 10MB video image, as opposed to a pointer, doesn't scale too well... ;-) So I don't think that example will come up in reality. From imap-request@cac.washington.edu Fri Sep 4 14:01:46 1992 Received: from mx1.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24763; Fri, 4 Sep 92 14:01:46 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04449; Fri, 4 Sep 92 14:01:37 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04443; Fri, 4 Sep 92 14:01:34 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <23562-0@ppsw1.cam.ac.uk>; Fri, 4 Sep 1992 22:01:27 +0100 Date: Fri, 04 Sep 92 22:01:14 BST From: A Grant To: imap@cac.washington.edu Subject: re: Draft messages etc. (was IMAP2 futures) Message-Id: In-Reply-To: > I especially don't want my outgoing mail making two international hops > when I am sending domestic mail, just because I happen to be talking to > a foreign IMAP server. Indeed not. But how can you guarantee that the client isn't configured to send its SMTP mail to a relay host in another continent? With some POP-based clients, users are encouraged to carry around a floppy disk (created at their home base) with their draft messages and other user environment, including the address of the SMTP relay host. So there is nothing to prevent redundant international hops even with the SMTP-submission method. Surely, what we should be aiming at is sufficient common sense, in both client and server, to send data from _where it is_, to _the nearest SMTP relay_, _without an intervening hop_. This must include the case where the data is at the server, i.e. when it is a draft message managed by the server. > I'd undoubtably feel differently if my primary machine was my Mac (or a PC) > instead of my NeXT. I think it's this word 'my' that's causing the trouble! Many users will not have a machine which they can call their own. Many people will use computers for little, perhaps nothing, else besides mail. We see mail as a universal resource, like telephones. It must not become merely another luxury for the computer-owning, computer-literate minority. IMAP2, by delegating function to a central server, and reducing whichever computer the user happens to have walked up to to the status of a (rather intelligent) dumb terminal, helps to achieve that goal. But, by requiring the user to know about file systems to manage their draft messages, it does not go the whole way. Please understand that I am not asking (yet) for data-at-the-client to be sent by any other means than ordinary SMTP. (Though there is scope for some interaction with the IMAP2 server, e.g. notifying it that a message in its store has been replied to.) > The problem with adding an `optional submission subset' to IMAP is: > . it will make IMAP hairy -- we seek to avoid this > . it will create applications which *only* use the `optional' submission > mechanism. This is a REAL threat -- the POP world is already filled with > POP applications which DO NOT WORK unless the POP server supports the > unofficial and undocumented `optional' submission mechanism of Berkeley > popper. If clients create unnecessary traffic by forwarding all messages via the server, they deserve to be rejected. But clients which use IMAP2 for draft message management can reasonably expect draft messages at the server to be submitted without having to retrieve them to the (perhaps intercontinental) client. Maybe I should have talked about the `optional draft message management subset' and made it clear that submission from the draft message store is an integral and necessary part of that subset. > On the other hand, it is undoubtably related to IMAP, and belongs as part of a > sister protocol to IMAP. We have already identified Mail Management as one > sister protocol. I think that authenticated transport is probably going to be > part of a different sister. Let's start thinking about these siblings and not > allow IMAP's focus to be blurred. I hope these protocols become a reality. But the closer they are to IMAP2, the better the chance of them being integrated into IMAP2 clients. Is there any chance that these protocols could use the same syntax as IMAP2, as far as possible? For example, if draft message management is a part of these protocols, it would be silly to have analogues of SEARCH and FETCH with different syntaxes. (I am dubious about the value of creating dozens of protocols. Multiplexing two protocol subsets over a single TCP connection is not fundamentally different from using two TCP connections. Relying on an optional subset of one service is not different from relying on an optional service itself. I assume that the 'Mail Management' protocol will talk to the IMAP2 server in some way, so what is gained by separation?) From imap-request@cac.washington.edu Fri Sep 25 11:30:23 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19747; Fri, 25 Sep 92 11:30:23 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17967; Fri, 25 Sep 92 11:30:12 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA17961; Fri, 25 Sep 92 11:30:01 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42587-1>; Fri, 25 Sep 1992 12:29:30 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.25.1 #25.2) id ; Fri, 25 Sep 92 11:31 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mYJYt-000cuxC; Fri, 25 Sep 92 11:34 MDT Received: by isasun-3.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Fri, 25 Sep 92 11:29 MDT Date: Fri, 25 Sep 1992 11:05:56 -0600 From: Steve Hole Subject: Some general mail message issues To: imap@cac.washington.edu, pine-info@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII None of these are really IMAP or pine issues themselves, but are related - they are general questions concerning the handling of mail messages. 1. Is there a mailing list for the discussion of the MIME message format? I am interested in discussing the howtos on including PEM key information in MIME messages, and want to make sure to ask the *right* people. 2. Who is responsible for the development of the message management protocol? Is there a mailing list for this? What is the status of this effort? This is becoming a real issue for us. The ability to get and configure services like delivery acknowledgement, read acknowledgments, and automatic reply are a high priority for many of our clients - especially when packages like Microsoft mail are able to do it. I know that the architecture is much simpler and not very good for MS Mail - but that is what the users still see. The issue needs to be addressed presently or we are going to find ourselves swamped with proprietary file system based mail systems in user workgroups. 3. Is there a list of "management services" or whatever you want to call them available. The X.400 spec has a list that seems comprehensive enough (watch me burn on that one :-) to use as a base point. Is there an equivalent for Internet mail services? 4. Is there an agreement or description of where services like automatic reply should be provided - in the MTA or the MUA? X.400 specifies the message store (which makes sense), but there is no equivalent in the Internet architecture (I think there should be). 5. There was some mention on work being done to implement lightwieght directory access protocols for getting X.500 information quickly. Could someone point me to these individuals again? This is very important to us as a mechanism for distributing public keys for PEM. ... and specifically for Mark ... 6. Is there a todo list for the c-client? What are the current priorities for the c-client? Thanks all. Cheers. -- Steve Hole Director of Research and Communications ISA Corporation mail: steve@edm.isac.ca Edmonton, Alberta, Canada phone: (403) 420-8081 From imap-request@cac.washington.edu Sun Sep 27 14:21:20 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19897; Sun, 27 Sep 92 14:21:20 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01295; Sun, 27 Sep 92 14:21:07 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA01289; Sun, 27 Sep 92 14:21:03 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Sun, 27 Sep 92 17:20:19 EDT Received: via switchmail; Sun, 27 Sep 1992 17:20:17 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Sun, 27 Sep 1992 17:19:58 -0400 (EDT) Received: via niftymail; Sun, 27 Sep 1992 17:19:50 -0400 (EDT) Date: Sun, 27 Sep 1992 17:19:49 -0400 (EDT) From: Chris Newman Subject: Re: Some general mail message issues To: Steve Hole , imap@cac.washington.edu In-Reply-To: References: Message-Id: <717628789.15646.0@nifty.andrew.cmu.edu> Steve Hole writes: >2. Who is responsible for the development of the message management >protocol? Is there a mailing list for this? What is the status of >this effort? The CMU team (John Myers and myself) have agreed to spearhead the design of this protocol. We have just finished our survey of user requirements on campus, and have a final functional requirements document for the mail system we will need here (and a draft design document). I expect us to start design of the protocol in a month or so, and you _might_ see an implementation in a year. The protocol is likely to be very similar to IMAP2bis (probably with some of the same commands for subscriptions & such). > This is becoming a real issue for us. The ability to get and >configure services like delivery acknowledgement, read >acknowledgments, and automatic reply are a high priority for many of >our clients - especially when packages like Microsoft mail are able to >do it. Delivery acknowledgements are useless (the message will bounce if not delivered). Read acknowledgements, and reply are client issues. If by "automatic reply" you mean something like the unix vacation service, we have that rated as "NICE" meaning we'll consider it if we get time (I think putting support for it in either the management protocol or the user directory protocol is reasonable). >4. Is there an agreement or description of where services like >automatic reply should be provided - in the MTA or the MUA? X.400 >specifies the message store (which makes sense), but there is no >equivalent in the Internet architecture (I think there should be). Anything that can go in the MUA should, IMHO. Keeping the MTA & mailstore simple and easy to maintain is very important. Things like vacation replies, and automatic filing of incoming mail will probably be put at the mailstore end of the MTA. >5. There was some mention on work being done to implement >lightwieght directory access protocols for getting X.500 information >quickly. Could someone point me to these individuals again? This is >very important to us as a mechanism for distributing public keys for >PEM. There's a protocol called CSO/ph which we're going to look into. If it's not good enough, we'll design & write our own. - Chris Newman Carnegie Mellon University Computing Services From imap-request@cac.washington.edu Mon Sep 28 00:34:47 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25738; Mon, 28 Sep 92 00:34:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03437; Mon, 28 Sep 92 00:34:42 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03431; Mon, 28 Sep 92 00:34:38 -0700 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA04375; Mon, 28 Sep 92 00:34:27 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01527; Mon, 28 Sep 92 00:34:21 -0700 Date: Mon, 28 Sep 1992 00:23:08 -0700 (PDT) From: Mark Crispin Subject: re: Some general mail message issues To: Steve Hole Cc: IMAP Interest List , pine-info@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Sep 1992 11:05:56 -0600, Steve Hole wrote: > 1. Is there a mailing list for the discussion of the MIME message format? The mailing list for MIME is IETF-822@dimacs.Rutgers.EDU. The issue of integration of PEM with MIME is right now being discussed within an `internal group' of MIME/PEM folks. You can check with Marshall Rose or Einar Stefferud to get a current status. Presently, PEM in MIME is not formally defined yet, so you should not be doing any implementations unless you're prepared to be one of the pioneers with arrows in their backs. I hope that Chris Newman answered questions 2-6 to your satisfaction. > 6. Is there a todo list for the c-client? Yes. It's much longer than I would like it to be. > What are the current priorities for the c-client? The current focus is to get acceptable DOS/Mac clients going and in particular to get PC Pine ready for prime time. I just finished the code to allow local file MIME parsing in DOS without requiring you to have the entire message in memory. We have a DOS local file format driver; pretty much the mail.txt format. None of us are very happy with it; I think we need more of an mh style format, while my boss wants a /usr/spool/mail format. Fortunately, c- client allows you to write as many drivers as you want. I hope to be able to get back to development (I don't consider DOS ports `development') and in particular getting IMAP2bis fully implemented in c- client Real Soon Now. From imap-request@cac.washington.edu Mon Sep 28 07:43:50 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA00738; Mon, 28 Sep 92 07:43:50 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05536; Mon, 28 Sep 92 07:43:43 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05530; Mon, 28 Sep 92 07:43:41 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03546; Mon, 28 Sep 92 07:43:35 -0700 Date: Mon, 28 Sep 1992 07:37:13 -0700 (PDT) From: Terry Gray Subject: re: Some general mail message issues To: Mark Crispin Cc: Steve Hole , IMAP Interest List , pine-info@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think we need more of an mh style format, while my boss wants a > /usr/spool/mail format. For the record: what I think I heard your boss say :) is that he wants a Bky format driver for compatibility --so that existing "foreign" mailboxes could be copied and successfully read-- in *addition* to whatever the "driver of choice" turns out to be for PCs. -teg From imap-request@cac.washington.edu Mon Sep 28 10:45:05 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04525; Mon, 28 Sep 92 10:45:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07909; Mon, 28 Sep 92 10:44:59 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07903; Mon, 28 Sep 92 10:44:45 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.65/ECO.m-$Revision: 2.16 $) id AA23537; Mon, 28 Sep 92 13:43:39 -0400 Message-Id: <9209281743.AA23537@eco.twg.com> Received: from navajo.twg.com by apache.twg.com id <18954-0@apache.twg.com>; Mon, 28 Sep 1992 10:31:32 -0700 From: "David Herron" Subject: Re: Re: Some general mail message issues To: Chris Newman Cc: Steve Hole , imap@cac.washington.edu Date: Mon, 28 Sep 92 10:34:43 PDT In-Reply-To: Your message of Sun, 27 Sep 1992 17:19:49 -0400 (EDT).<717628789.15646.0@nifty.andrew.cmu.edu> Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 43 TEXT , 4 TEXT >> This is becoming a real issue for us. The ability to get and >>configure services like delivery acknowledgement, read >>acknowledgments, and automatic reply are a high priority for many of >>our clients - especially when packages like Microsoft mail are able to >>do it. >Delivery acknowledgements are useless (the message will bounce if not >delivered). Read acknowledgements, and reply are client issues. If >by "automatic reply" you mean something like the unix vacation >service, we have that rated as "NICE" meaning we'll consider it if we >get time (I think putting support for it in either the management >protocol or the user directory protocol is reasonable). Delivery acknowledgements are not useless. It is an unfortunately true fact that not all the MTAs on the Internet are robust. This is much less true than in the past, but is still true. If you are sending messages to someone and do not have confidence that they're being delivered (and are getting no response from the recipient), you're in a very frustrating situation. You do not know why s/he isn't responding and may get mad at them when it isn't their fault. With delivery acknowledgements you know when to get mad at them ;-). Is the way these message-store-ish things are implemented an issue? In our product the UA fiddles directly with a PP-style ".mailfilter" file (our MTA is based on PP) in order to configure these kind of services. >>5. There was some mention on work being done to implement >>lightwieght directory access protocols for getting X.500 information >>quickly. Could someone point me to these individuals again? This is >>very important to us as a mechanism for distributing public keys for >>PEM. >There's a protocol called CSO/ph which we're going to look into. If >it's not good enough, we'll design & write our own. There are others, but I don't remember any RFC numbers. In our product we're using one of these protocols and it's nice to be able to pull in addresses from the directory with few hassles. But we're not satisfied with the kinds of requests we can make from the directory, this protocol is heavily geared towards finding *people* and we're wanting to build other products based on the X.500 directory. GREPing through RFC-INDEX.TXT is recommended. The only name which comes to mind is "DIXIE". <- 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 imap-request@cac.washington.edu Mon Sep 28 11:01:14 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04932; Mon, 28 Sep 92 11:01:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08159; Mon, 28 Sep 92 11:01:05 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from olive.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08153; Mon, 28 Sep 92 11:01:04 -0700 Received: by olive.cac.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.21 ) id AA11249; Mon, 28 Sep 92 10:56:25 PDT Date: Mon, 28 Sep 1992 10:47:25 -0700 (PDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: Re: Some general mail message issues To: David Herron Cc: Chris Newman , Steve Hole , imap@cac.washington.edu In-Reply-To: <9209281743.AA23537@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII There was a mailing list to discuss the delivery acknowledgements: ietf-ack@ics.uci.edu. I think it's inactive now, but things got pretty sticky when trying to make it work across all the different things connected on the "greater Internet" (BITNET, VAXMail, MCI Mail, gateways to Microsoft mail....). It seems very possible that with such a system often the mail would arrive, but it's arrival would very often not be acknowledged. At least until there was a standard that we all agreed on. Microsoft mail and such have an advantage (disadvantage as well of course) in that they're closed systems. Right now sendmail has a "Return-Receipt-To:" header that will do this, but no guarantees it will work with anything else! Laurence Lundblade 206-543-5617 lgl@cac.washington.edu Computing and Communications, University of Washington, Seattle On Mon, 28 Sep 1992, David Herron wrote: > Date: Mon, 28 Sep 92 10:34:43 PDT > From: David Herron > To: Chris Newman > Cc: Steve Hole , imap@cac.washington.edu > Subject: Re: Re: Some general mail message issues > > >> This is becoming a real issue for us. The ability to get and > >>configure services like delivery acknowledgement, read > >>acknowledgments, and automatic reply are a high priority for many of > >>our clients - especially when packages like Microsoft mail are able to > >>do it. > >Delivery acknowledgements are useless (the message will bounce if not > >delivered). Read acknowledgements, and reply are client issues. If > >by "automatic reply" you mean something like the unix vacation > >service, we have that rated as "NICE" meaning we'll consider it if we > >get time (I think putting support for it in either the management > >protocol or the user directory protocol is reasonable). > > Delivery acknowledgements are not useless. It is an unfortunately > true fact that not all the MTAs on the Internet are robust. This is > much less true than in the past, but is still true. If you are sending > messages to someone and do not have confidence that they're being > delivered (and are getting no response from the recipient), you're > in a very frustrating situation. You do not know why s/he isn't responding > and may get mad at them when it isn't their fault. With delivery > acknowledgements you know when to get mad at them ;-). > > Is the way these message-store-ish things are implemented an issue? In our > product the UA fiddles directly with a PP-style ".mailfilter" file (our > MTA is based on PP) in order to configure these kind of services. > From imap-request@cac.washington.edu Mon Sep 28 12:24:02 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06890; Mon, 28 Sep 92 12:24:02 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09315; Mon, 28 Sep 92 12:23:53 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09309; Mon, 28 Sep 92 12:23:47 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42394-2>; Mon, 28 Sep 1992 13:23:27 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.25.1 #25.2) id ; Mon, 28 Sep 92 12:01 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mZPTe-000cuxC; Mon, 28 Sep 92 12:05 MDT Received: by isasun-3.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Mon, 28 Sep 92 12:00 MDT Date: Mon, 28 Sep 1992 11:07:51 -0600 From: Steve Hole Subject: Re: Some general mail message issues To: imap@cac.washington.edu In-Reply-To: <717628789.15646.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 27 Sep 1992, Chris Newman wrote: > Steve Hole writes: > >2. Who is responsible for the development of the message management > >protocol? Is there a mailing list for this? What is the status of > >this effort? > The CMU team (John Myers and myself) have agreed to spearhead the > design of this protocol. We have just finished our survey of user > requirements on campus, and have a final functional requirements > document for the mail system we will need here (and a draft design > document). Would it be possible to have a look at this document? I would be very interested in comparing the requirements of your organization to the requirements of the business and government organizations we do work for. Also, is there a mailing list for discussing these issues - or is the IMAP list a good enough forum? Can I suggest that it would be worthwhile to create or designate a list for such discussions. > I expect us to start design of the protocol in a month or so, and you > _might_ see an implementation in a year. The protocol is likely to be > very similar to IMAP2bis (probably with some of the same commands for > subscriptions & such). Very good! This is pretty much as we expected - it should integrate nicely into the user interfaces. > Delivery acknowledgements are useless (the message will bounce if not > delivered). I used to think so. In fact they would be IF all the MTA's in the world handled bouncing mail correctly. Unfortunately, many MTA's make a habit of returning badly addressed mail to the postmaster (actually MAILER-DAEMON) at the originating site, rather than to the originating user - especially if the mail originated outside the organizational domain. The result of this is that mail often ends up in a postmaster queue that only infrequently gets checked. Now, I understand that the role of the postmaster should be monitored and managed correctly, but the reality for us is that it often is not. In some of networks, we have 50+ departmental workgroups, each with their own mail servers and assigned domain. This is a very nice solution for large hierarchical organizations, but we do find that administrative functions tend to slip. For executive class messages (Very Important Messages VIM :-), even a 15 minute delay on getting the message back if improperly addressed is enough for the executive to complain. I agree that the MTA's should deal with this correctly, and I continue to lobby for policy change within the various development groups (smail, zmail, sendmail), and do enforce it locally. The bottom line is, that delivery acknowledgement would still be beneficial for us, especially when dealing with external organizations. > Read acknowledgements, and reply are client issues. If by "automatic > reply" you mean something like the unix vacation service, we have that > rated as "NICE" meaning we'll consider it if we get time (I think > putting support for it in either the management protocol or the user > directory protocol is reasonable). I agree. > >4. Is there an agreement or description of where services like > >automatic reply should be provided - in the MTA or the MUA? X.400 > >specifies the message store (which makes sense), but there is no > >equivalent in the Internet architecture (I think there should be). > Anything that can go in the MUA should, IMHO. Keeping the MTA & > mailstore simple and easy to maintain is very important. Things like > vacation replies, and automatic filing of incoming mail will probably > be put at the mailstore end of the MTA. That is pretty much how I thought it would go. We have already done some experimentation with smail 3.x drivers to handle automatic reply, and new mail notification - it already handles forwarding. > >5. There was some mention on work being done to implement > >lightwieght directory access protocols for getting X.500 information > >quickly. Could someone point me to these individuals again? This is > >very important to us as a mechanism for distributing public keys for > >PEM. > There's a protocol called CSO/ph which we're going to look into. If > it's not good enough, we'll design & write our own. Is CSO/ph an OSI compliant protocol, or some new creation for an Internet only Directory service? I know that Andrew has its own directory service which appears to be quite serviceable - is this what you are talking about? 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 imap-request@cac.washington.edu Mon Sep 28 12:24:14 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06905; Mon, 28 Sep 92 12:24:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09333; Mon, 28 Sep 92 12:24:10 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09319; Mon, 28 Sep 92 12:24:03 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <42397-2>; Mon, 28 Sep 1992 13:23:31 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.25.1 #25.2) id ; Mon, 28 Sep 92 13:06 MDT Received: from isasun-3.edm.isac.ca by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0mZQUl-000cuxC; Mon, 28 Sep 92 13:10 MDT Received: by isasun-3.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Mon, 28 Sep 92 13:06 MDT Date: Mon, 28 Sep 1992 12:40:44 -0600 From: Steve Hole Subject: Re: Re: Some general mail message issues To: David Herron Cc: imap@cac.washington.edu In-Reply-To: <9209281743.AA23537@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 28 Sep 1992, David Herron wrote: > Is the way these message-store-ish things are implemented an issue? In our > product the UA fiddles directly with a PP-style ".mailfilter" file (our > MTA is based on PP) in order to configure these kind of services. It may be depending on how and what the scope and mandate of the "mail management protocol" is. One thing that I do not like about the current run of MTA's and MUA's is that they all depend on host based authentication and configuration. I don't think that it should be necessary for a user to have an account on the host that the message store resides on to hold configuration information for the MUA or MTA. Would it not be far better for this type of information to be held either in the message store, or (better) a distributed network service? Actually, this raises some more interesting questions. 1. What types of things will the mail management protocol manage? What will be its mandate? To me it (1) must be able to manage folders (manage the message store), and (2) configure message services like those that we have talked about. Is this correct - is there more? 2. Where will the static user configuration information reside? In some sort of directory service? -- 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 imap-request@cac.washington.edu Mon Sep 28 12:49:25 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07377; Mon, 28 Sep 92 12:49:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09591; Mon, 28 Sep 92 12:49:17 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09585; Mon, 28 Sep 92 12:49:11 -0700 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA04671; Mon, 28 Sep 92 12:48:54 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01242; Mon, 28 Sep 92 12:48:44 -0700 Date: Mon, 28 Sep 1992 12:21:48 -0700 (PDT) From: Mark Crispin Subject: Re: Re: Some general mail message issues To: David Herron Cc: Chris Newman , Steve Hole , imap@cac.washington.edu In-Reply-To: <9209281743.AA23537@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Delivery acknowledgements and read acknowledgements are, as has been exhibited, a very emotional issue. They question generates a lot of heat but very little light. Extreme views proliferate, with very little moderation in between. One such extreme view -- which I subscribe to -- is that the privacy violation of this sort of function is of greater concern than the benefits. I do not necessarily want to acknowledge certain messages, much less tell someone if and when I read it. One frightening thought is the prospect of service of legal process through e-mail. The possibility also exists of covert channels; remember, you can get more information out of an acknowledgement than just the fact that the message was received. Delivery acknowledgements aren't as serious in their violation of privacy, but they don't verify that the user read the message. A lot can happen to a message between the time that the MTA delivers it and it is displayed on a screen. There is a privacy violation question as well; it makes it more difficult for a user to ignore mail and pretend it never reached him. My personal viewpoint is that the only acceptable solution is a client-based read acknowledgement, *under the control of the user*. That is, a slightly more automated mechanism than the message with a first line saying `please acknowledge receipt immediately.' Some cookie in the message triggers this in the client, and the user is asked whether or not he wants an acknowledgement sent. Of course, what an organization does in its INTERNAL mail infrastructure is its own business, and it is reasonable for e-mail implementors to provide this facility for internal usage. External usage is another matter. As frustrating as it may be for Joe Mooch at Foobar Corporation not to know if Nancy Nebbish at Garply Industries has received his message, ultimately, it is up to Nancy (and Garply) to decide if an acknowledgement -- or a reply -- should be made, and software should not subvert this. From imap-request@cac.washington.edu Mon Sep 28 13:15:47 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08031; Mon, 28 Sep 92 13:15:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09887; Mon, 28 Sep 92 13:15:42 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA09881; Mon, 28 Sep 92 13:15:40 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Mon, 28 Sep 92 16:04:10 EDT Received: via switchmail; Mon, 28 Sep 1992 16:04:09 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 28 Sep 1992 16:03:12 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 28 Sep 1992 16:03:05 -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, 28 Sep 1992 16:03:05 -0400 (EDT) Message-Id: Date: Mon, 28 Sep 1992 16:03:05 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: CMU functional requirements document In-Reply-To: References: Beak: is Not For those interested, this is the functional requirements document that CMU has for our next-generation mail system. Some of the features listed herein are inside the domain of IMAP, some are not. ------------------------------ Andrew II Mail Functional Requirements Sep 15, 1992 * Introduction This document describes the functional requirements of the Andrew II Electronic Mail project. The purpose of the project is to provide an electronic mail system for users who use the Andrew system and any other organizational computing facility on campus that desires to use it. Our experience with the Andrew Mail System has shown a number of problems with its design, leading to problems with performance and difficulty in administration. This project will attempt to implement a replacement mail system which corrects many of these problems. The Andrew Mail System has many useful features not found in other mail systems. Some of these features are important to the user community, others are of dubious value. Determining which features of the Andrew Mail System are important and reimplementing them in the new mail system is an important part of this project. * Organization The remainder of this document contains three sections, requirements for functions to be provided to users, requirements for functions to be provided to administrators, and design constraints. Each listed feature is given a priority. Design, resource, and performance constraints will most likely prohibit implementation of all features. The priorities are: Required - The Andrew II mail system must have this feature Highly desired - The mail system should have this feature unless it would be overly expensive to implement. Nice - The mail system should have this feature if it is easy to implement. Low priority - No real effort will be put into providing this feature * User requirements It is REQUIRED that there exist at least one user client for each of the X based workstation, Unix terminal, Mac, and PC environments. For all of them to have the same or similar user interface is HIGHLY DESIRED. Subject to the constraint that they be consistent across platforms, user clients should conform to the user interface guidelines of their respective platforms. (Our users span the various platforms. Several of them move from platform to platform. Consistency across platforms will improve training.) Ability to manage folders is REQUIRED. (Many users depend on ability to classify messages). The ability to optionally store folders on local media is HIGHLY DESIRED. Some form of subscription/"master update" service is REQUIRED. The ability for the service to maintain the read/unread state for each message in a folder is HIGHLY DESIRED. (system needs to keep track of which bboards the user is interested in. "master update" service tells which of user's subscribed folders have new messages--is necessary in order to keep performance acceptable. While AMS' "quit here" line is sufficient for recording what messages in a folder a user has read, keeping read/unread state per message allows users to read the messages in a bboard in a more presentable order. For example, they could read all messages with a given subject before moving to messages with a different subject.) The ability to search within a folder by subject and/or sender is REQUIRED. The ability to do other searches would be NICE. For searches by subject, sender, etc to search the entire field (instead of truncating to a fixed number of characters) is HIGHLY DESIRED. The ability to send and receive files as enclosures is REQUIRED. Full, generalized multimedia support would be NICE. If provided, multimedia support should be done through the MIME standard. Support for local and/or remote printing of messages is REQUIRED. The system is REQUIRED to not drop mail, short of hardware failures. (Once submitted, mail must either be delivered to the recipient(s) or, if that is not possible, returned back to the sender. Losing data for frivolous reasons (network outage, resource shortages, server unavailability) is unacceptable.) Authenticated delivery of local mail is REQUIRED. This is a feature of AMDS that is expected by users. Not only does it protect against users being mislead by forged mail, it allows mail-based services like EzFax and restricted-posting bboards to work. (If mail system cannot be assured that mail claiming to be sent from a local user was in fact sent from that account, it must indicate it as such. The delivery system is allowed to lose this assurance under adverse conditions.) A directory service of users which supports "fuzzy matching" name lookups is REQUIRED. Users are used to the features of the White Pages facility of AMDS and some equivalent is necessary. Some User-settable forwarding address facility is REQUIRED. The ability for changes to take effect immediately is HIGHLY DESIRED. In order to support beta-testing and a smooth transition from AMS/AMDS, a per-user "Leap of Faith" style phase-in mechanism is REQUIRED. (Users must be able to specify that they wish to use the new mail system instead of AMS. This transition need not be reversible. At some point, this transition may be forced upon users.) The "integrated Mail and Bboards" concept is HIGHLY DESIRED. A method for notification of new mail for a user is HIGHLY DESIRED. Zephyr is the most likely notification mechanism. (Users like to know when new mail arrives.) The ability to keep copies of all outgoing messages is HIGHLY DESIRED. The ability to perform well for mail-only users is HIGHLY DESIRED. If user doesn't read bboards, they shouldn't take any performance hit imposed by the bboard system. (There is a large number of users who only use mail) The ability to do archival and/or compression of old messages is HIGHLY DESIRED. A uniform bboard addressing scheme (for example, being able to post to any bboard by addressing mail to "bb+nameofbboard") is HIGHLY DESIRED. The .MS.DirectPost facility of AMS has proven to be confusing to users. Per-user mail aliases (address books) are HIGHLY DESIRED. The user's address book should be available regardless of the location or platform being used. Support for user-created/maintained distribution lists is HIGHLY DESIRED. The ability to have restricted-sending distribution lists would be NICE. Support for a user-defined portion of the address namespace (userid+whatever) is HIGHLY DESIRED. (This is an invaluable aid to users who do automated filing of incoming mail.) Some form of automatic filing mechanism for user's mail is HIGHLY DESIRED. Duplicate delivery elimination (by examining the message-id header) is HIGHLY DESIRED. Sometimes a message from an external system is delivered twice. AMDS currently avoids delivering the excess copies. The ability to eliminate the multiple presentation of messages that have been crossposted (by tracking the message-id field) would be NICE. (When a message is crossposted, it should only be presented to the user once.) Support for threading would be NICE. (Threaded readers group messages that are replies to the same post together, allowing users to read all messages in the same conversation together) Support for "kill files" would be NICE. (Kill files allow users to specify that they want to ignore messages on a bboard with, for example, a given subject or from a specific poster. They are an aid to reading large volume bboards.) Support for subscription invitations would be NICE. (These are messages that cause the client to be prompted to subscribe to a given folder.) An equivalent to the standard Unix "vacation" facility would be NICE. (User can configure their account to inform users that send them mail that they are unavailable for a certain time.) Support for direct delivery to folders would be NICE. (One mechanism for supporting private bboards) Support for requesting a return receipt would be NICE. (A return receipt is an automatically generated message that notifies the sender of a piece of mail that the mail was successfully delivered to the recipient.) Explicit support for delivery of mail to a user's workstation is LOW PRIORITY. There are problems administrating a system which relies on components that the computing facility has no administrative control over. It is extremely difficult to make such a system reliable. Equivalents to AMDS' dir-insert, fs-members, and file-append features are LOW PRIORITY. (These features are infrequently used.) Direct support of X.400 is LOW PRIORITY. The address syntax is unwieldy and there are several technical show-stoppers, such as the fact that an X.400 Message Transport Agent is allowed to silently discard messages due to "congestion". The ability to support "votes" is LOW PRIORITY. (This is a feature of dubious value.) * Administrative requirements Enforcement of disk space quotas is REQUIRED. (Administrators need to have control over resources and be able to avoid abuse of the mail system as additional storage.) Support for global mail aliases and mailing lists is REQUIRED. (Mail aliases and published mailing lists are frequently used.) The ability to efficiently handle large, frequently read bboards is REQUIRED. (We have several such bboards.) The ability to have bboards with restricted reading is REQUIRED. (Organizations use bboards for internal discussions which they do not want to be available to outside users.) Some form of BBoard filing mechanism is REQUIRED. (This is necessary in order to have bboards.) The ability for the bboard filing mechanism to enforce restricted posting to bboards is REQUIRED. The ability for it to be general enough to handle special setups, such as advisor, is HIGHLY DESIRED. (Enforcement of restricted-posting bboards is necessary in order to support "official" and other moderated-style forums. If the filing mechanism isn't general enough to handle such setups as advisor, special-purpose programs to handle this can be written.) A mechanism to handle administration of bboards (manipulate ACLs, create, delete, etc.) is REQUIRED. The ability for parts of this administration to be distributed to outside groups is HIGHLY DESIRED. (The bboard system needs to be maintained in some manner. If this maintenance can be distributed, this reduces the load on the central maintainers and allows outside groups to be given greater flexibility within their own part of the bboard system.) The ability to distribute the bboards across servers is REQUIRED. (The client must therefore have some mechanism for finding the server(s) for a given bboard. Distribution of bboards is necessary in order to handle a large load.) The ability to distribute users across servers is REQUIRED. (This is necessary in order to handle large numbers of users) The ability to move users and bboard trees between servers (in order to load-balance) is REQUIRED. The ability to purge bboards at administratively defined rates is REQUIRED. (Old messages have to be removed at some point. The rates at which bboards are purged need to be adjustable in order to allow for variations in resource usage and importance.) Monitoring of centrally maintained resources is REQUIRED. Usage and resource monitoring of other parts of the mail system is HIGHLY DESIRED. (Administrators need to do resource planning, budget justification, detection and diagnosis of problems.) The ability to "Short Circuit" local delivery of mail, to both andrew.cmu.edu and to CMU.EDU is HIGHLY DESIRED. This is expected to increase the performance and reliability of the delivery system significantly. (For example, both Andrew and CS know how to query the CMU.EDU database directly, so they can deliver mail directly to the user's forwarding address instead of making the mail be processed by the central CMU.EDU servers) The ability to replicate bboards on multiple servers is HIGHLY DESIRED. (This would be an aid to distributing load.) Administratively settable per-address bounce messages would be NICE. (This is the ability for an administrator to specify that mail sent to a given address is to be returned with an administratively settable error message. This is a feature of AMDS that is useful for dealing with suspended accounts.) * Design constraints The mail system is REQUIRED to use a client/server architecture. (This architecture is necessary to support "mobile" users, those who access their mail from different places.) Avoiding any reliance on a shared filesystem service is REQUIRED. Experience with AMDS shows that layering on top of a shared filesystem leads to serious problems with performance and availability. We may allow users to configure their own environment to make part of their mail service rely on a shared file system. Whenever a component of the mail system needs authentication, it is REQUIRED to support Kerberos V4. (Kerberos V4 is the authentication mechanism currently used by Andrew.) The use of standardized protocols is HIGHLY DESIRED. If we need to design a new protocol, we should work to make it standardized. From imap-request@cac.washington.edu Mon Sep 28 14:59:10 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10067; Mon, 28 Sep 92 14:59:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11121; Mon, 28 Sep 92 14:59:03 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11115; Mon, 28 Sep 92 14:59:01 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA17388; Mon, 28 Sep 92 14:50:35 PDT Date: Mon, 28 Sep 1992 14:56:58 PDT From: Bill Yeager Subject: Re: Re: Some general mail message issues To: Mark Crispin Cc: David Herron , Chris Newman , Steve Hole , imap@cac.washington.edu In-Reply-To: Your message of Mon, 28 Sep 1992 12:21:48 -0700 (PDT) Message-Id: >> One such extreme view -- which I subscribe to -- is that the privacy violation of this sort of function is of greater concern than the benefits. I too agree with this point of view. Bill ------- From imap-request@cac.washington.edu Tue Sep 29 02:37:26 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19704; Tue, 29 Sep 92 02:37:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15194; Tue, 29 Sep 92 02:37:19 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15188; Tue, 29 Sep 92 02:37:17 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <00622-3@ppsw1.cam.ac.uk>; Tue, 29 Sep 1992 10:37:01 +0100 Date: Tue, 29 Sep 92 10:36:49 BST From: A Grant To: imap@cac.washington.edu Subject: Re: Re: Some general mail message issues Message-Id: In-Reply-To: > One such extreme view -- which I subscribe to -- is that the privacy > violation of this sort of function is of greater concern than the > benefits. I do not necessarily want to acknowledge certain messages, > much less tell someone if and when I read it. 'finger' is a violation of privacy. Yet the way that this has been dealt with is not to suppress the protocol, but to make running a finger daemon optional. Many people still run it though. Let's distinguish between - delivery to the user's message store, which should happen within a matter of minutes. For inter-domain (e.g. international) mail it is particularly useful to know if the mail is getting to the destination domain ok, i.e. that (say) transatlantic links aren't broken, or that gateways have been crossed successfully. (Incidentally, there is scope here for delivery reports containing information about conversions that have taken place between multimedia formats.) - read acknowledgement, which is much more vague, and relies on the MUA trying to guess when the user has read the message. Do they have to read to the end? If it's a MIME message with a multimedia components, do they have to view all components? What if, simply, it's in a language they can't read? This is a much trickier problem, and is balanced by the fact that read-acks are of less use to senders, or to postmasters at sending sites, because of the possibly long wait times involved. > One frightening thought is the prospect of service of > legal process through e-mail. Process serving requires delivery of (a hard copy of) the message into the user's own hands (possibly with the assistance of a couple of heavies), not into their 'message store'. Even with read-ack as opposed to delivery-ack, it's unlikely that legal process could be served in electronic form, since the recipient could always claim that "I hit the wrong key and deleted the message before I'd read all of it". In contrast, nobody claims that registered mail is a privacy violation. If I send a valuable package to a company, I'd like to know when it has entered their sorting office. If I send important e-mail to an employee, I might like to know when it has entered the company's mail domain. > The possibility also exists of covert channels; > remember, you can get more information out of an acknowledgement than > just the fact that the message was received. Delivery-acks (of the form "message has entered domain " doesn't have to tell you anything, such as what are valid mail addresses, or attributes of the message store such as its time zone or operating system, that you can't deduce from a fail report. Spooks don't generate fail reports, so they hardly fit into a general discussion of mail protocols. In an academic context there is no reason (other than a very slight increase in traffic) for not allowing senders to request read-ack. And in _any_ context there is no reason for not allowing them to request delivery-ack. And if I was running a mail switch, which I'm not, I would see no reason for it not to give delivery-acks to people who wanted them. Read-acks are, as you say, for the recipient to decide, but personally I'm doubtful of the motivation of someone who pretends not to have read a message. So I'd say make it part of the protocol, then leave it for system admin to disable the feature if they want, just as they disable finger daemons. Of course, delivery reports and read-acknowledgements have to be unforgeable, but that's another story! p.s. the EDI world has had some interesting thoughts about this sort of thing, and since EDI is moving towards being based on top of mail, there might be useful precedents there. In particular, the legal implications have probably been explored at great length! -- Alasdair Grant A.Grant@ucs.cam.ac.uk MVS Systems Group / Small Systems Integration Group +44 223 334447 University Computing Service, Pembroke St., Cambridge CB2 3QG, UK From imap-request@cac.washington.edu Tue Sep 29 04:28:15 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21005; Tue, 29 Sep 92 04:28:15 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15981; Tue, 29 Sep 92 04:28:11 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15975; Tue, 29 Sep 92 04:28:06 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with NIFTP (PP-6.0) as ppsw.cam.ac.uk id <02209-0@ppsw1.cam.ac.uk>; Tue, 29 Sep 1992 12:27:39 +0100 Date: Tue, 29 Sep 92 12:27:30 BST From: A Grant To: imap@cac.washington.edu Subject: Re: [CMU functional requirements document] Message-Id: In-Reply-To: Very interesting... could you say who is defining this protocol, e.g. IETF, international, or proprietary to CMU and released on an as-is basis? Although it talks about (and virtually dismisses - have you participated in X.400(92), then?) "support for X.400", it doesn't mention convergence with protocols such as P7, _or with the set of functions provided by them_, even if differently (e.g. textually rather than BER). With similar protocols, one could have a common MUA front end with back ends for ASN.1-over-OSI (a la P7), text-over-TCP (a la IMAP2) etc. As I said before, the effort these days is not in designing protocols, but in getting MUAs to work with half a dozen different GUIs, not to mention 100 different PC video cards. Look at how long it's taking to port Pine to MS-DOS. (The implication that this is due to the cussedness of the platform is meant as a compliment!) After all, _you_ may see IP mail protocols as a DARPA or Andrew thing, but I see them as a stopgap until X.400 is widely available on PCs. It would be a real bonus if the work that had gone into remote-management MUAs could transfer neatly to OSI. Could you perhaps tell us how likely this is? p.s. if you think X.400 has flaws, do something! The USA has far more influence on ISO and CCITT than the rest of the world has on the IETF. From imap-request@cac.washington.edu Tue Sep 29 12:03:08 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA28786; Tue, 29 Sep 92 12:03:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20374; Tue, 29 Sep 92 12:03:01 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20368; Tue, 29 Sep 92 12:02:58 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Tue, 29 Sep 92 15:02:50 EDT Received: via switchmail; Tue, 29 Sep 1992 15:02:47 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Tue, 29 Sep 1992 15:00:52 -0400 (EDT) Received: via niftymail; Tue, 29 Sep 1992 15:00:45 -0400 (EDT) Date: Tue, 29 Sep 1992 15:00:42 -0400 (EDT) From: Chris Newman Subject: Re: Re: Some general mail message issues To: imap@cac.washington.edu In-Reply-To: References: Message-Id: <717793242.20534.0@nifty.andrew.cmu.edu> On Mon, 28 Sep 1992, David Herron wrote: > Is the way these message-store-ish things are implemented an issue? In our > product the UA fiddles directly with a PP-style ".mailfilter" file (our > MTA is based on PP) in order to configure these kind of services. Well, this depends on how sophisticated delivery filtering you want & such. A message management protocol could simply support shipping an implementation defined "filter program" to the mailstore which could be used by zmail or whatever other filing system might be there. If you want a nice MUA interface to the filtering/etc (at least for simple tasks), the message-store-ish implementation may become an issue. Steve Hole writes: >One thing that I do not like about the current run of MTA's and MUA's is that >they all depend on host based authentication and configuration. I don't think >that it should be necessary for a user to have an account on the host that the >message store resides on to hold configuration information for the >MUA or MTA. Would it not be far better for this type of information >to be held either in the message store, or (better) a distributed >network service? The kerberos additions to IMAP2bis should give one solution to the host-based authentication problem. >1. What types of things will the mail management protocol manage? > What will be its mandate? > > To me it (1) must be able to manage folders (manage the message > store), and (2) configure message services like those that we have > talked about. Is this correct - is there more? We're thinking about the message management protocol as being a step up from where you're thinking. In a large site (like CMU), a single IMAP server will not suffice. We need multiple IMAP servers and a seemless way to find the right ones. Here's some issues that could be addressed by a message/folder management protocol: 1) Finding the IMAP server on which a folder resides. 2) Keep/update global user subscription & reading information. 3) Provide a "master update service" which can list all folders/bboards with new messages since user last read. 4) Folder management including moving folders between IMAP servers and possibly even replication of folders. 5) Anything else which doesn't fit in one of the other protocols: authentication (Kerberos), mailstore access (IMAP), mail submission (SMTP), user directory service (?) This will probably include some of the configuration options we've been discussing. >2. Where will the static user configuration information reside? In > some sort of directory service? Yes. Either in the user directory service if there is a good enough one out there, or in a directory service managed by the message management protocol. - Chris From imap-request@cac.washington.edu Wed Sep 30 06:33:20 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16312; Wed, 30 Sep 92 06:33:20 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29192; Wed, 30 Sep 92 06:33:04 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from nexus.yorku.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29186; Wed, 30 Sep 92 06:33:01 -0700 Received: from localhost ([127.0.0.1]) by nexus.yorku.ca with SMTP id <9231>; Wed, 30 Sep 1992 09:32:51 -0400 To: imap@cac.washington.edu Cc: Chris Newman Subject: Re: Some general mail message issues Date: Wed, 30 Sep 1992 09:32:38 -0400 From: davecb@nexus.yorku.ca Message-Id: <92Sep30.093251edt.9231@nexus.yorku.ca> On Mon, 28 Sep 1992, David Herron wrote: | > Is the way these message-store-ish things are implemented an issue? In our | > product the UA fiddles directly with a PP-style ".mailfilter" file (our | > MTA is based on PP) in order to configure these kind of services. In <717793242.20534.0@nifty.andrew.cmu.edu> you write: | Well, this depends on how sophisticated delivery filtering you want & | such. A message management protocol could simply support shipping an | implementation defined "filter program" to the mailstore which could | be used by zmail or whatever other filing system might be there. If | you want a nice MUA interface to the filtering/etc (at least for simple | tasks), the message-store-ish implementation may become an issue. If you expect this to fly, you'd need to at least define and register as set of well-known filters, and it would be up the the MUA and message-store people to agree on the semantics of each, plus their extension mechanism for not-well-known filters. This is easy if you're writing an ``integrated package'', but once you drop the one-world assumption and start worrying about interoperability in a hetrogenous world, it gets real complex real fast. I think this is **another** kind of a split user agent and not a message-store, at least not in the x.400 sense of message-store. A carefull analyis of what can best be done where is advised. This isn't something with a simple, elegant answer: it is trivial to tell a mta or message-store ``I've moved to xxx@yyy''. It's tricky to tell it ``filter my mail into categories a and b by forwarding a to XXX'', and its bloody hard to tell it to apply more complex rules unless both ends of the conversation agree to a fine level of deatil about what each and every word of the instuctions means. I only recommend such where both ends of the conversation are strictly controlled by the same development/specification group, and where the requirements on implementers **not** proposing to implement such a scheme are minimal. Ie, if it isn't part of the official protocol. This is a reasonable, marketable approach to adding common functionality in a non-decomposable commercial product. It isn't something I'd like to standardize until I saw some different, interworkable, implementations. --dave [Ie, I wouldn't spend budgeted time on implementing it for us, but might buy a product that promised to do it in a way that wouldn't affect our existing multi-brand, multi-protocol, multi-religion site. I can't afford to maintain one-offs.] From imap-request@cac.washington.edu Tue Oct 6 10:35:21 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA24965; Tue, 6 Oct 92 10:35:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06301; Tue, 6 Oct 92 10:34:59 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA06293; Tue, 6 Oct 92 10:34:57 -0700 Received: from msob-a-fp-dynamic.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA04842; Tue, 6 Oct 92 10:34:40 PDT Date: Tue, 6 October 1992 10:46:28 -0800 From: Adam Treister To: A Grant Subject: Re: Read Acknowledgement Cc: imap@cac.washington.edu Message-Id: In-Reply-To: Your message of Tue, 29 Sep 92 10:36:49 BST Content-Type: TEXT/plain; charset=US-ASCII I happen to be in favor of read and delivery acks, and am planning on adding request-read-ack and read-ack to Mailstrom. I can't really see what skeletons will come out of MY closets based on the time I read mail, tho I'd be interested in hypothetical cases where this would be a issue. And considering that any self-respecting hacker can probably get at the contents of my mailbox, this is a relatively minor breech of security. (IMHO) And if it is, isn't timestamping sent messages likewise invasive? I am even tempted to take a hard line approach and not allow the user to read it without acknowledging, but for now I'll put the switch in, and decide later if I'll give an interface for setting/clearing it. My question: Is there an accepted standard header that's used for this purpose, or should I create a X-Read-Acknowledge, which would effectively mean that Mailstrom users would only acknowledge mail to other Mailstrom users? Maybe RSVP is a kinder and gentler approach, whereby the reader automatically creates a reply with a timestamp and sufficient text to indicate that the message has been read, but allows the reader to append a reply (or edit the text or throw away the reply). Until the feature becomes required, it really has no teeth, as users can refuse to read the message, and go to a non-enforcing mailer to read that message, so the soft approach may be best for now. But a standard header that allowed Delivery Ack, Read Ack, or RSVP would be nice in the next 822 revision. I would assume X.400 includes this (what doesn't it include?) What variations does it have? ------------------------------ Adam Treister 415-508-9349 treister@sumex.stanford.edu From imap-request@cac.washington.edu Tue Oct 6 11:40:46 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26230; Tue, 6 Oct 92 11:40:46 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07248; Tue, 6 Oct 92 11:40:41 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07242; Tue, 6 Oct 92 11:40:40 -0700 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA07175; Tue, 6 Oct 92 11:40:34 PDT Date: Tue, 6 Oct 1992 11:41:01 PDT From: Bill Yeager Subject: Re: Read Acknowledgement To: Adam Treister Cc: A Grant , imap@cac.washington.edu In-Reply-To: Your message of Tue, 6 October 1992 10:46:28 -0800 Message-Id: > I am even tempted to take a hard line approach and not allow the user to read it without acknowledging, but for now I'll put the switch in, and decide later if I'll give an interface for setting/clearing it. Clearly a bad idea Adam. You know where hardline stands lead. Some like them and others hate them. This is really pretty moot right now though, since very little software requests such an acknowledgement. Bill ------- From imap-request@cac.washington.edu Tue Oct 6 12:01:13 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26762; Tue, 6 Oct 92 12:01:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07576; Tue, 6 Oct 92 12:01:09 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07570; Tue, 6 Oct 92 12:01:05 -0700 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA02210; Tue, 6 Oct 92 12:00:48 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00644; Tue, 6 Oct 92 12:00:41 -0700 Date: Tue, 6 Oct 1992 11:43:53 -0700 (PDT) From: Mark Crispin Subject: Re: Read Acknowledgement To: Bill Yeager Cc: Adam Treister , A Grant , IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Oct 1992 11:41:01 PDT, Bill Yeager wrote: > it without acknowledging, but for now I'll put the switch in, and decide > later if I'll give an interface for setting/clearing it. > > Clearly a bad idea Adam. You know where hardline stands lead. Some like them > and others hate them. This is wise advice, given that there are a number of users (including me), who detest the idea of software presuming to decide for me whether or not to send a message. It may be alright to ask the user whether to send an acknowledgement. I wish to don my moderator hat for a moment. The question of acknowledgements is really not an appropriate issue to be discussed in the IMAP mailing list. It is orthogonal to the IMAP protocol. I suggest the IETF-REMMAIL@UMICH.EDU mailing list, or the comp.mail.misc newsgroup. From imap-request@cac.washington.edu Mon Oct 19 12:22:33 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20465; Mon, 19 Oct 92 12:22:33 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21189; Mon, 19 Oct 92 12:22:15 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21183; Mon, 19 Oct 92 12:22:12 -0700 Return-Path: Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA02449; Mon, 19 Oct 92 12:21:47 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01458; Mon, 19 Oct 92 12:21:42 -0700 Date: Mon, 19 Oct 1992 12:09:25 -0700 (PDT) From: Mark Crispin Subject: international character set support in IMAP2bis To: IMAP Interest List Cc: Nojima Hisao Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have been thinking about the issue of supporting international character sets in IMAP2bis better than they presently are. Although IMAP2bis goes a great way towards internationalization with its MIME support, there are some gaps, most notably SEARCH. I believe that modifying SEARCH is generally a show-stopper for IMAP2bis; it's too complex an issue to address at this go-round. It'll open a whole can of worms including pent-up demands for new features and will prevent the rest of IMAP2bis from being finalized for a long time. However, I am considering one possibility to assist our foreign friends. That is, to define that search strings are now in the proposed format used to express multinational characters in message headers. I forget the exact RFC number, but it came out as a companion to MIME. Since message headers have to be 7-bit US-ASCII forever because of the needs of header parsers, a means was invented by the MIME group to encode international characters in strings such as personal names. I believe that if we define that the search strings use this format for specifying multinational characters, it will not introduce an incompatability. The worst thing that would happen is that you would get a false negative when searching for texts in the message body if the IMAP server does not support that character set. You would get a true positive with a current IMAP server for international characters in the header! Due to the characteristics of the strings in question, I feel that a false positive is unlikely and certainly much less likely than ignoring 8th bits or ISO-2022 shifts. I would like to hear, particularly from my friends at NTT, if this would be helpful. I think it is better than the current choices: no multinational search, or coercion the string into 7-bit ASCII and lots of false positives. Implementation of this proposal is another matter! ;-) -- Mark -- From imap-request@cac.washington.edu Mon Oct 19 19:16:26 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA28804; Mon, 19 Oct 92 19:16:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25994; Mon, 19 Oct 92 19:13:05 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25988; Mon, 19 Oct 92 19:13:04 -0700 Received: by po5.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Mon, 19 Oct 92 22:12:57 EDT Received: via switchmail; Mon, 19 Oct 1992 22:12:54 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 19 Oct 1992 22:11:30 -0400 (EDT) Received: via niftymail; Mon, 19 Oct 1992 22:11:21 -0400 (EDT) Date: Mon, 19 Oct 1992 22:11:19 -0400 (EDT) From: Chris Newman Subject: Disconnected Operation To: imap@cac.washington.edu Message-Id: <719547079.404.0@nifty.andrew.cmu.edu> The folks on the ietf-remmail seem quite interested in this issue, and I gather it's on the future-wish-list for CMU & UW... The real question is how to "synchronize" which bringing the client state up to the server state (via expunges, flag changes, and new messages) and sending client state to the server (flag changes and new messages). Here's a few ways this could be done: * It should be doable with the current version of IMAP by fetching the internal-date and flags for all the messages in a folder, and comparing the server internal-dates with the client ones (at least assuming that internal-dates are unique per-message). This requires no change to the server, but is a bit client/network intensive. * adding a unique-id and last-flag-change-timestamp for each message along with command(s) to update flags by unique-id and get the flag changes since a given timestamp, would make things much easier but add a bit of expense to the server and clutter to the protocol. * adding a log of folder changes indexed by timestamp would allow a one-command synchronize, but add quite a bit of storage and complexity to the server. Is any of this feasable, or should disconnected operation be left to another protocol? - Chris Newman Computing Services, Carnegie Mellon University From imap-request@cac.washington.edu Mon Oct 19 20:12:47 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29533; Mon, 19 Oct 92 20:12:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26358; Mon, 19 Oct 92 20:12:43 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from cyklop.nada.kth.se by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA26352; Mon, 19 Oct 92 20:12:40 -0700 Received: from localhost.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA02940; Tue, 20 Oct 92 04:06:00 +0100 Message-Id: <9210200306.AA02940@nada.kth.se> To: Mark Crispin Cc: IMAP Interest List , Nojima Hisao Subject: Re: international character set support in IMAP2bis In-Reply-To: from "Mark Crispin " "Mon, 19 Oct 1992 12:09:25 -0700 (PDT) " Date: Tue, 20 Oct 92 04:05:58 +0100 From: Peter Svanberg Quoting: Mark Crispin > > However, I am considering one possibility to assist our foreign > friends. That is, to define that search strings are now in the > proposed format used to express multinational characters in message > headers. I forget the exact RFC number RFC 1342, Representation of Non-ASCII Text in Internet Message Headers > I believe that if we define that the search strings use this format > for specifying multinational characters, it will not introduce an > incompatability. The worst thing that would happen is that you > would get a false negative when searching for texts in the message > body if the IMAP server does not support that character set. Will it be possible for the client to find out if a certain character set is supported, or in any other way know when there is a risk of false negatives? > I would like to hear, particularly from my friends at NTT, if this > would be helpful. I think it is better than the current choices: no > multinational search, or coercion the string into 7-bit ASCII and > lots of false positives. (I'm not from Japan, I'm from Sweden.) Yes, it would help us, if this is what you meant: 1) The user types his search string as any other text, i.e. with eightbit characters. 2) The client encodes the user string into RFC1342 format and sends it to the server. 3) The server decodes it and compares it with (a decoded version of) the specified part of each letter. --- 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 46 S-100 44 Stockholm, SWEDEN Fax: +46 8 790 09 30 From imap-request@cac.washington.edu Tue Oct 20 11:38:22 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13720; Tue, 20 Oct 92 11:38:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03109; Tue, 20 Oct 92 11:38:06 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from Sun.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03103; Tue, 20 Oct 92 11:38:05 -0700 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA11485; Tue, 20 Oct 92 11:37:59 PDT Received: from lassie.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04210; Tue, 20 Oct 92 11:38:00 PDT Received: from localhost by lassie.Eng.Sun.COM (4.1/SMI-4.1) id AA20081; Tue, 20 Oct 92 11:37:55 PDT Message-Id: <9210201837.AA20081@lassie.Eng.Sun.COM> To: Chris Newman Cc: imap@cac.washington.edu, karl.jacob@Eng.Sun.COM Subject: Re: Disconnected Operation In-Reply-To: Your message of "Mon, 19 Oct 92 22:11:19 EDT." <719547079.404.0@nifty.andrew.cmu.edu> Date: Tue, 20 Oct 92 11:37:55 PDT From: Don Jackson >> The folks on the ietf-remmail seem quite interested in this issue, and I >> gather it's on the future-wish-list for CMU & UW... Karl Jacob and I have been thinking about disconnected operation here at Sun also. Our model is that some users are going to want to use a variety of clients to read, process, and compose their email. Users may wish to use one client on the workstation/pc in their office at work, and another client on their notebook/notepad/PDA portable computer. Futhermore, there will be a variety of connection mechanisms: Direct LAN connection Dialup (PPP over V32bis) Two way wide area packet radio (like Mobitex and ARDIS) and sometimes clients will be disconnected. Disconnected clients should be able to read messages they have previously downloaded, delete, file, respond, and compose new messages. Upon reconnection, synchronization needs to happen. For this model, there are two important new issues: Disconnected operation, with multiple clients a possibility. Very low speed/high latency connection between client and server (imagine 2400 baud, packets, with seconds of latency, with every byte you send/recieve costing you $0.0002) >> The real question is how to "synchronize" which bringing the client >> state up to the server state (via expunges, flag changes, and new >> messages) and sending client state to the server (flag changes and new >> messages). Here's a few ways this could be done: >> >> * It should be doable with the current version of IMAP by fetching the >> internal-date and flags for all the messages in a folder, and >> comparing the server internal-dates with the client ones (at least >> assuming that internal-dates are unique per-message). This requires >> no change to the server, but is a bit client/network intensive. I'm more concerned with network traffic than client complexity. >> * adding a unique-id and last-flag-change-timestamp for each message >> along with command(s) to update flags by unique-id and get the flag >> changes since a given timestamp, would make things much easier but add >> a bit of expense to the server and clutter to the protocol. This seems like the minimum support for disconnected operation. If each message had a unique-id, would it still be necessary to refer to message numbers? I guess for compatibility you'd still want to use message numbers.... >> * adding a log of folder changes indexed by timestamp would allow a >> one-command synchronize, but add quite a bit of storage and complexity >> to the server. This is even beter. >> Is any of this feasable, or should disconnected operation be left to >> another protocol? How independent of mail access is disconnected operation? My initial position is that I'd like to see them combined. From imap-request@cac.washington.edu Thu Oct 22 20:42:22 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA13682; Thu, 22 Oct 92 20:42:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04984; Thu, 22 Oct 92 20:42:05 -0700 Errors-To: imap-request@cac.washington.edu Sender: imap-request@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04978; Thu, 22 Oct 92 20:42:01 -0700 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA07867; Thu, 22 Oct 92 20:41:57 -0700 Date: Thu, 22 Oct 1992 20:41:16 -0700 (PDT) From: Mark Crispin Subject: imap mailing list archives now available To: IMAP 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/imap_archive This is a copy of the actual archive, updated daily at 1AM. From imap-request@cac.washington.edu Mon Oct 26 21:40:41 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29111; Mon, 26 Oct 92 21:40:41 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA11932; Mon, 26 Oct 92 21:40:30 -0800 Errors-To: imap-request@cac.washington.edu Sender: imap-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 owner-imap@cac.washington.edu Thu Dec 3 17:25:34 1992 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA12931; Thu, 3 Dec 92 17:25:34 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07941; Thu, 3 Dec 92 17:23:29 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07934; Thu, 3 Dec 92 17:23:28 -0800 Return-Path: Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 1.60.MRC ) id AA03026; Thu, 3 Dec 92 17:23:20 -0800 Date: Thu, 3 Dec 1992 17:18:03 -0800 (PST) From: Mark Crispin Subject: IMAP2bis change To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I propose a minor modification of the PARTIAL command (which I am implementing now), to remove the option of sending a sequence and replace it with a number. I do not think that a partial fetch of more than one message is a useful thing, given that it is aimed for small machines that can't slurp up all that much data. I'm implementing it now in imapd, and it's more work for me if I have to accept a sequence. I really don't want to do it if it's as useless as I think it is. If you have any objections to this change in definition, please let me know. If I don't hear any definitions, it will take effect immediately (I'm writing the code now). This is what PARTIAL will look like after this change. tag PARTIAL msgno RFC822 start_byte byte_count tag PARTIAL msgno RFC822.HEADER start_byte byte_count tag PARTIAL msgno RFC822.TEXT start_byte byte_count tag PARTIAL msgno BODY[section] start_byte byte_count From owner-imap@cac.washington.edu Mon Jan 25 13:23:54 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19436; Mon, 25 Jan 93 13:23:54 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21874; Mon, 25 Jan 93 13:23:34 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from brazos.is.rice.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21868; Mon, 25 Jan 93 13:23:32 -0800 Received: by brazos.is.rice.edu (AA06270); Mon, 25 Jan 93 15:23:31 CST From: corywest@is.rice.edu (Cory Richard West) Message-Id: <9301252123.AA06270@brazos.is.rice.edu> Subject: Typo problem in the latest IMAP-2.3 in news.c To: imap@cac.washington.edu Date: Mon, 25 Jan 93 15:23:31 CST X-Mailer: ELM [version 2.3 PL11] Hi Mark, There are a few little problems in the version of IMAP-2.3 that I grabbed from cac.washington.edu today at around 14:40. First (in pseudo-diff format), there's an incorrect declaration that will cause Sun compilers to choke: ---news.c:line 516--- -> int news_numsort (struct direct **d1,struct direct **d2) struct direct **d1; struct direct **d2; { return (atoi ((*d1)->d_name) - atoi ((*d2)->d_name)); } --------------------- -> int news_numsort (d1,d2) struct direct **d1; struct direct **d2; { return (atoi ((*d1)->d_name) - atoi ((*d2)->d_name)); } --------------------- Secondly, in nntpclient.c, I think you wanted a different function than you said, but I can only guess. At any rate, the Sun libraries don't have a strcpyn and it looks like you want strncpy. ---nntpclient.c:line 627--- fs_resize ((void **) &LOCAL->buf,LOCAL->buflen += (MAXMESSAGESIZE + 1)); /* copy the text */ -> strcpyn (LOCAL->buf + bufpos,t,i); bufpos += i; /* set new buffer position */ LOCAL->buf[bufpos++] = '¥015'; LOCAL->buf[bufpos++] = '¥012'; --------------------------- fs_resize ((void **) &LOCAL->buf,LOCAL->buflen += (MAXMESSAGESIZE + 1)); /* copy the text */ -> strncpy (LOCAL->buf + bufpos,t,i); bufpos += i; /* set new buffer position */ LOCAL->buf[bufpos++] = '¥015'; LOCAL->buf[bufpos++] = '¥012'; --------------------------- And... ---nntpclient.c:line 1027--- h[4] == ':' && h[5] == ' ') || (s1 = strstr (h,"¥nPath: "))) && (s = strchr (s1 += 6,'¥n'))) { -> strcpyn (tmp+5,s1,i = s - s1); tmp[5 + i] = ' '; s = tmp + 6 + i; /* where to write date */ ---------------------------- h[4] == ':' && h[5] == ' ') || (s1 = strstr (h,"¥nPath: "))) && (s = strchr (s1 += 6,'¥n'))) { -> strncpy (tmp+5,s1,i = s - s1); tmp[5 + i] = ' '; s = tmp + 6 + i; /* where to write date */ ---------------------------- Thanks for all the work you've done on IMAP and hopefully I'll get to meet you in the early part of March when I'm up visiting :-). Cory West, corywest@rice.edu From owner-imap@cac.washington.edu Mon Jan 25 14:35:20 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22400; Mon, 25 Jan 93 14:35:20 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22396; Mon, 25 Jan 93 14:35:09 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from brazos.is.rice.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22390; Mon, 25 Jan 93 14:35:06 -0800 Received: by brazos.is.rice.edu (AA06703); Mon, 25 Jan 93 16:35:05 CST From: corywest@is.rice.edu (Cory Richard West) Message-Id: <9301252235.AA06703@brazos.is.rice.edu> Subject: Unhappiness and production level software... To: imap@cac.washington.edu Date: Mon, 25 Jan 93 16:35:04 CST X-Mailer: ELM [version 2.3 PL11] Hello again. I am having problems with IMAP-2.3 as found on cac.washington.edu (imap-2.3.tar.Z). Mainly, IMAP seems to be brain dead in that it can't find any mail in mailboxes that are obviously not empty. My gripe is this: I grabbed this distribution about 3 weeks ago (same file name and same location, but obviously significantly different source) and did extensive testing with it on our test network to make sure the software would happily coexist with other things on our production network. After we decided that the server was safe, I started the installation on our production network. After fixing some typos in the new source, I got the server to happily compile and installed it. After about an hour of utter confusion, I have come to the conclusion that the server functions not at all. At least it doesn't seem to be able to find any mail in mailboxes. I've tried to access things through MailStrom and mtest to help isolate the problem and have some up with nothing. Now, I'm not complaining about the software so much as I am upset about the lack of a notification for the version change. I would think that if significant changes were being made to the source, one would test these changes and update the distribution number or something. Anyway, let me know if I can be of further help in the diagnosing of the problem. I'll be removing IMAP from our production server and backing down to an older version, so the bad code won't be around here for long. Sincerely, Cory West Network Programmer Rice University From owner-imap@cac.washington.edu Mon Jan 25 15:36:29 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25204; Mon, 25 Jan 93 15:36:29 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16573; Mon, 25 Jan 93 15:36:13 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16567; Mon, 25 Jan 93 15:36:10 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA09869; Mon, 25 Jan 93 15:36:05 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00402; Mon, 25 Jan 93 15:35:42 -0800 Date: Mon, 25 Jan 1993 15:30:50 -0800 (PST) From: Mark Crispin Subject: re: Typo problem in the latest IMAP-2.3 in news.c To: Cory Richard West Cc: IMAP Interest List In-Reply-To: <9301252110.AA06181@brazos.is.rice.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have fixed the declaration problem in news.c -- it is caused by a deficiency in the unansi script and must be edited by hand every time a new non-ANSI news.c is created. I have also fixed the bogus call to strcpyn() in nntpclient.c. Unfortunately, the NeXT lets you make this misspelling. It isn't the first time this has bit me. From owner-imap@cac.washington.edu Mon Jan 25 15:41:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25337; Mon, 25 Jan 93 15:41:48 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22900; Mon, 25 Jan 93 15:41:42 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from sti.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22894; Mon, 25 Jan 93 15:41:28 -0800 Received: by sti.com (4.1/SMI-4.1) id AA29340; Mon, 25 Jan 93 15:39:44 PST From: westes@sti.com (Will Estes) Message-Id: <9301252339.AA29340@sti.com> Subject: Want IMAP Demo To: imap@cac.washington.edu Date: Mon, 25 Jan 93 15:39:44 PST Reply-To: westes@netcom.com (Will Estes) X-Mailer: ELM [version 2.3 PL0] Is there anyone out there with a demo IMAP account that I could use. I have tried both: {cac.washington.edu}inbox {demo.cac.washington.edu}inbox from the pine G)o to folder option, and in both cases pine just hangs indefinitely. If someone has a demo account set up I would appreciate getting access to it for a day or two. -- Thanks, Will Estes Internet: westes@netcom.com U.S. Computer 1601 S. Saratoga-Sunnyvale Rd., Suite 100-A Cupertino, CA 95014 From owner-imap@cac.washington.edu Mon Jan 25 15:59:44 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25722; Mon, 25 Jan 93 15:59:44 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16814; Mon, 25 Jan 93 15:59:38 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA16808; Mon, 25 Jan 93 15:59:36 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA09882; Mon, 25 Jan 93 15:59:29 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA00468; Mon, 25 Jan 93 15:59:09 -0800 Date: Mon, 25 Jan 1993 15:36:08 -0800 (PST) From: Mark Crispin Subject: re: Unhappiness and production level software... To: Cory Richard West Cc: IMAP Interest List In-Reply-To: <9301252235.AA06703@brazos.is.rice.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cory - I am sorry for the difficulties you have encountered in the IMAP toolkit distribution. Let me explain what the purpose and function of the IMAP toolkit distribution is. The IMAP toolkit distribution is separate from the Pine distribution for a very good reason. People who wish to run IMAP in a production setting are *STRONGLY* urged to use the IMAP software that is bundled with Pine. The Pine-bundled IMAP software has been thoroughly tested and frozen for a significant period of time prior to release. The IMAP distribution, on the other hand, is intended to give a snapshot of my development sources, as a benefit to IMAP software developers who need the very latest software and are willing to risk the possibility of bugs. I update the IMAP distribution fairly quickly after changing my sources; shortly after it's been shown to compile on my NeXT and seems to run. Usually, it's good working code, but it has NOT been exhaustively tested. From time to time, I freeze the IMAP distribution at a stable point and start a new one. 2.2 is the last frozen version of the IMAP distribution; 2.3 is the current version and is still under evolution. 2.3 will probably freeze when the new NNTP client code ports to DOS. Please accept my profuse apologies for the confusion. Again, I urge all non-developers to use the IMAP software bundled with Pine for production use, or, at the least, use the version immediately preceeding the highest version. In any case, prudence would suggest not running code which you had to edit in order to successfully compile it! As far as the problems with accessing new mail that you report, I am running that code now on my NeXT, and I have not encountered any such problems. There has been no changes at all to any of the UNIX mailbox drivers. The only changes since the beginning of the year have been to 1) fix memory leaks in the news driver and in the default cache manager 2) fix an obscure crash in BASE64 decoding 3) teach mail_parse_date() about dates of the form ``dd mmm yy'' 4) add an NNTP client driver None of these should have affected imapd in any way. If you can give me any further information about the problem I will research it and come up with a solution. -- Mark -- From owner-imap@cac.washington.edu Tue Jan 26 00:40:06 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA05466; Tue, 26 Jan 93 00:40:06 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19534; Tue, 26 Jan 93 00:39:59 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA19528; Tue, 26 Jan 93 00:39:58 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA10863; Tue, 26 Jan 93 00:39:56 -0800 Date: Tue, 26 Jan 1993 00:35:49 -0800 (PST) From: Mark Crispin Subject: IMAP toolkit distribution To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, it turns out that the report of operational problems in the latest version of the IMAP was a false alarm. The problems were caused by an account configuration error at the site. However, a good point was made about clarifying that the IMAP toolkit is for developers and that the IMAP software contained in the Pine kit should be used for production use. I have created a mail/imap.tar.WARNING file to explains this. Suggestions for any other documents are welcome. -- Mark -- From owner-imap@cac.washington.edu Tue Jan 26 20:24:26 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA00995; Tue, 26 Jan 93 20:24:26 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA28673; Tue, 26 Jan 93 20:24:16 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA28667; Tue, 26 Jan 93 20:24:15 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA08172; Tue, 26 Jan 93 20:24:10 -0800 Date: Tue, 26 Jan 1993 20:14:56 -0800 (PST) From: Terry Gray Subject: Re: Want IMAP Demo To: Will Estes Cc: imap@cac.washington.edu In-Reply-To: <9301252339.AA29340@sti.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Will, Let me look into this and get back to you. -teg On Mon, 25 Jan 1993, Will Estes wrote: > Is there anyone out there with a demo IMAP account that I could use. > I have tried both: > {cac.washington.edu}inbox > {demo.cac.washington.edu}inbox > from the pine G)o to folder option, and in both cases pine just hangs > indefinitely. If someone has a demo account set up I would appreciate > getting access to it for a day or two. > > -- > Thanks, > Will Estes Internet: westes@netcom.com > U.S. Computer 1601 S. Saratoga-Sunnyvale Rd., Suite 100-A > Cupertino, CA 95014 From owner-imap@cac.washington.edu Mon Mar 1 12:52:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA00482; Mon, 1 Mar 93 12:52:40 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20773; Mon, 1 Mar 93 12:52:21 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from donald.uoregon.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA20767; Mon, 1 Mar 93 12:52:19 -0800 Received: from [128.223.32.240] (rhaller.cc.uoregon.edu) by OREGON.UOREGON.EDU (PMDF #3475 ) id <01GVAM714PA88WX7DL@OREGON.UOREGON.EDU>; Mon, 1 Mar 1993 12:52:14 PST Date: 01 Mar 1993 12:52:14 -0800 From: rhaller@OREGON.UOREGON.EDU (Rich Haller) Subject: imap use for student accounts To: imap@cac.washington.edu Message-Id: <01GVAM71MX5E8WX7DL@OREGON.UOREGON.EDU> X-Envelope-To: imap@cac.washington.edu Content-Transfer-Encoding: 7BIT X-Sender: rhaller@oregon-mailhost.uoregon.edu We are looking into eventually providing email accounts for all students. I would appreciate feedback from people at sites who are currently providing student email mailboxes via imap. Please include the client software you are using (e.g., mailstrom, pcpine, pine, etc.) and the server platform. Other means we are looking at are POP3 and ccmail. Comments on these are also welcome. If there is an appropriate FAQ or archive, please point me at it. I am new to this list. Thanking you in advance. From owner-imap@cac.washington.edu Mon Mar 1 14:24:59 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03049; Mon, 1 Mar 93 14:24:59 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21647; Mon, 1 Mar 93 14:24:51 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA21641; Mon, 1 Mar 93 14:24:49 -0800 Received: from (KSL-Mac-78.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA07986; Mon, 1 Mar 93 14:24:40 PST Date: Mon, 1 Mar 1993 14:30:40 PST From: Bill Yeager Subject: Re: imap use for student accounts To: Rich Haller Cc: imap@cac.washington.edu In-Reply-To: Your message of 01 Mar 1993 12:52:14 -0800 Message-Id: Rich, We use imap for everyone's mail access in our Laboratory. This includes faculty, staff and students. Our primary clients are MacMS, ximap, MailStrom, YesWay, and MailManager. YesWay is a commonlisp client. Our laboratory is the Knowledge System Laboratory. IMAP, MacMS, ximap, YesWay, and MailStrom are all products of our systems staff's, the Symbolic Systems Resource Group, efforts beginning around 1987 when Mark Crispin was a member of our staff, and led the effort to create IMAP. We have also introduced IMAP and its associated clients to other departments at Stanford, e.g., Lane Medical School Library Staff, the Department of Biochemistry, the Stanford Medical Group (Clincal Medicine), the Department of Medicine, and the Department of Neworking and Communication Systems. Our user's are extremely happy with this distributed mail environment, and we are working to create more advanced clients. Bill ------- From owner-imap@cac.washington.edu Mon Mar 1 14:25:58 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03083; Mon, 1 Mar 93 14:25:58 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22874; Mon, 1 Mar 93 14:25:46 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22868; Mon, 1 Mar 93 14:25:45 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA01438; Mon, 1 Mar 93 14:25:38 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA02246; Mon, 1 Mar 93 14:25:32 -0800 Date: Mon, 1 Mar 1993 14:15:55 -0800 (PST) From: Mark Crispin Subject: re: imap use for student accounts To: Rich Haller Cc: IMAP Interest List In-Reply-To: <01GVAM71MX5E8WX7DL@OREGON.UOREGON.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Rich - The choice between IMAP and POP basically boils down to what you want to do. If you want an environment where: 1) the server is merely a mail drop, the client will pick up and delete messages from the server. 2) long-term storage of mail is on the client. 3) the user only uses a single client (since the mail is stored there). then POP is probably alright for your needs. IMAP gives you much more flexibility. It can be used in the POP model, but it can also be used in a model in which all mail is stored remotely and the client manipulates mail on the server. This makes it possible to use mailboxes that are far larger than the available resources on the client, and also makes it possible to use multiple clients. Or, using c-client software you can have a hybrid model, with some mail on the server and some on the client. Also, IMAP provides a search and RFC-822 parsing engine on the server, so the client does not have to do these if it doesn't want to. I routinely monitor multiple mailboxes from my workstation at home and the office, with complete transparency (I have more personal mail going to my machine at home). I also use MailManager (NeXT), Pine, MS, and Mailstrom fairly regularly, depending upon which machine I am sitting in front at the time. None of these programs in any way affects the usability of mail with any other. The bottom line: the choice is between (extreme) simplicity and flexibility. IMAP can do what POP does, at the cost of somewhat more complex software that implements all the stuff you don't use. If you do decide to go the POP route, the IMAP toolkit includes a POP server that some people consider a lot easier to work with than the standard POP servers floating around the net. I would recommend against cc:Mail under any circumstances. Read the USENET messages on comp.mail.misc about problems with cc:Mail. -- Mark -- From owner-imap@cac.washington.edu Tue Mar 9 09:09:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03085; Tue, 9 Mar 93 09:09:48 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA00178; Tue, 9 Mar 93 09:09:27 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uvaarpa.Virginia.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA00172; Tue, 9 Mar 93 09:09:24 -0800 Received: from elvis.med.virginia.edu by uvaarpa.virginia.edu id aa01051; 9 Mar 93 12:09 EST Received: by elvis.med.Virginia.EDU (5.65c/1.34) id AA12702; Tue, 9 Mar 1993 12:09:21 -0500 Date: Tue, 9 Mar 1993 12:09:21 -0500 From: "Steven D. Majewski" Message-Id: <199303091709.AA12702@elvis.med.Virginia.EDU> X-Useless-Header-Line: This is an example. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: Mark Crispin Subject: re: IMAP and POP Cc: pine-info@cac.washington.edu, imap@cac.washington.edu On Mar 9, 7:53, Mark Crispin wrote: > Subject: re: IMAP and POP > Cc: pine-info@cac.washington.edu > Message-Id: > > No, there is no requirement to run ipop2d or ipop3d, unless of course you want > to use their POP -> IMAP conversion services. > > -- End of excerpt from Mark Crispin What exactly is the POP -> IMAP conversion service ? I had popper installed for pop before I installed the imap server, so I haven't used the ipop* features. ( Ok, I suppose I should Find and Read the FM, but I figured as long as your on the subject already ... ) - Steve Majewski From owner-imap@cac.washington.edu Tue Mar 9 09:16:57 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA03423; Tue, 9 Mar 93 09:16:57 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22618; Tue, 9 Mar 93 09:16:40 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA22612; Tue, 9 Mar 93 09:16:38 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA04908; Tue, 9 Mar 93 09:16:33 -0800 Date: Tue, 9 Mar 1993 09:13:45 -0800 (PST) From: Mark Crispin Subject: re: IMAP and POP To: "Steven D. Majewski" Cc: pine-info@cac.washington.edu, imap@cac.washington.edu In-Reply-To: <199303091709.AA12702@elvis.med.Virginia.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 9 Mar 1993 12:09:21 -0500, Steven D. Majewski wrote: > What exactly is the POP -> IMAP conversion service ? > I had popper installed for pop before I installed the imap server, > so I haven't used the ipop* features. In both ipop2d and ipop3d, you can do a POP login with a user name of the form host:user which will connect you to that host's IMAP server. That is, if I connect to POP server foo and log in as bar:mrc with my password on bar, I will be reading my IMAP mailbox on bar using POP. From owner-imap@cac.washington.edu Fri Mar 19 01:19:48 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA14300; Fri, 19 Mar 93 01:19:48 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA25500; Fri, 19 Mar 93 01:19:36 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Mar 21 13:06:22 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11355; Sun, 21 Mar 93 13:06:22 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10206; Sun, 21 Mar 93 13:05:53 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA10200; Sun, 21 Mar 93 13:05:51 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA02602; Sun, 21 Mar 93 13:05:35 -0800 Date: Sun, 21 Mar 1993 13:02:08 -0800 (PST) From: Mark Crispin Subject: re: MADMAN (Mail and Directory Management) BOF at IETF To: Steve Kille , ietf-madman@innosoft.com Cc: IMAP Interest List In-Reply-To: <3232.732735150@isode.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Steve - I will not be attending the Columbus IETF, but I think there would be considerable interest in the MADMAN effort within the IMAP community. Is it possible to extend this effort to encompass the management issues behind IMAP (and perhaps POP) as well? -- Mark -- On Sun, 21 Mar 1993 17:32:30 +0000, Steve Kille wrote: > At the last IETF, there was a meeting of a SAM (SNMP Application > Management) BOF, which proposed the formation of the MADMAN WG. This > WG has not yet been formed, primarily due to my slowness. This > group will meet as a BOF in Columbus, and I attach the proposed > agenda and the draft charter which is still under discussion with the > IESG. > > The list has been established, and minutes of the SAM BOF are in the > archive. > > You are all very welcome to attend the BOF meeting. > > > > Steve Kille > > ------------------------- > > Agenda for the MADMAN BOF > > Monday 29th March 7:30-10:00 > > 7:30 Introduction > 7:35 Minutes of SAM BOF > 7:40 Review of Charter and Milestones > 8:00 Review "Network Services Monitoring MIB" > 8:30 Review "Directory Monitoring MIB" > 9:00 Review "Mail Monitoring MIB" > 10:00 Adjourn to Bar > > > ------------------------- > > MADMAN (Mail and Directory Managment) > > Charter > > Chair: > > Steve Kille, S.Kille@isode.com > > Network Management Area Director(s) > TBD > > Mailing Lists: > General Discussion: ietf-madman@innosoft.com > To Subscribe: ietf-madman-request@innosoft.com > You can also send a message containing a line of the form: > > subscribe ietf-madman "Ned Freed" > > to mailserv@innosoft.com and your address will be added to the list > automatically. > > > Archive: The list archives are produced automatically and can be > obtained via anonymous FTP from innosoft.com in the [.IETF-MADMAN] > directory. > > Description of Working Group > > To define a MIB and framework to enable basic monitoring of > TCP/IP and OSI applications using SNMP. This should be a simple > specification, with the focus on monitoring for problem > conditions and not general purpose management. > > > > Tasks and Issues > > To define a basic MIB that > should be extensible to produce application specific MIBs. Two > such MIBs will be produced by the WG. The first is to monitor > Message Transfer Agents (including SMTP and X.400), and the > second to monitor Directory (including DNS and X.500). > > > Goals and Milestones > > > March 93: Post Internet Drafts of three MIBs > > April 93: Submit "Network Services Monitoring MIB" as proposed standard > > July 93: Submit "Mail Monitoring MIB" as proposed standard. > > July 93: Submit "Directory Monitoring MIB" as proposed standard From owner-imap@cac.washington.edu Mon Mar 22 00:02:20 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17478; Mon, 22 Mar 93 00:02:20 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29333; Mon, 22 Mar 93 00:02:11 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SIGURD.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29327; Mon, 22 Mar 93 00:02:09 -0800 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992) id <01GW33UZ3FF48WWOQ6@SIGURD.INNOSOFT.COM>; Mon, 22 Mar 1993 00:01:54 PST Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST) From: Ned Freed Subject: RE: MADMAN (Mail and Directory Management) BOF at IETF In-Reply-To: Your message dated "Sun, 21 Mar 1993 13:02:08 -0800 (PST)" To: Mark Crispin Cc: Steve Kille , ietf-madman@INNOSOFT.COM, IMAP Interest List Message-Id: <01GW37EA3ABE8WWOQ6@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT > I will not be attending the Columbus IETF, but I think there would be > considerable interest in the MADMAN effort within the IMAP community. Is it > possible to extend this effort to encompass the management issues behind IMAP > (and perhaps POP) as well? I agree that this is doable and desireable. However, IMAP/POP management equates in my mind to Message Store management, as opposed to the MTA management we want to nail down first. On the other hand, there's no reason not to pursue these things with some degree of overlap. I also suspect, albeit without any real evidence, that Message Stores embody enough additional diversity that coming up with a MIB for them will be somewhat harder than handling MTAs and directories. We probably should start off with some kind of abstraction of what aspects of a Message Store need managing. Ned From owner-imap@cac.washington.edu Mon Mar 22 00:46:14 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18511; Mon, 22 Mar 93 00:46:14 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29475; Mon, 22 Mar 93 00:46:08 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from haig.cs.ucl.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA29469; Mon, 22 Mar 93 00:46:05 -0800 Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Mon, 22 Mar 1993 08:45:58 +0000 Received: from localhost.isode.com by glengoyne.isode.com with SMTP (PP) id <00953-0@glengoyne.isode.com>; Mon, 22 Mar 1993 08:30:07 +0000 To: Mark Crispin Cc: ietf-madman@innosoft.com, IMAP Interest List Subject: Re: MADMAN (Mail and Directory Management) BOF at IETF Phone: +44-71-721-7582 In-Reply-To: Your message of Sun, 21 Mar 1993 13:02:08 -0800. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Mar 1993 08:30:05 +0000 Message-Id: <951.732789005@isode.com> From: Steve Kille I think that this is exactly right. One of the points identified in the last meeting (minutes are in the archive) is that the Mail MIB needs to be extended to cover message store issues. I certainly have some ideas on how to do this, and would be very interested to discuss the IMAP experience in this area to identify what is needed. I think that the first question is to decide whether to roll this in with the existing Mail MIB, or whether to have a new Message Store MIB (I've been told to avoid OSI terminology, but can't think of a better word!). My preference is the second, and we should look at simple managment abstractions which are appropriate to POP, IMAP and P7. How do you think that it is best to progress this? I will certainly make sure that the issue is raised in Columbus. Steve From owner-imap@cac.washington.edu Mon Mar 22 10:52:07 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01992; Mon, 22 Mar 93 10:52:07 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15270; Mon, 22 Mar 93 10:51:52 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15264; Mon, 22 Mar 93 10:51:51 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA04252; Mon, 22 Mar 93 10:51:42 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA06563; Mon, 22 Mar 93 10:51:32 -0800 Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST) From: Mark Crispin Subject: Re: MADMAN (Mail and Directory Management) BOF at IETF To: Steve Kille Cc: IETF Mail Management WG , IMAP Interest List In-Reply-To: <951.732789005@isode.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi - I have to confess that my of my knowledge of network management protocols and MIBs is limited to a general notion that these are A Good Thing and what I see in IETF traffic. Unfortunately, the latter tends to be infared -- much heat but little light. IMAP is a little bit different from P7 and POP, although they're widely perceived as being the same class of protocols. Although IMAP can be used to retrieve mail from a message store ala P7 and POP, it's really a lot more than this. To be honest, there's really no reason not to go with POP if all you want to do is snarf messages from a maildrop. IMAP can be thought of as a remote procedure call mechanism for a mail UA; that is, it is a mechanism to distribute the job of a UA. I'm not sure how much of that class of function is ameniable to management. As for the issue of a Message Store MIB, remember that the role of a message store is different in POP/P7 from IMAP. In POP/P7, it is a maildrop for new mail; a staging area in a store-and-forward model. In IMAP, it is the place where the user's email bits are located. So, any MIB has to consider the differing needs of these two models. [Actually, the IMAP model is quite general and most IMAPware supports bits on a local disk as well as on a server, so that is an argument for a single general case MIB.] I also wonder how this would fit in with what our friends at CMU are working on with IMSP (the multi-server support protocol; it is to IMAP servers what IMAP is to IMAP folders). I admit that I'm way out of my depth here, so I'll probably shut up now and start listening. -- Mark -- From owner-imap@cac.washington.edu Mon Mar 22 11:35:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04006; Mon, 22 Mar 93 11:35:56 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04535; Mon, 22 Mar 93 11:35:48 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mhs-relay.cs.wisc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA04529; Mon, 22 Mar 93 11:35:45 -0800 X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Mon, 22 Mar 1993 13:35:04 +0000 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Mon, 22 Mar 1993 13:34:53 +0000 X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed; Mon, 22 Mar 1993 13:34:51 +0000 Date: Mon, 22 Mar 1993 13:34:51 +0000 X400-Originator: harald.t.alvestrand@delab.sintef.no X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;930322203451] X400-Content-Type: P2-1984 (2) Content-Identifier: 9760 From: Harald Tveit Alvestrand Message-Id: <"9760*/I=t/G=harald/S=alvestrand/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> To: Mark Crispin Cc: IETF Mail Management WG , IMAP Interest List In-Reply-To: Subject: RE: MADMAN (Mail and Directory Management) BOF at IETF On P7 and IMAP: The only commercial use of P7 I have seen is the POP (maildrop) model. However, P7 (and P7+) is a protocol much too large for this simple usage. Especially P7+ is very close in functionality to IMAP, I think. I have a short and unsatisfying chapter on modelling of message stores in my "E-mail modelling for management" document, available from the IFIP WG on E-mail management archive. Anyone is free to jump up and down on it, especially if they are able to write better text. Harald Tveit Alvestrand PS: Archive reference: email address: archive-server@nic.switch.ch S=archive-server; OU=nic; O=switch; P=switch; A=arcom; C=CH; command: send e-mail/ifip-emailmgt/docs/'document-name' ftp address: nic.switch.ch account: anonymous passwd: 'your email address' store: e-mail/ifip-emailmgt/docs/ interactive address: nic.switch.ch address: +22847971014540 account: info gopher address: nic.switch.ch FTAM address: nic.switch.ch address: +22847971014540 address: NSAP=39756f11112222223333aa0004000ae100, TSEL=0103Hex account: ANON From owner-imap@cac.washington.edu Mon Mar 22 14:01:16 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09761; Mon, 22 Mar 93 14:01:16 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07025; Mon, 22 Mar 93 14:00:54 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA07019; Mon, 22 Mar 93 14:00:51 -0800 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Mon, 22 Mar 93 17:00:41 EST Received: via switchmail; Mon, 22 Mar 1993 17:00:39 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 22 Mar 1993 16:59:49 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 22 Mar 1993 16:59:46 -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; Mon, 22 Mar 1993 16:59:45 -0500 (EST) Message-Id: Date: Mon, 22 Mar 1993 16:59:45 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: IMSP Beak: Is I think I'm ready to throw this to the wolves. Comments welcome. *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* Network Working Group J. G. Myers Request for Comments: ???? Carnegie Mellon March 1993 IMSP -- Interactive Mail Support Protocol Status of this memo This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Introduction The intent of the Interactive Mail Support Protocol (IMSP) is to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the IMAP2bis protocol [RFC-1176] [IMAP2bis], providing services which are either outside the scope of mail access or which pertain to environments which must run more than one IMAP2 server in the same mail domain. The protocol The IMSP protocol consists of a sequence of client commands and server responses, with server data interspersed between the responses. To simplify the implementation of clients, the IMSP protocol has a command structure similar to the IMAP protocol. Many of the IMSP commands and responses have the same or similar syntax and semantics of their IMAP2 counterparts. Like the IMAP2 protocol, commands and responses are tagged. That is, a command begins with a unique identifier (typically a short alphanumeric sequence such as a Lisp "gensym" function would generate e.g., A0001, A0002, etc.), called a tag. The response to this command is given the same tag from the server. Additionally, the server may send an arbitrary amount of "unsolicited data", which is identified by the special reserved tag of "*". There is another special reserved tag, "+", discussed below. The server must be listening for a connection on TCP port XXX. When a connection is opened the server sends an unsolicited OK or PREAUTH response as a greeting message and then waits for commands. The client opens a connection and waits for the greeting. The client must not send any commands until it has received the greeting from the server. Once the greeting has been received, the client may begin sending commands and is not under any obligation to wait for a server response to this command before sending another command, within the constraints of TCP flow control. When commands are received the server acts on them and responds with command responses, often interspersed with data. The effect of a command can not be considered complete until a command response with a tag matching the command is received from the server. Although all known IMSP servers at the time of this writing process commands to completion before processing the next command, it is not required that a server do so. However, many commands can affect the results of other commands, creating processing-order dependencies (or, for FIND and GETACL, ambiguities about which data is associated with which command). All implementations that operate in a non- lockstep fashion must recognize such dependencies and defer or synchronize execution as necessary. Generally, the first command from the client is a LOGIN command with user name and password arguments to establish identity and access authorization, unless this has already been accomplished through other means, e.g. connecting via the BSD "RSH" protocol. Until identity and access authorization have been established, no operations other than LOGIN or LOGOUT are permitted. The client terminates the session with the LOGOUT command. The server returns a "BYE" followed by an "OK". A Typical Scenario Client Server ------ ------ {Wait for Connection} {Open Connection} --> <-- * OK IMSP Server Ready {Wait for command} A001 LOGIN Fred Secret --> <-- A001 OK User Fred logged in {Wait for command} A002 FIND ALL.MAILBOXES INBOX --> <-- * MAILBOX INBOX (imap3.do.main) <-- A0002 OK Find complete {Wait for command} A003 SUBSCRIBE BBOARD comp.mail.mime --> <-- A003 OK Subscribe complete {Wait for command} A004 LOGOUT --> <-- * BYE IMSP server quitting <-- A004 OK Logout complete {Close Connection} --><-- {Close connection} {Go back to start} Base functionality Commands tag NOOP The NOOP command returns an OK to the client. By itself, it does nothing, but certain things may happen as side effects. Responses tag OK text This response identifies successful completion of the command with that tag. The text is a line of human-readable text that may be useful in a protocol telemetry log for debugging purposes. tag NO text This response identifies unsuccessful completion of the command with that tag. The text is a line of human-readable text that probably should be displayed to the user in an error report by the client. tag BAD text This response identifies faulty protocol received from the client; The text is a line of human-readable text that should be recorded in any telemetry as part of a bug report to the maintainer of the client. * BYE text This response identifies that the server is about to close the connection. The text is a line of human-readable text that should be displayed to the user in a status report by the client. This may be sent as part of a normal logout sequence, or as a panic shutdown announcement by the server. It is also used by some servers as an announcement of an inactivity autologout. * OK text This response identifies normal operation on the server. No special action by the client is called for, however, the text should be displayed to the user in some fashion. This is currently only used by servers at startup as a greeting message to show they are ready to accept the first command. * NO text This response identifies a warning from the server that does not affect the overall results of any particular request. The text is a line of human-readable text that should be presented to the user as a warning of improper operation. * BAD text This response identifies a serious error at the server; it may also indicate faulty protocol from the client in which a tag could not be parsed. The text is a line of human-readable text that should be presented to the user as a serious or possibly fatal error. It should also be recorded in any telemetry as part of a bug report to the maintainer of the client and server. + text This response identifies that the server is ready to accept the text of a literal from the client. Normally, a command from the client is a single text line. If the server detects an error in the command, it can simply discard the remainder of the line. It cannot do this for commands that contain literals, since a literal can be an arbitrarily long amount of text, and the server may not even be expecting a literal. This mechanism is provided so the client knows not to send a literal until the server expects it, preserving client/server synchronization. In practice, this condition is rarely encountered. In the current protocol, the only client command likely to contain a literal is the LOGIN command. Consider a server that validates the user before checking the password. If the password contains "funny" characters and hence is sent as a literal, then if the user is invalid an error would occur before the password is parsed. No such synchronization protection is provided for literals sent from the server to the client, for performance reasons. Any synchronization problems in this direction would be caused by a bug in the client or server. Identification and Authorization Commands tag LOGIN user password The LOGIN command identifies the user to the server and carries the password authenticating this user. This information is used by the server to control access to commands. EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with password SESAME. tag LOGOUT The LOGOUT command informs the server that the client is done with the session. The server should send an unsolicited BYE response before the (tagged) OK response, and then close the network connection. Responses * PREAUTH A pre-authenticated IMSP server should recognize that authentication has already happened, and enter the post-login state. In its greeting message, it should use the unsolicited reply "PREAUTH" instead of "OK" to indicate that external authentication has taken place. Server location and new message information Commands tag FIND MAILBOXES pattern The FIND MAILBOXES command accepts as an argument a pattern (including wildcards) that specifies some set of mailbox names that are usable by connecting to an IMAP2 server and using the SELECT command. The format of mailboxes is implementation dependent. Only those mailboxes that the user has declared as being "subscribed" are returned. Two wildcard characters are defined; "*" specifies any number (including zero) characters may match at this position and "%" specifies a single character may match at this position. For example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas FOO%BAR will match only FOO.BAR. "*" will match all mailboxes. The FIND MAILBOXES command will return some set of unsolicited MAILBOX replies that have as their value a single mailbox name and a list of hosts on which the mailbox resides. EXAMPLE: A002 FIND MAILBOXES * * MAILBOX INBOX (imap3.do.main) * MAILBOX FOOBAR (imap3.do.main) * MAILBOX GENERAL (imap12.do.main) A002 OK Find completed Although the use of explicit file or path names for mailboxes is discouraged by this standard, it may be unavoidable. It is important that the value returned in the MAILBOX unsolicited reply be usable in a SELECT command given to an IMAP server running on each of the returned hosts without remembering any path specification that may have been used in the FIND MAILBOXES pattern. The SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX commands manipulate the list returned by this command. tag FIND ALL.MAILBOXES pattern The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES; however, it should return a complete list of all mailboxes available to the user. Data is returned as in FIND MAILBOXES. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `mailboxes available to the user' may not be meaningful for a particular server or server implementation. The command must at least return the set of mailboxes that FIND MAILBOXES does. tag FIND UNSEEN.MAILBOXES pattern The FIND UNSEEN.MAILBOXES command is similar to FIND MAILBOXES; however, only those "subscribed" mailboxes in which there are messages without the ¥SEEN flag are returned. Data is returned as in FIND MAILBOXES. Should an implementation be unable to determine which mailboxes have unread messages, it should return the same information returned by FIND MAILBOXES. tag FIND BBOARDS pattern The FIND BBOARDS command accepts as an argument a pattern that specifies some set of bulletin board names that are usable by connecting to an IMAP2 server and using the BBOARD command. Wildcards are permitted as in FIND MAILBOXES. Only those bboards that the user has declared as being "subscribed" are returned. The FIND BBOARDS command will return some set of unsolicited BBOARD replies that have as their value a single bulletin board name and a list of hosts on which the bboard resides. EXAMPLE: A002 FIND BBOARDS * * BBOARD comp.mail.mime (imap7.do.main imap8.do.main) * BBOARD GENERAL (imap2.do.main) A002 OK Find completed tag FIND ALL.BBOARDS pattern The FIND ALL.BBOARDS command is similar to FIND BBOARDS; however, it should return a complete list of all bulletin boards available to the user. Data is returned as in FIND BBOARDS. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `bboards available to the user' may not be meaningful for a particular server or server implementation. The command must at least return the set of bboards that FIND BBOARDS does. tag FIND UNSEEN.BBOARDS pattern The FIND UNSEEN.BBOARDS command is similar to FIND BBOARDS; however, only those "subscribed" bboards for which there are messages without the ¥SEEN flag are returned. Data is returned as in FIND BBOARDS. Should an implementation be unable to determine which bboards have unread messages, it should return the same information returned by FIND BBOARDS. Responses * MAILBOX string server_list This response occurs as a result of a FIND MAILBOXES, FIND ALL.MAILBOXES, or FIND UNSEEN.MAILBOXES command. The string is a mailbox name that matches the pattern in the command. server_list is an S-expression list of the fully qualified domain names of the hosts on which the mailbox resides. Should the server_list contain more than one host name, the client should access the mailbox by attempting to connect to each server until one connection succeeds. The client should attempt each possible host in the sequence listed unless it has good reason to do otherwise (such as an already-open connection or geographic information). * BBOARD string server_list This response occurs as a result of a FIND BBOARDS, FIND ALL.BBOARDS, or FIND UNSEEN.BBOARDS command. The string is a bboard name that matches the pattern in the command. server_list is an S-expression list of the fully qualified domain names of the hosts on which the bboard resides. Should the server_list contain more than one host name, the client should access the bboard by attempting to connect to each server until one connection succeeds. The client should attempt each possible host in the sequence listed unless it has good reason to do otherwise (such as an already-open connection or geographic information). Discussion When a user asks a client to read a bboard by name, the client should issue a "FIND ALL.BBOARDS" command to the IMSP server in order to determine which server it is on. An alternate way of returning the server location would be to use the {server.do.main} notation used by a popular IMAP client library. This would have simplified the implementation of IMSP by those client. This was not done for the following reasons: * The {server.do.main} notation provides no mechanism for specifying multiple hosts. * This would assign a protocol interpretation to what is explicitly specified in RFC-1176 as being implementation specific. There is a minor design flaw in IMAP2bis: the MAILBOX/BBOARD unsolicited response has an ambiguous meaning--one can only tell if the folder is subscribed or not by figuring out whether it is a response to a FIND foo or a FIND ALL.foo command. The following is a possible implementation of the FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS commands: When a message is appended to a folder, the IMAP server notifies the IMSP server of some unique (within the folder) attribute of the message. Possibile attributes include the message-id and the internaldate. This could be done using an IMSP extension: tag LAST MAILBOX mailbox attribute user tag LAST BBOARD mailbox attribute When a user switches folders or closes a connection and has read all messages in that folder, the IMAP server notifies the IMSP server that the user has read all of the messages, including the attribute of the last message. This too could be done using an IMSP extension: tag SEEN MAILBOX mailbox attribute user tag SEEN BBOARD mailbox attribute user When asked for folders with unread by the user, the IMSP server can check the attribute of the message last reported for the user against the attribute of the message last appended to the folder. In the interest of having the IMAP server/IMSP server communications be the same across implementation, it might be worthwhile to propose this method of implementing FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS as a standard. Subscription management tag SUBSCRIBE MAILBOX mailbox The SUBSCRIBE MAILBOX command adds the specified mailbox name to the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE MAILBOX mailbox The UNSUBSCRIBE MAILBOX command removes the specified mailbox name from the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. tag SUBSCRIBE BBOARD bboard The SUBSCRIBE BBOARD command adds the specified mailbox name to the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE BBOARD bboard The UNSUBSCRIBE BBOARD command removes the specified mailbox name from the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. Mailbox and BBoard management tag CREATE mailbox tag CREATE mailbox server_partition_list The CREATE command creates a mailbox with the given name. This command returns an OK response only if a new mailbox with that name has been created. It is an error to attempt to create a mailbox with a name that refers to an extant mailbox. Any error in creation will return a NO response. Creating INBOX is not permitted. If there is a primary or default mailbox for this user, it MUST exist and be called INBOX; hence it may not be created. Otherwise, the name INBOX can not be used; see section VI, "INBOX Requirement Loosened", of IMAP2bis [IMAP2bis] for more details. If server_partition_list is specified, it indicates the server or set of servers on which the mailbox is to be created. Each hostname in the list may be followed by a slash character and an atom. The atom specifies in an implementation-dependent manner where to store the mailbox on the server. EXAMPLE: A002 CREATE FOOBAR (imap2.do.main/a imap4.do.main) A002 OK Create completed If server_partition_list is not specified, the placement of the mailbox is up to the implementation. tag DELETE mailbox tag DELETE mailbox hostname The DELETE command deletes a mailbox with the given name. This command returns an OK response only if a mailbox with that name has been deleted. It is an error to attempt to delete a mailbox name that does not exist. Any error in deletion will return a NO response. A server SHOULD NOT attempt to test that a mailbox is empty prior to permitting deletion; this would prevent the deletion of a mailbox which for some reason can not be opened or expunged, leaving to possible denial of service problems. Any such checking should be left to the discretion of the client. Deleting INBOX is not permitted. If hostname is specified, the mailbox is deleted on that host. If it is not specified, the mailbox is deleted on all hosts on which the mailbox resides. tag RENAME oldmailbox newmailbox The RENAME command changes the name of a mailbox. This command returns an OK response only if a mailbox with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old mailbox name that does not exist or a new mailbox name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to the mailbox, their subscriptions should be updated appropriately. Renaming INBOX is permitted. A new, empty INBOX is created in its place. Should users be subscribed to the INBOX, they should remain subscribed to the new, empty INBOX. tag MOVE mailbox hostname server_partition_list The MOVE command moves a mailbox between servers and/or replicates a mailbox. Hostname specifies where the move is to be made from and server_partition_list specifies where the move is to be made to. The interpretation of server_partition_list is the same as for the CREATE command. tag CREATE.BBOARD bboard tag CREATE.BBOARD bboard server_partition_list The CREATE.BBOARD command creates a bboard with the given name. This command returns an OK response only if a new bboard with that name has been created. It is an error to attempt to create a bboard with a name that refers to an extant bboard. Any error in creation will return a NO response. If server_partition_list is specified, it indicates the server or set of servers on which the bboard is to be created. Each hostname in the list may be followed by a slash character and an atom. The atom specifies in an implementation-dependent manner where to store the bboard on the server. EXAMPLE: A002 CREATE.BBOARD FOOBAR (imap2.do.main/a map4.do.main) A002 OK Create completed If server_partition_list is specified, the placement of the bboard is up to the implementation. tag DELETE.BBOARD bboard tag DELETE.BBOARD bboard hostname The DELETE.BBOARD command deletes a bboard with the given name. This command returns an OK response only if a bboard with that name has been deleted. It is an error to attempt to delete a mailbox name that does not exist. Any error in deletion will return a NO response. If hostname is specified, the bboard is deleted on that host. If it is not specified, the bboard is deleted on all hosts on which the bboard resides. tag RENAME.BBOARD oldbboard newbboard The RENAME.BBOARD command changes the name of a bboard. This command returns an OK response only if a bboard with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old bboard name that does not exist or a new bboard name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to the bboard, their subscriptions should be updated appropriately. tag MOVE.BBOARD bboard hostname server_partition_list The MOVE.BBOARD command moves a bboard between servers and/or replicates a bboard. Hostname specifies where the move is to be made from and server_partition_list specifies where the move is to be made to. The interpretation of server_partition_list is the same as for the CREATE command. tag ALIAS.BBOARD oldbboard newbboard After "oldbboard" gets subsequently deleted, all users that are subscribed to "oldbboard" will be subscribed to newbboard. [Call this RESUBSCRIBE? Put in Subscription management? Actually perform the deletion? Provide ALIAS command for mailboxes?] Discussion Of course, local administrative policy may restrict use of these commands. Implementations may use this as justification for not implementing partitions, multiple locations for mailboxes/bboards, or the MOVE and MOVE.BBOARD commands. MOVE and MOVE.BBOARD cannot be implemented without some non-IMAP2 communication with the IMAP servers. Replication requires some communication between IMAP servers. CREATE.BBOARD, DELETE.BBOARD, and RENAME.BBOARD, and partitions require IMAP protocol extensions. Everything else can be implemented through the use of IMAP2bis commands. User configuration information Commands tag GET pattern The GET command accepts as an argument a pattern that specifies some set of configuration options. Wildcards are permitted as in FIND MAILBOXES. The GET command will return some set of unsolicited OPTION replies, giving the names and values of matching options. Example: A002 GET BCC* * OPTION BCC.MAILBOX SENT-MAIL [READ-WRITE] A002 OK Get completed tag SET option value The SET command accepts as arguments the name of an option and a string value. The value of the option is set to the specified string. If the option with that name does not already exist, it is created. Option names must conform to the grammar of atoms. SET is not allowed if the named option is read-only. tag UNSET option The UNSET command accepts as an argument the name of an option. Depending on the implementation, the option is either removed or its value reverts to the implementation-defined default. UNSET is not allowed if the named option is read-only. Responses * OPTION atom string string This response occurs as a result of a GET command. The first string is an option name that matches the pattern in the command. The second string is the value of the option. The third string is either [READ-WRITE] if the user may change the option or [READ-ONLY] if the user may not. Discussion Options can be site wide or per-user. Possible uses include: User preferences (e.g. mailbox to store copies of outgoing mail) Site configuration information (e.g. names of SMTP servers) Per-user configuration information (e.g. contents of From: header) The option namespace could be split into a section for standard options and sections for client-specific options. Possible standard options include: DATE (current time, in rfc822 format) DOMAIN (local mail domain) FROM (string to use for From: header) DELIVERY.HOSTS (list of smtp hosts for mail submission) BCC.MAILBOX (mailbox to store copies of outgoing mail) Access control lists Commands tag SETACL MAILBOX mailbox identifier rights Changes the access control list on the specified mailbox so that the specified identifier is granted the permissions enumerated in rights. Identifier has implementation-defined semantics. Possible variations of identifier interpretation include: * User names, as specified in the LOGIN command. * Named groups of users, presumably managed by some authorization service. * Only allowing identifiers supported by the operating system (e.g. ``user'', ``group'', and ``other'' for the Unix filesystem) * Whether rights granted to other mailboxes in an implementation-defined hierarchy are inherited * A portion of the identifier specifying an "authentication type". As an example, an implementation may control posting to a group based on the contents of the From: header: from$user p * Whether the union of rights for matching identifiers are granted to a user or whether the rights for the most specific matching identifier is granted. As an example, for a mailbox with the following ACL: user lrsa group-user-is-in lrsw One implementation may grant the user 'lrswa' rights, another may only grant the user 'lrsa'. * A prefix to an identifier name specifying the listed rights are to be removed from users who match the prefixed identifier. As an example, for a mailbox with the following ACL: group-user-is-in lrsw -user w An implementation may grant the user 'lrs' rights. Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations which is being controlled. Letters [lowercase?] are reserved for ``standard'' rights, listed below. Digits are reserved for implementation or site defined rights. The standard rights are: l - lookup (folder is visible to FIND commands) r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, SEARCH, COPY from mailbox) s - keep seen/unseen information across sessions (STORE ¥SEEN flag) w - write (STORE flags other than ¥SEEN and ¥DELETED) i - insert (perform APPEND, COPY into mailbox) p - post (send mail to submission address for mailbox, not enforced by IMAP2/IMSP itself) c - create (CREATE new sub-folders in any implementation-defined hierarchy) d - delete (STORE ¥DELETED flag, perform EXPUNGE) a - administer (perform SETACL) An implementation may tie rights together or may force rights to always or never be granted. For example, in an implementation that uses unix mode bits, the rights "wisd" are tied. The "a" right is always granted to the owner and is never granted to another user. If rights are tied in an implementation, it should be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none should be used. Numeric rights may not be tied. tag SETACL BBOARD bboard identifier rights Changes the access control list on the specified mailbox so that the specified identifier is granted the permissions enumerated in rights. Identifier and rights are as specified for SETACL MAILBOX. tag DELETEACL MAILBOX mailbox identifier Removes any portion of the access control list for mailbox for the specified identifier. tag DELETEACL BBOARD bboard identifier Removes any portion of the access control list for bboard for the specified identifier. tag GETACL MAILBOX mailbox Returns the access control list for mailbox in some set of unsolicited ACL replies. There may not be more than one ACL reply specifying any given identifier. EXAMPLE: A002 GETACL MAILBOX INBOX * ACL MAILBOX INBOX Fred rwipslda A002 Ok Getacl complete tag GETACL BBOARD bboard Returns the access control list for bboard in some set of unsolicited ACL replies. EXAMPLE: A002 GETACL BBOARD comp.mail.mime * ACL BBOARD comp.mail.mime anybody-else rpsl * ACL BBOARD comp.mail.mime news rwipcsld A002 Ok Getacl complete tag MYACL MAILBOX mailbox Returns the set of rights that the user has to mailbox in an unsolicited ACL reply. tag MYACL BBOARD mailbox Returns the set of rights that the user has to bboard in an unsolicited ACL reply. Responses * ACL MAILBOX string string string This response occurs as a result of a GETACL MAILBOX or MYACL MAILBOX command. The first string is the mailbox name for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * ACL BBOARD string string string This response occurs as a result of a GETACL BBOARD or MYACL BBOARD command. The first string is the bboard name for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. Discussion The assignment of letters to rights is AFS-centric. Alternatively we could change i->a, l->v, a->what?. The set of rights should make some sense in other messaging domains, particularly NNTP. The IMSP and NNTP ACL specifications should be similar. The IMSP author will work with the author of the NNTP ACL extension in order to resolve this. Unresolved issues The following mail support issues have been raised, but not resolved in IMSP. * User forwarding address * User address book * Distribution lists Deferred. These probably belong in a separate user directory service. * Mail filing control (e.g. ``vacation'', delivery of mail to folders other than INBOX based on subject, sender) Deferred. This probably belongs in a separate service, quite possibly a user directory service. * Administrative issues: Purge rates for bboards (not necessarily age related) Quotas for users or bboards (not necessarily megabyte related) * Notification issues Current use of quota Exhaustion of quota Renamed/deleted folders/bboards [ Use unsolicited OK/NO messages? ] For renamed/deleted folders/bboards, server should notify, then change or delete subscription as necessary. Minimal conformance Implementation of the following commands is mandatory: NOOP LOGIN LOGOUT FIND MAILBOXES FIND ALL.MAILBOXES FIND UNSEEN.MAILBOXES FIND BBOARDS FIND ALL.BBOARDS FIND UNSEEN.BBOARDS SUBSCRIBE MAILBOX SUBSCRIBE BBOARD UNSUBSCRIBE MAILBOX UNSUBSCRIBE BBOARD GET SET [CREATE DELETE RENAME CREATE.BBOARD, DELETE.BBOARD RENAME.BBOARD ALIAS.BBOARD with partitions and multiple residency optional?] Backwards compatibility When a client is directed by a user or an initial configuration to contact a server, it should first attempt to reach the IMSP service. If that fails with connection refused, it should fall back to the IMAP2 protocol. Conventions The following terms are used in a meta-sense in the syntax specification below: An ASCII-STRING is a sequence of arbitrary ASCII characters. An ATOM is a sequence of ASCII characters delimited by SP or CRLF. A CHARACTER is any ASCII character except """", "{", CR, or LF. A CRLF is an ASCII carriage-return character followed immediately by an ASCII linefeed character. A NUMBER is a sequence of the ASCII characters that represent decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or ":". A SP is the ASCII space character. A TEXT_LINE is a human-readable sequence of ASCII characters up to but not including a terminating CRLF. A common field in the IMSP protocol is a STRING, which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), or a LITERAL. A literal consists of an open brace ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, where n is the value of the number inside the brace. In general, a string should be represented as an ATOM or QUOTED-STRING if at all possible. The semantics for QUOTED-STRING or LITERAL are checked before those for ATOM; therefore an ATOM used in a STRING may only contain CHARACTERs. Literals are most often sent from the server to the client; in the rare case of a client to server literal there is a special consideration (see the "+ text" response below). Note the set of allowable CHARACTERs is larger than specified for IMAP2. Formal syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma. acl ::= "ACL" acl_option SP string SP string SP string acl_option ::= "MAILBOX" / "BBOARD" alias_bboard ::= "ALIAS.BBOARD" SP string SP string bboard_reply ::= "BBOARD" SP string SP "(" 1#hostname ")" create ::= "CREATE" SP mailbox [ server_partition_list ] create_bboard ::= "CREATE.BBOARD" SP string [ server_partition_list ] delete ::= "DELETE" SP mailbox [ hostname ] delete_bboard ::= "DELETE.BBOARD" SP string [ hostname ] find ::= "FIND" SP find_option SP string find_option ::= "MAILBOXES" / "ALL.MAILBOXES" / "UNSEEN.MAILBOXES / "BBOARDS" / "ALL.BBOARDS" / "UNSEEN.BBOARDS" get ::= "GET" SP string getacl ::= "GETACL" SP acl_option SP string hostname ::= atom ; Fully qualified domain name literal ::= "{" NUMBER "}" CRLF ASCII-STRING login ::= "LOGIN" SP userid SP password logout ::= "LOGOUT" mailbox ::= "INBOX" / string mailbox_reply ::= "BBOARD" SP string SP "(" 1#hostname ")" move ::= "MOVE" SP mailbox SP hostname SP server_partition_list move_bboard ::= "MOVE.BBOARD" SP string SP hostname SP server_partition_list myacl ::= "MYACL" SP acl_option SP string noop ::= "NOOP" option ::= "OPTION" SP atom SP string SP string rename ::= "RENAME" SP mailbox SP string rename_bboard ::= "RENAME.BBOARD" SP string SP string request ::= tag SP (noop / login / logout / find / subscribe / unsubscribe / create / delete / rename / move / create_bboard / delete_bboard / rename_bboard / move_bboard / alias_bboard / get / set / getacl / setacl / myacl) CRLF response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF server_partition ::= hostname [ "/" atom ] server_partition_list ::= "(" 1#server_partition ")" set ::= "SET" SP atom SP string setacl ::= "SETACL" SP acl_option SP string SP string string ::= atom / """" 1*character """" / literal subscribe ::= "SUBSCRIBE" SP subscribe_opt SP string subscribe_opt ::= "MAILBOX" / "BBOARD" unsolicited ::= "*" SP (mailbox_reply / bboard_reply / option / acl) CRLF unsubscribe ::= "UNSUBSCRIBE" SP subscribe_opt SP string References [RFC-1176] Crispin, Mark R. Interactive Mail Access Protocol - Version 2. August 1990. RFC-1176. [IMAP2bis] Crispin, Mark R. IMAP2bis - Extensions to the IMAP2 Protocol, December 1992 Author's Address John G. Myers Carnegie-Mellon University 4910 Forbes Ave. Pittsburgh PA, 15213-3890 Email: jgm+@cmu.edu From owner-imap@cac.washington.edu Wed Mar 24 17:41:50 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25712; Wed, 24 Mar 93 17:41:50 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08516; Wed, 24 Mar 93 17:41:34 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from pike.biostat.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08510; Wed, 24 Mar 93 17:41:32 -0800 Received: by pike.biostat.washington.edu (4.1/UW-NDC Revision: 2.13 ) id AA02726; Wed, 24 Mar 93 17:39:16 PST Date: Wed, 24 Mar 93 17:39:16 PST From: David Fetrow Message-Id: <9303250139.AA02726@pike.biostat.washington.edu> To: imap@cac.washington.edu Subject: add me fetrow@biostat.washington.edu should be added to the list. Oh boy, another Protocol :-) From owner-imap@cac.washington.edu Thu Mar 25 19:08:03 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27581; Thu, 25 Mar 93 19:08:03 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07963; Thu, 25 Mar 93 19:07:54 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Mar 30 23:37:51 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29523; Tue, 30 Mar 93 23:37:51 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04530; Tue, 30 Mar 93 23:37:17 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04524; Tue, 30 Mar 93 23:37:16 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA16490; Tue, 30 Mar 93 23:37:10 -0800 Date: Tue, 30 Mar 1993 22:17:10 -0800 (PST) From: Mark Crispin Subject: IMSP specification To: John Gardiner Myers Cc: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I finally took some time to read the IMSP specification. Here are some comments: 1) Should the wildcard syntax used by FIND be limited to the TOPS-20 wildcard characters selected by IMAP2? Perhaps a regular expression syntax would be better?? 2) I like the way IMSP deals with server names in FIND results. Much better than IMAP2. However, there's one additional improvement to be made, which is to include the pattern in the results. For example: a002 FIND MAILBOXES * * MAILBOX * INBOX (imap1.podunk.edu) * MAILBOX * FOOBAR (imap23.podunk.edu) a002 OK FIND completed This will greatly please certain people, and there's no harm done by doing it now. Some of the other commands which return data should also have the request patterns included in the responses. 3) I like FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS -- neat idea and a possible big performance win. 4) I don't think you need to justify your selection of a list of server hosts for FIND instead of using the {host} syntax. The {host} syntax is obviously inappropriate for this purpose. 5) Why not fix the ``design flaw'' by requiring that FIND ALL.mumble indicate subscription status. You don't have to be bug-for-bug matching with IMAP. 6) I'm not sure I like the proposed implementation of FIND UNSEEN.mumble, since it seems to preclude doing it by hunt/examination. This should be a implementation detail and not a protocol detail. 7) Instead of CREATE and CREATE.BBOARD, I suggest CREATE MAILBOX and CREATE BBOARD & etc. for the other commands. 8) I'm not convinced that a user's private address book couldn't be part of the GET/SET stuff instead of having to wait for directory services. From owner-imap@cac.washington.edu Wed Mar 31 09:31:29 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09911; Wed, 31 Mar 93 09:31:29 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06775; Wed, 31 Mar 93 09:31:09 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from eco.twg.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06769; Wed, 31 Mar 93 09:31:03 -0800 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA13214; Wed, 31 Mar 93 12:30:52 -0500 Message-Id: <9303311730.AA13214@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <10082-0@apache.twg.com>; Wed, 31 Mar 1993 09:31:01 -0800 From: "David Herron" Subject: Re: IMSP specification To: Mark Crispin Cc: John Gardiner Myers , IMAP Interest List Date: Wed, 31 Mar 93 9:30:59 PST In-Reply-To: Your message of Tue, 30 Mar 1993 22:17:10 -0800 (PST). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 4 TEXT , 4 TEXT Qu'est-ce que c'est "IMSP"??? >From what Mark is saying it sounds like a replacement prototocol for IMAP... <- 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-imap@cac.washington.edu Wed Mar 31 13:08:55 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15314; Wed, 31 Mar 93 13:08:55 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07802; Wed, 31 Mar 93 13:08:45 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07796; Wed, 31 Mar 93 13:08:42 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA17032; Wed, 31 Mar 93 13:08:32 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA15947; Wed, 31 Mar 93 13:08:14 -0800 Date: Wed, 31 Mar 1993 13:03:39 -0800 (PST) From: Mark Crispin Subject: Re: IMSP specification To: David Herron Cc: John Gardiner Myers , IMAP Interest List In-Reply-To: <9303311730.AA13214@eco.twg.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 31 Mar 93 9:30:59 PST, David Herron wrote: > Qu'est-ce que c'est "IMSP"??? > > From what Mark is saying it sounds like a replacement prototocol > for IMAP... No. IMSP (Interactive Mail Support Protocol) is a support protocol for IMAP. It handles collections of IMAP servers the way IMAP handles collections of message folders. IMSP extends the IMAP2bis operations for creating, deleting, renaming, [un]subscribing, and listing folders to multiple IMAP servers; it also has some capabilities for distributed user configuration information. IMSP doesn't have any capability to deal with messages. You don't need IMSP at all if you only have one IMAP server. -- Mark -- From owner-imap@cac.washington.edu Wed Mar 31 15:01:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19360; Wed, 31 Mar 93 15:01:13 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20942; Wed, 31 Mar 93 15:01:04 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20936; Wed, 31 Mar 93 15:01:03 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02500; Wed, 31 Mar 93 15:01:01 -0800 Date: Wed, 31 Mar 1993 14:55:37 -0800 (PST) From: Terry Gray Reply-To: Terry Gray Subject: Draft IETF Working Group charter To: imap@cac.washington.edu Cc: imap-local@epilogue.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Folks, Several of you have encouraged me in private communications to move ahead with getting IMAP onto the IETF standards track. I took the first step toward that goal today by chairing a BOF at the Columbus IETF to gauge interest, discern commonality of objectives, and discuss a draft W.G. charter, which is appended herewith for your consideration. (I'll post more info on the BOF discussion within a few days, but I want to get the BOF attendees onto this list first.) In any case, the wording and objectives stated below were acceptable to the folks who were able to come to the BOF. If you have objections or suggestions, please let me know soon. (48 hours of silence will be interpreted as universal, unanimous, enthusiastic assent :) Seriously, I'd like to ask Russ Hobby (the area co-director) to forward it on to IESG fairly soon. Thanks... -teg p.s. the long form "ietf-imap@cac.washington.edu" is an alias for "imap@cac.washington.edu" --likewise, the -request address. -------------------------------------------------------------------------- Interactive Mail Access Protocol Working Group (imap) Chair: Terry Gray gray@cac.washington.edu Mailing Lists: General Discussion: ietf-imap@cac.washington.edu To Subscribe: ietf-imap-request@cac.washington.edu Mail archive: ftp.cac.washington.edu /imap/imap_archive Description of Working Group: The Internet Interactive Mail Access Protocol (IMAP) working group is chartered to refine and extend the current IMAP2 protocol as a candidate standard for a client-server Internet email protocol to manipulate remote mailboxes as if they were local. An explicit objective is to retain compatibility with the growing installed base of IMAP2-compliant software. It is expected that the resulting specification will replace both RFC-1176 and the more recent (as yet unplublished) IMAP2bis extensions. A mail access protocol provides a uniform, OS-independent way of manipulating email message data on a remote mail store (repository). Mail user agents implementing such a protocol can provide individuals with a consistent view of the mail store, regardless of what type of computer they are using, and regardless of where they are connected in the network. Multiple concurrent sessions accessing a single remote mailbox, and single sessions accessing multiple remote mailboxes are both possible with this approach. There are no Internet standards in this area, and one is needed to define a consistent approach to the problem in the context of other Internet mail protocols including RFC-822, SMTP, and MIME. IMAP appears to be the only existing *open* protocol that achieves the above goals. Hence, the choice is either to invent a new protocol from scratch, or to refine IMAP2. IMAP2 is in production use at a number of large sites, and several commercial products based on it are now available. Operational experience has been very positive, and the installed base is growing. In the absence of any serious problems with the current specifications (IMAP2 plus IMAP2bis extensions), it makes little sense to start over, nor to abandon compatibility with the installed base. Comparison to POP. There is a Draft Standard describing the latest version of the Post Office protocol (POP3, RFC-1225). POP is a store-and-forward transport protocol that allows an MUA to retrieve pending mail from a mail drop (where it is then usually deleted automatically). IMAP, in contrast, is focused on remote mailbox manipulation rather than mail transport. Although IMAP is a functional superset of POP and can operate in the same mode, the two have different purposes and should not be viewed as competing. Comparison to PCMAIL. PCMAIL, defined in RFC-1056, uses the Distributed Mail System Protocol (DMSP). It has been relegated to Informational status by the IAB. A strength of DMSP is support for "disconnected operation" wherein a local message cache can be created for off-line processing, and later resynchronized with the main mail server. (Preliminary discussions have taken place with members of the DMSP community on how to fold similar capabilities into IMAP2. The working group needs to complete this effort.) Commercial alternatives. Many of the vendor-specific remote mail access approaches are based on proprietary remote file system protocols that neither scale well nor support diverse types of client operating systems. Others are unsuitable candidates for Internet standardization due to licensing restrictions. Comparison with NFS. Achieving many of the stated goals is possible using a generic remote file access protocol such as NFS, rather than an application-specific email protocol. However, there are also some significant drawbacks, including: file locking on the mail server in the face of concurrent local and (possibly multiple) remote updates; network performance; and difficulty in implementing on small client machines. Moreover, using an application-specific protocol allows the server to provide more efficient searching and message parsing. The latter is particularly important in the context of MIME, so that the client can request message structure information from the server, and thereafter retrieve only the body parts it needs. Security. Security-related tasks include how to incorporate secure authentication mechanisms when establishing a session, and interactions with Privacy Enhanced Mail. This working group's IMAP standardization activity complements (and does not compete with) parallel efforts to define the "IMSP" mail support protocol which will be layered on top of the resulting IMAP protocol. The mail support protocol work addresses issues of managing large email sites, such as determining on which mail server a particular user's incoming mail resides. Goals and Milestones: It is expected that most of the work of this group will be conducted via email. Opportunities to meet face-to-face at IETF meetings will be used initially to review the charter and context for the work, as well as presentations to help members get up to speed on IMAP. A goal is to have the IMAP2bis draft updated and submitted as an Internet draft in the July timeframe. The November IETF WG meeting would then focus on detailed review of the draft standard. Mar 93 IETF A BOF to review the working group charter, and discuss its relationship to the broader remote mail issues considered in previous IETF email BOFs. Jul 93 IETF Foreign travel restrictions may preclude several of the key players from attending the Amsterdam IETF, however, it may be possible to schedule a WG meeting for presentations and to solicit input from those who are normally unable to attend US IETF meetings. Nov 93 IETF Based on continuing email refinement of the text, use this meeting for a detailed review of Internet draft text. From owner-imap@cac.washington.edu Fri Apr 2 12:12:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14067; Fri, 2 Apr 93 12:12:05 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14514; Fri, 2 Apr 93 12:11:41 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14508; Fri, 2 Apr 93 12:11:40 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07072; Fri, 2 Apr 93 12:11:17 -0800 Date: Fri, 2 Apr 1993 11:57:42 -0800 (PST) From: Terry Gray Reply-To: Terry Gray Subject: IMAP BOF To: Karl Auerbach , Rob Austein et al , Sandy Bryant , William Chung , Jim Conklin , Mark Davis Craig , Roger Fajman , Ned Freed , Russ Hobby , Steve Hubert , "David M. Katinsky" , Sylvain Langlois , Bob Morgan , "Robert J. Reschly Jr." Cc: Marshall Rose , Dave Crocker , Carl Schoeneberger <70410.3563@compuserve.com>, IMAP Interest Group Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Folks, I wanted to thank all of you for your interest and participation in Wednesday's IMAP BOF. I look forward to working with all of you, and I think we can do something very significant here. Those of you listed in the "To:" field of this message indicated that you would like to be added to the IMAP list. That should happen shortly. Look for notes from the meeting to be posted before the weekend is over. -teg From owner-imap@cac.washington.edu Fri Apr 2 13:23:14 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16241; Fri, 2 Apr 93 13:23:14 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19432; Fri, 2 Apr 93 13:22:57 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from eco.twg.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19422; Fri, 2 Apr 93 13:22:39 -0800 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA04964; Fri, 2 Apr 93 16:22:13 -0500 Message-Id: <9304022122.AA04964@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <21180-0@apache.twg.com>; Fri, 2 Apr 1993 13:21:49 -0800 From: "David Herron" Subject: Re: IMAP BOF To: Terry Gray Cc: Karl Auerbach , Rob Austein et al , Sandy Bryant , William Chung , Jim Conklin , Mark Davis Craig , Roger Fajman , Ned Freed , Russ Hobby , Steve Hubert , "David M. Katinsky" , Sylvain Langlois , Bob Morgan , "Robert J. Reschly Jr." , Marshall Rose , Dave Crocker , Carl Schoeneberger <70410.3563@compuserve.com>, IMAP Interest Group Date: Fri, 2 Apr 93 13:21:45 PST In-Reply-To: Your message of Fri, 2 Apr 1993 11:57:42 -0800 (PST). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 5 TEXT Terry, I am interested in joining the IMAP working group. David From owner-imap@cac.washington.edu Sat Apr 3 18:11:01 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08379; Sat, 3 Apr 93 18:11:01 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24671; Sat, 3 Apr 93 18:10:40 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24665; Sat, 3 Apr 93 18:10:38 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23395; Sat, 3 Apr 93 18:10:37 -0800 Date: Sat, 3 Apr 1993 18:08:05 -0800 (PST) From: Terry Gray Reply-To: Terry Gray Subject: small changes to WG charter To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Based on feedback to date, a few words have been changed. Here are the diffs, followed by the latest version. -teg =========================================================================== OLD < --- NEW > Re: Definitions (2nd paragraph): < manipulating email message data on a remote mail store (repository). Mail < user agents implementing such a protocol can provide individuals with a < consistent view of the mail store, ... --- > manipulating message data (email or bulletin board) on a remote message > store (repository). Mail user agents implementing such a protocol can > provide individuals with a consistent view of the message store, ... Re: disconnected operation: < group needs to complete this effort.) --- > group will develop extensions to imap2 which provide a similar capability. Re: Comparison with NFS: < provide more efficient searching and message parsing. --- > provide more efficient caching, searching and message parsing. Re: security: < authentication mechanisms when establishing a session, and interactions < with Privacy Enhanced Mail. --- > authentication mechanisms when establishing a session, and possible > interactions with Privacy Enhanced Mail. =========================================================================== 93.4.3 teg Interactive Mail Access Protocol Working Group (imap) Chair: Terry Gray gray@cac.washington.edu Mailing Lists: General Discussion: ietf-imap@cac.washington.edu To Subscribe: ietf-imap-request@cac.washington.edu Mail archive: ftp.cac.washington.edu /imap/imap_archive Description of Working Group: The Internet Interactive Mail Access Protocol (IMAP) working group is chartered to refine and extend the current IMAP2 protocol as a candidate standard for a client-server Internet email protocol to manipulate remote mailboxes as if they were local. An explicit objective is to retain compatibility with the growing installed base of IMAP2-compliant software. It is expected that the resulting specification will replace both RFC-1176 and the more recent (as yet unplublished) IMAP2bis extensions. A mail access protocol provides a uniform, OS-independent way of manipulating message data (email or bulletin board) on a remote message store (repository). Mail user agents implementing such a protocol can provide individuals with a consistent view of the message store, regardless of what type of computer they are using, and regardless of where they are connected in the network. Multiple concurrent sessions accessing a single remote mailbox, and single sessions accessing multiple remote mailboxes are both possible with this approach. There are no Internet standards in this area, and one is needed to define a consistent approach to the problem in the context of other Internet mail protocols including RFC-822, SMTP, and MIME. IMAP appears to be the only existing *open* protocol that achieves the above goals. Hence, the choice is either to invent a new protocol from scratch, or to refine IMAP2. IMAP2 is in production use at a number of large sites, and several commercial products based on it are now available. Operational experience has been very positive, and the installed base is growing. In the absence of any serious problems with the current specifications (IMAP2 plus IMAP2bis extensions), it makes little sense to start over, nor to abandon compatibility with the installed base. Comparison to POP. There is a Draft Standard describing the latest version of the Post Office protocol (POP3, RFC-1225). POP is a store-and-forward transport protocol that allows an MUA to retrieve pending mail from a mail drop (where it is then usually deleted automatically). IMAP, in contrast, is focused on remote mailbox manipulation rather than mail transport. Although IMAP is a functional superset of POP and can operate in the same mode, the two have different purposes and should not be viewed as competing. Comparison to PCMAIL. PCMAIL, defined in RFC-1056, uses the Distributed Mail System Protocol (DMSP). It has been relegated to Informational status by the IAB. A strength of DMSP is support for "disconnected operation" wherein a local message cache can be created for off-line processing, and later resynchronized with the main mail server. Preliminary discussions have taken place with members of the DMSP community on how to fold similar capabilities into IMAP2. The working group will develop extensions to imap2 which provide a similar capability. Commercial alternatives. Many of the vendor-specific remote mail access approaches are based on proprietary remote file system protocols that neither scale well nor support diverse types of client operating systems. Others are unsuitable candidates for Internet standardization due to licensing restrictions. Comparison with NFS. Achieving many of the stated goals is possible using a generic remote file access protocol such as NFS, rather than an application-specific email protocol. However, there are also some significant drawbacks, including: file locking on the mail server in the face of concurrent local and (possibly multiple) remote updates; network performance; and difficulty in implementing on small client machines. Moreover, using an application-specific protocol allows the server to provide more efficient caching, searching and message parsing. The latter is particularly important in the context of MIME, so that the client can request message structure information from the server, and thereafter retrieve only the body parts it needs. Security. Security-related tasks include how to incorporate secure authentication mechanisms when establishing a session, and possible interactions with Privacy Enhanced Mail. This working group's IMAP standardization activity complements (and does not compete with) parallel efforts to define the "IMSP" mail support protocol which will be layered on top of the resulting IMAP protocol. The mail support protocol work addresses issues of managing large email sites, such as determining on which mail server a particular user's incoming mail resides. Goals and Milestones: It is expected that most of the work of this group will be conducted via email. Opportunities to meet face-to-face at IETF meetings will be used initially to review the charter and context for the work, as well as presentations to help members get up to speed on IMAP. A goal is to have the IMAP2bis draft updated and submitted as an Internet draft in the July timeframe. The November IETF WG meeting would then focus on detailed review of the draft standard. Mar 93 IETF A BOF to review the working group charter, and discuss its relationship to the broader remote mail issues considered in previous IETF email BOFs. Jul 93 IETF Foreign travel restrictions may preclude several of the key players from attending the Amsterdam IETF, however, it may be possible to schedule a WG meeting for presentations and to solicit input from those who are normally unable to attend US IETF meetings. Nov 93 IETF Based on continuing email refinement of the text, use this meeting for a detailed review of Internet draft text. From owner-imap@cac.washington.edu Sun Apr 4 22:48:45 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25530; Sun, 4 Apr 93 22:48:45 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01182; Sun, 4 Apr 93 22:48:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01176; Sun, 4 Apr 93 22:48:02 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02855; Sun, 4 Apr 93 22:48:01 -0700 Date: Sun, 4 Apr 1993 22:30:55 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Notes from IMAP BOF 3/31/93 (Columbus IETF) To: imap@cac.washington.edu Cc: Megan Davies Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 1. Attendance: 16 people came (5 others expressed regret that they couldn't make it.) 13 asked to be added to the IMAP email list. 7 planned to attend the Amsterdam IETF. 2. Agenda: -Introductions -Draft WG Charter -Discussion 3. Results: There was general agreement that the focus of the proposed working group should be to refine and extend the existing IMAP2/IMAP2bis protocol, hopefully without breaking the installed base of IMAP2-capable software. The wording of the proposed WG charter was deemed generally acceptable. A list of desired IMAP extensions was made. Many of the proposed features appear to be within the scope of the CMU IMSP (Interactive Mail Support Protocol) project, rather than IMAP. Also, some are likely to be incompatible with current software. It was clear that disconnected operation, ala DMSP/PC-Mail, was a very high priority. 4. Wish list: -Support for disconnected operation -Offline sorting of mailbox -Background server searching and sorting -Shared mailbox per-user state (like a .newsrc, but for mailboxes) -Function to determine where to submit messages -Storage/retrieval of MUA configuration data -Minimal non-plaintext authentication -Minimal confidentiality (XOR with shared secret) -Test assertion that PEM does not affect IMAP -Remote printing (from IMAP server's copy of msg) -Improved searching 5. Next steps: The proposed WG charter, with minor modifications, will soon be submitted to the IETF application area directors for endorsement and forwarding to IESG for approval of the WG. The wish list will be combined with other input and categorized according to scope, compatibility, etc. 6. References Mailing list: imap@cac.washington.edu To subscribe: imap-request@cac.washington.edu IMAP2: RFC-1176 IMAP2bis extensions: /imap/imap2bis.txt on ftp.cac.washington.edu -teg From owner-imap@cac.washington.edu Tue Apr 6 21:04:50 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21500; Tue, 6 Apr 93 21:04:50 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00352; Tue, 6 Apr 93 21:04:25 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00346; Tue, 6 Apr 93 21:04:22 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Wed, 7 Apr 93 00:04:18 EDT Received: via switchmail; Wed, 7 Apr 1993 00:04:18 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Wed, 7 Apr 1993 00:03:46 -0400 (EDT) Received: via niftymail; Wed, 7 Apr 1993 00:03:33 -0400 (EDT) Date: Wed, 7 Apr 1993 00:03:27 -0400 (EDT) From: Chris Newman Subject: CMU-IMSP implementation underway To: imap@cac.washington.edu Message-Id: <734155407.12421.0@nifty.andrew.cmu.edu> I am currently working on implementing the IMSP spec sent to this list earlier. Note that we are focusing on the needs of a large site with multiple IMAP servers, mobile users, and flexible administrative needs. I'm including a document I wrote outlining the implementation plan I am using. This is a fluid document which can change as the IMSP spec is updated, and as I encounter unexpected problems. I'm sending it so that you can get a better idea of how we're thinking and what we're doing at CMU. Comments and suggestions are welcome. - Chris Newman Carnegie Mellon University Computing Services --------------------------------------- *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* CMU's IMSP server implementation -------------------------------- by Chris Newman draft 3/26/93 ASSUMPTIONS ----------- This document assumes you are familiar with both the IMSP and IMAP2bis protocols. TERMS ----- CMU-IMSP CMU's implementation of IMSP IMAP Interactive Mail Access Protocol (see RFC-1176, IMAP2bis documents) A protocol for users to access mail and bboards. IMSP Interactive Mail Support Protocol (see IMSP document) A protocol to manage multiple IMAP servers and provide support functions that are related to mail access. Update string An implementation dependent string which uniquely specifies a message within a folder. USP Un-Specified Protocol A currently unspecified protocol or set of protocol extensions for communication between IMAP and IMSP servers. FILES ----- CMU-IMSP will store its configuration files in a configuration directory (usually /var/imsp). Within this configuration directory are the following files (the .lock files are empty files used to prevent synchronization errors): options, options.lock Global options file. See the "OPTIONS" section below. bboards, bboards.lock List of available bboards, the servers they're on and the update string of the last message in the folder. See "BBOARDS" below. changed, changed.lock List of bboards that have been renamed or aliased. user Directory for user specific information. The user subdirectory will contain another subdirectory for each user on the system. The user specific subdirectories will contain the following: options, options.lock User options. See "OPTIONS" section below. mailboxes, mailboxes.lock List of mailboxes the user has, a flag indicating subscription status, an update string of the last message for which the user has read everything previous, and the server they are on. See "USER MAILBOX LISTS" below. bbsubs, bbsubs.lock List of bboards the user has accessed, a flag indicating subscription status, and an update string. See "SUBSCRIPTIONS" below. When the CMU-IMSP server becomes a replicated service, cross server locking and synchronization of these files will need to be implemented. All file access and file locking will be heavily modularized in expectation of this replication. OPTIONS ------- Server configuration, user configuration and some general information is made available through the options interface. Options may be read with the IMSP "GET" command and changed with the IMSP "SET" or "UNSET" commands. Four basic types of options are supported. "Magic" options are built into the server and may return different values at different times (e.g. the "date" option). "Non-visible" options may only be used by the config administrator, and are for configuration options that are of no interest to the user. "Read-only" options may not be changed by users. "Read-write" options may have a default (global) value, which may be overridden by the user's local options. Non-visible options appear read-only to a full administrator. Magic options usually appear as read-only. The options file contains a list of options in the following format: OPTION-NAME OPTION-TYPE OPTION-VALUE LF The OPTION-NAME is a string containing no spaces or CRLF characters and specifies the option. The OPTION-TYPE is a single character either 'N' (Non-visible), 'R' (Read-only) or 'W' (Read-Write). The OPTION-VALUE field has the option value with '¥n' for newlines, and '¥¥' for '¥'. Option names are case-insensitive, but option values may be case sensitive. By convention: Boolean options are on if their value is '+' and off if their value is '-'. Integer options are numeric with an optional '-' prefix. List options begin with '(', end with ')', and the different items are separated by spaces. If necessary, '"' could be used to quote list items containing parentheses and spaces. The "imsp.options.quota" option specifies the maximum number of kilobytes permitted in a user options file. Normal users may only set options in their user options file that don't shadow a global read-only option. Full administrators may change global options using the IMSP "SET" command and prefixing the option name with a '*'. ADMINISTRATION -------------- There will be three levels of administration provided by CMU-IMSP. The usernames in the "imsp.admin.subs" list option are allowed to view but not change other user's subscriptions and mailboxes (by issuing the LOGIN command with a null password). This is provided to allow a subscription statistics service such as CMU's "arbitron" or a delivery system to find the location of a user's INBOX. The "imsp.admin.bboards" level would be useful for a postmaster who administrates the entire bboard tree. The "imsp.admin.all" level (which includes all the others) allows full access to the CMU-IMSP server and would be useful for the system administrator. The administrator options will be lists of userids. PTS or DFS groups may be also be supported by a compile-time option. The following IMSP commands will be generally restricted in CMU-IMSP: MOVE, MOVE.BBOARD, ALIAS.BBOARD, RENAME.BBOARD, CREATE or CREATE.BBOARD with server_partition_list, and DELETE or DELETE.BBOARD with hostname. If the bboard "user..INBOX" is removed, then that user will be removed from the IMSP server database. LOGIN ACCESS ------------ Access to the server is controlled by the login command. The initial version will allow kerberos-style logins as well as plaintext logins. If the global option "imsp.create.new.users" is not set, then a user must also have a subdirectory in the "user" directory in order to log in. If "imsp.create.new.users" is set and the user has no INBOX, it will be created according the the "CREATE" policy below. An administrator with appropriate access may gain access to a user's MAILBOX namespace by issuing a second LOGIN command with that user's name and a NULL password. SERVER STRUCTURE ---------------- The CMU-IMSP server will run as a process which watches the appropriate port. When a connection from a client is made, the server process will fork to give each client its own process. The parent process will continue to watch for connections and will also periodically update the BBOARD LISTS (see next section). A limit on the number of connections to service could be added if deemed necessary. FAULT TOLERANCE --------------- Any bad protocol or improper syntax from the user will be rejected through the protocol. If a connection from a user is dropped, the server will make sure all files are up to date, and let the connection go. In the case of server disk errors, the server will abort (and remove itself from the pool if replicated servers are being used) and wait for the system administrator to clean up. User subscriptions and options should be backed up regularly for recovery purposes. If a proxy connection to an IMAP server fails, IMSP will respond to the user request which prompted the proxy with a failure message. CONTACTING IMAP SERVERS ----------------------- Because the MAILBOXES namespace is user specific, CMU-IMSP must be able to do proxy logins to the IMAP servers. When a user logs into CMU-IMSP with a plaintext password, this is not a problem. However, when a user logs into CMU-IMSP with kerberos, CMU-IMSP can't pretend to be that user to the IMAP servers. In order to support kerberos, the IMAP server must allow the CMU-IMSP identity kerberos authenticator as a valid password for any user. Initially the CMU-IMSP identity will be "imap.*". When we implement our own IMAP server, it will keep a list of valid IMSP identities. BBOARD LISTS ------------ The first time the CMU-IMSP server is started, no top level "bboards" file will exist. At this point the server will check the "imap.servers" option and contact each IMAP server in the list to find the available bboards by doing a "FIND ALL.BBOARDS *". The bboards file will have the following format: BBOARD-NAME IMAP-SERVER-LIST UPDATE-STRING LF The BBOARD-NAME is the name of that bboard. IMAP-SERVER-LIST is a list of hostnames where that bboard is stored. If IMAP-SERVER-LIST is the empty list "()", then it is assumed that BBOARD-NAME is located on the same server as its parent bboard (using '.' notation). UPDATE-STRING is the update string for that bboard (optional). BBOARD NAMESPACE ---------------- If the "imsp.share.mailboxes" option is set, then the "user.." namespace is reserved as a mapping from the MAILBOX namespace to the BBOARDS namespace. If the "imsp.external.subs" option is set, than names of the form {hostname}folder are reserved for external sites. USER MAILBOX LISTS ------------------ Information about the location of user mailboxes are stored in that user's "mailboxes" file. The structure of the file is as follows: MAILBOX-NAME SUBSCRIPTION-STATUS UPDATE-STRING [SERVER-NAME] LF MAILBOX-NAME is the name of the mailbox. SUBSCRIPTION-STATUS is a flag: '0' indicates user is not subscribed and '1' indicates user is subscribed. UPDATE-STRING indicates how much the user has seen. The optional SERVER-NAME specifies the hostname where the mailbox is located. If it is omitted, the server is assumed to be the one specified by the "imap.default.server" option. If user logs in and has no mailboxes file, CMU-IMSP will contact the IMAP server specified by the "imap.default.server" option, do a proxy-login and a "FIND MAILBOXES *". The "SUBSCRIBE MAILBOX" and "UNSUBSCRIBE MAILBOX" IMSP commands are used to modify the SUBSCRIPTION-STATUS field. If the option "imsp.external.subs" is set, then a user may subscribe to any mailbox name with the '{' prefix. The subscription will be returned by the FIND MAILBOXES or FIND UNSEEN.MAILBOXES with an empty list of server locations. This is only appropriate for sites whose clients all recognize the {hostname}mailbox notation. SUBSCRIPTIONS ------------- Information about subscriptions to mailboxes are stored in the mailboxes file (see the USER MAILBOX LISTS above). Information about subscriptions to bboards are stored in the user's "bbsubs" file with the following format: BBOARD-NAME SUBSCRIPTION-STATUS UPDATE-STRING LF BBOARD-NAME is the name of the bboard. SUBSCRIPTION-STATUS is a flag: '0' indicates user is not subscripted and '1' indicates user is subscribed. UPDATE-STRING indicates how much the user has seen. Subscriptions may be adjusted with the IMSP "SUBSCRIBE" and "UNSUBSCRIBE" commands. A user is not permitted to unsubscribe to a bboard listed in the "imsp.required.bbsubs" option. If a user has no bbsubs file, a new one will be created with a subscription to each bboard listed in the "imsp.default.bbsubs" option. If the option "imsp.external.subs" is set, then a user may subscribe to any bboard name with the '{' prefix. The subscription will be returned by the FIND BBOARDS or FIND UNSEEN.BBOARDS with an empty list of server locations. This is only appropriate for sites whose clients all recognize the {hostname}bboard notation. If a user tries to subscribe to a name of the form "user..*" and the "imsp.share.mailboxes" option is set, then the ACL for that folder (if existent) will be checked to see if the user has lookup access, and the subscription will be permitted if the user does. Error messages should not allow the current user to find out what folders may or may not have. The mailboxes and bbsubs files will be kept in alphabetic order. By default, the FIND commands will return results in this order. A user may adjust the order returned by the "FIND BBOARDS *" and "FIND UNSEEN.BBOARDS *" commands by setting their "bboard.order" option. This option is a list of patterns (as would be used with the FIND command). For each pattern, all subscriptions that match that pattern (and have not yet been sent) will be sent in alphabetic order. Any subscriptions not matched by any pattern will be sent afterwards. The "mailbox.order" option functions the same, but it adjusts the responses to the "FIND MAILBOXES *" and "FIND UNSEEN.MAILBOXES *" commands. FIND UNSEEN ----------- The "FIND UNSEEN.*" commands will be implemented as follows: all new subscriptions will default to an unseen state, so by default "FIND UNSEEN.BBOARDS/UNSEEN.MAILBOXES" will be the same as "FIND BBOARDS/MAILBOXES". The "LAST" and "SEEN" IMSP extension commands will be used to change seen/unseen information as follows: tag LAST MAILBOX mailbox update-string userid tag LAST BBOARD bboard update-string These commands will be sent from an IMAP server to CMU-IMSP periodically to indicate the mailboxes and bboards with new messages. tag SEEN MAILBOX mailbox update-string userid tag SEEN BBOARD bboard update-string userid These commands will be sent from an IMAP server to CMU-IMSP only when a user finishes reading all messages on the specified mailbox or bboard. For bboards, a "LAST" will specify the update string to be placed the the bboards file for a given bboard, and a "SEEN" will specify the update string to be placed in the bbsubs file for a given user and bboard. For mailboxes, a "LAST" will specify that a NULL should be placed in the update string for that mailbox, and a "SEEN" will specify that that value should be placed in the update string. It is expected that the IMAP servers will be the only users allowed to use the "SEEN" and "LAST" commands. The "FIND UNSEEN.BBOARDS" command will list all bboards where the bbsubs update string differs from the bboards update string (or where the strings are NULL). The "FIND UNSEEN.MAILBOXES" will list all mailboxes with a NULL update string. IMSP SERVER REPLICATION ----------------------- A single IMSP server will probably be insufficient for a medium to large site. Therefore consideration must be taken on how to replicate the CMU-IMSP database between cooperating CMU-IMSP servers. An inter-IMSP server locking and data transfer protocol will need to be found. One possibility is to use the ubik protocol from Transarc. This would, however, prevent us from being able to distribute a replicated IMSP implementation outside of CMU. Load balancing between IMSP servers should be provided by DNS. For the first implementation (which won't include IMSP server replication), care will be taken to keep all access to potentially shared data highly modularized. BBOARD REPLICATION ------------------ IMSP supports replication of mailboxes and bboards on multiple servers. CMU-IMSP will only support replication of bboards. To do this, CMU-IMSP will have to designate a master site for a bboard and manage replication through the USP. The master site will be the first bboard listed in the server list. In addition, the USP may support a server-load indicator so that CMU-IMSP can sort the output of the list of servers for FIND command by a load parameter. Alternatively, the CMU-IMSP server could simply randomize the list. The FIND command will return unsorted server lists to any administrator (so that the administrator can determine the master site). If a "CREATE.BBOARD" or "MOVE.BBOARD" command with replication sites is specified and the bboard already exists on some of the replication sites, they will simply be added to the list and no error will be generated. MOVE ---- The IMSP "MOVE" and "MOVE.BBOARD" are used to move folders between IMAP servers. This requires a command in USP (or IMAP) to direct an IMAP server to send a folder to another IMAP server. CREATE ------ The IMSP "CREATE" and "CREATE.BBOARD" commands are used to create new mailboxes and bboards. Both commands adjust the mailboxes and bboards files as appropriate. If no hostname is specified on the "CREATE" command, the hostname will be selected as follows: 1) If the user has an INBOX, the server the INBOX is on. 2) If the user has a "imap.default.server" option set, that server is used. 3) If the USP has a "request server free space" option, then the server with the most free space in the "imap.new.mailbox.servers" list will be used. 4) Otherwise a random server from the "imap.new.mailbox.servers" list will be selected. "CREATE" will be implemented by proxy to an IMAP server. If no hostname is specified on the "CREATE.BBOARD" command, then the policy used to select a location for the bboard is specified by the "imsp.create.policy" option. Policy types to be implemented in CMU-IMSP include the following: "random" selects a random server from the "imap.new.bboard.servers" list. "parent" selects the server that the "parent" bboard is located on, if no parent bboard is found, it falls back to another policy. "free-space" selects the server with the most available free space. This can only be implemented if a free space request is available through USP. The "CREATE.BBOARD" command requires USP. CHANGED SUBSCRIPTIONS --------------------- The "changed" file allows a lazy evaluation method of updating user bbsubs files. When a user is subscribed to a non-existent bboard, the "changed" file will be checked for an entry for that bboard. The changed file contains lines of the form: OLD-BBOARD NEW-BBOARD TIMESTAMP LF OLD-BBOARD is the name of a non-existent bboard and NEW-BBOARD is the name of the new bboard which has replaced OLD-BBOARD. The TIMESTAMP is provided as a mechanism to expire changed entries to prevent the file from growing without bound. If the TIMESTAMP has a value of 0, then the entry represents a permanent alias. If a bboard is renamed more than once, the previous entries in the "changed" file will be updated to prevent chaining. "user..*" bboards will only be entered into this file if the "RENAME.BBOARD" command is used on them. Otherwise users are expected to keep track of shared mailboxes that have been renamed. RENAME ------ If a user mailbox is renamed with the IMSP "RENAME" command, the mailboxes file should be adjusted as appropriate. The IMSP "RENAME.BBOARD" command will adjust the bboards file and add a line to "changed" file. This allows modification of individual user's bbsubs file to be done in a lazy-evaluation style and also allows CMU-IMSP to alert the user (through an unsolicited OK) that the bboard has been renamed. The "RENAME" command will be implemented by proxy to the appropriate IMAP server. The "RENAME.BBOARD" command will require USP or an IMAP extension. DELETE ------ The IMSP "DELETE" and "DELETE.BBOARD" commands will adjust the bboards or mailboxes file as appropriate (no change is necessary for deleting a replication site). When a user has a subscription entry that refers to a non-existent bboard (that doesn't have an entry in the changed file) they will be informed that the bboard was deleted and the subscription entry will be removed. The "DELETE" command will be implemented by proxy to the appropriate IMAP server. The "DELETE.BBOARD" command will require USP or an IMAP extension. ACLS ---- The IMSP "SETACL", "DELETEACL", "GETACL" and "MYACL" commands only require location of the bboard on the part of the CMU-IMSP server. The rest is dependent upon implementing ACL support in either IMAP or USP. CMU-IMSP will assume that the lookup access right is always set for all bboards. LOGGING ------- CMU-IMSP will support multiple levels of logging using the standard UNIX syslog mechanism. Logging will be modular so that an alternate mechanism could be used if syslog is deemed too primitive. The "imsp.log.level" option will specify the logging level (each level includes the previous levels) as follows: 0 - only fatal errors will be sent to syslog as LOG_ERROR. 1 - warnings will be sent to syslog as LOG_WARNING. 2 - bboard administrative actions (including new bboard creations) will be sent to syslog as a LOG_NOTICE. The message will include the user, hostname, type and time of the action. 3 - every time a user logs in or out, a syslog LOG_NOTICE message will be sent. 9 - debugging messages will be sent to syslog as LOG_DEBUG. MONITORING ---------- The initial implementation will keep in mind that we will want to monitor serious IMSP errors and possibly the number of active connections to a given server. These might be made available through SNMPcon or a similar mechanism. USP FEATURES ------------ A directed move/copy function is necessary to implement the IMSP "MOVE"/"MOVE.BBOARD" command and replication. The CMU-IMSP server must be able to request available free space on a server in order to implement load-balanced creation policies. ACL support should be added to USP (or IMAP) in order to allow implementation of the IMSP ACL commands. A way of finding a system load parameter on IMAP servers should be added to support load-balanced bboard replication. Support would also be needed in order to implement the partition based CREATE feature. Also extensions to IMAP or USP commands would be needed to implement the CREATE.BBOARD, DELETE.BBOARD, RENAME.BBOARD, and ALIAS.BBOARD. INTERFACE TO DELIVERY SYSTEM ---------------------------- The delivery system is expected to use CMU-IMSP to locate the appropriate IMAP server to deliver a message. It must have "imsp.admin.subs" level access to locate the INBOX for any user. PREDEFINED OPTIONS ------------------ The following option names are reserved in this implementation. bboard.listorder [READ-WRITE] This is a list of patterns used to order the results of a "FIND BBOARDS *" or "FIND UNSEEN.BBOARDS *" command. bcc.mailbox [READ-WRITE] The name of a mailbox to APPEND blind carbon copies. date [READ-ONLY] (magic) When a user asks for the value of the date option, an RFC-822 date string should be returned with the current time. This is provided to assist small clients with unreliable clocks. delivery.hosts [READ-ONLY] This contains the list of recommended SMTP hosts for mail delivery. domain [READ-ONLY] When a user asks for the domain option, the local mail domain is returned. from [READ-ONLY] (magic) When a user asks for the value of the from option, an RFC-822 address for that user is returned. imap.default.server [READ-ONLY] This specifies the default imap server for a user. imap.new.bboard.servers [NON-VISIBLE] This specifies a list of imap servers where new bboards may be created. imap.new.mailbox.servers [NON-VISIBLE] This specifies a list of imap servers where an INBOX may be created for a new user. imap.servers [READ-ONLY] This global option contains a list of all IMAP servers managed by IMSP. imsp.admin.all [NON-VISIBLE] This is a list of users that may use any implemented IMSP features. imsp.admin.bboards [NON-VISIBLE] This is a list of users that may create, rename, delete and alias any bboards. imsp.admin.subs [NON-VISIBLE] This is a list of users allowed to view (but not change) other user's subscriptions and mailboxes. imsp.create.new.users [NON-VISIBLE] If this global option is on, the directory for a new user will be created automatically. Otherwise the system administrator must create a directory for each authorized user. imsp.create.policy [NON-VISIBLE] This is specifies the creation policy for new bboards. The option is specified as a site-defined string. imsp.default.bbsubs [NON-VISIBLE] A list of the default bboard subscriptions given to a new user. imsp.external.subs [NON-VISIBLE] If this is set, subscriptions to external mailboxes and bboards are allowed by using the {hostname}folder notation. imsp.log.level [NON-VISIBLE] This integer specifies the amount of logging to be done. imsp.options.quota [NON-VISIBLE] This is an integer specifying the maximum number of kilobytes in an options file. imsp.required.bbsubs [NON-VISIBLE] Users will not be allowed to unsubscribe to bboards in this list. imsp.share.mailboxes [NON-VISIBLE] If this global option is on, then bboard names beginning with the prefix "user.." are reserved as mappings of individual user's MAILBOXES into the BBOARDS namespace. In addition, it permits users to allow other users to read their mailboxes if ACLs permit. mailbox.listorder [READ-WRITE] This is a list of patterns used to order the results of a "FIND MAILBOXES *" or a "FIND UNSEEN.MAILBOXES *" command. PROJECT PLAN ------------ Phase 1 - Basic Implementation The goal of phase 1 will be to produce an IMSP server with all basic functionality that works with a stock IMAP client. Only features which can be implemented without the USP will be done. This includes the following: Options: including GET, SET, and UNSET. FIND * (although the "SEEN" and "LAST" commands won't be implemented) Administrative levels with LOGIN SUBSCRIBE, UNSUBSCRIBE CREATE/RENAME/DELETE without replication or free-space create policy. Phase 2 - Unseen Information This will involve implementing the "SEEN" and "LAST" commands as well as modifying an IMAP server to use them. Phase 3 - Advanced features This will involve implementing the USP, "MOVE", "MOVE.BBOARD", create/rename/delete/alias for bboards, ACLs, and free-space create policy. It will probably be necessary to write our own IMAP implementation in order to make the IMAP and IMSP servers work together smoothly with these features. Phase 4 - Replicated IMSP This might be done before phase 3, as it has no dependencies on IMAP modifications. This involves adding inter-IMSP server synchronization. Phase 5 - Replicated bboards This could be done before phase 4 but depends on phase 3. Add replication support for bboards as well as load-balanced server lists returned by the FIND command. From owner-imap@cac.washington.edu Fri Apr 16 03:24:33 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29663; Fri, 16 Apr 93 03:24:33 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04682; Fri, 16 Apr 93 02:25:22 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04676; Fri, 16 Apr 93 02:25:17 -0700 Received: from ppsw.cam.ac.uk by ppsw1.cam.ac.uk id <02555-0@ppsw1.cam.ac.uk>; Fri, 16 Apr 1993 10:24:57 +0100 From: Tim Brooks To: imap@cac.washington.edu, pine-info@cac.washington.edu Subject: ECSMail (?) Reply-To: T.Brooks@UCS.Cam.AC.UK Date: Fri, 16 Apr 1993 10:24:53 +0100 Message-Id: <"ppsw1.cam..587:16.03.93.09.25.10"@ppsw.cam.ac.uk> I've heard a rumour of a PC Windows Mail Client based on the c-client libraries. Called ECSMail? Can anyone confirm/deny this and tell me if/where it is available. Many thanks, Tim Brooks Mail-Support(@UK.AC.Cam.UCS, @UCS.Cam.AC.UK) University of Cambridge Computing Service Tel: 0223-334709, Int: +44 223 334709 New Museums Site Fax: 0223-334678, Int: +44 223 334678 Pembroke Street Telex: 81240 CAMSPL G CAMBRIDGE E-Mail(JNT): T.Brooks@UK.AC.Cam.UCS CB2 3QG United Kingdom "(Internet): T.Brooks@UCS.Cam.AC.UK X.400: /I=T/S=Brooks/OU=Computing-Service/O=Cambridge/PRMD=UK.AC/ADMD= /C=GB/ From owner-imap@cac.washington.edu Sat Apr 17 07:35:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01150; Sat, 17 Apr 93 07:35:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19750; Sat, 17 Apr 93 07:34:47 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from livbird.liv.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19744; Sat, 17 Apr 93 07:34:42 -0700 Received: from liverbird.liverpool.ac.uk by liverbird.liverpool.ac.uk with Local-SMTP (PP) id <19324-0@liverbird.liverpool.ac.uk>; Sat, 17 Apr 1993 15:26:44 +0100 Date: Sat, 17 Apr 1993 15:19:27 +0100 (BST) From: Alan Thew Subject: Re: ECSMail (?) To: Tim Brooks Cc: imap@cac.washington.edu, pine-info@cac.washington.edu In-Reply-To: <"ppsw1.cam..587:16.03.93.09.25.10"@ppsw.cam.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="587219625-594766692-735056802:#19319" --587219625-594766692-735056802:#19319 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Apr 1993, Tim Brooks wrote: > I've heard a rumour of a PC Windows Mail Client based on the c-client > libraries. Called ECSMail? Can anyone confirm/deny this and tell me > if/where it is available. > The software exists and I enclose the original announcement which was mailed to the pine-info list. I've not tried it yet but have all the components. Note that the software now resides in the directory /pub/windows/utilities I'd be grateful if anyone who's tried this would share their experiences. Alan Thew --587219625-594766692-735056802:#19319 Content-Type: APPLICATION/octet-stream; name="ANNOUNCE.TXT" Content-ID: Content-Description: ISA has developed a new Mail User Agent (MUA) for processing electronic mail on networks. It is named "ECSMail". ECSMail can function as both a "remote" MUA and a "local" MUA. While functioning in remote mode, it will access a remote message store using standards based mail access protocols. In local mode, it will access a local message store using system dependent message store access routines. ECSMail is has been designed and implemented to be as independent as possible from operating system, display, and network protocols. We have achieved this by building driver libraries for the OS and displays, and using Mark Crispin's c-client drivers for message store access (both local and remote message stores). Using this strategy, we are planning to support the following operating systems, display, and mail protocol combinations: OS - Unix, DOS, OS/2 v2, MacOS, NT Displays - X11 (R4, R5, Openlook, Motif), MS Windows v3, Presentation Manager, Mac Finder MAP Protocols - IMAP2, P7, PP7 MTP Protocols - SMTP, P1 It is our full intention to make this run on as many platforms, with as many different mail application protocols as possible. With ECSMail we plan to provide many interesting features, such as: * Multi-part, multimedia mail messages: - supporting both MIME and X.400 message formats - files (e.g. binaries, images, text, voice, application) can be attached and sent along with the message. - the different parts of the messsage can be extracted and displayed (using the necessary application) to the user. * Multiple simultaneous folder access and management (drag and drop messages or blocks of messages between folders). * Hierarchical folder structures. * Virtual folders within folders. Messages can be grouped using any combination of message header criteria into a virtual folder. Messages in a virtual folder can be listed and manipulated as a single object. This supports threading of messages within folders. * Integration of multicast (mail) and broadcast (NEWS, BBS) message stores via into a single interface. NEWS groups appear as a list of folders and threading of broadcast messages will be supported. * Privancy Enhanced Mail (PEM). Support encryption of message parts, digital signatures, and digital timestamps. * Forms mail. Messages can be composed inside of a forms interface as a special message part. It will include form design and display tools. * Draft message support. Users will be able to create and store standard draft messages, and select draft messages from both public and private draft message stores. * Integration with "mail enabled applications". * Personal configuration files. * Asynchronous new mail notification. * Personal address book lookup and management. Addresses can be loaded manually, copied from incoming mail, or copied from an X.500 DUA (see next). * Integration with X.500 Directory Services. The user can query local and network-wide address information while composing messages. Addresses can be copied from the Directory User Agent to the user's local address book. This facility will be optionally available for those who have the X.500 Directory Service capability. What Is Available Now --------------------- A BETA demonstration version of the Microsoft Windows version of ECSMail is available via anonymous ftp from ftp.srv.ualberta.ca in the directory /pub/networking/win/mail/ecs.tar.Z This version of ECSMail only supports the TCP/IP based mail access and transport protocols (IMAP2, SMTP), and can deliver MIME format messages. It provides what we term "basic functionality" - it does the things that most mailers do. Features such as the virtual folders, and NEWS message sources have not been implemented at this time. We encourage you to get the software and try it out. This version of ecs is released for demonstration purposes only - IT IS NOT CURRENTLY IN THE PUBLIC DOMAIN. As I have mentioned earlier, we are not currently charging for the product, and are in the process of evaluating different forms of funding for the software. There are some restrictions on what you can do with the software at this time. The mailer is designed to support several different TCP/IP stacks through the use of Windows DLLs. Currently we support the following TCP/IP stacks: * Beame and Whiteside - BWTCP 2.x * Sun Microsystems - PCNFS 4.x * DEC Pathworks v We are currently working on providing: * Microsoft WinSock DLL compliance * FTP Software - PCTCP 2.04 If you are interested in supporting another TCP/IP stack, then provide us with a copy of the stack and development kit - it must have a sockets API - and we'll try to provide a DLL interface for it. How will we fund ECSMail? ------------------------- There are two funding methods for ECSMail - maintenance contracts and development contracts. Maintenance contracts are signed with organizations that want support and software maintenance on the ECSMail software. This will include free software upgrades and immediate response to software problems. The cost of the maintenance is designed to be far less than purchase->upgrade cost of conventional shrinkwrapped software. The cost is based on the number of installations that are in place. The organization will never be charged more than an agreed upon maximum. As the number of installations increases, the per seat cost decreases such that maximum is never exceeded. An organization can install as many copies of ECSMail as they like. Development contracts are signed to produce new functionality in the ECSMail product. ISA has identified a number of potential functionality improvements that it would like to make to ECSMail. We also believe that clients will have a number of features that they would like to see added to the product. The cost of the contract is determined by the amount of work required to complete the development, and the number of organizations contributing to the development. The more organizations that contribute, the lower the cost. ISA publishes a detailed list of feature development projects that it plans to run in the ecs-info mailing list (see below). Mailing lists ------------- There is an ecs mailing list. To join the mailing list send a message to ecs-info-request@edm.isac.ca To submit messages to the mailing list, send mail to ecs-info@edm.isac.ca If there are problems with the list, then send mail to owner-ecs-info@edm.isac.ca --587219625-594766692-735056802:#19319-- From owner-imap@cac.washington.edu Sun Apr 18 19:37:09 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20535; Sun, 18 Apr 93 19:37:09 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14721; Sun, 18 Apr 93 19:36:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Apr 18 20:20:26 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20932; Sun, 18 Apr 93 20:20:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28842; Sun, 18 Apr 93 20:20:07 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Apr 18 22:10:34 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22051; Sun, 18 Apr 93 22:10:34 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15098; Sun, 18 Apr 93 22:10:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Apr 19 10:47:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05401; Mon, 19 Apr 93 10:47:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05282; Mon, 19 Apr 93 10:47:43 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Apr 19 14:01:45 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12687; Mon, 19 Apr 93 14:01:45 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19409; Mon, 19 Apr 93 14:01:35 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Apr 19 23:07:03 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22061; Mon, 19 Apr 93 23:07:03 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13519; Mon, 19 Apr 93 23:06:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13513; Mon, 19 Apr 93 23:06:25 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02151; Mon, 19 Apr 93 23:06:19 -0700 Date: Mon, 19 Apr 1993 23:02:17 -0700 (PDT) From: Terry Gray Subject: IMAP WG Charter w. Revised Milestones To: IESG Application Directorate Cc: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Erik et al, Per your request, here is an IMAP charter with more concrete milestones added. (The rest of the text is unchanged.) -teg -------------------------------------------------------------------------- 93.4.19 teg Interactive Mail Access Protocol Working Group (imap) Chair: Terry Gray gray@cac.washington.edu Mailing Lists: General Discussion: ietf-imap@cac.washington.edu To Subscribe: ietf-imap-request@cac.washington.edu Mail archive: ftp.cac.washington.edu /imap/imap_archive Description of Working Group: The Internet Interactive Mail Access Protocol (IMAP) working group is chartered to refine and extend the current IMAP2 protocol as a candidate standard for a client-server Internet email protocol to manipulate remote mailboxes as if they were local. An explicit objective is to retain compatibility with the growing installed base of IMAP2-compliant software. It is expected that the resulting specification will replace both RFC-1176 and the more recent (as yet unplublished) IMAP2bis extensions. A mail access protocol provides a uniform, OS-independent way of manipulating message data (email or bulletin board) on a remote message store (repository). Mail user agents implementing such a protocol can provide individuals with a consistent view of the message store, regardless of what type of computer they are using, and regardless of where they are connected in the network. Multiple concurrent sessions accessing a single remote mailbox, and single sessions accessing multiple remote mailboxes are both possible with this approach. There are no Internet standards in this area, and one is needed to define a consistent approach to the problem in the context of other Internet mail protocols including RFC-822, SMTP, and MIME. IMAP appears to be the only existing *open* protocol that achieves the above goals. Hence, the choice is either to invent a new protocol from scratch, or to refine IMAP2. IMAP2 is in production use at a number of large sites, and several commercial products based on it are now available. Operational experience has been very positive, and the installed base is growing. In the absence of any serious problems with the current specifications (IMAP2 plus IMAP2bis extensions), it makes little sense to start over, nor to abandon compatibility with the installed base. Comparison to POP. There is a Draft Standard describing the latest version of the Post Office protocol (POP3, RFC-1225). POP is a store-and-forward transport protocol that allows an MUA to retrieve pending mail from a mail drop (where it is then usually deleted automatically). IMAP, in contrast, is focused on remote mailbox manipulation rather than mail transport. Although IMAP is a functional superset of POP and can operate in the same mode, the two have different purposes and should not be viewed as competing. Comparison to PCMAIL. PCMAIL, defined in RFC-1056, uses the Distributed Mail System Protocol (DMSP). It has been relegated to Informational status by the IAB. A strength of DMSP is support for "disconnected operation" wherein a local message cache can be created for off-line processing, and later resynchronized with the main mail server. Preliminary discussions have taken place with members of the DMSP community on how to fold similar capabilities into IMAP2. The working group will develop extensions to imap2 which provide a similar capability. Commercial alternatives. Many of the vendor-specific remote mail access approaches are based on proprietary remote file system protocols that neither scale well nor support diverse types of client operating systems. Others are unsuitable candidates for Internet standardization due to licensing restrictions. Comparison with NFS. Achieving many of the stated goals is possible using a generic remote file access protocol such as NFS, rather than an application-specific email protocol. However, there are also some significant drawbacks, including: file locking on the mail server in the face of concurrent local and (possibly multiple) remote updates; network performance; and difficulty in implementing on small client machines. Moreover, using an application-specific protocol allows the server to provide more efficient caching, searching and message parsing. The latter is particularly important in the context of MIME, so that the client can request message structure information from the server, and thereafter retrieve only the body parts it needs. Security. Security-related tasks include how to incorporate secure authentication mechanisms when establishing a session, and possible interactions with Privacy Enhanced Mail. This working group's IMAP standardization activity complements (and does not compete with) parallel efforts to define the "IMSP" mail support protocol which will be layered on top of the resulting IMAP protocol. The mail support protocol work addresses issues of managing large email sites, such as determining on which mail server a particular user's incoming mail resides. Goals and Milestones: It is expected that most of the work of this group will be conducted via email. Opportunities to meet face-to-face at IETF meetings will be used initially to review the charter and context for the work, as well as presentations to help members get up to speed on IMAP. A goal is to have the IMAP2bis draft updated and submitted as an Internet draft in the July timeframe. The November IETF WG meeting would then focus on detailed review of the draft standard. Mar 93 IETF A BOF to review the working group charter, and discuss its relationship to the broader remote mail issues considered in previous IETF email BOFs. Jun 93 Submit Internet-draft, integrating RFC-1176 and IMAP2bis doc. Jul 93 IETF Foreign travel restrictions may preclude several of the key players from attending the Amsterdam IETF, however, it may be possible to schedule a WG meeting for presentations and to solicit input from those who are normally unable to attend US IETF meetings. Sep 93 Incorporate changes for disconnected service, etc, and submit as Proposed Standard. Nov 93 IETF Based on continuing email refinement of the text, and implementation experience, use this meeting for a detailed review of Proposed Standard text. From owner-imap@cac.washington.edu Tue Apr 20 06:56:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28778; Tue, 20 Apr 93 06:56:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16052; Tue, 20 Apr 93 06:55:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from watson.ibm.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16046; Tue, 20 Apr 93 06:55:48 -0700 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2203; Tue, 20 Apr 93 09:55:48 EDT Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0" id 7592; Tue, 20 Apr 1993 09:55:42 EDT Received: from WHCHUNG1.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Tue, 20 Apr 93 09:55:41 EDT Return-Path: Received: by WHCHUNG1.watson.ibm.com (IBM OS/2 SENDMAIL 1.2.8/) id AA0164; Tue, 20 Apr 93 09:50:21 -0700 Message-Id: <9304201650.AA0164@WHCHUNG1.watson.ibm.com> Date: Tue, 20 Apr 93 09:31:11 EST From: William Chung Reply-To: William Chung To: IMAP Interest List Subject: Rich, hierarchical mail object storage in IMAP X-External-Networks: yes We've uncovered a couple of issues during our post-Columbus IETF examination of IMAP we'd like to raise. These issues concern how IMAP treats mailboxes. First of all, IMAP assumes a UNIX style mail storage area. This means mailboxes are stored in a flat fashion with no way to accomodate something like a hierarchical folder tree. For example, there doesn't seem any way to retrieve a description of the user's mail storage area from the server and have the client let the user browse through the mail tree to select a folder/mailbox of interest. We'd like to see a richer mailbox organization model in IMAP to accomodate users with lots of mail. A way of specifying and querying pathnames in IMAP filenames independent of operating system would probably suffice. Does IMAP already provide some mail organization operations we've somehow missed? Next, a related issue. IMAP assumes just one type of mail object: the mailbox. How can a richer set of mail object types be accomodated? For example, most users keep things like address books, folders, etc. There doesn't seem to be any to store such non-mailbox objects on an IMAP server. We'd like to see an extensible mechanism for storing objects other than mailboxes on an IMAP server. Maybe some additional FETCH verbs are all that would be necessary... Your comments are much appreciated! - William Chung. IBM Research whchung@watson.ibm.com From owner-imap@cac.washington.edu Tue Apr 20 09:52:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03177; Tue, 20 Apr 93 09:52:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18846; Tue, 20 Apr 93 09:52:20 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SUMEX-AIM.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18840; Tue, 20 Apr 93 09:52:18 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by SUMEX-AIM.Stanford.EDU (4.1/inc-1.0) id AA20166; Tue, 20 Apr 93 09:52:16 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA00525; Tue, 20 Apr 93 09:50:50 -0700 Date: Tue, 20 Apr 1993 09:40:41 -0700 (PDT) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: IMAP WG Charter w. Revised Milestones To: Terry Gray Cc: IESG Application Directorate , imap@cac.washington.edu In-Reply-To: Terry Gray's message of Mon, 19 Apr 1993 23:02:17 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Terry, in your comparision with NFS you ought to mention that IMAP has the distinct advantage of being able to access mail at remote (not local to your own network) sites efficiently. NFS takes a big performance loss as soon as one introduces routers. And, certainly one cannot use NFS across the country! Since IMAP's introduction to our laboratory in 1987 I have carefully observed the impact of IMAP network traffic in comparion to NFS, ftp, X11, etc ... Currently, we routinely have 50-75 imapusers locally, and even when this number was more than double (we added an additional server isolated behind a bridge), IMAP has never taken even 1% of the total packet traffic. In fact IMAP coupled with SMTP is about 1%. When Mark and our group designed this protocal we wanted to maximize the information and at the same time minimize the network utilization. I think this goal has clearly been acheived. IMAP is extremely frugal with respect to its bandwidth utilization. Bill From owner-imap@cac.washington.edu Tue Apr 20 11:37:28 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06488; Tue, 20 Apr 93 11:37:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20735; Tue, 20 Apr 93 11:37:15 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20729; Tue, 20 Apr 93 11:37:13 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Tue, 20 Apr 93 14:36:59 EDT Received: via switchmail; Tue, 20 Apr 1993 14:36:52 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Apr 1993 14:36:10 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Apr 1993 14:35:48 -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; Tue, 20 Apr 1993 14:35:36 -0400 (EDT) Message-Id: Date: Tue, 20 Apr 1993 14:35:36 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: IMSP comment replies In-Reply-To: References: Beak: Is My apologies for taking so long to reply to Mark's comments on IMSP. Mark Crispin writes: > 1) Should the wildcard syntax used by FIND be limited to the TOPS-20 wildcard > characters selected by IMAP2? I believe so. One of the goals of IMSP is to be as similar to IMAP in syntax and structure as possible, in order to simplify client implementations. The IMAP wildcard syntax is sufficient for the task, I see insufficient advantage to using something more powerful > 2) I like the way IMSP deals with server names in FIND results. Much better > than IMAP2. However, there's one additional improvement to be made, which > is to include the pattern in the results. My position is that folder names in FIND results should match the source pattern syntactically, as well as semantically. (If the search pattern was "FOO*", all results should start with the three characters "FOO". A client that cares should be able to sort out the replies using that information. Including the pattern in the results breaks the model of unsolicited data. If we are to go this route, we might as well just return the tag corresponding to the request. I think it is far better to allow a server to tell a client "mailbox FOOBAR now has unread messages" outside the context of any pending FIND command. When it does this, it shouldn't have to pick a search pattern corresponding to one of the previous FIND commands. > 5) Why not fix the ``design flaw'' by requiring that FIND ALL.mumble indicate > subscription status. You don't have to be bug-for-bug matching with IMAP. My idea is to return a list of attributes associated with the mailbox. For example: a002 FIND ALL.MAILBOXES * * MAILBOX INBOX (¥SUBSCRIBED) (imap1.podunk.edu) * MAILBOX FOOBAR (¥SUBSCRIBED ¥UNSEEN) (imap23.podunk.edu) * MAILBOX SENT () (imap1.podunk.edu) a002 OK FIND completed I put the flags list before the server list to make addition of this extension to IMAP easier. I use the term "attributes" instead of "flags" to avoid confusion with the flags associated with messages. > 7) Instead of CREATE and CREATE.BBOARD, I suggest CREATE MAILBOX and > CREATE BBOARD & etc. for the other commands. IMAP has "CREATE" for creating mailboxes. I want to keep the syntax for IMSP the same as IMAP where possible. > 8) I'm not convinced that a user's private address book couldn't be part of > the GET/SET stuff instead of having to wait for directory services. I will address this in a separate message. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Apr 20 15:16:57 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13689; Tue, 20 Apr 93 15:16:57 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24269; Tue, 20 Apr 93 15:16:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24263; Tue, 20 Apr 93 15:16:35 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Tue, 20 Apr 93 18:16:24 EDT Received: via switchmail; Tue, 20 Apr 1993 18:16:16 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Apr 1993 18:14:38 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 20 Apr 1993 18:10:21 -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; Tue, 20 Apr 1993 18:08:06 -0400 (EDT) Message-Id: Date: Tue, 20 Apr 1993 18:08:06 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Address books & IMSP Beak: is Not The March draft of the IMSP protocol specification listed the "user address book" as an issue that was deferred, noting that it probably belonged in a separate user directory service. It is clear to us that a user address book capability is strongly desired in the marketplace, to the point where its absence could prevent the wide acceptance of a mail system. Per-user address books can be implemented using the option facility of IMSP. A portion of the option namespace can be reserved for address book entries and suitable naming conventions can be adopted. For example, one might have: a005 GET ADDRESS.* * OPTION ADDRESS.FRED.EMAIL "fflinstone@foo.bar.com" * OPTION ADDRESS.FRED.NAME "Fred Flinstone" * OPTION ADDRESS.FRED.PHONE "+1 700 555 1234" * OPTION ADDRESS.LODGE.EMAIL "fflinstone@foo.bar.com, brubble@foo.bar.com" * OPTION ADDRESS.WILMA.EMAIL "wilma@bedrock.edu" * OPTION ADDRESS.WILMA.PHYSMAIL "3 Granite Rd; Bedrock" a005 OK Get completed Many mail systems treat the per-user address book and the system-wide mail aliases/distribution lists as different instances of the same thing. The concepts are so similar that I feel it important to implement them with the same subsystem. This would allow both per-user address books and system-wide aliases/distribution lists to be manipulated with the same set of tools. System-wide aliases seem to naturally belong in a user directory service, as they share the same namespace and have many of the same informational attibutes as users. One way to resolve the conflict between "address books should be in IMSP" and "address books belong in the user directory service" is to put user directory service functionality into IMSP. This would have the advantage of reducing the number of services a mail client would have to converse with. On the other hand, it further complicates the IMSP protocol and opens an entire can of worms. A user directory service facility of IMSP would loook something like a cross between the option facility and the CSO/ph protocol. I would have as a design goal the ability to implement the facility by having the IMSP server query an X.500 database, but my limited knowledge of X.500 would make that difficult without outside help. I welcome people's thoughts on the matter. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Apr 20 21:00:19 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20018; Tue, 20 Apr 93 21:00:19 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27766; Tue, 20 Apr 93 20:59:52 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Apr 21 00:02:28 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22028; Wed, 21 Apr 93 00:02:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28468; Wed, 21 Apr 93 00:02:04 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28460; Wed, 21 Apr 93 00:02:02 -0700 Received: from ppsw.cam.ac.uk by ppsw1.cam.ac.uk id <25956-0@ppsw1.cam.ac.uk>; Wed, 21 Apr 1993 08:01:47 +0100 From: Tim Brooks To: Alan Thew Cc: imap@cac.washington.edu, pine-info@cac.washington.edu Subject: Re: ECSMail (?) In-Reply-To: Your message of "Sat, 17 Apr 1993 15:19:27 BST." Reply-To: T.Brooks@UCS.Cam.AC.UK Date: Wed, 21 Apr 1993 08:01:43 +0100 Message-Id: <"ppsw1.cam..961:21.03.93.07.01.49"@ppsw.cam.ac.uk> Thanks Alan! Tim From owner-imap@cac.washington.edu Wed Apr 21 10:26:44 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04716; Wed, 21 Apr 93 10:26:44 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04464; Wed, 21 Apr 93 10:26:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SUMEX-AIM.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04458; Wed, 21 Apr 93 10:26:16 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by SUMEX-AIM.Stanford.EDU (4.1/inc-1.0) id AA13289; Wed, 21 Apr 93 10:26:14 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA01042; Wed, 21 Apr 93 10:24:49 -0700 Date: Wed, 21 Apr 1993 10:19:11 -0700 (PDT) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: Address books & IMSP To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: John Gardiner Myers's message of Tue, 20 Apr 1993 18:08:06 -0400 (EDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, something like this is absolutely needed. We are currently trying to decide how to do this (keep address books on servers and retrieve their contents at connect time, and update the servers appropriately) within IMAP using CREATE, DELETE and APPEND, ie, storing the address book entries as messages in a special mailbox. Pretty much a hack. Bill From owner-imap@cac.washington.edu Wed Apr 21 11:56:16 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07650; Wed, 21 Apr 93 11:56:16 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01546; Wed, 21 Apr 93 11:55:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from csgrad.cs.vt.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01540; Wed, 21 Apr 93 11:55:51 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA04455; Wed, 21 Apr 1993 14:55:49 -0400 Date: Wed, 21 Apr 1993 14:50:50 -0400 (EDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: RE: Address books & IMSP To: Bill Yeager Cc: John Gardiner Myers , imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I'd certainly agree this is needed. My impression is that the current directory service protocols don't necessarily provide for personal address books. Using those protocols in the long run is probably a better idea, but I think we'll have the need before they're ready. The proposed way of doing it with the existing options facility seems fine. I think what you want it to be able to down load the whole address book (for browsing) and send it back up if it was modified. My recollection from some measurements we took on a thousand Pine address books at the UW was that they averaged 2Kb or so. Personal distribution lists are a *very* popular feature in Pine. Some folks have distribution lists with hundreds of entries making for address books over 10Kb. The IMSP specification didn't say, but I assume the "set option" creates an option entry when it doesn't exist, and that the stored strings can be quite long. Say a few Kb, to store a distribution list. LL On Wed, 21 Apr 1993, Bill Yeager wrote: > > Yes, something like this is absolutely needed. We are currently trying to > decide how to do this (keep address books on servers and retrieve their > contents at connect time, and update the servers appropriately) within IMAP > using CREATE, DELETE and APPEND, ie, storing the address book entries as > messages in a special mailbox. Pretty much a hack. > > Bill > From owner-imap@cac.washington.edu Wed Apr 21 12:24:50 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08446; Wed, 21 Apr 93 12:24:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01683; Wed, 21 Apr 93 12:24:41 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from eco.twg.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01677; Wed, 21 Apr 93 12:24:34 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA06972; Wed, 21 Apr 93 15:15:51 -0400 Message-Id: <9304211915.AA06972@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <14993-0@apache.twg.com>; Wed, 21 Apr 1993 12:15:23 -0700 From: "David Herron" Subject: RE: Address books & IMSP To: Laurence Lundblade (Non Receipt Notification Requested) (IPM Return Requested) Cc: Bill Yeager (Non Receipt Notification Requested) (IPM Return Requested), John Gardiner Myers (Non Receipt Notification Requested) (IPM Return Requested), imap@cac.washington.edu (Non Receipt Notification Requested) (IPM Return Requested) Date: Wed, 21 Apr 93 12:15:21 PDT In-Reply-To: Your message of Wed, 21 Apr 1993 14:50:50 -0400 (EDT). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 22 TEXT It is possible for X.500 to store a personal address book within the person's information. What you'd do is create an `object class' containing the necessary attributes, and add that object class to the `person' object. It should be more straightforward to put the facility into either IMAP or IMSP. It certainly makes fewer assumptions about the customers environment. The information we keep in our address book is: full name RFC-822 address X.400 address FAX number Voice telephone number list of address groups the address is a member of All are just character strings. The `address groups' serve both the `personal distribution list' role and to help organize the address book in meaningful ways. David From owner-imap@cac.washington.edu Wed Apr 21 12:26:43 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08508; Wed, 21 Apr 93 12:26:43 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01697; Wed, 21 Apr 93 12:26:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from eco.twg.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01691; Wed, 21 Apr 93 12:26:28 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA06972; Wed, 21 Apr 93 15:15:51 -0400 Message-Id: <9304211915.AA06972@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <14993-0@apache.twg.com>; Wed, 21 Apr 1993 12:15:23 -0700 From: "David Herron" Subject: RE: Address books & IMSP To: Laurence Lundblade (Non Receipt Notification Requested) (IPM Return Requested) Cc: Bill Yeager (Non Receipt Notification Requested) (IPM Return Requested), John Gardiner Myers (Non Receipt Notification Requested) (IPM Return Requested), imap@cac.washington.edu (Non Receipt Notification Requested) (IPM Return Requested) Date: Wed, 21 Apr 93 12:15:21 PDT In-Reply-To: Your message of Wed, 21 Apr 1993 14:50:50 -0400 (EDT). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 22 TEXT It is possible for X.500 to store a personal address book within the person's information. What you'd do is create an `object class' containing the necessary attributes, and add that object class to the `person' object. It should be more straightforward to put the facility into either IMAP or IMSP. It certainly makes fewer assumptions about the customers environment. The information we keep in our address book is: full name RFC-822 address X.400 address FAX number Voice telephone number list of address groups the address is a member of All are just character strings. The `address groups' serve both the `personal distribution list' role and to help organize the address book in meaningful ways. David From owner-imap@cac.washington.edu Wed Apr 21 14:40:05 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13028; Wed, 21 Apr 93 14:40:05 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02559; Wed, 21 Apr 93 14:39:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02553; Wed, 21 Apr 93 14:39:47 -0700 Received: from cyklop.nada.kth.se by nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27148; Wed, 21 Apr 93 23:39:44 +0200 Message-Id: <9304212139.AA27148@nada.kth.se> To: imap@cac.washington.edu Cc: psv@nada.kth.se Subject: Non-ASCII letters (Was Re: Address books & IMSP ) In-Reply-To: from "John Gardiner Myers " "Tue, 20 Apr 1993 18:08:06 -0400 (EDT) " Date: Wed, 21 Apr 1993 23:39:44 +0200 From: Peter Svanberg Quoting: John Gardiner Myers > > Per-user address books can be implemented using the option facility of > IMSP. A portion of the option namespace can be reserved for address > book entries and suitable naming conventions can be adopted. For > example, one might have: > > a005 GET ADDRESS.* > * OPTION ADDRESS.FRED.EMAIL "fflinstone@foo.bar.com" Just a thought: Have you (not especially John) considered non-[A-Z]-letters in the short-form name? Wider thought: Have you considered non-[A-Z]-letters in _every_ string which is the result of user input or mail contents? Sooner or later someone somewhere will have to consider such things (if it should be widely usable outside USA), both in IMAP and IMSP. The IMAP2BIS use of RFC-1342-type strings in the SEARCH command _is_ a start. --- 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-imap@cac.washington.edu Thu Apr 22 08:02:39 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29417; Thu, 22 Apr 93 08:02:39 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17031; Thu, 22 Apr 93 08:02:12 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17025; Thu, 22 Apr 93 08:02:11 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Thu, 22 Apr 93 11:01:58 EDT Received: via switchmail; Thu, 22 Apr 1993 11:01:57 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 22 Apr 1993 11:01:15 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 22 Apr 1993 11:01:08 -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; Thu, 22 Apr 1993 11:00:59 -0400 (EDT) Message-Id: Date: Thu, 22 Apr 1993 11:00:59 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Non-ASCII letters (Was Re: Address books & IMSP ) In-Reply-To: <9304212139.AA27148@nada.kth.se> References: <9304212139.AA27148@nada.kth.se> Beak: Is Peter Svanberg writes: > Quoting: John Gardiner Myers > > a005 GET ADDRESS.* > > * OPTION ADDRESS.FRED.EMAIL "fflinstone@foo.bar.com" > > Just a thought: Have you (not especially John) considered > non-[A-Z]-letters in the short-form name? In short, yes. I have considered it, it is a major problem with my example as written, and it is something I want to address. Solutions I can think of: * Remove the restriction that option names be atoms. * Require the client to map the short-form name to an atom. * Make the second component of the name a gensym, putting the short-form name in the value. (* OPTION ADDRESS.A0001.NICK "Fred") None of these is particularly appealing. I would be very grateful for any assistance from someone with experience in these matters. > Wider thought: Have you considered non-[A-Z]-letters in _every_ string > which is the result of user input or mail contents? I believe so, but could be wrong. RFC 821 limitations aside, I think the only problematic character is NUL. _.John From owner-imap@cac.washington.edu Thu Apr 22 08:04:23 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29572; Thu, 22 Apr 93 08:04:23 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06809; Thu, 22 Apr 93 08:04:09 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06803; Thu, 22 Apr 93 08:04:07 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Thu, 22 Apr 93 11:04:04 EDT Received: via switchmail; Thu, 22 Apr 1993 11:04:03 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 22 Apr 1993 11:02:14 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 22 Apr 1993 11:01:56 -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; Thu, 22 Apr 1993 11:01:27 -0400 (EDT) Message-Id: Date: Thu, 22 Apr 1993 11:01:27 -0400 (EDT) From: Wallace Colyer To: imap@cac.washington.edu Subject: Re: IMSP specification In-Reply-To: References: I thought I would elaborate on Mark's explaination of IMSP. Excerpts from internet.computing.imap: 31-Mar-93 Re: IMSP specification Mark Crispin@Panda.COM (682*) > No. IMSP (Interactive Mail Support Protocol) is a support protocol for > IMAP. It handles collections of IMAP servers the way IMAP handles > collections of message folders. IMSP extends the IMAP2bis operations > for creating, deleting, renaming, [un]subscribing, and listing folders > to multiple IMAP servers; it also has some capabilities for distributed > user configuration information. > IMSP doesn't have any capability to deal with messages. > You don't need IMSP at all if you only have one IMAP server. Though it is true that you do not need IMSP if you only have on IMAP server, IMSP will actually give you additional functionality that may prove very useful. First, I'll describe our mail usage profile. We have about 7,600 unique mail users during peak usage weeks. They have around 81,000 mail sessions. The interesting thing to point out is that these users move around a lot. In one week about 5800 users read mail and bboards from a Macintosh or PC (there were only 2200 Macs and 600 PCs which they read the mail from), 5300 users read mail and bboards on a Unix system, and 3200 read mail and bboards on both a MAC/PC and a Unix system. On the unix systems they read mail using X11 based clients and a variety of terminal clients (an emacs based client, two curses clients, and a command line client). This means that we need to make the movement from one mail client to another relatively seemless. Some of the profile information needs to move with the user and not the client. They expect things like bcc's and signatures to be universal. IMSP while providing the means to scale up an IMAP installation by treating folders and mailboxes as objects which can be moved around from server to server to balance for space and load (location transparency), provides a mechanism for user specific information to be stored in a central location for use by all clients. The IMSP server can be queried for the bcc address to use, the person name of the user, the central SMTP server(s) to contact, the IMAP server to the users inbox lives on. What the list of bboards the user is subscribed to which have unread messages is. Following the current discussions, it looks like it will have an address book mechanism as well. I think IMSP gives a lot more than just location transparency and scalability. -Wallace From owner-imap@cac.washington.edu Thu Apr 22 12:45:33 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07324; Thu, 22 Apr 93 12:45:33 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21656; Thu, 22 Apr 93 12:45:20 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21650; Thu, 22 Apr 93 12:45:18 -0700 Received: from Athens.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA26784; Thu, 22 Apr 93 12:45:13 PDT Date: Thu, 22 April 1993 12:46:50 -0800 From: Adam Treister To: imap@cac.washington.edu Subject: Re: IMSP specification Message-Id: In-Reply-To: Your message of Thu, 22 Apr 1993 11:01:27 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII Wallace Colyer : > I think IMSP gives a lot more than just location > transparency and scalability. High on my list for next round Mailstrom features is location transparancy. My primary concern is one Mailstrom user reading mail via Mailstrom from multiple locations (which coincidentally is my situation), but the same user may also want to read mail from other platforms. IMSP provides the means to go get the file(s), but this is only half the problem. Ideally we need a common format for preferences and personal address books, shared by multiple clients. And can the client assume that IMSP exists (using local or default values if it doesn't), or do I need to add FTP to Mailstrom too? Is there interest in collaborating on a standard convention on client settings? Because clients have different features, this could be tricky, but the address books are actually more important (IMHO) and should be relatively easy. Adam From owner-imap@cac.washington.edu Fri Apr 23 03:00:54 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24443; Fri, 23 Apr 93 03:00:54 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12183; Fri, 23 Apr 93 03:00:39 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Fri Apr 23 06:15:28 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26972; Fri, 23 Apr 93 06:15:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00445; Fri, 23 Apr 93 06:15:10 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Fri Apr 23 06:58:59 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27511; Fri, 23 Apr 93 06:58:59 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00750; Fri, 23 Apr 93 06:58:51 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Apr 25 20:07:04 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24177; Sun, 25 Apr 93 20:07:04 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26097; Sun, 25 Apr 93 20:06:18 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26091; Sun, 25 Apr 93 20:06:17 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA09973; Sun, 25 Apr 93 20:06:13 -0700 Date: Sun, 25 Apr 1993 19:16:03 -0700 (PDT) From: Mark Crispin Subject: re: Rich, hierarchical mail object storage in IMAP To: William Chung Cc: IMAP Interest List In-Reply-To: <9304201650.AA0164@WHCHUNG1.watson.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi William - Thank you for your comments. I'm sorry to have taken so long to reply; this past week has been quite busy... To begin, note that at UW ``mailbox'' and ``folder'' are synonyms, with me (and the IMAP documents) using ``mailbox'' and everyone else using ``folder''. [My co-workers claim that a mailbox is an address that you send mail to, not an entity that you read.] I think that you mean ``folder'' as referring to the entity I call ``a collection of mailboxes'' (and my co- workers call ``a collection of folders''). Please keep this in mind when reading the rest of this message......... There is no presumption in IMAP of ``a UNIX style mail storage area''. In fact, IMAP was originally designed and implemented on a completely different operating system. Nor does IMAP presume that ``mailboxes are stored in a flat fashion with no way to accomodate something like a hierarchial folder tree.'' To my knowledge, IMAP has never been implemented on an operating system with a flat filesystem. IMAP lacks any presumption of the nature of the mail store, beyond a fundamental assumption that a character string can adequately identify a single folder object in the mail store. This is quite intentional. Any greater presumption necessarily limits IMAP to a particular mail store scheme; possibly even to a particular operating system. It was a fundamental design goal of IMAP that there be no such limitations. Recall that IMAP defines only the special name ``INBOX''. All other names are completely up to the particular server implementation. It may well be that certain implementations have chosen to use file path names, but there is no requirement that they do so. What this implies is that any mechanism for folder hierarchy must be external to IMAP. Indeed, there have been any number of individuals who have wished that IMAP solved the folder hierarchy management problem, including in our group at UW. It would make a lot of problems much simpler. However, like most simple solutions, it's *too* simplistic. Gradually, after seeing the extent of the interoperability problem, people have been won over towards the external solution viewpoint. Consider, if you would, how much less attractive IMAP would be to you if a ``UNIX style mail folder hierarchy'' were imposed upon you. Not only wouldn't your preferred model be supported, you'd have to deal with working around a different (perhaps totally hostile) model imposed upon you. It can also be claimed that ``folder structure (hierarchy) is in the mind of the beholder''. There is nothing that prevents a client from imposing its own hierarchical view (context management in the forthcoming new release of Pine is somewhat like this). Similarly, a client can flatten out heirarchy into extinction. Similarly, the management of a server may wish to impose (or eliminate) physical hierarchy of the bits on their disk to suit their operational needs. For example, one can imagine a mailer which recognizes that users Bob, Ted, Carol, and Alice all received a copy of the same message; and instead of giving them each a private copy gave them a pointer to a single shared copy. Such details may be very relevant to the management of a server, but are of no interest to a client. Some work on external hierarchy exists in IMSP (the IMAP support protocol) and in the context management code in the forthoming Pine. I would like to refer you to the IMSP work at CMU for answers to your questions about non-mailbox objects. IMSP is designed to be a layer on top of IMAP that does the tasks that IMAP does not do. The idea is to split the labor and have two smaller tools rather than one monolithic tool. Recently, our friends at CMU have posted some comments about address book implementation in IMSP. Like you, we feel that a distributed address book is very important and certainly have this as a requirement. We just don't have the requirement that IMAP satisfy *all* of the requirements by itself... The reason for this was that I (and others) have become quite wary of monolithic solutions that purport to solve all problems. Such monolithic solutions tend to be unwieldy kludge towers (X.400 comes immediately to mind) that few people understand and fewer implement to any degree. Worse, they tend to ``solve all problems'' by defining out of existance areas of the problem space. [For example, it is easy to put folder hierarchy into IMAP if you define that all file stores now and forever are BSD UNIX.] The combination of IMAP and IMSP addresses a considerable portion of the overall distributed mail problem; although it is conceivable that at some point in the future additional protocols may be necessary (we've already talked about a ``netbiff'' for PC's). I hope that this has satisfactorily answered your concerns. I am quite aware that these issues are complex and the seeming absence of such important functionality in IMAP can be difficult to fathom. Please do not hesitate to contact me if you have any further questions. Regards, -- Mark -- From owner-imap@cac.washington.edu Thu May 6 13:44:15 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10255; Thu, 6 May 93 13:44:15 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17714; Thu, 6 May 93 13:43:51 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17708; Thu, 6 May 93 13:43:50 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16460; Thu, 6 May 93 13:43:49 -0700 Date: Thu, 6 May 1993 13:38:24 -0700 (PDT) From: Terry Gray Subject: Amsterdam To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, I've received word that the IESG would like some changes to the proposed IMAP WG charter, but that approval of the WG is expected, and that it is OK to plan on having a WG meeting at the July IETF. Accordingly, how many IMAP developers are likely to be going to Amsterdam? (I'm currently assuming that Mark Crispin and I will find a way over if there is sufficient interest.) Respond to me, and I'll post a list of those planning on going. -teg From owner-imap@cac.washington.edu Thu May 6 14:10:40 1993 Received: by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10997; Thu, 6 May 93 14:10:40 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Relay.Prime.COM by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10991; Thu, 6 May 93 14:10:37 -0700 Received: from PR1MEA.Prime.COM by Relay.Prime.COM; 06 May 93 17:09:39 EDT Received: from bart.prime.com.Prime.COM [210.5.200.37] by PR1MEA.Prime.COM ; 07 May 93 08:58:33 Y Received: by bart.prime.com.Prime.COM (4.1/SMI-4.1) id AA01403; Fri, 7 May 93 09:02:02 NZS Date: Fri, 7 May 1993 08:59:08 +1200 (NZST) From: Michael J A Lasham Reply-To: michael_lasham@pr1mea.Prime.COM Subject: IMAP on PC's To: IMAP Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello I am new to this list, and also new to IMAP. My company has decided to use a mail system called pine that supports IMAP on a unix box. We also have alot of PCs that need to send mail. Can anyone please tell me if there are any MS Windows mailers that support IMAP. If there is are there any in the public domain? Failing this I am to write one. Has anyone got any advice for me? I am new to Windows developement too. I personnally believe that I am going to have a much larger job than anyone within my company thinks ;-). Thanks Michael Lasham | Email: MICHAEL_LASHAM@Pr1mea.prime.COM Systems Engineer | Phone: (09) 300-3400 Eagle Technology Ltd | Fax: (09) 300-3430 Auckland, New Zealand | -------------------------------------------------------------------- From owner-imap@cac.washington.edu Thu May 6 14:40:55 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11880; Thu, 6 May 93 14:40:55 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18794; Thu, 6 May 93 14:40:44 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18788; Thu, 6 May 93 14:40:43 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18920; Thu, 6 May 93 14:30:37 -0700 Date: Thu, 6 May 1993 14:20:46 -0700 (PDT) From: Terry Gray Subject: Re: IMAP on PC's To: michael_lasham@pr1mea.Prime.COM Cc: IMAP Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Michael, You are almost surely correct that the task is larger than those around you believe! We began the DOS port of Pine nearly a year ago with the expectation that it would be in production by last Fall. We now hope the "final" beta will be ready in about two weeks... True, a lot of the delay was in reinventing virtual memory, which I'm told Microsoft has already done for Windows, but it is still easy to be too optimistic. As for Windows IMAP clients: a company in Canada (ISA) has one called ECS, but I'm not sure if it is "ready" yet, or what the licensing terms are. Also, Wollongong's Pathway Messenger products talk to IMAP servers, but someone told me that they tend to operate more in "POP mode" which may be a problem in a multiplatform environment. (I ordered copies to try out a couple of months ago, but they haven't arrived yet.) I believe there are folks from both ISA and TWG on this list, so more definitive info may be forthcoming. -teg On Fri, 7 May 1993, Michael J A Lasham wrote: > > Hello > > I am new to this list, and also new to IMAP. > > My company has decided to use a mail system called pine that supports IMAP > on a unix box. We also have alot of PCs that need to send mail. Can > anyone please tell me if there are any MS Windows mailers that support > IMAP. If there is are there any in the public domain? > > Failing this I am to write one. Has anyone got any advice for me? I am > new to Windows developement too. I personnally believe that I am going to > have a much larger job than anyone within my company thinks ;-). > > Thanks > > Michael Lasham | Email: MICHAEL_LASHAM@Pr1mea.prime.COM > Systems Engineer | Phone: (09) 300-3400 > Eagle Technology Ltd | Fax: (09) 300-3430 > Auckland, New Zealand | > -------------------------------------------------------------------- From owner-imap@cac.washington.edu Fri May 14 16:01:59 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22289; Fri, 14 May 93 16:01:59 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03274; Fri, 14 May 93 16:01:45 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03268; Fri, 14 May 93 16:01:44 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05503; Fri, 14 May 93 16:01:43 -0700 Date: Fri, 14 May 1993 15:52:09 -0700 (PDT) From: Terry Gray Subject: Amsterdam, 2nd try To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, Only two of you (Sylvain Langlois and Jim Conklin) responded to my earlier inquiry asking who was going to the July IETF. This was a surpise, since quite a few people at the Columbus IMAP BOF indicated they were going. Now that we in the State of Washington need to get our Governor's approval for foreign travel, I want to make sure there might be a quorum of IMAPers before spending the political capital that goes with asking :) So if you meant to reply earlier but haven't gotten a Round Tuit yet, please do so now. -teg (If you can't make it to Amsterdam, but might be able to come to an IMAP WG meeting somewhere stateside, let me know that too.) From owner-imap@cac.washington.edu Sat May 15 23:18:59 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12931; Sat, 15 May 93 23:18:59 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18235; Sat, 15 May 93 23:18:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from lynx.dac.northeastern.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18229; Sat, 15 May 93 23:18:40 -0700 Received: by lynx.dac.northeastern.edu (5.65/DEC-Ultrix/4.3) id AA29305; Sun, 16 May 1993 02:16:53 -0400 Message-Id: <9305160616.AA29305@lynx.dac.northeastern.edu> X-Mailer: *Cinetic Mail Manager V2.1 Date: Sun, 16 May 1993 01:03:39 EDT Reply-To: tmetro@lynx.dac.northeastern.edu From: tmetro@lynx.dac.northeastern.edu (Tom Metro) To: IMAP@CAC.Washington.EDU (IMAP Interest List) Subject: IMAP over a serial line Is it possible to use IMAP over a serial line without SLIP? It doesn't require UDP or any lower level protocol - right? I was thinking about writing a news client that worked in this fashion (dialup to a host, telnet to an NNTP server), but I think IMAP can probably handle the news now (right?) and is more ideally targeted to this type of remote client. The advantage this type of system would have is that it would be much simpler to install and configure the client on the user's machine (no protocol stack, SLIP drivers, etc.) and it wouldn't have the overhead of SLIP. -Tom -- Tom Metro tmetro@lynx.dac.northeastern.edu Venture Logic Newton, MA, USA From owner-imap@cac.washington.edu Mon May 17 01:45:25 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29100; Mon, 17 May 93 01:45:25 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23150; Mon, 17 May 93 01:42:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23144; Mon, 17 May 93 01:42:32 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA19861; Mon, 17 May 93 01:42:25 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA05999; Mon, 17 May 93 01:42:17 -0700 Date: Mon, 17 May 1993 01:25:27 -0700 (PDT) From: Mark Crispin Subject: re: IMAP over a serial line To: tmetro@lynx.dac.northeastern.edu Cc: IMAP Interest List In-Reply-To: <9305160616.AA29305@lynx.dac.northeastern.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Tom - IMAP can be run over any link which provides reliable, flow-controlled transmission that does not intercept any characters. It does not require any specific lower-level protocol. In theory, an error-correcting (e.g. V.42 or MNP) modem with hardware (CTS/RTS) flow control connected to a serial port that respects (and uses!) hardware flow control will suffice for this purpose. In actuality, there are various conditions which make this less than fully perfect; I've seen transmission errors and dropped characters. So, it is preferable that there be some layer between the serial line and raw data to ensure a reliable link. Some people have run POP successfully without a reliable link. They just accept as ``sh*t happens'' the possibility of dropped characters or line noise, since error-correcting modems do reduce this greatly. The problem is that POP uses a data marker (a line with only a period) whereas IMAP uses byte counts; consequently IMAP is more dependent upon the stream being reliable. There has been some talk of a lightweight protocol (something that could run as a small user program on UNIX) that can be used in place of SLIP. One possibility is TCP without IP. The advantage is that you could run other protocols as well. Another possibility is reviving my old (1977) Dialnet protocol. The question with either of these is: do we want them to work over links which intercept characters? You mentioned Telnet; the UNIX telnet client intercepts lots of control characters in various evil ways and on top of that certain UNIX telnet servers adds their own bizarreness (some, but not all, systems have fixed this). To be reliable, you need a protocol such as Kermit or Cafard (my 1985 work for TOPS-20 mail interchange over dialups, designed to work over even the most cretinous X.25 PADs). My suspicion is that no single solution is really best for all dialup applications, and more research work is needed in this area. I might be doing some of this research later this year. -- Mark -- From owner-imap@cac.washington.edu Tue May 25 12:46:42 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19308; Tue, 25 May 93 12:46:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05677; Tue, 25 May 93 12:42:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05671; Tue, 25 May 93 12:42:16 -0700 Received: from OldMacJeff.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA25818; Tue, 25 May 93 12:42:15 PDT Date: Tue, 25 May 93 12:40:01 -0800 From: Adam Treister To: imap@cac.washington.edu Subject: IMAP clients/users view of expunge Message-Id: Content-Type: TEXT/plain; charset=US-ASCII A design question that other IMAP clients must have dealt with... Many of the bugs in Mailstrom have to do with the expunge process. Every kind of window (reads, replies, browsers, attachments) rely on the IMAP message number, and this changes upon expunge. So there are several approaches... * always use the MessageID field as the key and lookup IMAP number either from the server or a client index. [sounds cumbersome, but is the db-esque way to do it] * everytime an expunge response comes, propagate a message to all objects telling them to decrement their number if its < the response. [this seems to be what the protocol promotes, but makes an O(n) into O(n^2), and sends a huge number of messages thru out the existing objects on every pass] * assemble all expunge replies, build a temporary message map, and run all windows' references to any message thru a remap function [the current solution, has bugs. Is fixable, but will get even more messy if sorted, filtered views are added] * Only expunge at close. Use filtered views to hide deleted messages, rather than actually expunging. [this sidesteps the problem, and fits with trash can metaphor, until the user wants to empty trash, which could only be done on disconnection. This matches my user profile, which is why I rarely see the pbs others report in Mailstrom. ] I'm leaning towards the last of these, but am interested in others' opinions. Would you as users mind if deleted messages disappeared from the list, and only appeared in a view under the trash can? Adam -------------------------------------------------- Adam Treister Polya Hall 205, Stanford CA 94305 - (415) 725-9449 -------------------------------------------------- From owner-imap@cac.washington.edu Tue May 25 13:59:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21140; Tue, 25 May 93 13:59:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06869; Tue, 25 May 93 13:59:37 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06861; Tue, 25 May 93 13:59:35 -0700 Received: from localhost (LOCALHOST.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA28220; Tue, 25 May 93 13:59:24 PDT Date: Tue, 25 May 1993 13:21:20 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: RE: IMAP clients/users view of expunge To: Adam Treister Cc: imap@cac.washington.edu In-Reply-To: Adam Treister's message of Tue, 25 May 93 12:40:01 -0800: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > A design question that other IMAP clients must have dealt > with... > Many of the bugs in Mailstrom have to do with the expunge process. > Every kind of window (reads, replies, browsers, attachments) > rely on the IMAP message number, and this changes upon > expunge. > So there are several approaches... > * always use the MessageID field as the key and lookup IMAP > number either from the server or a client index. [sounds > cumbersome, but is the db-esque way to do it] Won't work, actually. The message-id is only unique from the sender's viewpoint. If I send you a message, and also Cc: you in the same message (via a different mail host) you'll have two messages from me with the same message-id. How do you determine which one you're getting rid of? (It's also quite likely you'll want to keep one and toss the duplicate, making the question even more relevant). I'm sympathetic. The sequencing really makes disconnected operation difficult to shoehorn into the existing protocol. > * everytime an expunge response comes, propagate a message to > all objects telling them to decrement their number if its < > the response. [this seems to be what the protocol promotes, > but makes an O(n) into O(n^2), and sends a huge number of > messages thru out the existing objects on every pass] Actually, only the server access functions need this number. It can get outdated on certain objects without penalty. Those objects exist as snapshots of what once was. For instance, a "read window" which already has text in it can still keep the number it had when it was opened. (It just can't -use- that number). Subtle distinction. > > * assemble all expunge replies, build a temporary message map, > and run all windows' references to any message thru a remap > function [the current solution, has bugs. Is fixable, but will > get even more messy if sorted, filtered views are added] Isn't this the same mechanism for implementing sort/filter engines? (Maybe you're going about this backwards. Instead of having every object maintain its current message number, perhaps the message should just know about all of its objects...). > * Only expunge at close. Use filtered views to hide deleted > messages, rather than actually expunging. [this sidesteps the > problem, and fits with trash can metaphor, until the user > wants to empty trash, which could only be done on > disconnection. This matches my user profile, which is why I rarely > see the pbs others report in Mailstrom. ] > I'm leaning towards the last of these, but am interested in > others' opinions. Would you as users mind if deleted messages > disappeared from the list, and only appeared in a view under > the trash can? > Adam You can do this kind of thing with xlview (it's actually my preferred mode of running). The complication would be forcing it on folks. When I come in after a weekend, I sometimes have 20 megs of new mail. I try to get rid of it quickly. If I'm forced to disconnect in order to actually get rid of it, it makes the MUA less conveneient, IMHO.; and also it is less likely that space-conscious sys-admins are going to want to propogate it. Some people NEVER disconnect, unless something crashes. How do you solve the expunge problem for them? > > -------------------------------------------------- Adam > Treister Polya Hall 205, > Stanford CA 94305 - (415) 725-9449 > -------------------------------------------------- > mike From owner-imap@cac.washington.edu Tue May 25 14:20:58 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21837; Tue, 25 May 93 14:20:58 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11886; Tue, 25 May 93 14:20:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11880; Tue, 25 May 93 14:20:47 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA07596; Tue, 25 May 93 14:20:43 -0700 Date: Tue, 25 May 1993 14:04:26 -0700 (PDT) From: Mark Crispin Subject: re: IMAP clients/users view of expunge To: Adam Treister Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Adam - Applications that use c-client have the problem solved for them. What they do is instead of remembering the message number, they remember the message cache element from mail_elt(). For each time you remember the elt (e.g. by storing it on a window's property list), you increment its lock count (elt->lockcount). When you are finished with a remembered elt, you call mail_free_elt(), which decrements the lock count and frees the elt only if the lock count reaches 0. The message number can then be accessed by elt->msgno. It is kept current in spite of expunges. If elt->msgno is 0, that means that that particular message has been expunged and is now an orphan. This is precisely why the message number is in the elt, and why elts have a lock count. Your workaround of deferring expunge until close is not guaranteed to work, because it is perfectly possible that messages will get expunged without you issuing an expunge yourself. This doesn't happen much yet, but forewarned is forearmed......... Unique ID's are going to be added to IMAP to support disconnected use, but they aren't there yet. -- Mark -- From owner-imap@cac.washington.edu Wed May 26 10:36:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16438; Wed, 26 May 93 10:36:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18280; Wed, 26 May 93 10:36:23 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SUMEX-AIM.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18261; Wed, 26 May 93 10:35:49 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by SUMEX-AIM.Stanford.EDU (4.1/inc-1.0) id AA01101; Wed, 26 May 93 10:35:19 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA20940; Wed, 26 May 93 10:33:06 -0700 Date: Wed, 26 May 1993 10:20:00 -0700 (PDT) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: IMAP clients/users view of expunge To: Adam Treister Cc: imap@cac.washington.edu In-Reply-To: Adam Treister's message of Tue, 25 May 93 12:40:01 -0800: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >* always use the MessageID field as the key and >lookup IMAP number either from the server or a >client index. [sounds cumbersome, but is the >db-esque way to do it] There is another problem here. Not all mailers include a message-id. >* everytime an expunge response comes, propagate a >message to all objects telling them to decrement >their number if its < the response. [this seems to >be what the protocol promotes, but makes an O(n) >into O(n^2), and sends a huge number of messages >thru out the existing objects on every pass] Yes, this is how to correctly propagate the expunge. This isn't really computationally that expensive. ximap updates all private maps on a given expunge, and browsers actually have two such maps, one for the browser and one for the highlighted messages. >* Only expunge at close. We'll, macMS got around this buy only expunging when there were no read windows open. This was really a cop-out :-). I don't think one can beg the question by saying it takes lots of cpu cycles. It doesn't given the processing power we have on our desktops these days. Most of the cycles are dedicated to updating the user interface. Bill From owner-imap@cac.washington.edu Wed May 26 11:51:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21457; Wed, 26 May 93 11:51:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19862; Wed, 26 May 93 11:51:37 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19856; Wed, 26 May 93 11:51:36 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Wed, 26 May 93 14:51:32 EDT Received: via switchmail; Wed, 26 May 1993 14:51:31 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 26 May 1993 14:50:49 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 26 May 1993 14:50:46 -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; Wed, 26 May 1993 14:50:41 -0400 (EDT) Message-Id: Date: Wed, 26 May 1993 14:50:41 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: IMAP clients/users view of expunge In-Reply-To: References: Beak: is Not Realize that an IMAP server can give the client an EXPUNGE unsolicited reply at any time. (except, perhaps, during a FETCH command or somewhere else where it makes the reply ambiguous.) The macMS cop-out won't work when talking to sufficiently sophisticated IMAP server implementations. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Wed May 26 11:54:02 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21536; Wed, 26 May 93 11:54:02 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19892; Wed, 26 May 93 11:53:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19886; Wed, 26 May 93 11:53:52 -0700 Received: from Mac-Treister.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA21225; Wed, 26 May 93 11:53:51 PDT Date: Wed, 26 May 93 12:02:35 From: Adam Treister To: Mark Crispin Subject: Re: IMAP clients/users view of expunge Cc: imap@cac.washington.edu Message-Id: In-Reply-To: Your message of Tue, 25 May 1993 14:04:26 -0700 (PDT) Content-Type: TEXT/plain; charset=US-ASCII > Applications that use c-client have the problem > solved for them. > > What they do is instead of remembering the message > number, they remember the message cache element from > mail_elt() This means moving the primary key from something known to change on expunge, to using a memory location as a primary key. Sounds dicey, but probably will work....if I never garbage collect. Do I read InternalDoc correctly...that mail_gc(stream,GC_ELT) will throw away the cache elements. It also is making assumptions about direct pointers, violating the cardinal rule of Macs. mail_elt is mail_element, right? -------------------------------------------------- Adam Treister Polya Hall 205, Stanford CA 94305 - (415) 725-9449 -------------------------------------------------- From owner-imap@cac.washington.edu Wed May 26 11:55:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21577; Wed, 26 May 93 11:55:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19906; Wed, 26 May 93 11:55:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SIGURD.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19900; Wed, 26 May 93 11:55:35 -0700 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992) id <01GYMOW5EAGG8ZDXYE@SIGURD.INNOSOFT.COM>; Wed, 26 May 1993 11:55:27 PDT Date: Wed, 26 May 1993 11:53:52 -0700 (PDT) From: Ned Freed Subject: RE: IMAP clients/users view of expunge In-Reply-To: Your message dated "Wed, 26 May 1993 10:20:00 -0700 (PDT)" To: Bill Yeager Cc: Adam Treister , imap@cac.washington.edu Message-Id: <01GYMP9EC9O28ZDXYE@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT > >* always use the MessageID field as the key and > >lookup IMAP number either from the server or a > >client index. [sounds cumbersome, but is the > >db-esque way to do it] > There is another problem here. Not all mailers include a message-id. It is worse than this -- two messages can and often do have the same id. This can be legitimate (two real copies of the same message), but there are also some mailers that routinely emit duplicate ids. This is very unfortunate, but it is nevertheless a fact of Internet life. Ned From owner-imap@cac.washington.edu Wed May 26 13:07:36 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24024; Wed, 26 May 93 13:07:36 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17889; Wed, 26 May 93 13:07:02 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17876; Wed, 26 May 93 13:07:00 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA08806; Wed, 26 May 93 13:06:54 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA02444; Wed, 26 May 93 13:06:46 -0700 Date: Wed, 26 May 1993 13:01:18 -0700 (PDT) From: Mark Crispin Subject: RE: IMAP clients/users view of expunge To: Bill_Yeager@camis.stanford.edu Cc: Adam Treister , imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bill - Why does ximap bother to have a message number map at all? If you keep a pointer to the elt instead (being sure to lock it!) that's all you need. The elt will always have the correct message number for that message, or 0 if it has been expunged (in which case the elt becomes a zombie elt). I agree with your comment that this is not computationally expensive, not even on a Mac PowerBook-100 or a PC/XT. I/O time is most of the real-time wait. -- Mark -- From owner-imap@cac.washington.edu Wed May 26 13:40:46 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24981; Wed, 26 May 93 13:40:46 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21315; Wed, 26 May 93 13:40:37 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SUMEX-AIM.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21309; Wed, 26 May 93 13:40:36 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by SUMEX-AIM.Stanford.EDU (4.1/inc-1.0) id AA10728; Wed, 26 May 93 13:40:33 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA21073; Wed, 26 May 93 13:38:29 -0700 Date: Wed, 26 May 1993 13:21:18 -0700 (PDT) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: IMAP clients/users view of expunge To: Mark Crispin Cc: Adam Treister , imap@cac.washington.edu In-Reply-To: Mark Crispin's message of Wed, 26 May 1993 13:01:18 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Why does ximap bother to have a message number >map at all? If you keep a pointer to the elt >instead (being sure to lock it!) that's all you >need. The elt will always have the correct message >number for that message, or 0 if it has been >expunged (in which case the elt becomes a zombie >elt). In order to use the X athena widgets Kevin Brock modified the Xaw list widget, and also created a special "browser" widget so things like double-click and SHIFT-select could be handled. Ximap or the newer Xlview call the browser widget routines. This latter widget uses a map which requires the message number as one of its elements to build the list widget's own map which demands message number like indices. I believe the "browser" widget could be rewritten to use the pointer to the elt, and then a special call could be made to update after an expunge which would nuke the zombies from the list, and redisplay the browser. All in all, such a rewrite is not worth the pain. When this code breaks it usually causes a crash in the bowels of xlib somewhere. We haven't had such a crash in a long, long time and so I think you can understand our hesitancy A better choice would be to one day abandon the Xaw's. A good job for a student ;-). Read windows do use the elt, and thus cope well with expunging. Bill From owner-imap@cac.washington.edu Wed May 26 16:08:15 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29939; Wed, 26 May 93 16:08:15 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18918; Wed, 26 May 93 16:08:04 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18912; Wed, 26 May 93 16:08:02 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA08900; Wed, 26 May 93 16:07:57 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA03035; Wed, 26 May 93 16:07:50 -0700 Date: Wed, 26 May 1993 16:01:37 -0700 (PDT) From: Mark Crispin Subject: Re: IMAP clients/users view of expunge To: Adam Treister Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 May 93 12:02:35 , Adam Treister wrote: > This means moving the primary key from something known to change on > expunge, to using a memory location as a primary key. Yes. > Sounds dicey, but probably will work....if I never garbage collect. Do I > read InternalDoc correctly...that mail_gc(stream,GC_ELT) will throw away > the cache elements. Right. The usage of GC_ELT is fundamentally incompatible with using elt locking and sharing. Not only won't the space be reclaimed, but you'll have orphaned elts. Actually, that could be fixed. I could make GC_ELT be a no-op on an elt if the lockcount is greater than 1, but then in the stream close case I would have to duplicate the code since there you want to release it unconditionally. I don't think GC'ing elts is really all that useful a thing to do. It only works on IMAP streams anyway, never on local messages, and Macs are not anywhere near as tight on memory as Pieces'o'Crap are..... > It also is making assumptions about direct pointers, > violating the cardinal rule of Macs. Yes, well, that's throughout c-client. > mail_elt is mail_element, right? There is no mail_element function in c-client, but yes, it gets a cache element. From owner-imap@cac.washington.edu Wed Jun 2 11:22:03 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03789; Wed, 2 Jun 93 11:22:03 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05669; Wed, 2 Jun 93 11:21:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05663; Wed, 2 Jun 93 11:21:46 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07372; Wed, 2 Jun 93 11:21:41 -0700 Date: Wed, 2 Jun 1993 11:14:28 -0700 (PDT) From: Terry Gray Subject: Re: IMAP WG Charter To: Greg Vaudreuil Cc: Erik Huizer , apples@surfnet.nl, imap@cac.washington.edu In-Reply-To: <9305061426.aa07982@IETF.CNRI.Reston.VA.US> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greg, Erik, et al: Finally here is a new draft of the IMAP WG charter that incorporates the IESG feedback you sent me. (It's much shorter now :) -teg ---------------------------------------------------------------------------- Rev 93.6.2 Interactive Mail Access Protocol Working Group (imap) Chair: Terry Gray gray@cac.washington.edu Mailing Lists: General Discussion: imap@cac.washington.edu To Subscribe: imap-request@cac.washington.edu Mail archive: ftp.cac.washington.edu /imap/imap_archive Description of Working Group: The Internet Interactive Mail Access Protocol (IMAP) working group is chartered to refine and extend the current IMAP2 protocol as a candidate standard for a client-server Internet email protocol to manipulate remote mailboxes as if they were local. An explicit objective is to retain compatibility with the growing installed base of IMAP2-compliant software. It is expected that the resulting specification will replace both RFC-1176 and the more recent (as yet unplublished) IMAP2bis extensions document. The IMAP Working Group will also investigate how to provide for "disconnected operation" capabilities similar to the DMSP protocol (RFC-1056, recently relegated to Informational Status) with a goal of making it possible for IMAP to replace DMSP. A mail access protocol provides a uniform, OS-independent way of manipulating message data (email or bulletin board) on a remote message store (repository). Mail user agents implementing such a protocol can provide individuals with a consistent view of the message store, regardless of what type of computer they are using, and regardless of where they are connected in the network. Multiple concurrent sessions accessing a single remote mailbox, and single sessions accessing multiple remote mailboxes are both possible with this approach. This differs from POP3 (RFC-1225) in that POP is a store-and-forward transport protocol that allows an MUA to retrieve pending mail from a mail drop (where it is then usually deleted automatically), whereas IMAP is focused on remote mailbox manipulation rather than transport. IMAP differs from various vendor-specific remote access approaches in that IMAP is an open protocol designed to scale well and accommodate diverse types of client operating systems. Security. Security-related tasks include how to incorporate secure authentication mechanisms when establishing a session, and possible interactions with Privacy Enhanced Mail. Goals and Milestones: It is expected that most of the work of this group will be conducted via email. A goal is to integrate and update RFC-1176 and the existing IMAP2bis draft, then submit the result as an Internet draft well before the November IETF WG meeting, which would then focus on detailed review of the text in preparation for submission as a Proposed Standard before the end of 1993. Jul 93 IETF Foreign travel restrictions may preclude several of the key players from attending the Amsterdam IETF, however, it may be possible to schedule a WG meeting for presentations and to solicit input from those who are normally unable to attend US IETF meetings. Aug 93 Submit Internet-draft, integrating RFC-1176 and IMAP2bis doc. Aug 93 Possible IMAP WG meeting at CMU or UW. Sep 93 Incorporate changes for disconnected operation. Nov 93 IETF Based on continuing email refinement of the text, and implementation experience, use this meeting for a detailed review of proposed Proposed Standard text. Dec 93 Submit as Proposed Standard. From owner-imap@cac.washington.edu Thu Jun 10 13:27:49 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05736; Thu, 10 Jun 93 13:27:49 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15514; Thu, 10 Jun 93 13:27:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ietf.cnri.reston.va.us by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15508; Thu, 10 Jun 93 13:27:28 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09427; 10 Jun 93 15:10 EDT To: IETF-Announce:; Cc: imap@cac.washington.edu Subject: WG ACTION: Interactive Mail Access Protocol (imap) Date: Thu, 10 Jun 93 15:10:07 -0400 From: Greg Vaudreuil Message-Id: <9306101510.aa09427@IETF.CNRI.Reston.VA.US> A new working group has been formed in the Applications Area of the IETF. Please contat the working group chairman of the Internet area directors for more information. Greg Vaudreuil IESG Secretary Interactive Mail Access Protocol (imap) --------------------------------------- Charter Chair(s): Terry Gray Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:imap@cac.washington.edu To Subscribe: imap-request@cac.washington.edu Archive: ftp.cac.washington.edu:‾/imap/imap_archive Description of Working Group: The Internet Interactive Mail Access Protocol (IMAP) working group is chartered to refine and extend the current IMAP2 protocol as a candidate standard for a client-server Internet email protocol to manipulate remote mailboxes as if they were local. An explicit objective is to retain compatibility with the growing installed base of IMAP2-compliant software. It is expected that the resulting specification will replace both RFC-1176 and the more recent (as yet unplublished) IMAP2bis extensions document. The IMAP Working Group will also investigate how to provide for ``disconnected operation'' capabilities similar to the DMSP protocol (RFC-1056, recently relegated to Informational Status) with a goal of making it possible for IMAP to replace DMSP. A mail access protocol provides a uniform, OS-independent way of manipulating message data (email or bulletin board) on a remote message store (repository). Mail user agents implementing such a protocol can provide individuals with a consistent view of the message store, regardless of what type of computer they are using, and regardless of where they are connected in the network. Multiple concurrent sessions accessing a single remote mailbox, and single sessions accessing multiple remote mailboxes are both possible with this approach. This differs from POP3 (RFC-1225) in that POP is a store-and-forward transport protocol that allows an MUA to retrieve pending mail from a mail drop (where it is then usually deleted automatically), whereas IMAP is focused on remote mailbox manipulation rather than transport. IMAP differs from various vendor-specific remote access approaches in that IMAP is an open protocol designed to scale well and accommodate diverse types of client operating systems. Security. Security-related tasks include how to incorporate secure authentication mechanisms when establishing a session, and possible interactions with Privacy Enhanced Mail. It is expected that most of the work of this group will be conducted via email. A goal is to integrate and update RFC-1176 and the existing IMAP2bis draft, then submit the result as an Internet draft well before the November IETF WG meeting, which would then focus on detailed review of the text in preparation for submission as a Proposed Standard before the end of 1993. Goals and Milestones: Aug 93 Post an Internet Draft of the revised IMAP 2 protocol. Aug 93 Hold an Interim Working Meeting at UW or CMU. Nov 93 Hold a Working Group meeting to review the IMAP document. Nov 93 Hold a Working Group meeting at the November IETF meeting. Dec 93 Submit the IMAP protocol to the IESG for consideration as a Proposed Standard. From owner-imap@cac.washington.edu Thu Jun 10 13:30:09 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05778; Thu, 10 Jun 93 13:30:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15527; Thu, 10 Jun 93 13:30:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from phantom.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15518; Thu, 10 Jun 93 13:29:59 -0700 Received: from [140.142.110.88] by phantom.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05155; Thu, 10 Jun 93 13:29:58 -0700 Date: Thu, 10 Jun 1993 13:29:28 PDT From: Terry Gray Subject: WG ACTION: Interactive Mail Access Protocol (imap) (fwd) To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In case any of you missed this, it's now official... -teg ---------- Forwarded message ---------- Date: Thu, 10 Jun 93 15:10:07 -0400 From: Greg Vaudreuil To: IETF-Announce: ; Cc: imap@cac.washington.edu Subject: WG ACTION: Interactive Mail Access Protocol (imap) A new working group has been formed in the Applications Area of the IETF. Please contat the working group chairman of the Internet area directors for more information. Greg Vaudreuil IESG Secretary Interactive Mail Access Protocol (imap) --------------------------------------- Charter Chair(s): Terry Gray Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:imap@cac.washington.edu To Subscribe: imap-request@cac.washington.edu Archive: ftp.cac.washington.edu:‾/imap/imap_archive Description of Working Group: The Internet Interactive Mail Access Protocol (IMAP) working group is chartered to refine and extend the current IMAP2 protocol as a candidate standard for a client-server Internet email protocol to manipulate remote mailboxes as if they were local. An explicit objective is to retain compatibility with the growing installed base of IMAP2-compliant software. It is expected that the resulting specification will replace both RFC-1176 and the more recent (as yet unplublished) IMAP2bis extensions document. The IMAP Working Group will also investigate how to provide for ``disconnected operation'' capabilities similar to the DMSP protocol (RFC-1056, recently relegated to Informational Status) with a goal of making it possible for IMAP to replace DMSP. A mail access protocol provides a uniform, OS-independent way of manipulating message data (email or bulletin board) on a remote message store (repository). Mail user agents implementing such a protocol can provide individuals with a consistent view of the message store, regardless of what type of computer they are using, and regardless of where they are connected in the network. Multiple concurrent sessions accessing a single remote mailbox, and single sessions accessing multiple remote mailboxes are both possible with this approach. This differs from POP3 (RFC-1225) in that POP is a store-and-forward transport protocol that allows an MUA to retrieve pending mail from a mail drop (where it is then usually deleted automatically), whereas IMAP is focused on remote mailbox manipulation rather than transport. IMAP differs from various vendor-specific remote access approaches in that IMAP is an open protocol designed to scale well and accommodate diverse types of client operating systems. Security. Security-related tasks include how to incorporate secure authentication mechanisms when establishing a session, and possible interactions with Privacy Enhanced Mail. It is expected that most of the work of this group will be conducted via email. A goal is to integrate and update RFC-1176 and the existing IMAP2bis draft, then submit the result as an Internet draft well before the November IETF WG meeting, which would then focus on detailed review of the text in preparation for submission as a Proposed Standard before the end of 1993. Goals and Milestones: Aug 93 Post an Internet Draft of the revised IMAP 2 protocol. Aug 93 Hold an Interim Working Meeting at UW or CMU. Nov 93 Hold a Working Group meeting to review the IMAP document. Nov 93 Hold a Working Group meeting at the November IETF meeting. Dec 93 Submit the IMAP protocol to the IESG for consideration as a Proposed Standard. From owner-imap@cac.washington.edu Thu Jun 10 14:28:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07284; Thu, 10 Jun 93 14:28:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16323; Thu, 10 Jun 93 14:28:25 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ctt.ctt.bellcore.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16317; Thu, 10 Jun 93 14:28:23 -0700 Received: from shadow.secure.bellcore.com by ctt.ctt.bellcore.com (4.1/1.34) id AA01654; Thu, 10 Jun 93 17:28:17 EDT Received: by shadow.secure.bellcore.com (4.1/SMI-4.1) id AA13970; Thu, 10 Jun 93 16:51:53 EDT Date: Thu, 10 Jun 93 16:51:53 EDT From: Steve Lunt Message-Id: <9306102051.AA13970@shadow.secure.bellcore.com> To: cat-ietf@mit.edu, imap@cac.washington.edu Subject: Re: WG ACTION: Interactive Mail Access Protocol (imap) > Security. Security-related tasks include how to incorporate secure > authentication mechanisms when establishing a session, and possible > interactions with Privacy Enhanced Mail. Since IMAP would be an online, interactive protocol (as opposed to store-and-forward), CAT mechanisms would be more appropriate to secure it than PEM. I don't see any interactions with PEM. -- Steve Steven J. Lunt lunt@bellcore.com Information Technology Security RRC 1L-213 Bellcore 444 Hoes Lane (908) 699-4244 Piscataway, NJ 08854 > Subject: WG ACTION: Interactive Mail Access Protocol (imap) > Date: Thu, 10 Jun 93 15:12:33 -0400 > From: Greg Vaudreuil > > A new working group has been formed in the Applications Area of the > IETF. Please contat the working group chairman of the Internet area > directors for more information. > > Greg Vaudreuil > IESG Secretary > > > Interactive Mail Access Protocol (imap) > --------------------------------------- > > Charter > > Chair(s): > Terry Gray > > Applications Area Director(s) > Brewster Kahle > Erik Huizer > > Mailing lists: > General Discussion:imap@cac.washington.edu > To Subscribe: imap-request@cac.washington.edu > Archive: ftp.cac.washington.edu:‾/imap/imap_archive > > Description of Working Group: > > The Internet Interactive Mail Access Protocol (IMAP) working group > is chartered to refine and extend the current IMAP2 protocol as a > candidate standard for a client-server Internet email protocol to > manipulate remote mailboxes as if they were local. An explicit > objective is to retain compatibility with the growing installed base > of IMAP2-compliant software. It is expected that the resulting > specification will replace both RFC-1176 and the more recent (as yet > unplublished) IMAP2bis extensions document. > > The IMAP Working Group will also investigate how to provide for > ``disconnected operation'' capabilities similar to the DMSP protocol > (RFC-1056, recently relegated to Informational Status) with a goal > of making it possible for IMAP to replace DMSP. > > A mail access protocol provides a uniform, OS-independent way of > manipulating message data (email or bulletin board) on a remote > message store (repository). Mail user agents implementing such a > protocol can provide individuals with a consistent view of the > message store, regardless of what type of computer they are using, > and regardless of where they are connected in the network. Multiple > concurrent sessions accessing a single remote mailbox, and single > sessions accessing multiple remote mailboxes are both possible with > this approach. > > This differs from POP3 (RFC-1225) in that POP is a store-and-forward > transport protocol that allows an MUA to retrieve pending mail from > a mail drop (where it is then usually deleted automatically), > whereas IMAP is focused on remote mailbox manipulation rather than > transport. IMAP differs from various vendor-specific remote access > approaches in that IMAP is an open protocol designed to scale well > and accommodate diverse types of client operating systems. > > Security. Security-related tasks include how to incorporate secure > authentication mechanisms when establishing a session, and possible > interactions with Privacy Enhanced Mail. > > It is expected that most of the work of this group will be conducted > via email. A goal is to integrate and update RFC-1176 and the > existing IMAP2bis draft, then submit the result as an Internet draft > well before the November IETF WG meeting, which would then focus on > detailed review of the text in preparation for submission as a > Proposed Standard before the end of 1993. > > > Goals and Milestones: > > Aug 93 Post an Internet Draft of the revised IMAP 2 protocol. > > Aug 93 Hold an Interim Working Meeting at UW or CMU. > > Nov 93 Hold a Working Group meeting to review the IMAP document. > > Nov 93 Hold a Working Group meeting at the November IETF meeting. > > Dec 93 Submit the IMAP protocol to the IESG for consideration as a Proposed > Standard. From owner-imap@cac.washington.edu Thu Jun 10 14:58:12 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08198; Thu, 10 Jun 93 14:58:12 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16698; Thu, 10 Jun 93 14:58:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16692; Thu, 10 Jun 93 14:58:01 -0700 From: Rob Austein To: Steve Lunt Cc: cat-ietf@mit.edu, imap@cac.washington.edu In-Reply-To: Steve Lunt's message of Thu, 10 Jun 93 16:51:53 EDT <9306102051.AA13970@shadow.secure.bellcore.com> Subject: WG ACTION: Interactive Mail Access Protocol (imap) Date: Thu, 10 Jun 93 17:57:05 EDT Message-Id: <9306101757.aa21567@quern.epilogue.com> Don't be fooled by the protocol name. One of the goals of the IMAP WG is to add support for "disconnnected access" to the existing IMAP protocol, similar to what DMSP (PCMAIL) calls "batch mode". --Rob Austein From owner-imap@cac.washington.edu Fri Jun 11 05:54:55 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24073; Fri, 11 Jun 93 05:54:55 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14088; Fri, 11 Jun 93 05:54:37 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from pad-thai.aktis.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14082; Fri, 11 Jun 93 05:54:32 -0700 Received: from gza-server.aktis.com by pad-thai.aktis.com (5.67/) with SMTP id ; Fri, 11 Jun 93 08:54:32 -0400 Received: by gza-server.aktis.com (4.1/4.7) id AA00738; Fri, 11 Jun 93 08:54:29 EDT Message-Id: <9306111254.AA00738@gza-server.aktis.com> To: Rob Austein Cc: Steve Lunt , cat-ietf@MIT.EDU, imap@cac.washington.edu, linn@GZA.COM Subject: Re: WG ACTION: Interactive Mail Access Protocol (imap) In-Reply-To: Your message of "Thu, 10 Jun 1993 17:57:05 EDT." <9306101757.aa21567@quern.epilogue.com> Date: Fri, 11 Jun 1993 08:54:28 -0400 From: John Linn If the security requirement relates to message/content protection, largely independent of transport, this sounds like PEM. If it relates to a real-time, peer-peer session instantiated to transfer mail from one place to another, this sounds more like CAT (drawing analogy, e.g., to Kerberized POP). PEM (given sufficient certificate cache and related information held locally) can be applied within a disconnected device without IMAP or other mail transport needing to know or care that PEM is being used. I'd expect (please correct me if I'm wrong) that the "disconnected access" requirement doesn't imply PEM but instead implies the need for a CAT mechanism offering the characteristic that credentials for security context establishment must remain or become available at the point in time when the currently-disconnected device later becomes connected to the outside world. Since the act of becoming connected likely corresponds to a user login event of some sort, IMAP activity would be queued locally pending the connection, credential establishment, and authentication-bearing context setup. (Caveat: I'm not at all familiar with IMAP, and could well be misinferring its paradigm.) --jl From owner-imap@cac.washington.edu Fri Jun 11 09:20:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28646; Fri, 11 Jun 93 09:20:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25474; Fri, 11 Jun 93 09:19:53 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25468; Fri, 11 Jun 93 09:19:52 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06464; Fri, 11 Jun 93 09:19:51 -0700 Date: Fri, 11 Jun 1993 09:19:39 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Working Group meeting To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Folks, The response to my inquiries about who will be attending the Amsterdam IETF has indicated that only a few of you will be able to make it. I still expect to be there, and will attempt to arrange a session on IMAP, if nothing else to gather input from folks who cannot normally attend IETF mtgs. However, it is clear that several of the key players will not be there, so the July IETF session will not attempt to do any detail design work. Accordingly, John Myers (CMU) and I have been talking about holding a working group meeting in the U.S., sometime in August. Questions: -Who would be able to come? -Would more people be able to come to a mtg at UW or CMU? -Is two days the right length to plan for? -What part of the week is preferred? (beginning, middle, end) Note that INET93 and Interop are in San Francisco the weeks of 8/16 and 8/23, so it can't be during those weeks unless we want to try to piggyback the mtg on one of those. (I have no idea what would be involved in finding a room to use, but would imagine the INET sponsors might be helpful.) The week of 8/9 is the earliest I could participate... and I probably have a slight bias for holding it at UW so that more of our team could participate, but we should pick the place where the greatest number of workers can attend. -teg From owner-imap@cac.washington.edu Thu Jun 24 13:55:54 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14231; Thu, 24 Jun 93 13:55:54 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02562; Thu, 24 Jun 93 13:55:27 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02556; Thu, 24 Jun 93 13:55:25 -0700 Received: from Mac-Treister.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA13872; Thu, 24 Jun 93 13:55:24 PDT Date: Thu, 24 Jun 93 13:52:45 -0800 From: Adam Treister To: imap@cac.washington.edu Subject: imapd for aix 3.2//risc-6000 Cc: jdh@bu-pub.bu.edu (Jason Heirtzler) Message-Id: In-Reply-To: Your message <9306240031.AA15656@bu-pub.bu.edu> of Wed, 23 Jun 93 20:31:51 -0400 Content-Type: TEXT/plain; charset=US-ASCII Can anyone help with this..... From: jdh@bu-pub.bu.edu (Jason Heirtzler) To: treister@sumex-aim.stanford.edu Date: Wed, 23 Jun 93 20:31:51 -0400 Subject: imapd for aix 3.2//risc-6000 Hello, would you happen to have imapd for the risc-6000 running AIX 3.2 ? I saw the source on sumex-aim in /imap which was imap version 3.2, but it seems to have some problems on aix 3.2 Thanks, Jason Heirtzler Boston University -------------------------------------------------- Adam Treister Polya Hall 205, Stanford CA 94305 - (415) 725-9449 -------------------------------------------------- From owner-imap@cac.washington.edu Thu Jun 24 14:00:30 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14316; Thu, 24 Jun 93 14:00:30 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25445; Thu, 24 Jun 93 14:00:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25439; Thu, 24 Jun 93 14:00:25 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA10019; Thu, 24 Jun 93 14:00:12 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA24082; Thu, 24 Jun 93 14:00:05 -0700 Date: Thu, 24 Jun 1993 13:58:11 -0700 (PDT) From: Mark Crispin Subject: re: imapd for aix 3.2//risc-6000 To: Adam Treister Cc: imap@cac.washington.edu, Jason Heirtzler In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Jason Heirtzler - The reference IMAP server implementation is on ftp.cac.washington.edu, in the file mail/imap.tar.Z The SUMEX-AIM IMAP server is an older implementation and is not current with modern IMAP technology (although for the most part it is still interoperable. This implementation supports AIX 3.2. Use the A32, not the AIX, port; the AIX port is for AIX/370. -- Mark -- From owner-imap@cac.washington.edu Fri Jun 25 13:23:33 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09960; Fri, 25 Jun 93 13:23:33 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01236; Fri, 25 Jun 93 13:23:25 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01230; Fri, 25 Jun 93 13:23:23 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA10684; Fri, 25 Jun 93 13:23:17 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA28972; Fri, 25 Jun 93 13:23:10 -0700 Date: Fri, 25 Jun 1993 13:13:11 -0700 (PDT) From: Mark Crispin Subject: MAILBOX and BBOARD replies To: Chris Newman Cc: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It appears that there is a serious bug in the IMAP protocol BNF that we are going to have to work on. The IMAP specification uses the concept of a ``string'', which can be NIL, an atom, a quoted string, or a literal. In reality, what has come about is that in fetch responses a string can be NIL, a quoted string, or a literal. Atoms are not permitted. In certain other cases (e.g. MAILBOX and BBOARD), the string is a whole-line argument. In certain other cases (e.g. flags and keywords), the string is an atom. I thought I could fix the code to conform to the document, but experimentation showed that lots of deployed code breaks. So, I think it would be best if the new IMAP document describes the implemented behavior, rather than the rather vaguely-expressed Lisp-like behavior that RFC-1176 inherited from RFC-1064. Comments? From owner-imap@cac.washington.edu Fri Jun 25 14:49:23 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12857; Fri, 25 Jun 93 14:49:23 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16544; Fri, 25 Jun 93 14:49:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16538; Fri, 25 Jun 93 14:49:01 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for IMAP@cac.washington.edu; Fri, 25 Jun 93 17:48:49 EDT Received: via switchmail; Fri, 25 Jun 1993 17:48:48 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Fri, 25 Jun 1993 17:48:34 -0400 (EDT) Received: via niftymail; Fri, 25 Jun 1993 17:48:28 -0400 (EDT) Date: Fri, 25 Jun 1993 17:48:23 -0400 (EDT) From: Chris Newman Subject: Re: MAILBOX and BBOARD replies To: Mark Crispin Cc: IMAP Interest List In-Reply-To: References: Message-Id: <741044903.27260.0@nifty.andrew.cmu.edu> RFC-1176 clearly states (in the command summary) that the "* MAILBOX" and "* BBOARD" commands have a single "string" argument. In IMSP, we've taken advantage of this fact by adding more fields (such as server location(s)) to this unsolicited reply -- the goal being to allow the IMAP and IMSP client code to share as much parsing as possible. Rather than making the protocol definition less consistant and RFC-1176 invalid, it would be better to state that having certain characters in mailbox/bboard names (e.g. double-quotes and spaces) are likely to break older clients that don't conform to the spec. Flags and keywords already are defined to be ATOMs in the BNF, so there's no ambiguity there. - Chris From owner-imap@cac.washington.edu Sun Jun 27 21:14:49 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16298; Sun, 27 Jun 93 21:14:49 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11496; Sun, 27 Jun 93 21:14:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11490; Sun, 27 Jun 93 21:14:28 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA13022; Sun, 27 Jun 93 21:14:22 -0700 Date: Sun, 27 Jun 1993 20:46:33 -0700 (PDT) From: Mark Crispin Subject: Re: MAILBOX and BBOARD replies To: Chris Newman Cc: IMAP Interest List In-Reply-To: <741044903.27260.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Chris - > RFC-1176 clearly states (in the command summary) that the "* MAILBOX" > and "* BBOARD" commands have a single "string" argument. We have a few problems that have to be ironed out no matter what: 1) No known IMAP implementation generates or accepts atoms where a string is required. Thus, the definition of string as atom, quoted, or literal is broken. It probably should be redefined as being NIL, quoted, or literal. I don't think it will break anything to change the spec on this. 2) Existing IMAP implementations report remote (to the server) mailboxes using the {host}mailbox syntax. That is, they report things such as: * BBOARD {news.u.washington.edu/nntp}comp.mail.misc which is a direct violation of the definition of a literal. I was going to fix this (and even sent you mail saying it was fixed), but then I found that there were horrible interoperability problems. Without having a flag day much worse than what happened when COPY's semantics were changes so as not to create the target mailbox, I don't see how this can be fixed. What can I say except ``I'm sorry, I goofed.'' > In IMSP, > we've taken advantage of this fact by adding more fields (such as > server location(s)) to this unsolicited reply -- the goal being to > allow the IMAP and IMSP client code to share as much parsing as > possible. I agree that this is desirable, but it may end up being necessary to have IMSP be different from IMAP in this case. How about having the new fields appear *before* the mailbox/bboard name instead of after them? That provides for a number of extension capabilities while retaining compatibility. > Rather than making the protocol definition less consistant and > RFC-1176 invalid, it would be better to state that having certain > characters in mailbox/bboard names (e.g. double-quotes and spaces) are > likely to break older clients that don't conform to the spec. The problem is in what you do when spaces and quotes happen, and worse what about remote mailboxes which appear in the imapd replies. -- Mark -- From owner-imap@cac.washington.edu Mon Jun 28 10:05:37 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29208; Mon, 28 Jun 93 10:05:37 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14488; Mon, 28 Jun 93 10:05:23 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14482; Mon, 28 Jun 93 10:05:21 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for IMAP@cac.washington.edu; Mon, 28 Jun 93 13:05:17 EDT Received: via switchmail; Mon, 28 Jun 1993 13:05:17 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 28 Jun 1993 13:05:02 -0400 (EDT) Received: via niftymail; Mon, 28 Jun 1993 13:04:47 -0400 (EDT) Date: Mon, 28 Jun 1993 13:04:45 -0400 (EDT) From: Chris Newman Subject: Re: MAILBOX and BBOARD replies To: Mark Crispin Cc: IMAP Interest List In-Reply-To: References: Message-Id: <741287085.27260.0@nifty.andrew.cmu.edu> Mark Crispin writes: > 1) No known IMAP implementation generates or accepts atoms where a string is > required. Thus, the definition of string as atom, quoted, or literal is > broken. It probably should be redefined as being NIL, quoted, or literal. > I don't think it will break anything to change the spec on this. > > 2) Existing IMAP implementations report remote (to the server) mailboxes > using the {host}mailbox syntax. That is, they report things such as: > * BBOARD {news.u.washington.edu/nntp}comp.mail.misc > which is a direct violation of the definition of a literal. I was going > to fix this (and even sent you mail saying it was fixed), but then I found > that there were horrible interoperability problems. Without having a flag > day much worse than what happened when COPY's semantics were changes so as > not to create the target mailbox, I don't see how this can be fixed. OK, here's my proposal: A) Create a construct called a FOO-STRING (better names, anyone?) which may be "NIL", a quoted string, or a literal. Replace STRING with FOO-STRING where appropriate in the spec. B) Loosen the restrictions on ATOMS used in a STRING to be: an ATOM used in a STRING may not begin with a `{' followed by at least one digit, or contain a `"', CR, or LF. Or perhaps even define an ATOM this way (similar to what we've done in the IMSP spec). Proposal A should solve problem 1, while still preserving the useful concept of a STRING (e.g. I think it's a good idea not to have to wrap everything in quotes). Proposal B should mostly resolve issue 2, except for bboard names with spaces and quotes (which are uncommon), or hostnames beginning with a digit. It preserves the "* BBOARD string" syntax in RFC-1176, which makes additional fields possible. An additional bonus of proposal B, is that it allows patterns with the `%' wildcard to be sent as non-literals and still follow the spec. - Chris From owner-imap@cac.washington.edu Mon Jun 28 11:05:49 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01449; Mon, 28 Jun 93 11:05:49 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08809; Mon, 28 Jun 93 11:05:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08801; Mon, 28 Jun 93 11:05:34 -0700 Received: from Mac-Treister.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA03383; Mon, 28 Jun 93 11:05:23 PDT Date: Mon, 28 Jun 93 11:02:42 -0800 From: Adam Treister To: Chris Newman Subject: Re: MAILBOX and BBOARD replies Cc: Mark Crispin , IMAP Interest List Message-Id: In-Reply-To: Your message <741287085.27260.0@nifty.andrew.cmu.edu> of Mon, 28 Jun 1993 13:04:45 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII I'm not sure Im following the nuances of this discussion. But I think there needs to be a way to embed non-IMAP commands into an IMAP stream, and systematically pass it down a line of server processes until someone can deal with it. I'm in a situation where we have 5-6K users of a mainframe database oriented mail system, with amazing filing and retrieval capabilities and a tty interface. We should be able to write an IMAP server for the mainframe, and enable access to the archives of messages via a snazzy gui, but will need to make homegrown RPC calls to access the indexes, or extended capabilities. Cant my client test this on connection and say: if (isConnectedToEMS) IMAPSend("A0001 EMBEDDED ( EMS Expire(4, 30 days) )" else IMAPSend("A0001 DELETE 4" ) in such a way that the imapd will pass along the embedded command. Anyway, to come back to the thread, if this is reasonable, couldn't IMSP then send: A0001 EMBEDDED ( IMSP SetACL... ) Adam -------------------------------------------------- Adam Treister Polya Hall 205, Stanford CA 94305 - (415) 725-9449 -------------------------------------------------- From owner-imap@cac.washington.edu Mon Jun 28 12:30:10 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03514; Mon, 28 Jun 93 12:30:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09974; Mon, 28 Jun 93 12:29:56 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from phantom.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09968; Mon, 28 Jun 93 12:29:54 -0700 Received: from [140.142.110.88] by phantom.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04721; Mon, 28 Jun 93 12:29:53 -0700 Date: Mon, 28 Jun 1993 12:06:22 PDT From: Terry Gray Reply-To: Terry Gray Subject: Re: Working Group meeting To: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII OK, folks... here are the results: One person prefers meeting at CMU. Two people prefer San Francisco. Two people, plus four of us at UW, prefer Seattle. Accordingly, I'd like to propose that an IMAP working group meeting be held at UW on Mon-Tues Aug 30-31. This is the week following Interop, for those who might be able to "take the long way home"... Comments/RSVP? (Please also let me know if you really want to attend, but can't due to the time or location... If there are enough of those, we'll try again.) -teg From owner-imap@cac.washington.edu Tue Jun 29 00:51:33 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19238; Tue, 29 Jun 93 00:51:33 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18105; Tue, 29 Jun 93 00:51:06 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18099; Tue, 29 Jun 93 00:51:04 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA14558; Tue, 29 Jun 93 00:51:00 -0700 Date: Tue, 29 Jun 1993 00:34:01 -0700 (PDT) From: Mark Crispin Subject: Re: MAILBOX and BBOARD replies To: Chris Newman Cc: IMAP Interest List In-Reply-To: <741287085.27260.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I don't think there is at present *anything* that uses the current definition of string (including atoms). Even though you say ``it's a good idea not to have to wrap everything in quotes'', in actual fact everything is. Unfortunately, ``compatibility with the past'' means that % can not be in anything other than a literal or a text_line. Perhaps the people at Stanford can comment on whether or not MM-D on Interlisp-D machines is extinct, since that restriction was for its benefit. Let me offer a counter-proposal to yours: Retain the current implementation's definition of the FIND result mailbox name as being text_line (as opposed to the RFC-1176 definition as string). In IMSP, transmit the additional information as a list in front of the mailbox name, e.g. something like: * MAILBOX (foo bar baz) INBOX If there is not something that looks like a proper list in front of the additional data, then assume it's the IMAP form. The burden would be upon future servers not to have mailbox names that start with things that look like list. I'm prepared to put a monument in the IMAP BNF that essentially indicates that. It isn't as clean as one would like, but it causes less trauma to existing code. From owner-imap@cac.washington.edu Tue Jun 29 09:41:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03498; Tue, 29 Jun 93 09:41:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21699; Tue, 29 Jun 93 09:41:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SUMEX-AIM.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21693; Tue, 29 Jun 93 09:41:36 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by SUMEX-AIM.Stanford.EDU (4.1/inc-1.0) id AA12234; Tue, 29 Jun 93 09:41:33 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA07181; Tue, 29 Jun 93 09:38:53 -0700 Date: Tue, 29 Jun 1993 09:27:21 -0700 (PDT) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: MAILBOX and BBOARD replies To: Mark Crispin Cc: Chris Newman , IMAP Interest List In-Reply-To: Mark Crispin's message of Tue, 29 Jun 1993 00:34:01 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Unfortunately, ``compatibility with the past'' means that % can not be > in anything other than a literal or a text_line. Perhaps the people > at Stanford can comment on whether or not MM-D on Interlisp-D machines > is extinct, since > that restriction was for its benefit. Interestingly enough we were going to run MM-D about three weeks ago on a SUN running the INVOS interlisp-D compatibility package, but we could not because the ip packets are not passed from the unix kernel to the INVOS package. So, we no longer use MM-D. Whether or not it is used elsewhere is unknown. One can query comp.sys.xerox. MM-D is a great program considering its vintage :-) Bill From owner-imap@cac.washington.edu Wed Jun 30 18:10:24 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24903; Wed, 30 Jun 93 18:10:24 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13903; Wed, 30 Jun 93 18:10:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13897; Wed, 30 Jun 93 18:10:13 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21081; Wed, 30 Jun 93 18:10:09 -0700 Date: Wed, 30 Jun 1993 18:03:04 -0700 (PDT) From: Terry Gray Subject: Re: Working Group meeting To: Wallace Colyer Cc: Wallace Colyer , Chris Newman , John Gardiner Myers , imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Wallace, I've received no objections to Aug 30-31, so I'd say 'go for it'... -teg On Wed, 30 Jun 1993, Wallace Colyer wrote: > Are the dates for this set yet? If we buy the tickets by tommorow > we save $120 a piece. > > -Wallace From owner-imap@cac.washington.edu Thu Jul 1 02:40:20 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03516; Thu, 1 Jul 93 02:40:20 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16685; Thu, 1 Jul 93 02:40:12 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from inesc.inesc.pt by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16679; Thu, 1 Jul 93 02:40:06 -0700 Received: from rabbit.inesc.pt by inesc.inesc.pt with SMTP; id AA10851 (5.65c/SunOS4.1.3); Thu, 1 Jul 1993 11:38:39 +0200 Received: by rabbit.inesc.pt (5.57/Ultrix4.2) id AA09378; Thu, 1 Jul 93 11:41:12 +0100 From: ammf@rabbit.inesc.pt (Antonio Franco) Message-Id: <9307011041.AA09378@rabbit.inesc.pt> Subject: IMAP support for several message types To: IMAP@CAC.Washington.EDU Date: Thu, 1 Jul 1993 11:41:12 +0100 (WET DST) Cc: ammf@rabbit.inesc.pt (Antonio Franco) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1213 I have recently read RFC 1203 (2/91). A question occurred me when I saw the following sentence (page 3): "This should allow the IMAP protocol to evolve away from its current reliance on RFC822". Is there any work being done in order to support other message types (for example, X.400 P2(84) or P2(88)) ? I suppose this could be interesting since the same UA could be used for the following configurations: 1) UA <-----> IMAP Server / SMTP Server <-----> SMTP 2) UA <-----> IMAP Server / X.400 MTA <-----> X.400 3) UA <-----> IMAP Server / Mail server <-----> SMTP or X.400 This configuration would allow the UA to receive RFC822 and P2 messages without any conversions to be applied. As far as I can see, this could be achieved by: 1) Fetch 1.1) Using the Generic, Canonical and Concrete keys concept. 1.2) Using the ENCODING recommended feature. 2) Submission 2.1) With some extensions to the SEND recommended feature (?). Regards, Antonio Franco (ammf@inesc.pt) PS: Sorry if I am using the mailing list for a stupid question. From owner-imap@cac.washington.edu Thu Jul 1 07:03:02 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07837; Thu, 1 Jul 93 07:03:02 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18498; Thu, 1 Jul 93 07:02:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18492; Thu, 1 Jul 93 07:02:52 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for IMAP@cac.washington.edu; Thu, 1 Jul 93 10:02:49 EDT Received: via switchmail; Thu, 1 Jul 1993 10:02:48 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Thu, 1 Jul 1993 10:01:54 -0400 (EDT) Received: via niftymail; Thu, 1 Jul 1993 10:01:49 -0400 (EDT) Date: Thu, 1 Jul 1993 10:01:45 -0400 (EDT) From: Chris Newman Subject: Re: MAILBOX and BBOARD replies To: Mark Crispin Cc: IMAP Interest List In-Reply-To: References: Message-Id: <741535305.27260.0@nifty.andrew.cmu.edu> I'd like to see some sort of compromise on this issue such that there are minimal changes to the IMAP spec, and minimal breakage of old clients. The published RFC-1176 spec is important, because we really don't know if anyone else has implemented it. I recall hearing about some commercial IMAP client, and I'm unsure if it's been tested on this issue. Any substantial change to the RFC-1176 spec could break existing clients and servers we don't know about. In addition, I agree that it is important not to break the reference IMAP implementation "too much". But when it was written such that it failed to meet the spec, I don't see a problem with it breaking on unusual cases (e.g. spaces or quotes in bboard names). I agree, however, that it has to work for the {hostname}folder notation since that's in common use. Let me try a slightly different proposal from my previous one: 1) STRINGs should be sent as NIL, a quoted-string, or a literal, but atoms should be accepted as per RFC-1176. 2) NEW-STRINGs are an ATOM, a quoted string, or a literal. An ATOM will be sent if at all possible. The parser should consider the argument an ATOM, unless it contains a `"' or begins with a `{' followed by a digit. 3) Change * MAILBOX, * BBOARD, SELECT, CREATE/RENAME/DELETE, etc. to use NEW-STRING. Proposal 1 should assure compatibility with the reference IMAP implementation, as well as compatibility with RFC-1176 based IMAP implementations. Proposals 2 & 3 are minimal changes to the grammer. They do permit the {hostname}folder notation as used today. They would break the reference IMAP implementation (with "* MAILBOX" and "* BBOARD") only when a bboard name contains a space or a double-quote -- both of which are very uncommon (I only noticed the problem because I was doing extreme-case testing of my IMSP server). I'd also like to point out that what I describe for NEW-STRING is almost precisely what is implemented by the snarf() function in imapd.c -- the only exception being that snarf() uses text_line where I use ATOM. - Chris From owner-imap@cac.washington.edu Thu Jul 1 07:23:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08362; Thu, 1 Jul 93 07:23:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18706; Thu, 1 Jul 93 07:23:07 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18700; Thu, 1 Jul 93 07:23:05 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for IMAP@cac.washington.edu; Thu, 1 Jul 93 10:22:55 EDT Received: via switchmail; Thu, 1 Jul 1993 10:22:53 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Thu, 1 Jul 1993 10:21:22 -0400 (EDT) Received: via niftymail; Thu, 1 Jul 1993 10:21:18 -0400 (EDT) Date: Thu, 1 Jul 1993 10:21:17 -0400 (EDT) From: Chris Newman Subject: embedded commands (was Re: MAILBOX and BBOARD replies) To: Adam Treister Cc: IMAP Interest List In-Reply-To: References: Message-Id: <741536477.27260.0@nifty.andrew.cmu.edu> In message , Adam Treister writes: >I'm in a situation where we have 5-6K users of a mainframe database >oriented mail system, with amazing filing and retrieval capabilities and a >tty interface. We should be able to write an IMAP server for the >mainframe, and enable access to the archives of messages via a snazzy gui, >but will need to make homegrown RPC calls to access the indexes, or >extended capabilities. > >Cant my client test this on connection and say: > >if (isConnectedToEMS) > IMAPSend("A0001 EMBEDDED ( EMS Expire(4, 30 days) )" >else > IMAPSend("A0001 DELETE 4" ) I'd don't really see the need for a reserved "EMBEDDED" word. Why not just try something like: IMAPSend("A0001 EMS Expire(4, 30 days)"); Then if EMS isn't supported on the server, you'll just get a "BAD" response back. >in such a way that the imapd will pass along the embedded command. > >Anyway, to come back to the thread, if this is reasonable, couldn't IMSP >then send: > >A0001 EMBEDDED ( IMSP SetACL... ) The current implementation of IMSP just relays the SETACL command as defined in the IMSP spec to the IMAP server. If the IMAP server doesn't support it (as none do at present), a "BAD" will be returned to IMSP, and IMSP then responds with "tag NO ACLs not implementated at this site" to it's client. In general, this sort of relaying commands through one server to another should be avoided for efficiency unless there's a really good reason to do it (e.g. to implement the "l" access right, IMSP has to know about the ACLs). - Chris From owner-imap@cac.washington.edu Thu Jul 1 10:53:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14541; Thu, 1 Jul 93 10:53:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22186; Thu, 1 Jul 93 10:53:00 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from THOR.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22180; Thu, 1 Jul 93 10:52:58 -0700 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H006G05T5C8WW4NN@INNOSOFT.COM>; Thu, 1 Jul 1993 10:52:52 PDT Date: Thu, 01 Jul 1993 10:22:18 -0700 (PDT) From: Ned Freed Subject: Re: IMAP support for several message types In-Reply-To: Your message dated "Thu, 01 Jul 1993 11:41:12 +0100 (WET DST)" <9307011041.AA09378@rabbit.inesc.pt> To: ammf@rabbit.inesc.pt Cc: IMAP@CAC.Washington.EDU, ammf@rabbit.inesc.pt Message-Id: <01H00XK8FGT88WW4NN@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I have recently read RFC 1203 (2/91). A question occurred > me when I saw the following sentence (page 3): "This should allow > the IMAP protocol to evolve away from its current reliance on RFC822". > Is there any work being done in order to support other > message types (for example, X.400 P2(84) or P2(88)) ? Yes, if you count the addition of structure decomposition aligned with MIME. I know of no plans or intentions to support X.400 P2 or P22 constructs in the protocol, however. Mark? The real advantage of adding structuring support to the protocol is that then you don't have to do it all in every client. Clients can use the server to parse and obtain whatever parts of each message they want. This is true even when you use a disconnectable client -- the client can store the message in whatever format it likes. > I suppose > this could be interesting since the same UA could be used for the > following configurations: > ... > This configuration would allow the UA to receive RFC822 and > P2 messages without any conversions to be applied. While there might be some advantage here, it is not likely to amount to much. Any conversion of X.400 to MIME should involve no loss of semantics at all. (The same cannot be said for the other direction, unfortunately.) Remember that one goal of IMAP is to keep the clients small and simple. Having support for two message formats and structures, no matter what formats you pick, increases the size of the clients considerably. It would be far better to do the conversion to MIME format and structure on the server host. In the case of X.400->MIME this can be done quite efficiently on a server -- I know because I've written code to do it myself. Ned From owner-imap@cac.washington.edu Thu Jul 1 12:32:52 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18289; Thu, 1 Jul 93 12:32:52 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03592; Thu, 1 Jul 93 12:32:35 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from WILMA.CS.UTK.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03586; Thu, 1 Jul 93 12:32:33 -0700 Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.8c-UTK) id AA18292; Thu, 1 Jul 1993 15:31:23 -0400 Message-Id: <9307011931.AA18292@wilma.cs.utk.edu> To: IMAP@cac.washington.edu Subject: using imap to peruse list archives? Cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 01 Jul 1993 15:31:22 -0400 I keep wanting a standardized way for my UA to browse mailing list archives, rather than having to copy the entire archive file to my local machine and translate it to my UA's mailbox format. It seems like IMAP is close to a good approximation of an appropriate protocol to do this. Is this reasonable with the current protocol? If not, is this being looked at? Are there any mailing list archives that are IMAP-accessible from remote sites? Keith Moore From owner-imap@cac.washington.edu Fri Jul 2 00:43:31 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02970; Fri, 2 Jul 93 00:43:31 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06455; Fri, 2 Jul 93 00:43:05 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06449; Fri, 2 Jul 93 00:43:04 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA19815; Fri, 2 Jul 93 00:42:56 -0700 Date: Fri, 2 Jul 1993 00:30:06 -0700 (PDT) From: Mark Crispin Subject: re: IMAP support for several message types To: Antonio Franco Cc: IMAP Interest List In-Reply-To: <9307011041.AA09378@rabbit.inesc.pt> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 1 Jul 1993 11:41:12 +0100 (WET DST), Antonio Franco wrote: > I have recently read RFC 1203 (2/91). A question occurred > me when I saw the following sentence (page 3): "This should allow > the IMAP protocol to evolve away from its current reliance on RFC822". Please do not believe anything you may read in RFC-1203. RFC-1203 is NOT part of any current IMAP development efforts. The base for current IMAP development is RFC-1176. In spite of it having a lower number, it is the authoritative document for IMAP. Extending RFC-1176 is an unpublished document which describes ``IMAP2bis extensions''. This document is available from the ftp.cac.washington.edu anonymous FTP server on the mail/ directory. > Is there any work being done in order to support other > message types (for example, X.400 P2(84) or P2(88)) ? There is presently no such work. As Ned Freed suggests, the current thinking is that the way to address this problem is through X.400 to MIME conversion. IMAP clients should not have to deal with multiple message formats and structures. > 1) Fetch > 1.1) Using the Generic, Canonical and Concrete keys concept. > 1.2) Using the ENCODING recommended feature. > 2) Submission > 2.1) With some extensions to the SEND recommended feature (?). These are RFC-1203 concepts and are not part of IMAP. Nor will they be: - The keys concept, although possibly interesting, was not specified to the point that it could be implemented or even reasonably evaluated. - The encoding concept is an incorrect understanding of how to do multi-media and multinational character sets. It is completely worthless. The IMAP2bis extensions solved this problem correctly. - Sending through IMAP would have a (marginal) benefit only if the IMAP server is co-located with the client on a local area network. If the IMAP server is remote (or in a foreign country), sending through IMAP is potentially a horribly slow (and expensive!) operation. It is best not to go down that slippery slope... From owner-imap@cac.washington.edu Fri Jul 2 00:47:05 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03035; Fri, 2 Jul 93 00:47:05 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06468; Fri, 2 Jul 93 00:46:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06462; Fri, 2 Jul 93 00:46:53 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA19821; Fri, 2 Jul 93 00:46:44 -0700 Date: Fri, 2 Jul 1993 00:43:05 -0700 (PDT) From: Mark Crispin Subject: re: using imap to peruse list archives? To: Keith Moore Cc: IMAP Interest List In-Reply-To: <9307011931.AA18292@wilma.cs.utk.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 01 Jul 1993 15:31:22 -0400, Keith Moore wrote: > I keep wanting a standardized way for my UA to browse mailing list > archives, rather than having to copy the entire archive file to > my local machine and translate it to my UA's mailbox format. > > It seems like IMAP is close to a good approximation of an appropriate > protocol to do this. Is this reasonable with the current protocol? If not, > is this being looked at? Are there any mailing list archives that are > IMAP-accessible from remote sites? Hi Keith - Your message generated a fair amount of discussion here at UW. The answers to your questions are ``Yes!!'', ``Yes!!'' and ``Real Soon Now!!'' Specifically, it is quite reasonable to do this with IMAP; that is what the whole BBOARD functionality is all about (not just netnews). The c-client software isn't quite capable of doing this yet, though. However, the changes needed to make it capable are fairly trivial. The discussion going on is which of a set of possible implementation choices to pick to accomplish it. Stay tuned... -- Mark -- From owner-imap@cac.washington.edu Fri Jul 2 01:43:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04467; Fri, 2 Jul 93 01:43:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01399; Fri, 2 Jul 93 01:43:35 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01393; Fri, 2 Jul 93 01:43:33 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <06566-0@ppsw1.cam.ac.uk>; Fri, 2 Jul 1993 09:43:26 +0100 Date: Fri, 02 Jul 93 09:43:19 BST From: A.Grant@ucs.cam.ac.uk To: imap@cac.washington.edu Subject: re: IMAP support for several message types Message-Id: In-Reply-To: > - Sending through IMAP would have a (marginal) benefit only if the IMAP > server is co-located with the client on a local area network. On the contrary, sending through IMAP could have a great benefit if the IMAP server is co-located with the client (or to be precise, if the IMAP server is not located significantly further away than the nearest available SMTP server), in that it would not require the sender's authenticity to be established for each submitted message. I may be wrong but I expect IMAP to be used a lot from shared non-personal workstations, in which case authentication becomes a major issue. > If the IMAP > server is remote (or in a foreign country), sending through IMAP is > potentially a horribly slow (and expensive!) operation. So? Nobody would be forced to use it. Anyway, if I was in a foreign country for a long time I would be just as likely to want to get my home IMAP server to forward my messages automatically to an IMAP server closer to me. Is there going to be IMAP support for this? And I would want a "submit from message store" function so that I could say "Fred, I'm out of the country - please could you deal with the attached 100MB piece of video mail". From owner-imap@cac.washington.edu Fri Jul 2 02:24:13 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05536; Fri, 2 Jul 93 02:24:13 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06842; Fri, 2 Jul 93 02:24:00 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06836; Fri, 2 Jul 93 02:23:58 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA20042; Fri, 2 Jul 93 02:23:51 -0700 Date: Fri, 2 Jul 1993 01:54:24 -0700 (PDT) From: Mark Crispin Subject: re: IMAP support for several message types To: A.Grant@ucs.cam.ac.uk Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 02 Jul 93 09:43:19 BST, A.Grant@ucs.cam.ac.uk wrote: > On the contrary, sending through IMAP could have a great benefit if the > IMAP server is co-located with the client (or to be precise, if the IMAP > server is not located significantly further away than the nearest available > SMTP server), in that it would not require the sender's authenticity to be > established for each submitted message. Access authentication is not the same thing as posting authentication. Note that IMAP already has an anonymous access mode. To get authenticated e-mail, you need authenticated data (e.g. PEM) and/or authenticated transport. Shoehorning transport into an access protocol such as IMAP, or the use of kludges like RFC-931, are band-aids that at best give the illusion of solving the problem. It is not the right solution to the problem of forged e-mail. There is also a performance problem, even on a local network. It ties up the IMAP stream while message delivery is going on. Sometimes it takes several minutes, particularly with dialup IP links, for the message to be delivered over the network. Shoehorning delivery into IMAP precludes background delivery of mail. > > If the IMAP > > server is remote (or in a foreign country), sending through IMAP is > > potentially a horribly slow (and expensive!) operation. > So? Nobody would be forced to use it. I can guarantee that most MUA implementors will implement only one way of sending mail. Whatever way is the ``encouraged way'' will become the forced way. The POP world has discovered this, with clients that use optional extentions and don't work with the reference implementations. > Anyway, if I was in a foreign > country for a long time I would be just as likely to want to get my home > IMAP server to forward my messages automatically to an IMAP server closer > to me. I am a frequent traveller, and I object to having to forward my mail every time I am out of the country for a week. Why should I, when I have this wonderful IMAP that is carefully designed to work well over slow links? Why shouldn't I keep my mail on a foreign IMAP server on that IMAP server if I want. Perhaps that data is there because it is primarily useful there, and not all forwarded to my local machine. Why should my IMAP mail reading be blocked while a message I just composed is being sent overseas, when I could drop it off at a local SMTP server in the background? The whole point is, with access and delivery functionality separate, the user has the choice. With them shoehorned into the same protocol, there is no choice. I agree that it sounds nice and easy, but it's only suitable in the most simple cases and has many possible bad side effects that can not be prevented easily. Why not lobby in the IETF-SMTP group to have authenticated transport? That is, after all, what you really want; the credentials required to access mail are not necessarily the same as the credentials to post mail. > And I would want a > "submit from message store" function so that I could say "Fred, I'm out > of the country - please could you deal with the attached 100MB piece of > video mail". MIME provides a mechanism of doing this now, with the external reference functionality. From owner-imap@cac.washington.edu Fri Jul 2 10:40:22 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16175; Fri, 2 Jul 93 10:40:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06457; Fri, 2 Jul 93 10:40:04 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06451; Fri, 2 Jul 93 10:39:58 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <24167-0@ppsw1.cam.ac.uk>; Fri, 2 Jul 1993 18:39:50 +0100 Date: Fri, 02 Jul 93 18:39:35 BST From: A.Grant@ucs.cam.ac.uk To: imap@CAC.Washington.EDU Subject: re: IMAP support for several message types Message-Id: In-Reply-To: > Access authentication is not the same thing as posting authentication. > Note that IMAP already has an anonymous access mode. If IMAP lets a client read a user's mail _by virtue of it having convinced IMAP that it was the user in question_ (and not otherwise), there is no reason not to allow it to submit on behalf of that user. (Subject to any administrative restrictions on mail submission, of course.) > To get authenticated e-mail, you need authenticated data (e.g. PEM) > and/or authenticated transport. Shoehorning transport into an access > protocol such as IMAP a) PEM is end-to-end; for it to have any value, both ends must be enabled for PEM. Feasible for a small group, but not for ubiquitous e-mail (yet) - just think of the key management problems for 20,000 naive users. How would PEM fit into IMAP? It would render all IMAP's fancy MIME-searching features useless, given that PEM specifically applies itself to the entire message. All IMAP would see is a lot of encrypted stuff. b) Authenticated transport (Kerberos?) would solve the problem only if you can do more than one thing on a transport connection. This is not possible in IMAP; it doesn't support either multiplexing onto, or reuse of, a transport connection. Should it? In this respect P7 scores over IMAP. It views retrieval, submission and authentication as logically distinct; yet it allows them to happen on the same transport connection. It is IMAP and SMTP that don't make a clear distinction between finding out who the user is and then what they want to do, and attempt to 'shoehorn' authentication into both protocols. > I can guarantee that most MUA implementors will implement only one way > of sending mail. True. But people can choose which MUA they use! > MIME provides a mechanism of doing this now, with the external reference > functionality. Out of interest, how? Which access-type is defined for use with IMAP? (MAIL-SERVER doesn't seem to be right...) From owner-imap@cac.washington.edu Fri Jul 2 12:02:37 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18595; Fri, 2 Jul 93 12:02:37 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07838; Fri, 2 Jul 93 12:02:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from THOR.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07832; Fri, 2 Jul 93 12:02:22 -0700 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H015PWRCZK8WW4NN@INNOSOFT.COM>; Fri, 2 Jul 1993 12:02:04 PDT Date: Fri, 02 Jul 1993 11:45:46 -0700 (PDT) From: Ned Freed Subject: RE: IMAP support for several message types In-Reply-To: Your message dated "Fri, 02 Jul 1993 18:39:35 -0300 (BST)" To: A.Grant@ucs.cam.ac.uk Cc: imap@CAC.Washington.EDU Message-Id: <01H02EACZM688WW4NN@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > a) PEM is end-to-end; for it to have any value, both ends must be enabled > for PEM. Feasible for a small group, but not for ubiquitous e-mail (yet) - > just think of the key management problems for 20,000 naive users. How would > PEM fit into IMAP? It would render all IMAP's fancy MIME-searching features > useless, given that PEM specifically applies itself to the entire message. > All IMAP would see is a lot of encrypted stuff. The issue of MIME-PEM incompatibility is a general one that affects many things besides IMAP. This is being addressed by the PEM working group; there is an Internet Draft available that describes one approach to resolving this. If this approach is used IMAP's MIME facilities change from being inappropriate for PEM processing to just the thing you need to do PEM processing. There's more to PEM processing than getting at the PEM material in the message, however. In particular, the handling of certificates is a very nasty problem. An IMAP client using PEM must at a minimum be able to: (1) Retrieve the current user's certificate (including the private key). (2) Obtain certificates for other users. (3) Validate certificates for other users (this is a complex topic in its own right and one that can be broken up in several ways). At present there are no established protocols for doing this. X.500 may provide part of the solution but really isn't positioned correctly -- you can use X.500 to obtain certificates but the X.500 client has to do all the tracking, alias handling, and validation itself. A SUBSTANTIAL amount of code is involved in doing all this stuff... This is not desireable in a lightweight client. (Nor is having an entire OSI stack, although LDAP presents a viable solution in this area.) What is needed is an extremely lightweight means of obtaining and checking certificates using a remote trusted server. This could be part of IMSP, I guess. If so, there has to be mutual authentication of client and server (a la Kerberos) and either the IMSP protocol must support encryption of various pieces of critical data or the entire data stream must be encrypted. I would prefer the former for performance reasons. Ned From owner-imap@cac.washington.edu Fri Jul 2 13:00:33 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19839; Fri, 2 Jul 93 13:00:33 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09374; Fri, 2 Jul 93 13:00:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Mordor.Stanford.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09368; Fri, 2 Jul 93 13:00:16 -0700 Received: from macii-morgan.Stanford.EDU by Mordor.Stanford.EDU (5.65/inc-1.0) id AA10422; Fri, 2 Jul 93 13:00:15 -0700 Date: Fri, 2 Jul 93 13:00:45 -0800 From: RL "Bob" Morgan To: IMAP@cac.washington.edu Subject: Re: using imap to peruse list archives? Cc: moore@cs.utk.edu Message-Id: In-Reply-To: Your message <9307011931.AA18292@wilma.cs.utk.edu> of Thu, 01 Jul 1993 15:31:22 -0400 Content-Type: TEXT/plain; charset=US-ASCII > I keep wanting a standardized way for my UA to browse mailing list > archives We use IMAP to do this here for several dozen mailing lists. It's the only way my inbox has been able to remain vaguely under control. It allows our whole group to easily browse list archives on a whole range of topics. The things I'd like to work better are: 1. These mailboxes are read-only to everyone, so I can't keep any of my state info about them (eg messages read). (Thinking about shared mailboxes, it seems like both shared-state and state-per-reader are useful.) 2. My IMAP client of choice (Mailstrom) tends to have problems when mailboxes are large ( > 2000 messages, say). This isn't a protocol problem, of course. 3. Things being what they are, it's hard to get around to looking at these mailboxes as often as I should. I have thought about something simple that would each day go through a selected set of mailboxes, extract headers of new messages, and mail them to my regular inbox to better alert me to new messages of interest. As an occasional Perl hacker, this led me to try to work on the "mcheck" example that comes with c-client to produce a flexible command-line IMAP client that could be integrated into scripts (unfortunately this is far from done). I'd be interested if anyone else has done anything like this. It may be that taking advantage of News/NNTP would solve some of these problems today, but I'm not a News hacker. I'm inclined to believe, as Mark implies, that IMAP could support this without any protocol changes. - RL "Bob" Morgan Networking Systems Stanford From owner-imap@cac.washington.edu Fri Jul 2 13:40:51 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21175; Fri, 2 Jul 93 13:40:51 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09013; Fri, 2 Jul 93 13:40:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from phantom.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09007; Fri, 2 Jul 93 13:40:33 -0700 Received: from [140.142.110.88] by phantom.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19464; Fri, 2 Jul 93 13:40:31 -0700 Date: Fri, 2 Jul 1993 13:17:29 PDT From: Terry Gray Subject: Re: using imap to peruse list archives? To: RL Bob Morgan Cc: IMAP@cac.washington.edu, moore@cs.utk.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 2 Jul 1993, RL Bob Morgan wrote: > 1. These mailboxes are read-only to everyone, so I can't keep any of my > state info about them (eg messages read). (Thinking about shared > mailboxes, it seems like both shared-state and state-per-reader are > useful.) Yes! In addition to the shared-(global)-state case we need to define the mail-equivalent of a .newsrc (only better, as we need more than a single flag) so that there can be per-user "views" of a read-only archive. I've come to think in terms of the following kinds of messge folders: Private folder/private state <-- normal personal mailbox Shared folder/shared state <-- needed for group transaction processing Shared folder/per-user state <-- exists (barely) for news Shared folder/no state <-- exists for both news and mail By the way, Tenex-format folders are well-suited to the shared-folder/ shared-state case, since the flags field is fixed length, and can therefore be updated in place. MRC's IMAPd just needs to be a little more aggressive about propagating state changes to the client, and the clients have to watch for state changes they didn't cause... I really agree that both forms of concurrent access to a folder will prove to be important. -teg From owner-imap@cac.washington.edu Fri Jul 2 13:47:10 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21325; Fri, 2 Jul 93 13:47:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09134; Fri, 2 Jul 93 13:46:57 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09128; Fri, 2 Jul 93 13:46:55 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 2 Jul 93 16:46:46 EDT Received: via switchmail; Fri, 2 Jul 1993 16:46:42 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 16:45:30 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 16:45:20 -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; Fri, 2 Jul 1993 16:45:16 -0400 (EDT) Message-Id: Date: Fri, 2 Jul 1993 16:45:16 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Authenticated delivery In-Reply-To: <01H02EACZM688WW4NN@INNOSOFT.COM> References: <01H02EACZM688WW4NN@INNOSOFT.COM> Beak: Is Certificate management quite possibly could be put under the domain of IMSP. I don't have a good understanding of how to do it, so until someone gives me a well-designed proposal, it's not going to happen. On the other hand, it could be that certificate management belongs in the directory service. So far I have tried to keep directory service functionality out of IMSP for the simple reason that directory services open up entire cans of worms. My current preferences encryption are for protocol extensions to the IMAP and IMSP protocols to cause the entire data stream to be encrypted. If you're concerned about privacy, you really want this in IMAP in order to keep network snoops from reading your mail while you do. If, for performance reasons, you want only pieces of critical data to be encrypted, you can pop into and out of encrypted mode at appropriate times. If one wants authenticated delivery of mail, but is unwilling to pay the cost of an end-to-end scheme like PEM, there are two obvious approaches: One approach is to add authentication to an existing delivery service, another is to add delivery service to an existing authenticated protocol. I agree with Mark that the first approach is far superior. A delivery system that has an authentication mechanism can use it to preserve the authentication during intermediary delivery hops. Adding delivery service to an existing authenticated protocol (such as IMAP) requires that the implementation learn all sorts of things regarding delivery: envelope addresses, authenticated message transport, and the like. In order to do it correctly, the implementation has duplicate everything in the delivery service. As Mark points out, the first approach has better fallback characteristics for when authenticated delivery is not supported. If a client takes the first approach but the delivery system does not support authentication, then the mail is delivered anyway--it is just not authentic. If a client takes the second approach and the existing authentication protocol does not support delivery, then the client either has to support a second delivery mechanism or it will not be able to deliver the mail. Internet protocol devopment is geared toward making small, simple services, which try to do few things, but do them well. They presuppose the use of an underlying transport system that handles the mundane tasks of providing multiple, reliable connections. Failure to keep protocols simple and focused on apropriate tasks leads to over-complex, unwieldy systems. If IMAP has to support message delivery for situations where the client does not have a transport mechanism which can support multiple connections, does it not also have to support other mail-related services, such as user information (Finger), directory service (X.500), password-changing, etc? -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Jul 2 14:00:23 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21681; Fri, 2 Jul 93 14:00:23 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09323; Fri, 2 Jul 93 14:00:11 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09317; Fri, 2 Jul 93 14:00:08 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 2 Jul 93 17:00:01 EDT Received: via switchmail; Fri, 2 Jul 1993 16:59:57 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 16:59:33 -0400 (EDT) Received: via niftymail; Fri, 2 Jul 1993 16:59:12 -0400 (EDT) Date: Fri, 2 Jul 1993 16:59:10 -0400 (EDT) From: Chris Newman Subject: re: IMAP support for several message types To: imap@cac.washington.edu In-Reply-To: References: Message-Id: <741646750.27260.0@nifty.andrew.cmu.edu> In message , A.Grant@ucs.cam.ac.uk writes: >a) PEM is end-to-end; for it to have any value, both ends must be enabled >for PEM. Feasible for a small group, but not for ubiquitous e-mail (yet) - Like it or not, PEM is probably how we're going to end up sended authentic mail worldwide unless some other standard comes along. A transport system shoehorned into IMAP certainly won't get worldwide acceptance for authentic mail transport. >b) Authenticated transport (Kerberos?) would solve the problem only if you >can do more than one thing on a transport connection. Why? Here at CMU, we plan on adding an optional Kerberos-authentication to SMTP so that we can have local authenticated delivery. I really don't know many people who send enough mail such that the per-message authentication is a problem. In fact, with Kerberos, once the client machine has a ticket, it's simply a matter of sending several bytes of data to the transport service. IMAP is already a fairly complex protocol to implement (I've been thinking about it since I'm probably going to start implementing a CMU IMAP server soon). Adding all the headaches involved in mail transport would make the IMAP servers larger and less efficient, and simply duplicate the what SMTP already does. It's not worth it for saving around 50 bytes of authenticator transmission. - Chris From owner-imap@cac.washington.edu Fri Jul 2 14:14:37 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22145; Fri, 2 Jul 93 14:14:37 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09579; Fri, 2 Jul 93 14:14:25 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09571; Fri, 2 Jul 93 14:14:23 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 2 Jul 93 17:14:13 EDT Received: via switchmail; Fri, 2 Jul 1993 17:14:13 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 17:13:48 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 17:13:43 -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; Fri, 2 Jul 1993 17:13:41 -0400 (EDT) Message-Id: Date: Fri, 2 Jul 1993 17:13:41 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: using imap to peruse list archives? Cc: moore@cs.utk.edu In-Reply-To: References: Beak: Is RL "Bob" Morgan writes: > 1. These mailboxes are read-only to everyone, so I can't keep any > of my state info about them (eg messages read). (Thinking about > shared mailboxes, it seems like both shared-state and > state-per-reader are useful.) This is a server implementation issue. > 3. Things being what they are, it's hard to get around to looking at these > mailboxes as often as I should. In IMSP, we've added "FIND UNSEEN.MAILBOXES" and "FIND UNSEEN.BBOARDS" commands which return only those subscribed bboards for which there are messages without the ¥SEEN flag. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Jul 2 14:18:27 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22217; Fri, 2 Jul 93 14:18:27 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09622; Fri, 2 Jul 93 14:18:13 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from WILMA.CS.UTK.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09616; Fri, 2 Jul 93 14:18:11 -0700 Received: from LOCALHOST by wilma.cs.utk.edu with SMTP (5.65/2.8c-UTK) id AA20856; Fri, 2 Jul 1993 17:16:54 -0400 Message-Id: <9307022116.AA20856@wilma.cs.utk.edu> From: Keith Moore To: John Gardiner Myers Cc: imap@cac.washington.edu, moore@cs.utk.edu Subject: Re: using imap to peruse list archives? In-Reply-To: Your message of "Fri, 02 Jul 1993 17:13:41 EDT." Date: Fri, 02 Jul 1993 17:16:53 -0400 To: imap@cac.washington.edu Subject: Re: using imap to peruse list archives? Date: Fri, 2 Jul 1993 17:13:41 -0400 (EDT) > RL "Bob" Morgan writes: > > 1. These mailboxes are read-only to everyone, so I can't keep any > > of my state info about them (eg messages read). (Thinking about > > shared mailboxes, it seems like both shared-state and > > state-per-reader are useful.) > > This is a server implementation issue. Really? If I were providing an IMAP server for a mailing list archive, I would not want to keep track of the per-user state for each of the thousands of users who might want to peruse the archive. Keith From owner-imap@cac.washington.edu Fri Jul 2 15:20:04 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23750; Fri, 2 Jul 93 15:20:04 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10349; Fri, 2 Jul 93 15:19:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10343; Fri, 2 Jul 93 15:19:48 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 2 Jul 93 18:19:39 EDT Received: via switchmail; Fri, 2 Jul 1993 18:19:37 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 18:19:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 18:19:03 -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; Fri, 2 Jul 1993 18:19:01 -0400 (EDT) Message-Id: Date: Fri, 2 Jul 1993 18:19:01 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: using imap to peruse list archives? In-Reply-To: <9307022116.AA20856@wilma.cs.utk.edu> References: <9307022116.AA20856@wilma.cs.utk.edu> Beak: Is Keith Moore writes: > If I were providing an IMAP server for a mailing list archive, I > would not want to keep track of the per-user state for each of the thousands > of users who might want to peruse the archive. That's a site-policy issue. There's a tradeoff between the level of service you want to give users and the amount of resources you want to devote to providing those users that service. In what I interpret Bob Morgan's example to be (a group of limited size accessing common mailing list archives), a site woud want to devote the resources to provide per-user /SEEN state. In Keith Moore's example (thousands of users accessing an archive site), a site may well decide not to provide users any per-user cross-session state. It's also possible that some sites may wish to provide different users different levels of service. A well-designed ACL mechanism should be able to do this. From owner-imap@cac.washington.edu Fri Jul 2 15:26:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23904; Fri, 2 Jul 93 15:26:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10429; Fri, 2 Jul 93 15:25:49 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10423; Fri, 2 Jul 93 15:25:45 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 2 Jul 93 18:25:38 EDT Received: via switchmail; Fri, 2 Jul 1993 18:25:37 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 18:25:11 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 18:25:09 -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; Fri, 2 Jul 1993 18:25:08 -0400 (EDT) Message-Id: Date: Fri, 2 Jul 1993 18:25:08 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Interactive Mail Support Protocol Beak: Is Here is the latest draft of the IMSP spec. I would like to stress the "highly experimental" state of this specification. In particular, the format of the unsolicited BBOARD and MAILBOX replies are subject to radical change, depending on the resolution of the grammar for the corresponding IMAP unsolicited replies. -*- text -*- *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* Network Working Group J. G. Myers Request for Comments: ???? Carnegie Mellon June 1993 IMSP -- Interactive Mail Support Protocol Status of this memo This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Introduction The intent of the Interactive Mail Support Protocol (IMSP) is to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the IMAP2bis protocol [RFC-1176] [IMAP2bis], providing services which are either outside the scope of mail access or which pertain to environments which must run more than one IMAP2 server in the same mail domain. The protocol The IMSP protocol consists of a sequence of client commands and server responses, with server data interspersed between the responses. To simplify the implementation of clients, the IMSP protocol has a command structure similar to the IMAP protocol. Many of the IMSP commands and responses have the same or similar syntax and semantics of their IMAP2 counterparts. Like the IMAP2 protocol, commands and responses are tagged. That is, a command begins with a unique identifier (typically a short alphanumeric sequence such as a Lisp "gensym" function would generate e.g., A0001, A0002, etc.), called a tag. The response to this command is given the same tag from the server. Additionally, the server may send an arbitrary amount of "unsolicited data", which is identified by the special reserved tag of "*". There is another special reserved tag, "+", discussed below. The server must be listening for a connection on TCP port 406. When a connection is opened the server sends an unsolicited OK or PREAUTH response as a greeting message and then waits for commands. The client opens a connection and waits for the greeting. The client must not send any commands until it has received the greeting from the server. Once the greeting has been received, the client may begin sending commands and is not under any obligation to wait for a server response to this command before sending another command, within the constraints of TCP flow control. When commands are received the server acts on them and responds with command responses, often interspersed with data. The effect of a command can not be considered complete until a command response with a tag matching the command is received from the server. Although all known IMSP servers at the time of this writing process commands to completion before processing the next command, it is not required that a server do so. However, many commands can affect the results of other commands, creating processing-order dependencies (or, for FIND and GETACL, ambiguities about which data is associated with which command). All implementations that operate in a non- lockstep fashion must recognize such dependencies and defer or synchronize execution as necessary. Generally, the first command from the client is a LOGIN command with user name and password arguments to establish identity and access authorization, unless this has already been accomplished through other means, e.g. connecting via the BSD "RSH" protocol. Until identity and access authorization have been established, no operations other than LOGIN or LOGOUT are permitted. The client terminates the session with the LOGOUT command. The server returns a "BYE" followed by an "OK". A Typical Scenario Client Server ------ ------ {Wait for Connection} {Open Connection} --> <-- * OK IMSP Server Ready {Wait for command} A001 LOGIN Fred Secret --> <-- A001 OK User Fred logged in {Wait for command} A002 FIND ALL.MAILBOXES INBOX --> <-- * MAILBOX INBOX (imap3.do.main) <-- A0002 OK Find complete {Wait for command} A003 SUBSCRIBE BBOARD comp.mail.mime --> <-- A003 OK Subscribe complete {Wait for command} A004 LOGOUT --> <-- * BYE IMSP server quitting <-- A004 OK Logout complete {Close Connection} --><-- {Close connection} {Go back to start} Base functionality Commands tag NOOP The NOOP command returns an OK to the client. By itself, it does nothing, but certain things may happen as side effects. Responses tag OK text This response identifies successful completion of the command with that tag. The text is a line of human-readable text that may be useful in a protocol telemetry log for debugging purposes. tag NO text This response identifies unsuccessful completion of the command with that tag. The text is a line of human-readable text that probably should be displayed to the user in an error report by the client. tag BAD text This response identifies faulty protocol received from the client; The text is a line of human-readable text that should be recorded in any telemetry as part of a bug report to the maintainer of the client. * BYE text This response identifies that the server is about to close the connection. The text is a line of human-readable text that should be displayed to the user in a status report by the client. This may be sent as part of a normal logout sequence, or as a panic shutdown announcement by the server. It is also used by some servers as an announcement of an inactivity autologout. * OK text This response identifies normal operation on the server. No special action by the client is called for, however, the text should be displayed to the user in some fashion. This is currently only used by servers at startup as a greeting message to show they are ready to accept the first command. * NO text This response identifies a warning from the server that does not affect the overall results of any particular request. The text is a line of human-readable text that should be presented to the user as a warning of improper operation. * BAD text This response identifies a serious error at the server; it may also indicate faulty protocol from the client in which a tag could not be parsed. The text is a line of human-readable text that should be presented to the user as a serious or possibly fatal error. It should also be recorded in any telemetry as part of a bug report to the maintainer of the client and server. + text This response identifies that the server is ready to accept the text of a literal from the client. Normally, a command from the client is a single text line. If the server detects an error in the command, it can simply discard the remainder of the line. It cannot do this for commands that contain literals, since a literal can be an arbitrarily long amount of text, and the server may not even be expecting a literal. This mechanism is provided so the client knows not to send a literal until the server expects it, preserving client/server synchronization. In practice, this condition is rarely encountered. In the current protocol, the only client command likely to contain a literal is the LOGIN command. Consider a server that validates the user before checking the password. If the password contains "funny" characters and hence is sent as a literal, then if the user is invalid an error would occur before the password is parsed. No such synchronization protection is provided for literals sent from the server to the client, for performance reasons. Any synchronization problems in this direction would be caused by a bug in the client or server. Identification and Authorization Commands tag LOGIN user password The LOGIN command identifies the user to the server and carries the password authenticating this user. This information is used by the server to control access to commands. EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with password SESAME. tag LOGOUT The LOGOUT command informs the server that the client is done with the session. The server should send an unsolicited BYE response before the (tagged) OK response, and then close the network connection. Responses * PREAUTH A pre-authenticated IMSP server should recognize that authentication has already happened, and enter the post-login state. In its greeting message, it should use the unsolicited reply "PREAUTH" instead of "OK" to indicate that external authentication has taken place. Server location and new message information Commands tag FIND MAILBOXES pattern The FIND MAILBOXES command accepts as an argument a pattern (including wildcards) that specifies some set of mailbox names that are usable by connecting to an IMAP2 server and using the SELECT command. The format of mailboxes is implementation dependent. Only those mailboxes that the user has declared as being "subscribed" are returned. Two wildcard characters are defined; "*" specifies any number (including zero) characters may match at this position and "%" specifies a single character may match at this position. For example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas FOO%BAR will match only FOO.BAR. "*" will match all mailboxes. The FIND MAILBOXES command will return some set of unsolicited MAILBOX replies that have as their value a single mailbox name, a list of mailbox attributes, and a list of hosts on which the mailbox resides. EXAMPLE: A002 FIND MAILBOXES * * MAILBOX INBOX (¥SUBSCRIBED) (imap3.do.main) * MAILBOX FOOBAR (¥SUBSCRIBED ¥UNSEEN) (imap3.do.main) * MAILBOX GENERAL (¥SUBSCRIBED ¥UNSEEN) (imap12.do.main) A002 OK Find completed Although the use of explicit file or path names for mailboxes is discouraged by this standard, it may be unavoidable. It is important that the value returned in the MAILBOX unsolicited reply be usable in a SELECT command given to an IMAP server running on each of the returned hosts without remembering any path specification that may have been used in the FIND MAILBOXES pattern. The SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX commands manipulate the list returned by this command. tag FIND ALL.MAILBOXES pattern The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES; however, it should return a complete list of all mailboxes available to the user. Data is returned as in FIND MAILBOXES. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `mailboxes available to the user' may not be meaningful for a particular server or server implementation. The command must at least return the set of mailboxes that FIND MAILBOXES does. tag FIND UNSEEN.MAILBOXES pattern The FIND UNSEEN.MAILBOXES command is similar to FIND MAILBOXES; however, only those "subscribed" mailboxes in which there are messages without the ¥SEEN flag are returned. Data is returned as in FIND MAILBOXES. Should an implementation be unable to determine which mailboxes have unread messages, it should return the same information returned by FIND MAILBOXES. tag FIND BBOARDS pattern The FIND BBOARDS command accepts as an argument a pattern that specifies some set of bulletin board names that are usable by connecting to an IMAP2 server and using the BBOARD command. Wildcards are permitted as in FIND MAILBOXES. Only those bboards that the user has declared as being "subscribed" are returned. The FIND BBOARDS command will return some set of unsolicited BBOARD replies that have as their value a single bulletin board name, a list of attributes, and a list of hosts on which the bboard resides. EXAMPLE: A002 FIND BBOARDS * * BBOARD comp.mail.mime (¥SUBSCRIBED ¥UNSEEN) (imap2.do.main) * BBOARD GENERAL (¥SUBSCRIBED) (imap7.do.main imap8.do.main) A002 OK Find completed tag FIND ALL.BBOARDS pattern The FIND ALL.BBOARDS command is similar to FIND BBOARDS; however, it should return a complete list of all bulletin boards available to the user. Data is returned as in FIND BBOARDS. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `bboards available to the user' may not be meaningful for a particular server or server implementation. The command must at least return the set of bboards that FIND BBOARDS does. tag FIND UNSEEN.BBOARDS pattern The FIND UNSEEN.BBOARDS command is similar to FIND BBOARDS; however, only those "subscribed" bboards for which there are messages without the ¥SEEN flag are returned. Data is returned as in FIND BBOARDS. Should an implementation be unable to determine which bboards have unread messages, it should return the same information returned by FIND BBOARDS. Responses * MAILBOX string attributes server_list This response occurs as a result of a FIND MAILBOXES, FIND ALL.MAILBOXES, or FIND UNSEEN.MAILBOXES command. The string is a mailbox name that matches the pattern in the command. attributes is an S-expression list of mailbox attributes. server_list is an S-expression list of the fully qualified domain names of the hosts on which the mailbox resides. The defined mailbox attributes are: ¥SUBSCRIBED FIND MAILBOXES command will return mailbox ¥UNSEEN FIND UNSEEN.MAILBOXES command will return mailbox An IMSP client must be able to accept attributes it does not understand. Should the server_list contain more than one host name, the client should access the mailbox by attempting to connect to each server until one connection succeeds. The client should attempt each possible host in the sequence listed unless it has good reason to do otherwise (such as an already-open connection or geographic information). * BBOARD string attributes server_list This response occurs as a result of a FIND BBOARDS, FIND ALL.BBOARDS, or FIND UNSEEN.BBOARDS command. The string is a bboard name that matches the pattern in the command. attributes is an S-expression list of mailbox attributes. server_list is an S-expression list of the fully qualified domain names of the hosts on which the bboard resides. The defined bboard attributes are: ¥SUBSCRIBED FIND BBOARDS command will return bboard ¥UNSEEN FIND UNSEEN.BBOARDS command will return bboard An IMSP client must be able to accept attributes it does not understand. Should the server_list contain more than one host name, the client should access the bboard by attempting to connect to each server until one connection succeeds. The client should attempt each possible host in the sequence listed unless it has good reason to do otherwise (such as an already-open connection or geographic information). Discussion When a user asks a client to read a bboard by name, the client should issue a "FIND ALL.BBOARDS" command to the IMSP server in order to determine which server it is on. The attribute list corrects a minor design flaw in IMAP2bis: without it the MAILBOX/BBOARD unsolicited response has an ambiguous meaning--one can only tell if the folder is subscribed or not by figuring out whether it is a response to a FIND foo or a FIND ALL.foo command. The following is a possible implementation of the FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS commands: When a message is appended to a folder, the IMAP server notifies the IMSP server of some unique (within the folder) attribute of the message. Possibile attributes include the message-id and the internaldate. This could be done using an IMSP extension: tag LAST MAILBOX mailbox attribute user tag LAST BBOARD bboard attribute When a user switches folders or closes a connection and has seen all messages in that folder, the IMAP server notifies the IMSP server that the user has read all of the messages, including the attribute of the last message. This too could be done using an IMSP extension: tag SEEN MAILBOX mailbox attribute user tag SEEN BBOARD bboard attribute user When asked for folders with messages unseen by the user, the IMSP server can check the attribute of the message last reported for the user against the attribute of the message last appended to the folder. In the interest of having the IMAP server/IMSP server communications be the same across implementation, it might be worthwhile to propose this method of implementing FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS as a standard. Subscription management tag SUBSCRIBE MAILBOX mailbox The SUBSCRIBE MAILBOX command adds the specified mailbox name to the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE MAILBOX mailbox The UNSUBSCRIBE MAILBOX command removes the specified mailbox name from the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. tag SUBSCRIBE BBOARD bboard The SUBSCRIBE BBOARD command adds the specified mailbox name to the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE BBOARD bboard The UNSUBSCRIBE BBOARD command removes the specified mailbox name from the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. Mailbox and BBoard management tag CREATE mailbox tag CREATE mailbox server_partition_list The CREATE command creates a mailbox with the given name. This command returns an OK response only if a new mailbox with that name has been created. It is an error to attempt to create a mailbox with a name that refers to an extant mailbox. Any error in creation will return a NO response. Creating INBOX is not permitted. If there is a primary or default mailbox for this user, it MUST exist and be called INBOX; hence it may not be created. Otherwise, the name INBOX can not be used; see section VI, "INBOX Requirement Loosened", of IMAP2bis [IMAP2bis] for more details. If server_partition_list is specified, it indicates the server or set of servers on which the mailbox is to be created. Each hostname in the list may be followed by a slash character and an atom. The atom specifies in an implementation-dependent manner where to store the mailbox on the server. EXAMPLE: A002 CREATE FOOBAR (imap2.do.main/a imap4.do.main) A002 OK Create completed If server_partition_list is not specified, the placement of the mailbox is up to the implementation. tag DELETE mailbox tag DELETE mailbox hostname The DELETE command deletes a mailbox with the given name. This command returns an OK response only if a mailbox with that name has been deleted. It is an error to attempt to delete a mailbox name that does not exist. Any error in deletion will return a NO response. A server SHOULD NOT attempt to test that a mailbox is empty prior to permitting deletion; this would prevent the deletion of a mailbox which for some reason can not be opened or expunged, leaving to possible denial of service problems. Any such checking should be left to the discretion of the client. Deleting INBOX is not permitted. If hostname is specified, the mailbox is deleted on that host. If it is not specified, the mailbox is deleted on all hosts on which the mailbox resides. tag RENAME oldmailbox newmailbox The RENAME command changes the name of a mailbox. This command returns an OK response only if a mailbox with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old mailbox name that does not exist or a new mailbox name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to the mailbox, their subscriptions should be updated appropriately. Renaming INBOX is permitted. A new, empty INBOX is created in its place. Should users be subscribed to the INBOX, they should remain subscribed to the new, empty INBOX. tag MOVE mailbox hostname server_partition_list The MOVE command moves a mailbox between servers and/or replicates a mailbox. Hostname specifies where the move is to be made from and server_partition_list specifies where the move is to be made to. The interpretation of server_partition_list is the same as for the CREATE command. tag CREATE.BBOARD bboard tag CREATE.BBOARD bboard server_partition_list The CREATE.BBOARD command creates a bboard with the given name. This command returns an OK response only if a new bboard with that name has been created. It is an error to attempt to create a bboard with a name that refers to an extant bboard. Any error in creation will return a NO response. If server_partition_list is specified, it indicates the server or set of servers on which the bboard is to be created. Each hostname in the list may be followed by a slash character and an atom. The atom specifies in an implementation-dependent manner where to store the bboard on the server. EXAMPLE: A002 CREATE.BBOARD FOOBAR (imap2.do.main/a map4.do.main) A002 OK Create completed If server_partition_list is not specified, the placement of the bboard is up to the implementation. tag DELETE.BBOARD bboard tag DELETE.BBOARD bboard hostname The DELETE.BBOARD command deletes a bboard with the given name. This command returns an OK response only if a bboard with that name has been deleted. It is an error to attempt to delete a bboard name that does not exist. Any error in deletion will return a NO response. If hostname is specified, the bboard is deleted on that host. If it is not specified, the bboard is deleted on all hosts on which the bboard resides. tag RENAME.BBOARD oldbboard newbboard The RENAME.BBOARD command changes the name of a bboard. This command returns an OK response only if a bboard with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old bboard name that does not exist or a new bboard name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to the bboard, their subscriptions should be updated appropriately. tag MOVE.BBOARD bboard hostname server_partition_list The MOVE.BBOARD command moves a bboard between servers and/or replicates a bboard. Hostname specifies where the move is to be made from and server_partition_list specifies where the move is to be made to. The interpretation of server_partition_list is the same as for the CREATE command. tag ALIAS.BBOARD oldbboard newbboard After "oldbboard" gets subsequently deleted, all users that are subscribed to "oldbboard" will be subscribed to newbboard. [Call this RESUBSCRIBE? Put in Subscription management? Actually perform the deletion? Provide ALIAS command for mailboxes?] Discussion Of course, local administrative policy may restrict use of these commands. Implementations may use this as justification for not implementing partitions, multiple locations for mailboxes/bboards, or the MOVE and MOVE.BBOARD commands. MOVE and MOVE.BBOARD cannot be implemented without some non-IMAP2 communication with the IMAP servers. Replication requires some communication between IMAP servers. CREATE.BBOARD, DELETE.BBOARD, and RENAME.BBOARD, and partitions require IMAP protocol extensions. Everything else can be implemented through the use of IMAP2bis commands. User configuration information Commands tag GET pattern The GET command accepts as an argument a pattern that specifies some set of configuration options. Wildcards are permitted as in FIND MAILBOXES. Option names are case-insensitive. The GET command will return some set of unsolicited OPTION replies, giving the names and values of matching options. Example: A002 GET SENT* * OPTION SENT.MAILBOX SENT-MAIL [READ-WRITE] A002 OK Get completed tag SET option value The SET command accepts as arguments the name of an option and a string value. The value of the option is set to the specified string. If the option with that name does not already exist, it is created. Option names are case-insensitive atoms. SET is not allowed if the named option is read-only. tag UNSET option The UNSET command accepts as an argument the name of an option. Depending on the implementation, the option is either removed or its value reverts to the implementation-defined default. UNSET is not allowed if the named option is read-only. Responses * OPTION atom string string This response occurs as a result of a GET command. The first string is an option name that matches the pattern in the command. The second string is the value of the option. The third string is either [READ-WRITE] if the user may change the option or [READ-ONLY] if the user may not. Discussion Options can be site wide or per-user. Possible uses include: User preferences (e.g. mailbox to store copies of outgoing mail) Site configuration information (e.g. names of SMTP servers) Per-user configuration information (e.g. contents of From: header) The option namespace could be split into a section for standard options and sections for client-specific options. Possible standard options include: DATE (current time, in rfc822 format) DOMAIN (local mail domain) FROM (string to use for From: header) DELIVERY.HOSTS (list of smtp hosts for mail submission) SENT.MAILBOX (mailbox to store copies of outgoing mail) Address book Commands tag SEARCHADDRESS addressbook lookup_criteria The SEARCHADDRESS command searches the specified address book for entries that express the intersection (AND function) of all of the specified criteria. The aliases matching the criteria are provided by a series of unsolicited SEARCHADDRESS replies. If no criterea are specified, all aliases in the address book are provided. The lookup_criteria is a sequence of "field pattern" pairs, each specifying entries where the value of field matches the specified pattern in a case-independent manner. The pattern may optionally be an RFC-1342 format multinational character string. EXAMPLE: A0340 SEARCHADDRESS Fred name "* Rubble" email "*@bedrock" * SEARCHADDRESS barney A0340 OK Searchaddress completed tag FETCHADDRESS addressbook aliases Fetches the contents of the entries in the specified address book for the specified aliases. The entries are returned in a series of unsolicited FETCHADDRESS replies. EXAMPLE: A0341 FETCHADDRESS Fred barney * FETCHADDRESS Fred barney name "Barney Rubble" email "barney@bedrock" A0341 OK Fetchaddress completed tag STOREADDRESS addressbook alias field_data Creates or modifies the entry in the specified addressbook for the specified alias. Fields not specified in the command are not changed. Setting the value of a field to the null string removes the field. EXAMPLE: A0342 STOREADDRESS Fred barney phone "555" email "" * FETCHADDRESS Fred barney name "Barney Rubble" phone "555" A0342 OK Storeaddress completed tag DELETEADDRESS addressbook alias Removes the entry in the specified addressbook for the specified alias. Responses * SEARCHADDRESS addressbook <1#alias> This response occurs as a result of a SEARCHADDRESS command. The alias(es) refer to those address book entries that match the search criteria. * FETCHADDRESS addressbook alias field_data This is the means by which address book entries are returned to the client. The entry for alias in addressbook contains field_data. Discussion Address books provide a way for users to store and search typed information. They are primarily intended to be used for storing information about entities with which the user communicates. The addressbook field to the various commands allows users to access address books belonging to other users, should they have the appropriate access. Servers are expected to at least allow the client to manipulate the address book with the same name as the "user" specified in the LOGIN command. Servers may accept "addressbook" values that do not correspond to users that may LOGIN. Each addres book contains some number of entries. Each entry is named by an alias and has any number of fields. Each field has an atom name and a string value. The standard fields are: NAME A full name EMAIL CRLF-separated list of electronic mail addresses PHONE CRLF-separated list of phone numbers ADDRESS Postal address An entry may also have additional, user-defined fields. Clients are expected to allow the user to view and modify all fields of an entry, even if they do not recognize some field names. Access control lists Commands tag SETACL MAILBOX mailbox identifier rights Changes the access control list on the specified mailbox so that the specified identifier is granted the permissions enumerated in rights. Identifier has implementation-defined semantics. Possible variations of identifier interpretation include: * User names, as specified in the LOGIN command. * Named groups of users, presumably managed by some authorization service. * Only allowing identifiers supported by the operating system (e.g. ``user'', ``group'', and ``other'' for the Unix filesystem) * Whether rights granted to other mailboxes in an implementation-defined hierarchy are inherited * A portion of the identifier specifying an "authentication type". As an example, an implementation may control posting to a group based on the contents of the From: header: from$user p * Whether the union of rights for matching identifiers are granted to a user or whether the rights for the most specific matching identifier is granted. As an example, for a mailbox with the following ACL: user lrsa group-user-is-in lrsw One implementation may grant the user 'lrswa' rights, another may only grant the user 'lrsa'. * A prefix to an identifier name specifying the listed rights are to be removed from users who match the prefixed identifier. As an example, for a mailbox with the following ACL: group-user-is-in lrsw -user w An implementation may grant the user 'lrs' rights. Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations which is being controlled. Letters [lowercase?] are reserved for ``standard'' rights, listed below. Digits are reserved for implementation or site defined rights. The standard rights are: l - lookup (folder is visible to FIND commands) r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, SEARCH, COPY from mailbox) s - keep seen/unseen information across sessions (STORE ¥SEEN flag) w - write (STORE flags other than ¥SEEN and ¥DELETED) i - insert (perform APPEND, COPY into mailbox) p - post (send mail to submission address for mailbox, not enforced by IMAP2/IMSP itself) c - create (CREATE new sub-folders in any implementation-defined hierarchy) d - delete (STORE ¥DELETED flag, perform EXPUNGE) a - administer (perform SETACL) An implementation may tie rights together or may force rights to always or never be granted. For example, in an implementation that uses unix mode bits, the rights "wisd" are tied. The "a" right is always granted to the owner and is never granted to another user. If rights are tied in an implementation, it should be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none should be used. Numeric rights may not be tied. tag SETACL BBOARD bboard identifier rights Changes the access control list on the specified bboard so that the specified identifier is granted the permissions enumerated in rights. Identifier and rights are as specified for SETACL MAILBOX. tag SETACL ADDRESSBOOK addressbook identifier rights Changes the access control list of the specified addressbook so that the specified identifier is granted the permissions enumerated in rights. Identifier and rights are as specified for SETACL MAILBOX. Not all rights specified in SETACL MAILBOX will be meaningful for an address book. tag DELETEACL MAILBOX mailbox identifier Removes any portion of the access control list for mailbox for the specified identifier. tag DELETEACL BBOARD bboard identifier Removes any portion of the access control list for bboard for the specified identifier. tag DELETEACL ADDRESSBOOK addressbook identifier Removes any portion of the access control list for the specified addressbook for the specified identifier. tag GETACL MAILBOX mailbox Returns the access control list for mailbox in some set of unsolicited ACL replies. There may not be more than one ACL reply specifying any given identifier. EXAMPLE: A002 GETACL MAILBOX INBOX * ACL MAILBOX INBOX Fred rwipslda A002 Ok Getacl complete tag GETACL BBOARD bboard Returns the access control list for bboard in some set of unsolicited ACL replies. EXAMPLE: A002 GETACL BBOARD comp.mail.mime * ACL BBOARD comp.mail.mime anybody-else rpsl * ACL BBOARD comp.mail.mime news rwipcsld A002 Ok Getacl complete tag GETACL ADDRESSBOOK addressbook Returns the access control list for the specified addressbook in some set of unsolicited ACL replies. EXAMPLE: A002 GETACL ADDRESSBOOK Fred * ACL ADDRESSBOOK Fred anybody-else r * ACL ADDRESSBOOK Fred Fred rwipd A002 Ok Getacl complete tag MYACL MAILBOX mailbox Returns the set of rights that the user has to mailbox in an unsolicited MYACL reply. tag MYACL BBOARD mailbox Returns the set of rights that the user has to bboard in an unsolicited MYACL reply. tag MYACL ADDRESSBOOK addressbook Returns the set of rights that the user has to the specified addressbook in an unsolicited MYACL reply. Responses * ACL MAILBOX string string string This response occurs as a result of a GETACL MAILBOX command. The first string is the mailbox name for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * ACL BBOARD string string string This response occurs as a result of a GETACL BBOARD command. The first string is the bboard name for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * ACL ADDRESSBOOK string string string This response occurs as a result of a GETACL ADDRESSBOOK command. The first string is the addressbook for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * MYACL MAILBOX string string This response occurs as a result of a MYACL MAILBOX command. The first string is the mailbox name for which this ACL entry applies. The third string is the set of rights that the client has. * MYACL BBOARD string string This response occurs as a result of a MYACL BBOARD command. The first string is the bboard name for which this ACL entry applies. The third string is the set of rights that the client has. * MYACL ADDRESSBOOK string string This response occurs as a result of a MYACL ADDRESSBOOK command. The first string is the addressbook for which this ACL entry applies. The second string is the set of rights that the client has. Discussion The assignment of letters to rights is AFS-centric. Alternatively we could change i->a, l->v, a->what?. The set of rights should make some sense in other messaging domains, particularly NNTP. The IMSP and NNTP ACL specifications should be similar. The IMSP author will work with the author of the NNTP ACL extension in order to resolve this. It is not resolved whether address book ACLs should be per-addressbook (as specified here) or per-entry. Unresolved issues The following mail support issues have been raised, but not resolved in IMSP. * User forwarding address Deferred. This probably belongs in a separate user directory service. * Mail filing control (e.g. ``vacation'', delivery of mail to folders other than INBOX based on subject, sender) Deferred. This probably belongs in a separate service, quite possibly a user directory service. * Administrative issues: Purge rates for bboards (not necessarily age related) Quotas for users or bboards (not necessarily megabyte related) * Notification issues Current use of quota Exhaustion of quota Renamed/deleted folders/bboards [ Use unsolicited OK/NO messages? ] For renamed/deleted folders/bboards, server should notify, then change or delete subscription as necessary. Minimal conformance Implementation of the following commands is mandatory: NOOP LOGIN LOGOUT FIND MAILBOXES FIND ALL.MAILBOXES FIND UNSEEN.MAILBOXES FIND BBOARDS FIND ALL.BBOARDS FIND UNSEEN.BBOARDS SUBSCRIBE MAILBOX SUBSCRIBE BBOARD UNSUBSCRIBE MAILBOX UNSUBSCRIBE BBOARD CREATE (server_partition_list argument is optional) DELETE RENAME GET SET SEARCHADDRESS FETCHADDRESS STOREADDRESS DELETEADDRESS Backwards compatibility When a client is directed by a user or an initial configuration to contact a server, it should first attempt to reach the IMSP service. If that fails with connection refused, it should fall back to the IMAP2 protocol. Conventions The following terms are used in a meta-sense in the syntax specification below: An ASCII-STRING is a sequence of arbitrary ASCII characters. A CHARACTER is any ASCII character except """", CR, or LF. An ATOM is a sequence of CHARACTERs delimited by SP or CRLF. An ATOM may not start with a "{". A CRLF is an ASCII carriage-return character followed immediately by an ASCII linefeed character. A NUMBER is a sequence of the ASCII characters that represent decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or ":". A SP is the ASCII space character. A TEXT_LINE is a human-readable sequence of ASCII characters up to but not including a terminating CRLF. A common field in the IMSP protocol is a STRING, which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), or a LITERAL. A literal consists of an open brace ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, where n is the value of the number inside the brace. In general, a string should be represented as an ATOM or QUOTED-STRING if at all possible. Literals are most often sent from the server to the client; in the rare case of a client to server literal there is a special consideration (see the "+ text" response above). Note the set of allowable CHARACTERs is larger than specified for IMAP2. Formal syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma. acl_reply ::= "ACL" acl_option SP string SP string SP string acl_option ::= "MAILBOX" / "BBOARD" / "ADDRESSBOOK" alias_bboard ::= "ALIAS.BBOARD" SP string SP string bboard_reply ::= "BBOARD" SP string SP "(" 0#atom ")" SP "(" 1#hostname ")" create ::= "CREATE" SP mailbox [ SP server_partition_list ] create_bboard ::= "CREATE.BBOARD" SP string [ SP server_partition_list ] delete ::= "DELETE" SP mailbox [ SP hostname ] deleteaddress ::= "DELETEADDRESS" SP userid SP atom delete_bboard ::= "DELETE.BBOARD" SP string [ SP hostname ] fetchaddress ::= "FETCHADDRESS" SP userid 1#( SP atom ) fetchaddress_r ::= "FETCHADDRESS" SP userid SP atom field_data field_data ::= 1#key_value find ::= "FIND" SP find_option SP string find_option ::= "MAILBOXES" / "ALL.MAILBOXES" / "UNSEEN.MAILBOXES / "BBOARDS" / "ALL.BBOARDS" / "UNSEEN.BBOARDS" get ::= "GET" SP string getacl ::= "GETACL" SP acl_option SP string hostname ::= atom ; Fully qualified domain name key_value ::= SP atom SP string literal ::= "{" NUMBER "}" CRLF ASCII-STRING login ::= "LOGIN" SP userid SP password logout ::= "LOGOUT" lookup_criterea ::= 0#( SP key SP pattern ) mailbox ::= "INBOX" / string mailbox_reply ::= "MAILBOX" SP string SP "(" 0#atom ")" SP "(" 1#hostname ")" move ::= "MOVE" SP mailbox SP hostname SP server_partition_list move_bboard ::= "MOVE.BBOARD" SP string SP hostname SP server_partition_list myacl ::= "MYACL" SP acl_option SP string myacl_reply ::= "MYACL" acl_option SP string SP string noop ::= "NOOP" option_reply ::= "OPTION" SP atom SP string SP ("[READ-ONLY]" / "[READ-WRITE]") rename ::= "RENAME" SP mailbox SP string rename_bboard ::= "RENAME.BBOARD" SP string SP string request ::= tag SP (noop / login / logout / find / subscribe / unsubscribe / create / delete / rename / move / create_bboard / delete_bboard / rename_bboard / move_bboard / alias_bboard / get / set / searchaddress / fetchaddress / storeaddress / deleteaddress / getacl / setacl / myacl) CRLF response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF searchaddress ::= "SEARCHADDRESS" SP userid lookup_criteria searchaddress_r ::= "SEARCHADDRESS" SP userid 1#( SP atom ) server_partition ::= hostname [ "/" atom ] server_partition_list ::= "(" 1#server_partition ")" set ::= "SET" SP atom SP string setacl ::= "SETACL" SP acl_option SP string SP string SP atom storeaddress ::= "STOREADDRESS" SP userid SP atom field_data string ::= atom / """" 1*character """" / literal subscribe ::= "SUBSCRIBE" SP subscribe_opt SP string subscribe_opt ::= "MAILBOX" / "BBOARD" unsolicited ::= "*" SP (mailbox_reply / bboard_reply / option_reply / searchaddress_r / fetchaddress_r / acl_reply / myacl_reply) CRLF unsubscribe ::= "UNSUBSCRIBE" SP subscribe_opt SP string userid ::= string References [RFC-1176] Crispin, Mark R. Interactive Mail Access Protocol - Version 2. August 1990. RFC-1176. [IMAP2bis] Crispin, Mark R. IMAP2bis - Extensions to the IMAP2 Protocol, December 1992 Author's Address John G. Myers Carnegie-Mellon University 5000 Forbes Ave. Pittsburgh PA, 15213-3890 Email: jgm+@cmu.edu From owner-imap@cac.washington.edu Fri Jul 2 16:26:43 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25058; Fri, 2 Jul 93 16:26:43 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11194; Fri, 2 Jul 93 16:26:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from phantom.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11188; Fri, 2 Jul 93 16:26:27 -0700 Received: from [140.142.110.88] by phantom.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20005; Fri, 2 Jul 93 16:26:24 -0700 Date: Fri, 2 Jul 1993 16:14:53 PDT From: Terry Gray Subject: Re: using imap to peruse list archives? To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 2 Jul 1993, John Gardiner Myers wrote: > It's also possible that some sites may wish to provide different users > different levels of service. A well-designed ACL mechanism should be > able to do this. Today NNTP news servers provide a way to deal with both anonymous/ stateless access by zillions of unknown users, and access by users where per-user state is maintained, by virtue of .newsrc files. We should be able to do at least as well with mail archives. We want to be sure that we don't paint ourselves into any corners with respect to where we *assume* per-user state information is stored. It *may* be on the same machine that has the archive, but not necessarily. I believe it is necessary to decouple the two, and I believe that the IMAP equivalent of an anonymous FTP server will be very useful. We have this now* for data organized as a news hierarchy; we need to do it for regular mailbox files. I see no reason why the same archive couldn't serve the needs of those who wish to keep track of what messages they've seen/pseudo-deleted/etc. I'm hoping IMSP can be used to bring the per-user state file to the client from wherever it might be stored. -teg * PC-Pine uses this idea to provide a convenient way to get new versions of itself. From owner-imap@cac.washington.edu Fri Jul 2 17:04:57 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25952; Fri, 2 Jul 93 17:04:57 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11679; Fri, 2 Jul 93 17:04:44 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11673; Fri, 2 Jul 93 17:04:41 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Fri, 2 Jul 93 20:04:36 EDT Received: via switchmail; Fri, 2 Jul 1993 20:04:32 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 20:03:21 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 2 Jul 1993 20:03:02 -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; Fri, 2 Jul 1993 20:02:57 -0400 (EDT) Message-Id: Date: Fri, 2 Jul 1993 20:02:57 -0400 (EDT) From: John Gardiner Myers Subject: Re: using imap to peruse list archives? To: imap@cac.washington.edu In-Reply-To: References: Beak: is Not NNTP's model for keeping per-user seen state has two problems: * It needs each message to have a unique-within-group identifier which is preserved across sessions. For performance reasons, it is a good idea for these identifiers to be strictly ordered. IMAP would either have to add such a construct, or declare one of the existing constructs as having this property. My preference would be for INTERNALDATE to have this property. * Storing this type of state information on the client is contrary to the goal of nomadic access. Users cannot access the server from different clients without moving the state information between the clients. In some sense, we have to paint ourselves into one corner or another. We have to pick either the client or the server as being responsible for keeping the per-user seen state. We can (and should) make it possible to do it the other way, but one model should be the rule and the other the exception. Otherwise, different clients will handle this different ways and confusion will reign. I suppose a good tack a client implementation could be "try to keep /SEEN state on the server. If this isn't possible, keep the state yourself." Such a client could detect whether FETCHing a message causes the /SEEN flag to be set. > I'm hoping IMSP can be used to bring the per-user > state file to the client from wherever it might be stored. An IMSP client can store almost anything it wants in an IMSP option. The difficulty is getting different clients to use the same conventions for storing the same information. Similarly, an IMAP server implementation could use some external distributed database to store the per-user state. I plan to use this approach if/when we get around to implementing replicated bboards. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Jul 2 17:26:31 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26461; Fri, 2 Jul 93 17:26:31 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11897; Fri, 2 Jul 93 17:26:18 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from phantom.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11891; Fri, 2 Jul 93 17:26:16 -0700 Received: from [140.142.110.88] by phantom.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20177; Fri, 2 Jul 93 17:26:12 -0700 Date: Fri, 2 Jul 1993 17:08:27 PDT From: Terry Gray Subject: Re: using imap to peruse list archives? To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 2 Jul 1993, John Gardiner Myers wrote: > NNTP's model for keeping per-user seen state has two problems: > > * It needs each message to have a unique-within-group identifier which > is preserved across sessions. For performance reasons, it is a good > idea for these identifiers to be strictly ordered. IMAP would either > have to add such a construct, or declare one of the existing > constructs as having this property. My preference would be for > INTERNALDATE to have this property. Right. We need persistent ID's for disconnected operation as well. > * Storing this type of state information on the client is contrary to > the goal of nomadic access. Users cannot access the server from > different clients without moving the state information between the > clients. I didn't argue *for* storing the info on the client; I only argued *against* assuming it would be stored and used on the server. The question of where the data gets *used* is orthogonal to where it will be stored. I tend to believe the world is simpler if we assume the public news and/or archive server has no notion of users, and per-user state info is manipulated by the client. In no way is this view at odds with the goal of supporting nomads, given the necessary protocol for getting at it, as we must also have for addressbooks, existing .newsrc files, and other personal config info. > In some sense, we have to paint ourselves into one corner or another. > We have to pick either the client or the server as being responsible > for keeping the per-user seen state. We can (and should) make it > possible to do it the other way, but one model should be the rule and > the other the exception. Otherwise, different clients will handle > this different ways and confusion will reign. Agreed. For the reasons stated above, I would vote for client-side manipulation of the state file. > I suppose a good tack a client implementation could be "try to keep > /SEEN state on the server. If this isn't possible, keep the state > yourself." Such a client could detect whether FETCHing a message > causes the /SEEN flag to be set. I'm never opposed to "best-of-both-worlds" solutions if they don't cost too much. If we can accommodate both models (server manipulates per-user state AND client manipulates per-user state), then fine. Again, where the state is actually stored between uses, should be a separate consideration. > > I'm hoping IMSP can be used to bring the per-user > > state file to the client from wherever it might be stored. > > An IMSP client can store almost anything it wants in an IMSP option. > The difficulty is getting different clients to use the same > conventions for storing the same information. Hence the need for defacto or dejur standards! The newsrc format is an existence proof of a defacto standard that has survived a couple of generations of news clients. (This statement is *not* an endorsement of newsrc format! :) > Similarly, an IMAP server implementation could use some external > distributed database to store the per-user state. I plan to use this > approach if/when we get around to implementing replicated bboards. Agreed that this is possible. It should not be the only model. We have servers that do not need nor want to know about user state. I see that happening more and more in the future because it simplifies management and operation of the server. -teg From owner-imap@cac.washington.edu Fri Jul 2 18:45:36 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27595; Fri, 2 Jul 93 18:45:36 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10969; Fri, 2 Jul 93 18:45:16 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from THUD.CS.UTK.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10963; Fri, 2 Jul 93 18:45:14 -0700 Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930125/2.7c-UTK) id AA19249; Fri, 2 Jul 93 21:45:07 -0400 Message-Id: <9307030145.AA19249@thud.cs.utk.edu> From: Keith Moore To: John Gardiner Myers Cc: imap@cac.washington.edu, moore@cs.utk.edu Subject: Re: using imap to peruse list archives? In-Reply-To: Your message of "Fri, 02 Jul 1993 20:02:57 EDT." Date: Fri, 02 Jul 1993 21:45:06 -0400 > * Storing this type of state information on the client is contrary to > the goal of nomadic access. Users cannot access the server from > different clients without moving the state information between the > clients. And putting the state information on the server is contrary to the goal of fault-tolerance and scalability. There might reasonably be a need for multiple, redundant mailing list archives. I can see a mail reader talking to two IMAP servers at once -- a mailing list archive server to peruse the old messages, and the user's "home" mailbox server -- to keep track of seen state. I can also envision the "home" mailbox server as sort of "local cache" for a particular list, where the mail reader will fetch articles from a remote server if necessary, to present a unified view of the list traffic. (In which case, readers would not have to subscribe to a list that they read only occasionally...) Keith From owner-imap@cac.washington.edu Sat Jul 3 05:33:58 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05785; Sat, 3 Jul 93 05:33:58 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15674; Sat, 3 Jul 93 05:33:40 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15668; Sat, 3 Jul 93 05:33:39 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Sat, 3 Jul 93 08:33:36 EDT Received: via switchmail; Sat, 3 Jul 1993 08:33:35 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 3 Jul 1993 08:33:14 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 3 Jul 1993 08:33:12 -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; Sat, 3 Jul 1993 08:33:12 -0400 (EDT) Message-Id: Date: Sat, 3 Jul 1993 08:33:12 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: using imap to peruse list archives? In-Reply-To: References: Beak: is Not Terry Gray writes: > I didn't argue *for* storing the info on the client; I only argued > *against* assuming it would be stored and used on the server. If the advice to clients is reasonably interpreted as "ignore the /SEEN flag for bboards and handle the per-user state yourself", then I fear clients will store this information in the simplest and most logical place (the local disk) and be done with it. Given your reference to "the" public news and/or archive server, I think this is a reasonable interpretation of what you're saying. > I tend to believe the world is simpler if we assume the public > news and/or archive server has no notion of users, and per-user state info > is manipulated by the client. Any distributed mechanism available to the client for handling this information is at least equally available to the server. As there are usually fewer varieties of servers than clients, and as servers usually don't run on low-resource machines, I believe it is much simpler to get all servers to handle this correctly than to get all clients to do so. Keith Moore writes: > And putting the state information on the server is contrary to the > goal of fault-tolerance and scalability. Not at all. The server can use a replicated, distributed database to store the information. > I can see a mail reader talking to two IMAP servers at once -- a mailing > list archive server to peruse the old messages, and the user's "home" > mailbox server -- to keep track of seen state. You're getting close to our vision--multiple IMAP servers in a domain, mailboxes and bboards distributed and/or replicated across them to distribute load, and a service (IMSP) to allow a client to find out where everything is and transparently present it to the users as one big, happy namespace. > I can also envision the "home" mailbox server as sort of "local > cache" for a particular list, where the mail reader will fetch > articles from a remote server if necessary, to present a unified > view of the list traffic. Our experience shows that intermediary servers tend not to scale well. They're certainly not necessary to present a unified view. > (In which case, readers would not have to subscribe to a list that > they read only occasionally...) I don't subscribe to mailing lists, period. I read all mailing lists (including this one) as bboards. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sat Jul 3 10:30:57 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08332; Sat, 3 Jul 93 10:30:57 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16814; Sat, 3 Jul 93 10:30:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16808; Sat, 3 Jul 93 10:30:37 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03790; Sat, 3 Jul 93 10:30:34 -0700 Date: Sat, 3 Jul 1993 09:25:48 -0700 (PDT) From: Terry Gray Subject: Re: using imap to peruse list archives? To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 3 Jul 1993, John Gardiner Myers wrote: > If the advice to clients is reasonably interpreted as "ignore the > /SEEN flag for bboards and handle the per-user state yourself", then I > fear clients will store this information in the simplest and most > logical place (the local disk) and be done with it. Again, in many cases there won't be any per-user /SEEN flags stored on the archive server. Whether or not client-writers choose the easy way out and store state locally depends largely on how easy we make it to access remote state files. But I'll also mention a scenario below where having the state stored locally on the client is the *right* --indeed, only-- thing to do. > Any distributed mechanism available to the client for handling this > information is at least equally available to the server. In principle, Yes. In practice, Not necessarily. I see a significant difference in operational cost when a (non-Kerberos) archive server suddenly needs to traffic in user-specific data. > As there are > usually fewer varieties of servers than clients, and as servers > usually don't run on low-resource machines, I believe it is much > simpler to get all servers to handle this correctly than to get all > clients to do so. We have to solve the same problem for addressbooks and existing newsrc files, so I don't believe there is much increase in complexity or resource requirements for the client. Moreover, as time goes on, shared server resources will become much more scarce than dedicated client resources. Besides, the which-Unix-flavor server wars will go on forever, but in a couple of years all clients will be running Win NT, won't they? :) :) Having the per-user state info manipulated on the server *requires* that the server have some cognizance of "user". Within a Kerberos realm, this may not be a big problem, but in many other situations it will make the difference between whether or not the per-user services are available at all. Consider a small K12 school that may be running their own mail server, but is relying on another site for access to news and public archive data. If per-user state data can *only* be manipulated on the server, a teacher who's entire data world lives on their PC's hard disk is powerless to take advantage of these per-user services. (I'm assuming a realistic view of how easy it is to get guest accounts set up at some other site as K12 demand scales!) In contrast, if the per-user data *may* be manipulated by the client, then we can accommodate sites where central *support* resources are slim-to-none as well as sites with relatively rich computing infrastructures (both systems & staff). NNTP is clearly a successful precedent for this model. I also want to see IMAPd code surface in the bazillion anonymous ftp servers around the world and suddenly have their mail archives available via IMAP. These systems don't know about specific users in general, and 99.99% will never know about me in particular. But I still want to be able to keep track of what messages I've seen/pseudo-deleted/answerd/etc. IF the IMAPd is the only one allowed to manipulate per user state info, I now have several additional dependencies when compared to client-side state manipulation: -My MUA must know how to authenticate itself to an IMAPd in any realm or location, even for *public* data access, -The IMAPd must know how and where to get my per-user state, -The IMAPd must be able to authenticate me and/or it to the state server, -and There must be a "state" server ready and willing to accommodate that request. Within a particular site, having the server do the per-user state processing may be perfectly reasonable, though I'm not yet convinced it is preferable. I am convinced that it is the wrong answer for the broader context cited above. -teg From owner-imap@cac.washington.edu Tue Jul 6 15:11:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14813; Tue, 6 Jul 93 15:11:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13540; Tue, 6 Jul 93 15:11:07 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13534; Tue, 6 Jul 93 15:11:05 -0700 Received: by andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Tue, 6 Jul 93 18:10:40 EDT Received: via switchmail; Tue, 6 Jul 1993 18:10:36 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 6 Jul 1993 18:09:48 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 6 Jul 1993 18:09:46 -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; Tue, 6 Jul 1993 18:09:43 -0400 (EDT) Message-Id: Date: Tue, 6 Jul 1993 18:09:43 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: using imap to peruse list archives? In-Reply-To: References: Beak: is Not I think we're talking past each other a bit. I'm not arguing that a client should *never* keep per-user state, I'm stating that it should not do so without a good indication that the server isn't keeping that state. Otherwise, the option of storing the state on the server effectively doesn't exist. To store this sort of state in IMSP would require some sort of locking mechanism. I suspect if users started habitually reading (instead of browsing) mailing lists off IMAP archives, the resulting load would cause the archive sites to do something to discourage that use. There aren't that many netwide open NNTP servers. You state that you need to solve the nomadic-user problem for "existing newsrc files". I don't see why you have to solve this problem--NNTP users don't currently have nomadic access and once they join the IMAP world no longer need NNTP. Could you give a more detailed explanation? From owner-imap@cac.washington.edu Tue Jul 6 16:21:12 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16431; Tue, 6 Jul 93 16:21:12 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14372; Tue, 6 Jul 93 16:20:55 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from phantom.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14366; Tue, 6 Jul 93 16:20:54 -0700 Received: from [140.142.110.88] by phantom.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02404; Tue, 6 Jul 93 16:20:50 -0700 Date: Tue, 6 Jul 1993 15:57:25 PDT From: Terry Gray Subject: Re: using imap to peruse list archives? To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 6 Jul 1993, John Gardiner Myers wrote: > I think we're talking past each other a bit. I'm not arguing that a client > should *never* keep per-user state, I'm stating that it should not do > so without a good indication that the server isn't keeping that state. > Otherwise, the option of storing the state on the server effectively > doesn't exist. Fair point. > To store this sort of state in IMSP would require some sort of locking > mechanism. Once we postulate concurrent sessions by the same user, this is hard to avoid. It's true also for address books, although those are somewhat less volatile. > I suspect if users started habitually reading (instead of browsing) > mailing lists off IMAP archives, the resulting load would cause the > archive sites to do something to discourage that use. There aren't > that many netwide open NNTP servers. Perhaps... but I think anonymous ftp servers are a closer analog than NNTP servers. Those ftp servers that become unusable due to popularity become either restricted or mirrored, but I believe that is the exceptional case. > You state that you need to solve the nomadic-user problem for > "existing newsrc files". I don't see why you have to solve this > problem--NNTP users don't currently have nomadic access Some NNTP users do have convenient nomadic access, using remote file system protocols to export their .newsrc. (And a few actually do try to manually move their newsrc around... but probably not very often!) > and once they join the IMAP world no longer need NNTP. Aye, and there's the rub! They won't be able to join the IMAP world unless we solve this problem, because in addition to the sites that won't run IMAP on their news server at all, there will be many sites where running an IMAPd alongside NNTPd is just fine, but no one but system staff will have accounts on the news server. For sure this scenario precludes storing the per-user data on the server, and I suspect it might also preclude pass-thru config and authentication info, to allow the IMAPd to obtain the per-user state data for itself. (Note that I'm focused here on accessing public data, not a shared group mailbox or bboard where authentication is essential for any access.) -teg From owner-imap@cac.washington.edu Tue Jul 6 16:31:02 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16849; Tue, 6 Jul 93 16:31:02 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14550; Tue, 6 Jul 93 16:30:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14544; Tue, 6 Jul 93 16:30:47 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Tue, 6 Jul 93 19:30:43 EDT Received: via switchmail; Tue, 6 Jul 1993 19:30:42 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 6 Jul 1993 19:30:21 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 6 Jul 1993 19:30:14 -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; Tue, 6 Jul 1993 19:30:11 -0400 (EDT) Message-Id: Date: Tue, 6 Jul 1993 19:30:11 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: using imap to peruse list archives? In-Reply-To: References: Beak: Is Terry Gray writes: > [...] there will be many sites where > running an IMAPd alongside NNTPd is just fine, but no one but system staff > will have accounts on the news server. For sure this scenario precludes > storing the per-user data on the server [...] This may be true of the c-client imapd implementation, it is not true in general. The IMAP server implementation we are planning is intended to run on sealed servers and will store per-user data. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Jul 6 17:32:36 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18394; Tue, 6 Jul 93 17:32:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15373; Tue, 6 Jul 93 17:32:21 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from phantom.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15367; Tue, 6 Jul 93 17:32:20 -0700 Received: from [140.142.110.88] by phantom.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02613; Tue, 6 Jul 93 17:32:17 -0700 Date: Tue, 6 Jul 1993 16:37:28 PDT From: Terry Gray Subject: Re: using imap to peruse list archives? To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The IMAP server implementation we are planning is > intended to run on sealed servers and will store per-user data. I surely wouldn't want to preclude this scenario (even though it isn't the one I would pick.) Rather, my goal in this thread was to make sure that client-side processing of per-user state was not precluded; likewise, your goal has been to make sure that server-side processing is not precluded. These goals need not conflict. Moreover, I have no problem with the client having a way to determine if server-side data is available, so that it can choose to use the server data. Given the above, what's our next step? -teg From owner-imap@cac.washington.edu Wed Jul 7 14:38:52 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17443; Wed, 7 Jul 93 14:38:52 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27005; Wed, 7 Jul 93 14:38:20 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26999; Wed, 7 Jul 93 14:38:15 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for gray@cac.washington.edu; Wed, 7 Jul 93 17:38:11 EDT Received: via switchmail; Wed, 7 Jul 1993 17:38:10 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Wed, 7 Jul 1993 17:36:52 -0400 (EDT) Received: via niftymail; Wed, 7 Jul 1993 17:36:47 -0400 (EDT) Date: Wed, 7 Jul 1993 17:36:44 -0400 (EDT) From: Chris Newman Subject: Re: using imap to peruse list archives? To: Terry Gray Cc: imap@cac.washington.edu In-Reply-To: References: Message-Id: <742081004.525.0@nifty.andrew.cmu.edu> Terry Gray writes: >I surely wouldn't want to preclude this scenario (even though it isn't the >one I would pick.) Rather, my goal in this thread was to make sure that >client-side processing of per-user state was not precluded; likewise, your >goal has been to make sure that server-side processing is not precluded. >These goals need not conflict. Moreover, I have no problem with the client >having a way to determine if server-side data is available, so that it can >choose to use the server data. > >Given the above, what's our next step? This seems to leave two issues: 1) How to you tell if a server is keeping seen information between sessions? 2) When a server doesn't keep seen information (i.e. it doesn't support nomadic users directly) what sort of conventions/mechanisms should be provided to clients to manage seen information? One possibility for solving issue 1 would be to make a convention that IMAP servers only show the ¥SEEN flag if the state is kept between sessions. I think this is reasonable since ¥SEEN information is fairly useless if it's not kept between sessions. An alternative would be a convention like: "[READ-ONLY] [NO-SEEN]" in the SELECT response to advise that SEEN information isn't kept between sessions. I'll ignore issue 2 for now, as it is rather closely tied with the whole problem of disconnected operation. - Chris From owner-imap@cac.washington.edu Sun Jul 11 16:53:42 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22435; Sun, 11 Jul 93 16:53:42 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25806; Sun, 11 Jul 93 16:53:16 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Jul 11 18:10:42 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23118; Sun, 11 Jul 93 18:10:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08782; Sun, 11 Jul 93 18:10:28 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Jul 11 23:07:03 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25563; Sun, 11 Jul 93 23:07:03 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09938; Sun, 11 Jul 93 23:06:49 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Jul 11 23:57:28 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26082; Sun, 11 Jul 93 23:57:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10138; Sun, 11 Jul 93 23:57:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10132; Sun, 11 Jul 93 23:57:13 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05052; Sun, 11 Jul 93 23:57:12 -0700 Date: Sun, 11 Jul 1993 23:53:59 -0700 (PDT) From: Terry Gray Subject: Amsterdam WG mtg agenda To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is the agenda for tomorrow's mtg. I view it as primarily an information dissemination and information gathering opportunity, with real protocol hacking being deferred to {email | Aug30-mtg | Houston IETF} -teg --------------------------------------- 93.7.11 teg Agenda for IMAP WG meeting at Amsterdam IETF 1. Introductions 2. Charter: comments? 3. Status of implementations 4. Status of protocol spec 5. Notes from Columbus IETF BOF: comments? 6. Suggestions for additional IMAP changes? 7. Announcement of WG meeting in Seattle Aug 30-31. 8. References On "ftp.cac.washington.edu" in the /imap directory: rfc1176 imap2bis.txt imap_archives imap.vs.pop imap.bof.393 imap.wg.charter imap.wg.agenda793 <-- this text From owner-imap@cac.washington.edu Mon Jul 12 09:05:55 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06011; Mon, 12 Jul 93 09:05:55 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14143; Mon, 12 Jul 93 09:05:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Jul 12 13:05:22 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15362; Mon, 12 Jul 93 13:05:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17790; Mon, 12 Jul 93 13:04:53 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Jul 12 14:44:34 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18132; Mon, 12 Jul 93 14:44:34 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01170; Mon, 12 Jul 93 14:44:09 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01164; Mon, 12 Jul 93 14:44:07 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Mon, 12 Jul 93 17:44:03 EDT Received: via switchmail; Mon, 12 Jul 1993 17:44:02 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 17:42:09 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 12 Jul 1993 17:42:07 -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:42:04 -0400 (EDT) Message-Id: <0gERegi00WBwA_TxN2@andrew.cmu.edu> Date: Mon, 12 Jul 1993 17:42:04 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: MAILBOX and BBOARD replies In-Reply-To: <741535305.27260.0@nifty.andrew.cmu.edu> References: <741535305.27260.0@nifty.andrew.cmu.edu> Beak: Is Chris and I have been looking at c-client code and have discovered that when given MAILBOX and BBOARD replies with names that do not conform to the syntax of atoms, different versions of c-client break in different ways. The c-client that comes with Pine 3.0 will always use a literal for SELECT, but for COPY will parrot back whatever it got as if it were an atom. Version 3.0 of c-client gets COPY right (it will use a literal if necessary), but will parrot back whatever it got when doing SELECT. I think this shows that trying to get the old clients to do the right thing for non-atom mailbox names by changing the IMAP grammar is leading down the path of insanity. I think the spec should stay more-or-less the way it is, except that QUOTED-STRING should be loosened to at least allow imbedded "{" characters. This loosening should not break any clients. The c-client imapd should then return mailbox names like {host.do.main}INBOX as * MAILBOX "{host.do.main}INBOX" If the client is the type that parrots back the name it got, everything will work as it should. If the client is the type that sends it back as a literal, the imapd could have the compatibility rule "if a mailbox/bboard name both starts and ends with a double quote, strip the quotes". The spec does need to be changed to disallow atoms-as-strings in unsolicited FETCH replies. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Mon Jul 12 16:27:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21841; Mon, 12 Jul 93 16:27:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20919; Mon, 12 Jul 93 16:27:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Jul 12 16:45:57 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22279; Mon, 12 Jul 93 16:45:57 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21175; Mon, 12 Jul 93 16:45:40 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Jul 12 22:05:35 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27282; Mon, 12 Jul 93 22:05:35 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02960; Mon, 12 Jul 93 22:05:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Jul 13 11:12:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14251; Tue, 13 Jul 93 11:12:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29298; Tue, 13 Jul 93 11:11:41 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Jul 13 14:21:58 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21041; Tue, 13 Jul 93 14:21:58 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02292; Tue, 13 Jul 93 14:21:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Jul 14 02:44:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08156; Wed, 14 Jul 93 02:44:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07943; Wed, 14 Jul 93 02:43:56 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07937; Wed, 14 Jul 93 02:43:55 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27878; Wed, 14 Jul 93 02:43:53 -0700 Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: IMAP WG mtg summary and minutes To: imap@cac.washington.edu Cc: minutes@CNRI.Reston.VA.US, John C Klensin , Erik Huizer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII IMAP WG meeting summary and minutes: 13 July 1993 (Amsterdam IETF) SUMMARY 21 people participated. For several it was their first exposure to IMAP, so a few minutes was spent summarizing what IMAP is, how it compares/relates to other alternatives, and what the working group is chartered to do. The WG charter and notes from the Columbus BOF were reviewed and questions answered. The status of the protocol spec and known IMAP implementations was reviewed. (An Internet Draft is being composed that integrates and updates RFC-1176 and the imap2bis extensions.) Existing practice on the use of IMAP for news, archive, and document access --in addition to mail-- was covered. Discussion on possible IMAP extensions followed. Finally, the next working group meeting (in Seattle, Aug 30-31), was announced. AGENDA Introductions IMAP overview Comments on the WG Charter? Status of implementations Status of protocol spec Comments on Columbus BOF notes? Additional IMAP change requests? Seattle WG meeting References: /imap/imap* on ftp.cac.washington.edu DISCUSSION POINTS Disconnected operation support, ala DMSP, continues to be widely desired. There is considerable interest in using IMAP to access message archives. Several people asked about extensions to support binary message part access, without Base64 or QP encoding: -Possible? -Impact on s-expression model? -Can unencoded binary attachments be transferred without charset concerns? The question of signalling when large blocks of data are being transferred: -Congestion of pipe; need to have multiple channels or out-of-band signals Can we have an IMAP server capabilities command, ala new SMTP? Be sure to look at URL/I work before settling on uniqe message ID scheme. Is IMAP a distribution list alternative: shared but limited access mailbox? Can IMAP "integrate" two mailboxes (remote mail archive plus local subset)? Should IMAP become "Interactive Message Access Protocol"? ACTION ITEMS Gray needs to maintain (or cause to be maintained?) an IMAP enhancement/request list, sorted into the following categories: o Protocol bug fixes o Upward compatible extensions, -high priority -lower priority o Non-upward compatible changes, -high priority -lower priority o Bad, or not clearly good, ideas A subset of that list must then be defined as the target for the immediate standardization effort, with other ideas being deferred for future consideration. Given the desire to preserve compatibility with the installed base, and move ahead promptly in getting a base IMAP standard defined, extensions will be necessarilly limited to those deemed to have an extremely high priority. Crispin needs to integrate RFC-1176 text with IMAP2BIS text and submit as Internet draft not later than Aug 15th. IMAP implementors/interested parties are encouraged to come to the next WG meeting in Seattle, Aug 30-31. -teg From owner-imap@cac.washington.edu Thu Jul 15 11:07:10 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11367; Thu, 15 Jul 93 11:07:10 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18565; Thu, 15 Jul 93 11:06:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from stc06.CTD.ORNL.GOV by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18559; Thu, 15 Jul 93 11:06:38 -0700 Received: by stc06.CTD.ORNL.GOV (5.57/Ultrix3.0-C) id AA25639; Thu, 15 Jul 93 14:06:29 -0400 Date: Thu, 15 Jul 93 14:06:29 -0400 From: News poster Message-Id: <9307151806.AA25639@stc06.CTD.ORNL.GOV> To: imap@cac.washington.edu Newsgroups: ornl.mail.imap Path: stc06!jnm From: jnm@ornl.gov (Jamey Maze) Subject: Nested mailboxes Message-ID: Sender: usenet@ornl.gov (News poster) Organization: Oak Ridge National Lab X-Newsreader: VersaTerm Link v1.1 Date: Thu, 15 Jul 1993 18:06:12 GMT Lines: 18 I use POP/Eudora, but am looking forward to the day when Eudora will understand IMAP. One thing I REALLY like about Eudora is how I can organize my mailboxes using nested folders. I have several levels in some cases, e.g., Technology E-Mail IMAP In glancing over the IMAP/IMSP specs, I'm not sure I see how these protocols could accomodate this feature. It seems that you need to be able to specify a "path" for each mailbox (e.g., Technology/E-Mail/IMAP). -- Jamey Maze Martin Marietta Energy Systems, Inc. Oak Ridge National Laboratory P.O. Box 2008 (615)574-6355 78 Mitchell Road FAX: (615)-576-4992 Oak Ridge, TN 37831-6283 From owner-imap@cac.washington.edu Thu Jul 15 19:50:04 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26974; Thu, 15 Jul 93 19:50:04 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05047; Thu, 15 Jul 93 19:49:44 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Thu Jul 15 23:39:55 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29372; Thu, 15 Jul 93 23:39:55 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21875; Thu, 15 Jul 93 23:37:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21869; Thu, 15 Jul 93 23:37:29 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA06105; Thu, 15 Jul 93 23:37:22 -0700 Date: Thu, 15 Jul 1993 23:27:11 -0700 (PDT) From: Mark Crispin Subject: re: Nested mailboxes To: Jamey Maze Cc: IMAP Interest List In-Reply-To: <9307151806.AA25639@stc06.CTD.ORNL.GOV> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Jamey - The brief answer to your question is that IMAP does not have any explicit hierarchy support. This does not mean ``you can't do hierarchy with IMAP'', but rather that IMAP does not say anything on the subject. You certainly can do hiearchy with IMAP servers; we do so all the time. Hierarchy and how it works is a function of a particular server and its software implementation. Some client implementations, such as the newest version of Pine (presently only released for PC's) have mechanisms for manipulating hierarchy. In the case of new Pine, there is a concept called ``collections'' which manipulate these in neat ways. Another possibility is hierarchy implemented in the client. After all, the user neither cares nor particularly needs to know where it is implemented as long as the interface is suitable. A hierarchy specification in the IMAP protocol would necessarily be limited to the common denominator across all possible implementations, which would not be A Good Thing. -- Mark -- From owner-imap@cac.washington.edu Fri Jul 16 09:58:50 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11755; Fri, 16 Jul 93 09:58:50 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11008; Fri, 16 Jul 93 09:58:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11002; Fri, 16 Jul 93 09:58:29 -0700 Received: from Mac-Treister.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA16380; Fri, 16 Jul 93 09:58:20 PDT Date: Fri, 16 Jul 93 09:55:40 -0800 From: Adam Treister To: Jamey Maze Subject: Re: Nested mailboxes Cc: IMAP Interest List Message-Id: In-Reply-To: Your message of Thu, 15 Jul 1993 23:27:11 -0700 (PDT) Content-Type: TEXT/plain; charset=US-ASCII MRC: > Another possibility is hierarchy implemented in the > client. After all, the user neither cares nor > particularly needs to know where it is implemented as > long as the interface is suitable. If a server don't provide the required functionality, its only a glorified bit stream. <¥flame> The hierarchy issue would be greatly served if a client could add parts (specifically, messages) to a message in a mailbox. I think the MIME multipart could be overstressed by creating folders as multipart msgs, but that method should serve adequately for hierarchies created by threads. But Search (or is it Find) would need to be extended somewhat. Add I don't think delete, append is a very satisfactory solution. That would require that the client is maintaining a sorted view of the mailbox, so its folders don't fall to the bottom when you put something in them. I could imagine implementing a hierarchy thru header annotations, but I can't do that either. It sure seems to me that any scheme whereby I could provide hierarchical views on a MacPlus would require some support from the protocol/server (nay, a miracle). -------------------------------------------------- Adam Treister Polya Hall 205, Stanford CA 94305 - (415) 725-9449 -------------------------------------------------- From owner-imap@cac.washington.edu Fri Jul 16 10:31:08 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12842; Fri, 16 Jul 93 10:31:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11476; Fri, 16 Jul 93 10:30:40 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Fri Jul 16 10:39:58 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13212; Fri, 16 Jul 93 10:39:58 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24701; Fri, 16 Jul 93 10:39:45 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from stc06.CTD.ORNL.GOV by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24695; Fri, 16 Jul 93 10:39:43 -0700 Received: by stc06.CTD.ORNL.GOV (5.57/Ultrix3.0-C) id AA01978; Fri, 16 Jul 93 13:39:40 -0400 Date: Fri, 16 Jul 93 13:39:40 -0400 From: News poster Message-Id: <9307161739.AA01978@stc06.CTD.ORNL.GOV> To: imap@cac.washington.edu Newsgroups: ornl.mail.imap Path: stc06!jnm From: jnm@ornl.gov (Jamey Maze) Subject: Re: Nested mailboxes Message-ID: Sender: usenet@ornl.gov (News poster) Organization: Oak Ridge National Lab X-Newsreader: VersaTerm Link v1.1 References: <16Jul93.17: 04:47.6793@stc06> Distribution: local Date: Fri, 16 Jul 1993 17:39:28 GMT Lines: 28 In Article <16Jul93.17:04:47.6793@stc06>, Adam Treister wrote: >The hierarchy issue would be greatly served if a client could add parts >(specifically, messages) to a message in a mailbox. Yep, I was thinking the heirarchy information needs to be stored in the server. If it's stored on the client, I would loose the structure if I went to another machine or client to look at my mail. For example, Mailstrom lets me create aliases for mailboxes, but if I go to Pine, I have to remember the actual mailbox name. I was thinking you might use a Unix style pathname for mailbox names, e.g., Technology/E-Mail/IMAP Working Group where the actual mailbox name is "IMAP Working Group" and "Technology/E-Mail/" is the path. If I were to implement this on a server platform that doesn't support the mailbox naming scheme, I'd need a mapping table, e.g., on an Windows NT server, I might have "Technology/E-Mail/IMAP Working Group" map to "TECHNOLO¥E-MAIL¥IMAP_WOR.MBX" (Yuk!). -- Jamey Maze Martin Marietta Energy Systems, Inc. Oak Ridge National Laboratory P.O. Box 2008 (615)574-6355 78 Mitchell Road FAX: (615)-576-4992 Oak Ridge, TN 37831-6283 From owner-imap@cac.washington.edu Fri Jul 16 17:47:38 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27373; Fri, 16 Jul 93 17:47:38 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17762; Fri, 16 Jul 93 17:47:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17752; Fri, 16 Jul 93 17:47:09 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42481-1>; Fri, 16 Jul 1993 18:46:58 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Fri, 16 Jul 93 16:18 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0oGyBP-000cwpC; Fri, 16 Jul 93 16:23 MDT Date: Thu, 15 Jul 1993 17:19:02 -0600 From: Steve Hole Subject: Re: Nested mailboxes To: IMAP Interest List Message-Id: Priority: Normal X-Read-Ack: No X-Delivery-Ack: No Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think that it is perhaps time to refocus the conversation here somewhat and talk about some specific issues. First of all, let's agree to the context of the problem. For purposes of consistent discussion let's define a bit of terminology. Note that these terms are not "official", they are just for use in the discussion. These definitions are definitely redundant, but it is important (IMHO) to be consistent. Message - a (potentially) multipart mail message. This also includes News postings. Folder - a collection of messages. Message Store - a collection of folders on a host, of a specific type, that are "owned" by a specific user. Therefore, unique identification of a message store is by host, type, and user. Server - an active application process that provides access to one or more message stores on a host. Client - an active application process that performs operations on a message store via an access protocol (IMAP in this case). Now to define the problem. Many people want to be able to organize mail messages into a hierarchical structure similar to that used by popular file system structures on UNIX and DOS. Therefore we are talking about hierarchical folder representations. More specifically we are trying to determine what the responsibilities of the various distributed mail components will be to effectively solve this problem. To make things a little easier on the road to a solution to the problem, let's break the problem down into a number of subproblems numbered P1, P2, etc. I hope that I have gotten them all, but I expect that some more refinement will be necessary here. Whatever ... it's a starting point. I will begin with the issues that I believe have been discussed, and that some rough (violent) agreement reached has been reached on. Then I'll move to unresolved issues. *** P1. What format should a message store have on the server host to represent hierarchical folder constructs? Should a single message store format be enforced? Everyone seems to agree here that it is simply not practical to have a single representation on the server. There are several points that justify this statement: - there are several pre-existing message stores of different format that need to be supported for backward compatibility. - a modular, driver based archicture for the server would be able to handle different format types effectively. The c-client does this quite nicely. - different host types provide different facilities for storing information on disk. - other mail components like MTA's may have specific requirements for representation and organization of deliverable folders - mailboxes. The format and layout of a message store on a server host is a server application implementation issue. The client certainly shouldn't care AS LONG AS THE PRESENTATION OF INFORMATION IS CONSISTENT. The server can decide what format the information should be in. As long as the server presents the message store information to the clients in a consistent way, they will not care. This is of course the whole reason for being for IMAP and the WSU imapd implementation. The only other entity that is potentially affected by the format and organization of a message store is an MTA. Delivery to a particular format by an MTA is an implementation issue on the MTA as well. The Server and MTA implementation just have to converge for a particular host and message store respresentation. *** P2. Should message stores use a single, common namespace to represent hierarchical message store information? What are the potential benefits of a canonical namespace? I think that the major benefit is that it would make writing clients a whole lot easier. A canonical namespace will allow clients to represent hierarchical folder information to the user in whatever manner they want, without having to have specific knowledge about the representation of the message store structure on the server. As long as a client can consistently identify and manipulate the namespace information that is returned by the server, then it can present it however it wants. If a canonical message store namespace is of some benefit to clients, what are the associated problems with making it happen. P2.1. What component (server, client) is responsible for canonicalizing the namespace? If the server does the canonicalization, then the client and the server must agree on a formal namespace representation in order for the client to be able to extract the hierarchical information. The server must be able to map from the message store specific namespaces to the canonical namespace. If the client does the canonicalization, then the server simply returns the namespace information native to the message store. The client defines its own canonicalization in order to represent the hiearchical information to the user. This of course requires that the client be knoweldgeable about every message store namespace that can be accessed by the client. There is potential for a large number of these. Right now, things are done at the client. We have experimented with this in ECSMail and basically have deferred hierarchical representation until some better understanding could be reached :-). I would certainly prefer from an abstraction viewpoint to have a cannonical namespace defined at the server. The message store specific namespace knowledge is already on the server, why should the client be required to know about it as well? (actually the following problem statements identify some of the problems with this). The bottom line is, given that an agreement to representation can be reached, it is much less complicated for the client to use the canonical namespace at a reasonably low cost in complexity on the server. P2.2. How and where does one specify the canonical namespace? In other words - where do we write the canonical namespace agreement down? Some sort of standard, but where and what is it called. I don't have an answer for this. We can certainly do something with the WSU server, but would everyone else follow without a hard spec. I guess if we did the defacto thing early enough. p2.3. What does the canonical namespace look like? This shouldn't be too hard. Pick one. The proposed solutions are: '/' delimited node names in a standard UNIX file path format. '.' delimited node names in a Newsgroup format. Basically they are identical except for the delimiter character. My personal choice would be the '/' so that we can have '.' in the names and not have them interpretted as special characters. If people reach agreement on canonical representation, then it seems to me a simple vote would solve this problem quickly. There is an important issue here though centering around the specific c-client implementation as it stands now. C-client returns absolute pathnames for folder names returned from a FIND. It is my contention that a client shouldn't give a rip about where in the server host filesystem a particular folder is stored. I think that the specific location for a message store on the server host can be accurately determined by the host,type,user unique identification. On my client, I really don't care if it works out to be /home/steve/Mail/joefolder or /folders/users/steve/joefolder. It is everything from the base directory down that I care about. Therefore ... I would like to see the WSU imapd server *implementation* make use of a runtime configuration file. The configuration file would store the base directory paths of the various message stores according to type. The drivers would determine where to go for files using a simple pathname construction based on the message store type and the particular user. Note that this would handle the present situation, AND provide a nice abstraction for the client. I am really uncomfortable having ECSMail specify "‾steve/Mail" as the directory to look in for folders. I would just prefer to connect as steve, type Berserkly and have access to my *server defined* message store. This argument (which I am sure I will have to defend some more) becomes much more valid when we start talking about using a distributed authentication service for authentication. There should be NO requirement for a UNIX user account on a mail server simply to do authentication. If there is no account, then there should be no requirement to know anything about where the message store is physically placed on the server host. If the base directory path is runtime configurable on the server, then an administrator can pick up the entire message store and move it somewhere else and the client will never know, much less care. VERY beneficial for large server installations where disk will be an issue. This has already occurred here and at the University of Toronto. To summarize this last point: I don't want our client to know anything about where folders are stored on the server file system. All it needs to know about is the structure of the hierarchical message store from the base directory down. p2.4. Does the access protocol have to be smart about the namespace? Nope. Shouldn't care. Just pass the name. This is what IMAP does now, and it works fine. Remember, it is the *interpretation* of the name that is important at either end. *** P3. Should the access protocol include facilities for navigating and managing a hierarchical message store? Please note that this is a completely separate problem from representing the hierarchical namespace. Any such facility would have to use the namespace, but it doesn't matter what the namespace looks like. This question really seems to be the crux of the problem. We have a couple of dissenting views here. I hope I have these right, because I found the circular arguments more that just a little confusing. Mark suggests that IMAP should not have any specific facilities for manipulating hierarchy. It should all be handled by the client and the server implementation based upon namespace information. Others (Laurence I think) suggest that there needs to be a facility for navigating and maintaining the hierarchy built into the protocol. The client would sent hierarchy manipulation commands to the server for action on the server host. I *believe* that I am in agreement with Mark here. I couldn't think of an example where simply using the existing management commands and interpretting the hierarchical namespace would not work. Let's take it as a given that we have some sort of hierarchical namespace - it doesn't matter whether it is canonical or not as long as the server and the client implementation agree on it. Navigation (up, down, previous, next and search) can be handled by the client. The client maintains the context (current folder level) and translates all relative movement into absolute namespace references that are handed to the server. The server will either refuse or accept the access of a folder in the same way as opening a file on UNIX. It would potentially fail for the same reasons - invalid name, incorrect access etc. etc. Management (add, delete, move) can be handled by the client in much the same way as navigation. The number of rules for managing a hierarchy are discreet and well known. The client would do relative name translation the same way as with navigation. A management operation request will result in the server interpretting the name and performing the operation through a message store specific mechanism. The operation will either succeed or fail based on the context of the folder name that it is passed. For example, an add request for a new subfolder level will result in the driver creating the appropriate message store specific representation for the subfolder based on the name that is passed to it. Only the message store driver in the server will care exactly what representational mechanism is used. How this is done is an *implementation* issue for the server. Note that just like with News it is possible that a folder may contain messages and subfolders at the same time. The server will have to be smart enough to deal with this situation. The client will always behave in the context of the operation that the user is trying to perform ie. open the folder, delete the folder, add a new folder, move a folder. This is another reason why I think a canonical namespace would be nice, because none of the hair associated with interpretting different hierachy names AND MANAGING them would show up in the client - the server would have to be smart about it anyway. It doesn't make sense to me that the client should have to know anything about what storage mechanism is used on the server to represent hierarchical folders. 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-imap@cac.washington.edu Fri Jul 16 21:22:28 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29541; Fri, 16 Jul 93 21:22:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18928; Fri, 16 Jul 93 21:22:07 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18922; Fri, 16 Jul 93 21:22:06 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for imap@cac.washington.edu; Sat, 17 Jul 93 00:22:02 EDT Received: via switchmail; Sat, 17 Jul 1993 00:22:01 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 17 Jul 1993 00:21:44 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 17 Jul 1993 00:21:42 -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; Sat, 17 Jul 1993 00:21:39 -0400 (EDT) Message-Id: Date: Sat, 17 Jul 1993 00:21:39 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Nested mailboxes In-Reply-To: References: Beak: is Not Steve Hole writes: > Message Store - a collection of folders on a host, of a specific type, > that are "owned" by a specific user. Therefore, > unique identification of a message store is by host, > type, and user. > > Server - an active application process that provides access to > one or more message stores on a host. One of the purposes of IMSP is to make the "host" part more transparent--A client queries the IMSP server for the location of the IMAP server (or servers) for a given folder. I'm not sure I agree with the definition of "message store", but I'll let it pass. IMSP and the Cyrus (CMU vaporware) IMAP server have a concept of "partitions", which specify implementation/site dependent information about where to store a folder. > *** P1. What format should a message store have on the server host to > represent hierarchical folder constructs? Should a single message store > format be enforced? I think we're in violent agreement that it is a server implementation issue. The Cyrus IMAP server assumes the only access to folders will be through message access protocols (IMAP/POP/NNTP) and supports exactly one storage format. (Two, if you count the netnews-compatibility option of having message files be LF separated instead of CRLF separated.) Of course, it comes with a "/bin/mail" replacement to allow an MTA to deliver messages. > p2.3. What does the canonical namespace look like? > > This shouldn't be too hard. Pick one. The proposed solutions are: > > '/' delimited node names in a standard UNIX file path format. > '.' delimited node names in a Newsgroup format. There are good reasons to use either. '/' is better in some domains, '.' is better in others. Most likely, a client should either make the delimiter configurable or treat both as delimiters. The Cyrus IMAP server uses '.' for hierarchy and prohibits '/' in folder names. I suppose this is really a site-policy issue--if anybody really cares I could make the allowable namespace per-server configurable (with a few exceptions) > There is an important issue here though centering around the specific > c-client implementation as it stands now. C-client returns absolute > pathnames for folder names returned from a FIND. I consider this an implementation bug in c-client. I have sent fixes for the bezerk driver's FIND ALL. to Mark. The fact that the % and * wildcards don't match the "/" character in the bezerk driver's FIND ALL. is also a bug, but it's much harder to fix. > Therefore ... I would like to see the WSU imapd server *implementation* > make use of a runtime configuration file. Agreed. I think the WSU folks have something like this on their list. > This argument (which I am sure I will have to defend some more) becomes > much more valid when we start talking about using a distributed > authentication service for authentication. There should be NO > requirement for a UNIX user account on a mail server simply to do > authentication. You're mixing three concepts: authentication, authorization, and location of per-user information. The c-client IMAPD uses a unix password file for all three. Respectively, it uses the password field, the uid/group fields, and the home directory field. (The existence/nonexistence of a user in the password file is also used for authorization.) The not-yet-integrated Kerberos changes allow it to use Kerberos for authentication and the password file for the other two. The password file is as good a place as any to store this information. Note that there is no requirement that the user actually be able to log into the server--you can set the shell field to something unusable. If you use Kerberos, you can set the password field to something unusable. > If the base directory path is runtime > configurable on the server, then an administrator can pick up the > entire message store and move it somewhere else and the client will > never know, much less care. VERY beneficial for large server > installations where disk will be an issue. With IMSP, an administrator can move the entire message store to a different server and the user will never know. Very beneficial to large sites where server performance will be an issue. > I *believe* that I am in agreement with Mark here. I couldn't think of > an example where simply using the existing management commands and > interpretting the hierarchical namespace would not work. I also agree with Mark. The advantage of disagreeing with Mark and having hierarchy-specific commands is being able to find the sub-hierarchies one level lower than a given hierarchy without having to fetch the entire list of folders in the hierarchy. I think this benefit is not worth the high cost of defining hierarchy in the protocol. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sat Jul 17 09:17:38 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07339; Sat, 17 Jul 93 09:17:38 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00185; Sat, 17 Jul 93 09:17:21 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00179; Sat, 17 Jul 93 09:17:20 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07121; Sat, 17 Jul 93 09:17:13 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA03361; Sat, 17 Jul 93 09:17:04 -0700 Date: Sat, 17 Jul 1993 09:15:06 -0700 (PDT) From: Mark Crispin Subject: Re: Nested mailboxes To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For your information: FIND results in c-client now always match the pattern. We discussed this for a very long time and decided to do what you more or less asked for several months ago. I didn't use your fix; rather, I pretty much rewrote the code. As a side benefit, ‾foo works too. Anyway, this former behavior in c-client is no longer an issue. From owner-imap@cac.washington.edu Sat Jul 17 11:47:51 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08916; Sat, 17 Jul 93 11:47:51 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00678; Sat, 17 Jul 93 11:47:36 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Jul 18 15:00:31 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24805; Sun, 18 Jul 93 15:00:31 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05579; Sun, 18 Jul 93 15:00:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05573; Sun, 18 Jul 93 15:00:01 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA08149; Sun, 18 Jul 93 15:00:00 -0700 Date: Sun, 18 Jul 1993 14:34:49 -0700 (PDT) From: Mark Crispin Subject: Updated IMAP document To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am in the process of putting together a draft of the new RFC for IMAP2bis. This document, following the comment and review period, will be submitted as a Proposed Standard. It will, of course, replace RFC-1176 as the authoritative IMAP document. For the next several days, I will be asking questions of the group on specific issues pertaining to the update. At the present time, I ask that you limit your comments to the specific questions I ask. Please do NOT send me suggestions for changes or improvements to RFC-1176 or the IMAP protocol until after I finish. This particular step is limited solely to making the document reflect all the changes in the IMAP2bis.TXT file as well as a few new (and hopefully uncontroversial) matters that aren't even described in IMAP2bis.TXT. There will be plenty of time for suggestions and extended discussion once I complete the update. I expect that this update will be completed by the end of this month, so that we can have an Internet Draft ready for submission on schedule on August 15. My first question is: There is a considerable amount of text (``System Model and Philosophy'') in the beginning of the document that, in my opinion, is surplusage. It basically outlines a particular e-mail handling religion and was largely copied from an ancient SUMEX-AIM grant proposal. There is also a fair amount of text comparing IMAP to POP and PCMAIL that could convey the necessary information without the present elaborate detail. I propose to remove most of this text and replace it with substantially smaller text that outlines the function and use of IMAP2bis. Are there any objections to doing this; specifically, does anyone feel that the System Model and Philsophy section needs to be retained more or less intact? I also intend to remove text related to DEC-20 server specifics and references to specific implementations and sites running IMAP. I am not sure that there should even be a reference to c-client as a reference implementation in the document itself. From owner-imap@cac.washington.edu Mon Jul 19 04:19:41 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04169; Mon, 19 Jul 93 04:19:41 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08104; Mon, 19 Jul 93 04:19:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08098; Mon, 19 Jul 93 04:19:22 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA17596; Mon, 19 Jul 93 04:19:20 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA09815; Mon, 19 Jul 93 04:10:33 PDT Received: from ford.air_net by air.airco.co.jp (4.1/6.4J.6) id AA00638; Mon, 19 Jul 93 18:10:33 JST Return-Path: Received: from ford (localhost) by ford.air_net (4.1/SMI-4.1) id AA00240; Mon, 19 Jul 93 16:15:15 JST Message-Id: <9307190715.AA00240@ford.air_net> Date: Mon, 19 Jul 1993 16:15:12 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Re: Nested mailboxes To: Steve Hole Cc: IMAP@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Steve, Some of your suggestions, I have been required to implement. The project that I am currently assigned to is to design, develop and deliver (the 3D's) a Multimedia Email Solution (nice buzz words). We have based it on IMAP since it provides most of the functionality we needed. One of the design requirements was a hierarchical folder representation. At some point we decided that the names that the user sees doesn't necessarily have to be the actual filename of the folder. A mapping mechanism was added to the c-client so that the folder name could be truly independent of the filename. The UNIX filename conventions are used for folder names since users would already familiar with it. The find mailboxes command returns the user's folder names. When the c-client gets a folder name, it gets mapped back to the actual filename before usage. The two names are almost identical, usually. A folder is a directory that contains essentially two things: a file named "mailbox" which has the folder's messages in it and a collection of directories which constitute the folder's children. Typically, the message store directory path is prepended to the folder name and "/mailbox" gets appended. The cases where the foldername contains 8bit characters or exceeds limits of the filesystem are also taken care of by the foldername to filename mapping algorithm. The .mailboxlist file format had to change to support this of course. The new format is either "foldername¥n" or "foldername¥tfilename¥n" using C string notation. The filename is the complete filepath from the mailstore directory. This solution seems to be fairly clean. It allows the user to name folders without having to know about filesystem restrictions. It allows the system administrator to move the user's directory around with out affecting the mail application, unless it's actually running when the directory is moved. We can modify the mapping algorithm to fit the system we install on without changing the user's perception of the folder name space. Our answer to the navigation issue is that the current folder displays its children (subfolders) as buttons with the INBOX displaying the toplevel folders. By selecting the subfolder's button, you descend into the hierarachy. The Motif version opens a new window. The dumb terminal version changes to the new folder. You can also select Open which presents a list of all folders for the host of the current folder. By selecting a name in this list, you open that folder or you can enter the name of a folder on another host and that folder will be opened, if it exists. makr --------------------------------------------------------------------- Mark A Keasling //¥¥¥¥¥ Twin Sun Inc. AIR Co. LTD (|-@^@-|) 360 N. Sepulveda, Suite 2055 1-3-14 Kitahama Chou-ku | ( | El Segundo, Ca 90245 Osaka 541 Japan ¥‾-‾/ Tel (310) 524-1800 (06) 201-4307 _|_|_ Fax (310) 640-2180 (06) 201-2107 ___| /V¥ |___ Email makr@twinsun.com makr@airco.co.jp |/ | ¥| From owner-imap@cac.washington.edu Mon Jul 19 11:42:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17267; Mon, 19 Jul 93 11:42:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09276; Mon, 19 Jul 93 11:39:18 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09270; Mon, 19 Jul 93 11:39:16 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA10407; Mon, 19 Jul 93 11:38:38 -0700 Date: Mon, 19 Jul 1993 10:51:36 -0700 (PDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: Nested mailboxes To: Steve Hole Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII With Steve's recent post I see I hadn't expressed myself clearly. Let me give it another shot. I see three possibilities: 1. Add protocol to IMAP to manage the hierarchy. This makes it standard and gives the full advantage of hierarchy. I think we all agree that it would be very difficult to do this. If it's considered at all I think it should be just in IMSP. 2. Define a standard naming scheme in the IMAP and IMSP documents and make it part of what becomes the official Internet IMAP standard. My initial concern with this was that there would be a big performance problem with it because there was no equivalent of the "cd" command. You'd have to transfer the whole namespace at once. This is not actually the case. You can use the pattern arguments to the FIND command to achieve almost exactly the same thing. I fear the problem with this is that coming up with a namespace that works for all mail formats, clients and servers is intractable. 3. Last we can leave the namespace in the "eye of the beholder". This is essentially the status quo. My very big concern about this is that we're going to wind up with significant interoperability problems because specific client/server implementation pairs will adopt conventions. For example, explicitly putting mail file driver names in the namespace, or using some hierarchy that not clients can easily deal with. I would be in favor of 1 or 2 if I believed there was strong support for them and that they were tractable, but I don't believe either is the case for either option. Thus I am in favor of option 3, but I believe we must include clear guidelines in the IMAP and IMSP standard document on how the namespace should and should not be used. For example it might state that all clients must provide a way for the user to set the patterns that are passed to the FIND command since they'll be essential to cope with larger and unusual name spaces. (Clients providing lists for users to pick mailboxes from is a must in this day and age.) I'd be interested in knowing how the different IMAP clients use the FIND command pattern argument. I couldn't find anyway to specify the pattern in XLView, nor do I recall there being such a feature in MailManager (NeXT). Pine allows quite fancy patterns to be specified. How do ECS and Mailstrom do it? LL P.S. WSU is Washington State University, not the University of Washington. Two distinct institutions that should probably not be confused. From owner-imap@cac.washington.edu Tue Jul 20 10:20:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17855; Tue, 20 Jul 93 10:20:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23043; Tue, 20 Jul 93 10:19:53 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23037; Tue, 20 Jul 93 10:19:50 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42375-2>; Tue, 20 Jul 1993 11:19:35 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Tue, 20 Jul 93 10:42 MDT Received: by isasun-1.edm.isac.ca (Smail3.1.26.7 #1) id m0oIKqU-000cwcC; Tue, 20 Jul 93 10:47 MDT Date: Tue, 20 Jul 1993 10:42:16 -0600 From: Steve Hole Subject: Re: Nested mailboxes To: Laurence Lundblade Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 19 Jul 1993, Laurence Lundblade wrote: > With Steve's recent post I see I hadn't expressed myself clearly. Let me > give it another shot. I see three possibilities: > > 2. Define a standard naming scheme in the IMAP and IMSP documents and > make it part of what becomes the official Internet IMAP standard. My > initial concern with this was that there would be a big performance > problem with it because there was no equivalent of the "cd" command. > You'd have to transfer the whole namespace at once. This is not > actually the case. You can use the pattern arguments to the FIND > command to achieve almost exactly the same thing. I fear the problem > with this is that coming up with a namespace that works for all > mail formats, clients and servers is intractable. > The more I think about it, the more I like option 2. The interoperability problems associated with option 3 is setting ourselves up for losts of work and support on the clients down the road. It seems to me that agreeing on a canonical path syntax can't be that bad. User's never have to see it. Perhaps I am missing something that complicates this? 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-imap@cac.washington.edu Tue Jul 20 10:27:30 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18072; Tue, 20 Jul 93 10:27:30 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16173; Tue, 20 Jul 93 10:27:15 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16167; Tue, 20 Jul 93 10:27:13 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA09774; Tue, 20 Jul 93 10:27:07 -0700 Date: Tue, 20 Jul 1993 10:21:59 -0700 (PDT) From: Mark Crispin Subject: Re: Nested mailboxes To: Steve Hole Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 20 Jul 1993 10:42:16 -0600, Steve Hole wrote: > It seems to me that agreeing on a canonical path syntax can't be that > bad. User's never have to see it. Perhaps I am missing something that > complicates this? Yes, you are missing something. As soon as you define a path syntax in IMAP, you no longer have a general purpose protocol. You are now stuck with that syntax. If it is unimplementable, inappropriate, or inadequate, on a particular operating system, you have just declared that IMAP can not be used on that operating system. Yes, by all means, define a canonical path syntax -- but not in IMAP. This is a layering violation. From owner-imap@cac.washington.edu Tue Jul 20 13:21:41 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25168; Tue, 20 Jul 93 13:21:41 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26451; Tue, 20 Jul 93 13:21:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26445; Tue, 20 Jul 93 13:21:23 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.3/8.3) id QAA00847; Tue, 20 Jul 1993 16:21:20 -0400 Received: via switchmail; Tue, 20 Jul 1993 16:21:19 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Tue, 20 Jul 1993 16:20:34 -0400 (EDT) Received: via niftymail; Tue, 20 Jul 1993 16:20:16 -0400 (EDT) Date: Tue, 20 Jul 1993 16:20:10 -0400 (EDT) From: Chris Newman Subject: IMSP server alpha release To: imap@cac.washington.edu Message-Id: <743199610.15275.0@nifty.andrew.cmu.edu> An alpha release of Carnegie Mellon University's Cyrus IMSP server is now available. This includes full support for user options, address books, and address book access control lists. It also supports the mailbox FIND/CREATE/RENAME/DELETE commands via proxy communications with an IMAP server. It optionally supports Kerberos and AFS-kerberos authentication. It is available for anonymous ftp from export.acs.cmu.edu in the pub/cyrus-mail directory as: cyrus-imspd-v1.00a2.tar.gz Since this is an alpha version and the IMSP specification is still changing, please contact chrisn+@cmu.edu or jgm+@cmu.edu if you are interested in adding client support for IMSP. - Chris Newman Carnegie Mellon University Computing Services From owner-imap@cac.washington.edu Tue Jul 20 17:09:01 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15434; Tue, 20 Jul 93 17:09:01 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19084; Tue, 20 Jul 93 17:08:41 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SIGURD.INNOSOFT.COM by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19078; Tue, 20 Jul 93 17:08:38 -0700 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H0RQWVJF6O8ZE43T@SIGURD.INNOSOFT.COM>; Tue, 20 Jul 1993 17:08:16 PDT Date: Tue, 20 Jul 1993 17:06:16 -0700 (PDT) From: Ned Freed Subject: RE: Nested mailboxes In-Reply-To: Your message dated "Tue, 20 Jul 1993 10:21:59 -0700 (PDT)" To: Mark Crispin Cc: Steve Hole , IMAP Interest List Message-Id: <01H0RU87V1IC8ZE43T@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT > > It seems to me that agreeing on a canonical path syntax can't be that > > bad. User's never have to see it. Perhaps I am missing something that > > complicates this? > Yes, you are missing something. > As soon as you define a path syntax in IMAP, you no longer have a general > purpose protocol. You are now stuck with that syntax. If it is > unimplementable, inappropriate, or inadequate, on a particular operating > system, you have just declared that IMAP can not be used on that operating > system. I agree with Mark 100%. A specific path syntax has no business being added to IMAP. This sort of thing is certain to curtail the ability to deploy IMAP in some environments. > Yes, by all means, define a canonical path syntax -- but not in IMAP. This is > a layering violation. Exactly right. Ned From owner-imap@cac.washington.edu Wed Jul 21 13:58:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10807; Wed, 21 Jul 93 13:58:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14955; Wed, 21 Jul 93 13:57:59 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14949; Wed, 21 Jul 93 13:57:58 -0700 Received: from norman.nwnet.net by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA13295; Wed, 21 Jul 93 13:57:54 -0700 Date: Wed, 21 Jul 1993 13:29:06 -0700 (PDT) From: Laurence Lundblade Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Have managed to get a chance to look at the latest IMSP spec and have some comments. On the responses to the FIND command that now include the ¥SUBSCRIBED status of the mailbox, I would like to see it also include the number of messages and the number of new messages. If this information is not available it should report -1 or "NIL". Poor performance on some formats of stored messages will make this too costly to return. I realize this will lead to inconsistent behavior depending on underlying technology, but I believe presenting this information to the user outweigh the inconsistency. An example I have in mind is NetNews. If you are browsing a list of of newsgroups for reading or subscribing, the size of the group is important information. It shows you which ones are popular and which ones aren't. A large number of current new readers display this information. On the address book, I'm trying to figure out how one would go about down loading the address book for browsing by the user. It seems one would do a SEARCHADDRESS on "*" and then FETCHADDRESS on all the aliases returned. This seems OK, but maybe sub-optimal. For current NetNews reading practice, the order of subscribed groups is important for the way many if not most people read news. So, it seems that there should be some way to control the order of the subscription list. Last, most operations seem like they will be very quick, but for the ones that might take more than 5 seconds or so, it would be really nice if there was some way that progress could be reported to the user. For example, if you do a FIND ALL.BBOARDS "*" you may wind up getting list of thousands. If the (approximate) number of items could be returned before the list is sent it would be possible for the client to report to the user the % of the operation that is complete. Similar could be done with the address book, though the client could probably just count the number of aliases in the FETCHADDRESS command. It would also be nice to be able to abort operations that are taking too long. Most of these suggestions are based on working on an IMAP client, mostly at the user-interface level. Pardon any misunderstandings I might have about the underlying protocol details. LL From owner-imap@cac.washington.edu Wed Jul 21 14:24:33 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12655; Wed, 21 Jul 93 14:24:33 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15872; Wed, 21 Jul 93 14:24:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15866; Wed, 21 Jul 93 14:24:18 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.3/8.3) id RAA00855; Wed, 21 Jul 1993 17:24:15 -0400 Received: via switchmail; Wed, 21 Jul 1993 17:24:13 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 21 Jul 1993 17:22:24 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 21 Jul 1993 17:22:22 -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, 21 Jul 1993 17:22:20 -0400 (EDT) Message-Id: <4gHPCAy00WBw4X4OVh@andrew.cmu.edu> Date: Wed, 21 Jul 1993 17:22:20 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: July IMSP draft specification In-Reply-To: <743199610.15275.0@nifty.andrew.cmu.edu> References: <743199610.15275.0@nifty.andrew.cmu.edu> Beak: Is The July draft of the IMSP protocol specification is now available via anonymous ftp on export.acs.cmu.edu in the file pub/cyrus-mail/imsp-9307.txt -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Wed Jul 21 20:17:00 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07566; Wed, 21 Jul 93 20:17:00 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27883; Wed, 21 Jul 93 20:16:32 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27877; Wed, 21 Jul 93 20:16:29 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.3/8.3) id XAA01053; Wed, 21 Jul 1993 23:16:25 -0400 Received: via switchmail; Wed, 21 Jul 1993 23:16:24 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 21 Jul 1993 23:15:23 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 21 Jul 1993 23:15: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; Wed, 21 Jul 1993 23:15:16 -0400 (EDT) Message-Id: Date: Wed, 21 Jul 1993 23:15:16 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: FYI: Cyrus IMAP server design Beak: Is Just to let folks know what we at CMU are up to, here is a draft document describing the IMAP server we plan to implement. This is all complete vaporware--except for some routines we will steal from the Cyrus IMSP server, there is no actual written code. Note that this implementation seeks to address an almost completely different set of administrative concerns than the c-client IMAP server. --------------------------------------------------------------------- Cyrus IMAP server design Jul 21, 1993 * Introduction This document describes the preliminary design of the Cyrus IMAP server. The Cyrus IMAP server will provide access to mail and bboards through the IMAP protocol. It differs from other IMAP server implementations in that it is intended to be run on "sealed" servers, where normal users are not normally permitted to log in. It will support extensions to allow administrative functions such as ACL's and quota control and will cooperate with the Cyrus IMSP server. The server can be compiled with or without Kerberos support. * Mailbox/Bboard namespace The Cyrus IMAP server presents folders using the "netnews" namespace convention. Folder names match in a case-insensitive manner. Non-ASCII characters, shell metacharacters, and "/" are not permitted in folder names. A folder name may not start or end with a "." character, nor may it contain two "." characters in a row. * IMAP protocol extensions and implementation decisions The Cyrus IMAP server supports the following protocol extensions: QUOTA (STORAGE only) ACL partitions on CREATE CREATE.BBOARD/RENAME.BBOARD/DELETE.BBOARD DUMP/RESTORE [to be defined] The CHECK command will scan for flags that have changed since the client was notified about them, issuing unsolicited FETCH replies to update the client's state. The EXPUNGE operation is allowed at any time, even when other server processes are reading the folder. To avoid sending unsolicited EXPUNGE replies at inopportune times, servers keep an open file handle on the folder header files that are replaced by the EXPUNGE operation. The server may send unsolicited EXPUNGE commands during the execution of the APPEND, CHECK, and EXPUNGE commands. The PURGE command is implemented as a NOOP. The server always acts as if PURGE ALWAYS is in effect. * Mailbox/Bboard storage format It is presumed that users will only be able to access folders (mailboxes and bboards) through the use of network protocols. The Cyrus server implementation is given the freedom to store folders on disk in a format best suited to its needs. Each folder is represented by a directory in the filesystem. Within the directory, each message is stored in its own file in RFC 822 format. The filenames of the message files are sequentially-assigned internal numbers, with a period appended. Once a message is appended to a folder, its internal sequence number never changes. Lines are terminated by CRLF. In order to allow the server to export netnews spool directories, there is a per-folder netnews compatability mode. Folders in this mode have message files named without an appended period. Lines in message files are terminated by just LF. Messages may not be appended to or copied into these folders in the normal manner. The directory contains the following additional files. All binary values are in network byte order: cyrus.header Contains variable-length information about the folder itself. - magic-number - Filename of cyrus.quota for this folder - The names of the user-defined flags - The folder's ACL cyrus.index Contains a header and a sequence of fixed-length records, one record per message in the folder. The header contains: - magic-number ? - folder-format 4 bytes nonzero if folder in netnews format - generation-no 4 bytes incremented each time cyrus.index is rewritten by an expunge operation - start-offset 4 bytes offset of first per-message record - record-size 4 bytes size of per-message records - last-date 4 bytes INTERNALDATE of the last message appended to the folder - last-seqno 4 bytes sequence number of the last message appended to the folder - quota-used 4 bytes size quota usage this folder Each per-message record contains: - sequence-no 4 bytes internal sequence number - internaldate 4 bytes (in unix date format) - rfc822.size 4 bytes - body-offset 4 bytes offset in file of message body - cache-offset 4 bytes offset in cyrus.cache - last-updated 4 bytes unix date of last modification of flags - system-flags 4 bytes bit-vector of system and internal flags: ¥answered ¥flagged ¥deleted - user-flags 16 bytes User-defined flags cyrus.cache Contains a header and asequence of variable-length records, one record per message in the folder. The header contains a "generation number" corresponding to the one in cyrus.index. Each record contains: - IMAP "envelope", in format suitable for use in FETCH reply - IMAP "body", in format suitable for use in FETCH reply - sizes and file offsets of the various MIME body parts cyrus.seen Contains the ¥seen and ¥recent information of users. One record per user, sorted by user, each record contains: - Userid - Time last opened (for ¥RECENT) - SEQUENCE of sequence-no's of read messages - Optional space character padding, to avoid having to rewrite file on updates In order to support replicated folders in a future implementation, access to cyrus.seen will be through an interface which can later be replaced by a distributed database. * Quota information storage format Each directory, whether it corresponds to folder or not, can act as the quota "root" of a hierarchy of folders. Such roots contain the file: cyrus.quota Contains hierarchy-wide quota limits and usage. * Folder locking semantics In order to update information in a folder, the implementation must follow set locking procedures in order to prevent concurrency errors. The locking order is: cyrus.header cyrus.index cyrus.seen cyrus.quota To prevent deadlocks, an implementation may not lock a given file while holding a lock on a later file. After obtaining a lock on any file, the implementation must double-check to make sure the file wasn't rewritten. It is necessary to lock cyrus.header before locking cyrus.quota in order to guard against the possibility of another process changing the cyrus.quota for the folder. The order of the specific update operations is: To append one or more messages: lock cyrus.header check ACL open cyrus.index and cyrus.cache if not already reading them lock already-open cyrus.index file if cyrus.index has been replaced since last opened, close, reopen, send EXPUNGE notifications, and repeat. if reopened cyrus.index file, reopen cyrus.cache file. Lock appropriate cyrus.quota check quota assign sequence number as one plus last-seqno ensure new internaldate is later than last-date write message file(s) append info to cyrus.cache append info to cyrus.index update last-date, last-seqno, and quota-used update cyrus.quota release locks To add or remove flags: if adding new user flag, lock cyrus.header, update, release lock lock already-open cyrus.index file if cyrus.index has been replaced since last opened open and lock the newer cyrus.index file. locate the record read previous flags if didn't read previous flags, read them from older cyrus.index calculate changes to flags update flags and last-updated update flags and last-updated in other cyrus.index release locks To expunge: lock cyrus.header lock appropriate cyrus.quota open cyrus.index and cyrus.cache if not already reading them lock already-open cyrus.index file if cyrus.index has been replaced since last opened, close, reopen, send EXPUNGE notifications, and repeat. if reopened cyrus.index file, reopen cyrus.cache file. create files cyrus.index.NEW and cyrus.cache.NEW copy header, incrementing generation-no copy non-¥DELETED records to new files, remember seqnos and sizes [remove unused user flags from cyrus.header?] update quota-used in cyrus.index.NEW rename cyrus.index.NEW to cyrus.index rename cyrus.cache.NEW to cyrus.cache update cyrus.quota release locks remove deleted message files lock cyrus.seen create cyrus.seen.NEW copy data, removing users who haven't read recently rename cyrus.seen.NEW to cyrus.seen release locks update recent/seen info: lock cyrus.seen find record if user appears to have read everything and previously hadn't check to make sure no new messages mark as having read through last-seqno dropoff request for IMSP SEEN command else if user previously had read everything but no longer does dropoff request for IMSP SEEN (0) command if enough room to update in place update record in place else create cyrus.seen.NEW copy data, updating record rename cyrus.seen.NEW to cyrus.seen release lock [need to deal with backout on failure.] [dump/restore, to implement IMSP MOVE] * Reading semantics In order to avoid presenting stale data, the following operations should be performed when implementing the following IMAP commands. Select/Bboard: open cyrus.header, check ACL open cyrus.index and cyrus.cache, repeat if generation-no doesn't match open cyrus.seen calculate FLAGS from information in cyrus.header calculate EXISTS by size of cyrus.index calculate RECENT by info in cyrus.seen and binary search of cyrus.index Fetch/Partial: calculate offset into cyrus.index follow pointers to cyrus.cache and/or message file Check: if newer cyrus.index open cyrus.index and cyrus.cache send EXPUNGE notifications scan for changed flags (using last-updated), send unsolicited FETCH FLAGS replies calculate EXISTS and RECENT Search: order the search criterea in cheapest-to-most-expensive order perform searches, narrowing return set send SEARCH reply The search criteria order in the following categoreis: - INTERNALDATE based -- binary search in cyrus.index ALL, BEFORE, ON, SINCE - cyrus.seen based -- binary search seqno, internaldate in cyrus.index NEW, OLD, RECENT, SEEN, UNSEEN - cyrus.header based ANSWERED, DELETED, FLAGGED, KEYWORD, UNANSWERED, UNDELETED, UNFLAGGED, UNKEYWORD - cyrus.cache based BCC, CC, FROM, SUBJECT, TO - must serch message file contents BODY, TEXT * Configuration directory On each server, there is a directory which contains files specifiying the server configuration. The files are: - policy Specifies site policy options, such as: Whether to automatcally create INBOX mailboxes for users The hostnames and Kerberos identifications of the IMSP servers Whether to support the SUBSCRIBE/UNSUBSCRIBE IMAP commands Which Kerberos realms to allow logins from [?] Whether to allow logins based on system password file Whether to allow anonymous logins - bboard.partitions Lists the bboard partition names and their corresponding directory roots. If a bboard exists in a given partition, the path to the bboard is found by taking the bboard name, changing "." characters to "/", and prepending the partition's directory root. - mailbox.partitions [or user.partitions] Lists the mailbox partition names and their corresponding directory roots. If a mailbox exists in a given partition, the path to the bboard is found by taking the bboard name, changing "." characters to "/", and prepending the partition's directory root and the mailbox's user. When creating a new folder, the default partition is determined as follows: If there exists a folder or quota root in some higher part of the hierarchy, the default partition is that of the longest such folder or quota root. Otherwise, the default partition is the one listed first in the appropriate partiton file. - bboard Lists the names and partitions of all the bboards. - delivered.dir & delivered.pag Database of delivered messages, for duplicate delivery elimination. Stores folder name (bboard or user/mailbox), message-id, and delivery time. The delivery time is used for purging the database of old entries. * User directory: There is a directory to contain files with per-user information. For each user, it contains one or more of the following files. In the filename, "USER" stands for the login name of the user. - USER.mailbox Lists the names and partitions of the user's mailboxes. - USER.mailboxsubs Lists the user's subscribed mailboxes - USER.bboardsubs Lists the user's subscribed bboards. * IMSP dropoff directory: Contains one file for each SEEN or LAST command that needs to be sent to an IMSP server. Filename is one of: - last.mailbox.USER.MAILBOX-NAME.SEQUENCE-NO - last.bboard.BBOARD-NAME.SEQUENCE-NO - seen.mailbox.USER.MAILBOX-NAME.SEQUENCE-NO - seen.bboard.USER.BBOARD-NAME.SEQUENCE-NO With the following definitions: USER - Name of user owning/reading MAILBOX-NAME - Name of relevant mailbox BBOARD-NAME - Name of relevant bboard SEQUENCE-NO - Sequence-no of last message posted/read A sequence-no of "0" for seen means user no longer read everything in folder. The order of operations for the update daemon is: list all files in directory sort in following order last before seen larger sequence-no's take precedence, except if have a sequence-no of 0, have to stat and use the one which was written later give IMSP SEEN and LAST commands unlink files sleep, repeat * Reader registry directory Contains one file for each server process reading a folder. Filename is process-id of server, contents of file is name of mailbox/bboard being read. When a folder is deleted or renamed, this directory is scanned for processes reading the folder. Those processes are sent a signal causing them to shut down. * Programs: The following programs will be written - cyrus-imapd Exports the IMAP protocol to a connecting client. Called by inetd or equivalent. - cyrus-deliver Called by the mail system to deliver message to mailbox or bboard. Will be backwards-interface-compatable with rmail. - cyrus-update Daemon to monitor the dropoff directory and give SEEN/LAST commands to an IMSP server. - cyrus-builddir Called by the netnews system to build cyrus header files in the news spool area. - cyrus-expire Expires old bboard posts Has mode where it will clean up after a news system expire - cyrus-arbitron Reports readership statistics - cyrus-pop2d - cyrus-pop3d Exports the POP2 or POP3 protocol to a connecting client. - cyrus-reconstruct Reconstructs/rebuilds a corrupted set of folder header/index/cache/seen files. Might be the same program as cyrus-builddir. * Monitoring The following things need to be monitored. In real time: - the number of connections Can be done with an inetd-equivalent that keeps a count - disk usage, load average Already have programs to do this In log files: - where connections come from - logins - feature usage (count) and timing (total/min/max) Can log on close of folder, with user and folder name On periodic basis: - quota usage Can write program to walk partitions and read quota roots. * Implementation priority Implementation order is as follows: - Basic functionality + append message (ex. cyrus.cache), check quotas, check ACLs + append cyrus.cache, minimal cyrus-deliver + bboard/noop/logout, minimal cyrus-imapd + fetch/partial (ex. MIME parts) - Flags/Search + store flags/recent/seen + search internaldate/flags + search cyrus.cache/body - Users + login/select/MIME fetch, full-fledged cyrus-deliver + create/rename/delete/create.bboard/rename.bboard/delete.bboard + subscribe/unsubscribe/find/acl - Full IMAP2bis + expunge + check + copy, etc. Alpha release - Everything else + IMSP seen/last, cyrus-update + quota + cyrus-builddir, minimal cyrus-expire + IMSP move + quota-usage reporter, full cyrus-expire + cyrus-arbitron, cyrus-pop2d, cyrus-pop3d + connection-counting inetd; Beta release From owner-imap@cac.washington.edu Wed Jul 21 22:43:06 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15795; Wed, 21 Jul 93 22:43:06 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01958; Wed, 21 Jul 93 22:42:41 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01952; Wed, 21 Jul 93 22:42:40 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.3/8.3) id BAA01112; Thu, 22 Jul 1993 01:42:36 -0400 Received: via switchmail; Thu, 22 Jul 1993 01:42:35 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 22 Jul 1993 01:42:27 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 22 Jul 1993 01:42:25 -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, 22 Jul 1993 01:42:25 -0400 (EDT) Message-Id: <8gHWX1G00WBwEYZVRX@andrew.cmu.edu> Date: Thu, 22 Jul 1993 01:42:25 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Interactive Mail Support Protocol In-Reply-To: References: Beak: is Not Laurence Lundblade writes: > Have managed to get a chance to look at the latest IMSP spec and have > some comments. > > On the responses to the FIND command that now include the ¥SUBSCRIBED > status of the mailbox, I would like to see it also include the number of > messages and the number of new messages. For background information, the primary reason responses to the FIND command now include "attributes" is to make the meaning of unsolicted MAILBOX and BBOARD replies unambiguous outside the context of a particular FIND command. The primary concerns I have with including the number of messages, etc. are ones of implementation. For performance reasons, the IMSP server presumably does not want to poll all the relevant IMAP servers while processing the client's FIND request. That means the IMAP server's information will necessarily be out of date. Highly visible out of date information will tend to confuse and/or annoy the user (who will then proceed to annoy the implementor). We currently run a mail system (AMS) which has a feature similar to IMSP's FIND.UNSEEN. As it is, I get an occasional bug report of the form "the folder list said the foo bboard had no new messages, but when I opened it there were in fact new messages." I would hate to have to fend off users who were told that there were 7 new messages when in fact there were 13. Netnews servers in particular have access to more up-to-date information than an IMSP server would be able to get. Do you define "new" as IMAP defines "NEW" (RECENT and UNSEEN)? I have to admit I don't really understand /RECENT and tend to think only in terms of /SEEN. At the very least, this points out the binary-state limitation of attributes. I based them on IMAP flags--it may be worthwhile to instead base them on envelopes. I appreciate other people's input on these matters. > On the address book, I'm trying to figure out how one would go about down > loading the address book for browsing by the user. It seems one would do > a SEARCHADDRESS on "*" and then FETCHADDRESS on all the aliases returned. > This seems OK, but maybe sub-optimal. That is the right procedure--It does take at least two round trips. On the other hand, downloading the entire address book is sub-optimal. For browsing the address book one may want a variant of FETCHADDRESS which only retrieves one field. One could then create a browser with all the "name" fields without having to transfer the 18KB of text they put in the various "comments" fields. I would appreciate it if client implementors would give me very explicit feedback on the address book facility. Would they consider using it, which features would they use, and what is missing. This facility is only going to fly if clients support it and clients are only going to support it if it does what the implementors need. > So, it seems that there should be some way to control the order of > the subscription list. The Cyrus IMAP server implementation supports this through a partiular named option in the IMSP "user configuration information" facility. The value of the option controls the order in which the server will send unsolicited MAILBOX or BBOARD replies. I tend to prefer leaving this as an implementation-specific private convention. To put it in the specification itself would assign meaning to the order of a set of unsolicted replies. There does need to be work done on option naming. > Last, most operations seem like they will be very quick, but for the ones > that might take more than 5 seconds or so, it would be really nice if > there was some way that progress could be reported to the user. This is a hard one. No clean, simple solution comes to mind. I assume you're only interested in network transfer time. The IMSP server would be hard-pressed to guess how much CPU it's going to burn before coming up with an answer. Besides, CPU's are fast, SLIP connections are slow. >From a UI standpoint, presenting the user with a scrolled view into an object that grows while the client receives items and letting them select items before the previous query finishes is preferable to making them wait watching a progress bar reach 100%. Unfortunately, it's also harder to implement. I'll have to think about this a bit. > It would also be nice to be able > to abort operations that are taking too long. You can always close the connection... I'm not sure anything less drastic is going to be effective. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Thu Jul 22 19:08:25 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16205; Thu, 22 Jul 93 19:08:25 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06057; Thu, 22 Jul 93 19:07:51 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06051; Thu, 22 Jul 93 19:07:49 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA23707; Thu, 22 Jul 93 19:07:43 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA28240; Thu, 22 Jul 93 19:04:39 PDT Received: from ford by air.airco.co.jp (4.1/6.4J.6) id AA02554; Fri, 23 Jul 93 10:29:20 JST Return-Path: Message-Id: <9307230129.AA02554@air.airco.co.jp> Date: Fri, 23 Jul 1993 10:24:09 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: imap@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think the address book as described in your 2-Jul-93 message is a good idea. It will allow convenient location independent access to that type of information. It's something that I would have liked to have seen in IMAP, but doesn't belong there. I would suggest, however, that the FETCH command allow you to specify what fields you want with the option of getting them all. That way if I want to implement a name and address list, I can fetch only what I need. Later if the user wishes to edit the address book entry I can fetch the whole thing. One question that I have is: If more than one person is allowed to edit an Address book and two people edit the same entry and field at the same time whose change take effect? There is no method in the protocol for the STOREADDRESS command to say that entry X was modified since you last fetched it. I am not sure if this capability is a necessity, but, I think the issue needs to be "Addressed". makr From owner-imap@cac.washington.edu Thu Jul 22 19:50:50 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18689; Thu, 22 Jul 93 19:50:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06286; Thu, 22 Jul 93 19:50:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06280; Thu, 22 Jul 93 19:50:36 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA13444; Thu, 22 Jul 93 19:50:24 -0700 Date: Thu, 22 Jul 1993 19:48:47 -0700 (PDT) From: Mark Crispin Subject: Re: Interactive Mail Support Protocol To: Mark Keasling Cc: John Gardiner Myers , imap@cac.washington.edu In-Reply-To: <9307230129.AA02554@air.airco.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Jul 1993 10:24:09 +0900 (JST), Mark Keasling wrote: > One question that I have is: If more than one person is allowed to edit > an Address book and two people edit the same entry and field at the same > time whose change take effect? There is no method in the protocol for the > STOREADDRESS command to say that entry X was modified since you last fetched > it. I am not sure if this capability is a necessity, but, I think the issue > needs to be "Addressed". Good point. It's the reason why I added the +FLAGS and -FLAGS attributes to IMAP; otherwise simultaneous updating would be difficult. Probably it sufficies to have some sort of sequencing code that is incremented by one each update, and if the sequencing code isn't what is expected report a skew. From owner-imap@cac.washington.edu Fri Jul 23 11:49:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23333; Fri, 23 Jul 93 11:49:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12534; Fri, 23 Jul 93 11:49:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12528; Fri, 23 Jul 93 11:49:29 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.4/8.4) id OAA00657; Fri, 23 Jul 1993 14:49:26 -0400 Received: via switchmail; Fri, 23 Jul 1993 14:49:26 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Jul 1993 14:48:27 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Jul 1993 14:48:18 -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; Fri, 23 Jul 1993 14:48:18 -0400 (EDT) Message-Id: Date: Fri, 23 Jul 1993 14:48:18 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Interactive Mail Support Protocol In-Reply-To: <9307230129.AA02554@air.airco.co.jp> References: <9307230129.AA02554@air.airco.co.jp> Beak: Is Mark Keasling writes: > I would suggest, however, that the FETCH > command allow you to specify what fields you want with the option of getting > them all. That way if I want to implement a name and address list, I can > fetch only what I need. Later if the user wishes to edit the address > book entry I can fetch the whole thing. I didn't put this in to start with because I wanted to discourage clients from only showing the user those address book fields the client knew about. On later reflection, it seems that in order for a client to efficiently implement a name browser, it will be necessary for it to be able to fetch the value of just one field. To do this, I could change SEARCHADDRESS, change FETCHADDRESS, or add a new command. I probably will not provide a mechanism to fetch two or more named fields at once. Mark Crispin writes: > Probably it sufficies to have some sort of sequencing code that is > incremented by one each update, and if the sequencing code isn't > what is expected report a skew. At which point the user's left holding the bag. I can just see the dialog box: "Someone else modified that entry out from under you. Type those 100 new addresses in again from scratch. [OK]" The concurrency issue exits for the option and ACL facilities as well. I'm not worried about the ACL's. I think the correct solution is some sort of advisory locking facility. From owner-imap@cac.washington.edu Fri Jul 23 12:09:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24901; Fri, 23 Jul 93 12:09:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13216; Fri, 23 Jul 93 12:09:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13210; Fri, 23 Jul 93 12:09:33 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18904; Fri, 23 Jul 93 12:09:29 -0700 Date: Fri, 23 Jul 1993 12:00:51 -0700 (PDT) From: David L Miller Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Jul 1993, John Gardiner Myers wrote: > Mark Keasling writes: > > Mark Crispin writes: > > Probably it sufficies to have some sort of sequencing code that is > > incremented by one each update, and if the sequencing code isn't > > what is expected report a skew. > > At which point the user's left holding the bag. I can just see the > dialog box: "Someone else modified that entry out from under you. > Type those 100 new addresses in again from scratch. [OK]" > > The concurrency issue exits for the option and ACL facilities as well. > I'm not worried about the ACL's. I think the correct solution is some > sort of advisory locking facility. > Correct. There is also the issue of notifying the client that an addressbook (entry) has been locked by another client. I suppose it would be appropriate to handle that as a return condition to the lock request. Naturally, I would prefer that the locking facility be on a per-entry basis, but I suppose it is not critical if that would entail too much additional overhead. -- |¥ | |¥/| 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 From owner-imap@cac.washington.edu Fri Jul 23 12:34:59 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26773; Fri, 23 Jul 93 12:34:59 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11781; Fri, 23 Jul 93 12:34:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11775; Fri, 23 Jul 93 12:34:41 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA14178; Fri, 23 Jul 93 12:34:35 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA27712; Fri, 23 Jul 93 12:34:27 -0700 Date: Fri, 23 Jul 1993 12:32:16 -0700 (PDT) From: Mark Crispin Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Jul 1993 14:48:18 -0400 (EDT), John Gardiner Myers wrote: > At which point the user's left holding the bag. I can just see the > dialog box: "Someone else modified that entry out from under you. > Type those 100 new addresses in again from scratch. [OK]" Not necessarily. The client has, potentially, the original value, the user's edits, and now can get the new value. Merging two sets of changes -- particularly if the user is queried -- is hardly rocket science. A locking mechanism would be alright too. But maybe it should be a record locking mechanism? From owner-imap@cac.washington.edu Fri Jul 23 12:54:24 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28300; Fri, 23 Jul 93 12:54:24 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14754; Fri, 23 Jul 93 12:54:06 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14748; Fri, 23 Jul 93 12:54:04 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.4/8.4) id PAA00729; Fri, 23 Jul 1993 15:54:01 -0400 Received: via switchmail; Fri, 23 Jul 1993 15:54:01 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Jul 1993 15:52:26 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Jul 1993 15:52: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; Fri, 23 Jul 1993 15:52:20 -0400 (EDT) Message-Id: Date: Fri, 23 Jul 1993 15:52:20 -0400 (EDT) From: John Gardiner Myers Subject: Re: Interactive Mail Support Protocol To: IMAP Interest List In-Reply-To: References: Beak: is Not Mark Crispin writes: > Merging two sets of changes -- particularly if the user is queried > -- is hardly rocket science. Asking address book clients to implement diff3 is perhaps a bit much. > A locking mechanism would be alright too. But maybe it should be a record > locking mechanism? I was planning on having the locking mechanism be on a per-option and per-entry level. Should someone else already have a lock, the lock command would return a NO response. The implementation could include text identifying the locking user. Should nobody have a lock, the server would send any unsolicited reply necessary to ensure the client has the newest data before it sends the OK response. Nonexistent options/entries can be locked, in order to allow atomic creation. I've been thinking of what the UI would look like. There are three possibilities: * The client to provides an explicit "edit" button or command which causes the client to issue the lock command. * The client always locks what the user is viewing, and uses read-only mode when the locks fail (ugh) * The client locks the record when the user clicks on a text widget displaying one of the record's fields. From owner-imap@cac.washington.edu Fri Jul 23 13:15:43 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00455; Fri, 23 Jul 93 13:15:43 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15659; Fri, 23 Jul 93 13:15:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15653; Fri, 23 Jul 93 13:15:27 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20312; Fri, 23 Jul 93 13:15:19 -0700 Date: Fri, 23 Jul 1993 13:09:40 -0700 (PDT) From: David L Miller Subject: Re: Interactive Mail Support Protocol To: Mark Crispin Cc: John Gardiner Myers , IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The advantage of a locking mechanism is that a properly written client will check for a lock *before* the edit begins. Otherwise you are going to end up with some perturbed users in the case John mentioned... I do agree that record locking is to be preferred. Would it make sense to make record locking optional in the spec? That way a minimal implementation would not have to worry about the additional overhead, at the expense of some (small?) loss of availability? -- |¥ | |¥/| 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 Fri, 23 Jul 1993, Mark Crispin wrote: > On Fri, 23 Jul 1993 14:48:18 -0400 (EDT), John Gardiner Myers wrote: > > At which point the user's left holding the bag. I can just see the > > dialog box: "Someone else modified that entry out from under you. > > Type those 100 new addresses in again from scratch. [OK]" > > Not necessarily. The client has, potentially, the original value, the user's > edits, and now can get the new value. Merging two sets of changes -- > particularly if the user is queried -- is hardly rocket science. > > A locking mechanism would be alright too. But maybe it should be a record > locking mechanism? > > From owner-imap@cac.washington.edu Fri Jul 23 13:34:26 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01928; Fri, 23 Jul 93 13:34:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16288; Fri, 23 Jul 93 13:34:12 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16280; Fri, 23 Jul 93 13:34:10 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20664; Fri, 23 Jul 93 13:34:05 -0700 Date: Fri, 23 Jul 1993 13:25:51 -0700 (PDT) From: David L Miller Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Jul 1993, John Gardiner Myers wrote: > Mark Crispin writes: > > Merging two sets of changes -- particularly if the user is queried > > -- is hardly rocket science. > > Asking address book clients to implement diff3 is perhaps a bit much. > Agreed. > > A locking mechanism would be alright too. But maybe it should be a record > > locking mechanism? > > I was planning on having the locking mechanism be on a per-option and > per-entry level. > > Should someone else already have a lock, the lock command would return > a NO response. The implementation could include text identifying the > locking user. Should nobody have a lock, the server would send any > unsolicited reply necessary to ensure the client has the newest data > before it sends the OK response. Nonexistent options/entries can be > locked, in order to allow atomic creation. > Would the server be required to remember if the client already has the latest data? > I've been thinking of what the UI would look like. There are three > possibilities: > > * The client to provides an explicit "edit" button or > command which causes the client to issue the lock command. > That is the one I would probably use, at least for text-based applications. > * The client always locks what the user is viewing, and uses read-only > mode when the locks fail (ugh) > This mode should be strongly discouraged, although there may be application for some form of block operation on multiple entries with one lock command. > * The client locks the record when the user clicks on a text widget > displaying one of the record's fields. > Fine for GUIs. From owner-imap@cac.washington.edu Fri Jul 23 15:19:22 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11156; Fri, 23 Jul 93 15:19:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20237; Fri, 23 Jul 93 15:19:00 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20231; Fri, 23 Jul 93 15:18:59 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.4/8.4) id SAA00813; Fri, 23 Jul 1993 18:18:56 -0400 Received: via switchmail; Fri, 23 Jul 1993 18:18:55 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Jul 1993 18:17:03 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 23 Jul 1993 18:17:02 -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; Fri, 23 Jul 1993 18:16:59 -0400 (EDT) Message-Id: <0gI6BPC00WBwIjuI4z@andrew.cmu.edu> Date: Fri, 23 Jul 1993 18:16:59 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Interactive Mail Support Protocol In-Reply-To: References: Beak: Is David L Miller writes: > Would it make sense to make record locking optional in the spec? > That way a minimal implementation would not have to worry about the > additional overhead, at the expense of some (small?) loss of > availability? The spec will have a per-option/per-entry interface. I could define the semantics in a way which would allow an implementation the flexibility of implementing the locking on a more coarse-grained level. > Would the server be required to remember if the client already has the > latest data? Nope, the server could choose to always send the data on a lock. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Jul 23 15:41:14 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13311; Fri, 23 Jul 93 15:41:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21128; Fri, 23 Jul 93 15:40:47 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21122; Fri, 23 Jul 93 15:40:46 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23570; Fri, 23 Jul 93 15:40:43 -0700 Date: Fri, 23 Jul 1993 15:36:32 -0700 (PDT) From: David L Miller Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: <0gI6BPC00WBwIjuI4z@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK, sounds good to me. -- |¥ | |¥/| 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 Fri, 23 Jul 1993, John Gardiner Myers wrote: > David L Miller writes: > > Would it make sense to make record locking optional in the spec? > > That way a minimal implementation would not have to worry about the > > additional overhead, at the expense of some (small?) loss of > > availability? > > The spec will have a per-option/per-entry interface. I could define > the semantics in a way which would allow an implementation the > flexibility of implementing the locking on a more coarse-grained > level. > > > Would the server be required to remember if the client already has the > > latest data? > > Nope, the server could choose to always send the data on a lock. > > -- > _.John G. Myers Internet: jgm+@CMU.EDU > LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up > > From owner-imap@cac.washington.edu Fri Jul 23 16:46:20 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17721; Fri, 23 Jul 93 16:46:20 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23375; Fri, 23 Jul 93 16:46:05 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23365; Fri, 23 Jul 93 16:45:58 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42223-2>; Fri, 23 Jul 1993 17:45:50 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Fri, 23 Jul 93 17:26 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0oJWaY-000cuiC; Fri, 23 Jul 93 17:31 MDT Date: Fri, 23 Jul 1993 18:27:05 -0600 From: Steve Hole Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: IMAP Interest List Message-Id: Priority: Normal X-Read-Ack: No X-Delivery-Ack: No Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=Part9307231705A --Part9307231705A Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 23 Jul 1993 13:52:20 -0600 John Gardiner Myers wrote: > From: John Gardiner Myers > Date: Fri, 23 Jul 1993 13:52:20 -0600 > Subject: Re: Interactive Mail Support Protocol > To: IMAP Interest List > > Should someone else already have a lock, the lock command would return > a NO response. The implementation could include text identifying the > locking user. Should nobody have a lock, the server would send any > unsolicited reply necessary to ensure the client has the newest data > before it sends the OK response. Nonexistent options/entries can be > locked, in order to allow atomic creation. > > I've been thinking of what the UI would look like. There are three > possibilities: > > * The client to provides an explicit "edit" button or > command which causes the client to issue the lock command. This is the option that I like best. It will fit in very nicely with a what happens in a GUI interface. John, I have attached the header definition file for the new address book API that I am developing for ECSMail. It supports both local and remote address book functionality. You will probably find the function definitions to be the most interesting because they define what it is that we need to be able to do in the application. The support for remote address book functionality is a barebones stub at best. After reading the new IMSP spec last night, I have a number of changes to make to the data structures to support caching and access to a remote IMSP server. You will note that I support the concept of user defined distribution lists in the address book. It would be very nice to be able to support DL's on the remote server as well. The address book API types entries in the address book as either a "person" or a "distribution list". In the local database file driver (it has been implemented as a simple ISAM database), member references in the distribution list are maintained as a set of "member" records in a second database file - keyed by the parent entry in the main entry database. There are a separate set of routines for managing and navigating the address book entries, and for managing and navigating DL member lists. I don't know how you feel about DL's - nobody has mentioned them so far. -- 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 --Part9307231705A Content-Type: TEXT/PLAIN; name="ADDRBOOK.H" /* MODULE [data_definition]: AddressBook */ /* FUNCTION */ /* This module contains the public data and function definitions */ /* for the ECS AddressBook. */ /* END FUNCTION */ /* NOTES */ /* Rules for the address book: * Each object stored in the address book is called an "entry". All of the entries in the address book are stored in a single ISAM database file. * There are two types of entry: a Person or a Distribution list. A Person corresponds to a single user, application or mailing address. A distribution list is a group of Persons. * Any member address in a distribution list must be defined in address book as a Person. Members of distribution lists are stored as a set of listname/member record number pairs stored in a second ISAM database. * Cache entries for remote address book storage are flushed on a "least recently used algorithm" that selects the FLUSHDELTA number of elements that have been unreferenced the longest. */ /* END NOTES */ /* HISTORY */ /* IncrDev June 23, 1993 by sh [0.2]: consolidated the two entry types */ /* Created June 1, 1993 by Steve Hole [2.0]: based on old address book */ /* END HISTORY */ /* DATA DEPENDENCIES */ #include /* END DATA DEPENDENCIES */ /* DATA DEFINITION */ /* : protect against multiple inclusions #ifndef _AddressBook #define _AddressBook /* : address book entry definitions */ #ifndef TRUE # define TRUE 1 #endif #ifndef FALSE # define FALSE 0 #endif #ifndef SUCCESS # define SUCCESS 1 #endif #ifndef FAILS # define FAILS 0 #endif # define S_TEXTLEN 20 /* short text string */ # define M_TEXTLEN 50 /* medium text string */ # define L_TEXTLEN 100 /* long text string */ # define H_TEXTLEN 200 /* huge text string */ # define MAX_BOOKS 20 /* maximum number of address books */ # define CACHESIZE 100 /* number of entries in the cache */ # define FLUSHDELTA 20 /* number of entries to flush in cache */ # define DLIST_GROWTH_DELTA 50 /* number of dlist entries to provide space for */ typedef enum { /* Address Book Entry Types */ Person, /* person address entry */ DList /* distribution list address entry */ } EntryType; typedef struct { /*** Person Address Entry Info */ char organization[M_TEXTLEN]; /* organization */ char title[L_TEXTLEN]; /* business title */ char internet[M_TEXTLEN]; /* Internet email address */ char x400[L_TEXTLEN]; /* X.400 O/R email address */ char phone[S_TEXTLEN]; /* telephone number */ char fax[S_TEXTLEN]; /* facsimile number */ } PEntry; typedef struct { /*** Distribution List Member */ char common_name[M_TEXTLEN]; /* parent dlist entry common name */ char member_name[M_TEXTLEN]; /* member entry common name */ long recnum; /* member entry record number */ } DLMember; typedef struct { /*** Distribution List Address Entry Info */ unsigned short count; /* number of members in the list */ unsigned short curmem; /* index of current member in the list */ unsigned short freespace; /* number of unused member elements in the list */ DLMember *members; /* list of members in the distribution list */ } DLEntry; typedef struct { /*** Address Entry */ char common_name[M_TEXTLEN]; /* common name of person */ char alias[S_TEXTLEN]; /* short name for the dl */ EntryType type; /* entry type */ union { PEntry p_entry; /* person entry value */ DLEntry dl_entry; /* distribution list entry value */ } entry; char comment[H_TEXTLEN]; /* additional notes */ time_t mod_date; /* last modification time */ } AddrEntry; /* : address book storage definitions */ typedef enum { /*** Address Book Types */ Local, /* local (file based) address book */ Remote /* remote (server based) address book */ } BookType; typedef enum { /*** Address Book Status */ Open, /* address book is open */ Closed /* address book is closed */ } BookStatus; typedef enum { /*** Address Book Cache Status */ InCache, /* entry is in cache */ OutCache /* entry is not in cache */ } CacheStatus; typedef struct { /*** Address Book Database File Storage */ char path[L_TEXTLEN]; /* database file pathname */ int m_fd; /* main address book database file descriptor */ int dl_fd; /* distribution list database file descriptor */ } BookFile; typedef struct { /*** Address Book Server Storage */ char host[M_TEXTLEN]; /* server hostname */ short port; /* server TCP port number */ int sd; /* server socket descriptor */ } BookServer; typedef struct { /*** Address Book */ char book_name[M_TEXTLEN]; /* address book name */ BookType book_type; /* address book type */ BookStatus status; /* address book status */ union { BookFile file; /* local address book file info */ BookServer server; /* remote address book server info */ } book_store; /* address book storage info */ } AddrBook; /* * This guy differs from the address book in that it is intended for * short term storage of a smallish (< 100) entries at a time. Mostly * it is used to collect a subset of entries that match addresses in * wildcard or regular expression lookup of addresses in the address book. * It may be better to store only the key value or record number of * matching records in the address list to save space in the future. It * will require that the keys or record numbers be dereferenced, and thus * be slower, but will save on a lot of memory. As we know, memory on * the DOS and Macintosh boxes is the issue. */ typedef struct { /*** Address Entry List */ unsigned short count; /* number of entries in the address list */ AddrEntry *members; /* list of entries */ } AddrList; /* * The following function definitions are for public use in * application functions. All access to public data structures * should be made using the public functions. */ /* : memory allocation isolation macros */ /* * These macros allow applications to overide the memory allocation mechanism * used by the address book with something of their own creation. This is * useful for applications that have to keep a close watch on memory leakage. * To use them, the calling application needs to define the adrbk_MALLOC macro * before referencing this include file. */ #ifndef adrbk_MALLOC # define adrbk_MALLOC malloc #endif #ifndef adrbk_REALLOC # define adrbk_REALLOC realloc #endif #ifndef adrbk_CALLOC # define adrbk_CALLOC calloc #endif /* : address book functions */ # define adrbk_new_book(p_book) (p_book = (AddrBook *) adrbk_MALLOC(sizeof(AddrBook))) # define adrbk_free_book(p_book) (free(p_book)) /*** Read Functions */ # define adrbk_book_name(p_book) (p_book->book_name) # define adrbk_book_type(p_book) (p_book->book_type) # define adrbk_book_status(p_book) (p_book->status) # define adrbk_file_path(p_book) (p_book->book_store.file.path) # define adrbk_connect_status(p_book) (p_book->book_store.server.status) /*** Write Functions */ # define adrbk_set_book_name(p_book, p_name) (strcpy(p_book->book_name,p_name)) # define adrbk_set_book_type(p_book, p_type) (p_book->book_type = p_type) # define adrbk_set_book_file(p_book, p_path) (strcpy(p_book->book_store.file.path,p_path)) # define adrbk_set_book_server(p_book, p_host, p_port) ¥ (strcpy(p_book->book_store.server.host,p_host);¥ p_book->book_store.server.port = p_port) /* : address book entry functions */ # define adrbk_new_entry(p_entry) (p_entry = (AddrEntry *) adrbk_MALLOC(sizeof(AddrEntry))) # define adrbk_free_entry(p_entry) (free(p_entry)) /* : address book management functions */ int adrbk_create ( /* create a new address book */ AddrBook *p_book /* U: book to create */ ); int adrbk_destroy ( /* destroy an address book */ AddrBook *p_book /* U: book to destroy */ ); int adrbk_open ( /* open an address book */ AddrBook *p_book /* U: address book to open */ ); int adrbk_close ( /* close an address book */ AddrBook *p_book /* U: book to close */ ); int adrbk_save ( /* save a modified address book */ AddrBook *p_book /* U: address book to save */ ); /* : address book navigation functions */ int adrbk_first_entry ( /* return the first entry in the address book */ AddrBook *p_book, /* I: address book to navigate */ AddrEntry *p_entry /* O: retrieved entry */ ); int adrbk_last_entry ( /* return the last entry in the address book */ AddrBook *p_book, /* I: address book to navigate */ AddrEntry *p_entry /* O: retrieved entry */ ); int adrbk_next_entry ( /* return the next entry in the address book */ AddrBook *p_book, /* I: address book to navigate */ AddrEntry *p_entry /* O: retrieved entry */ ); int adrbk_prev_entry ( /* return the previous entry in the address book */ AddrBook *p_book, /* I: address book to navigate */ AddrEntry *p_entry /* O: retrieved entry */ ); int adrbk_search ( /* search for an entry by common name key */ AddrBook *p_book, /* I: address book to navigate */ char *p_key, /* I: entry key to search for */ AddrEntry *p_entry /* O: retrieved entry */ ); int adrbk_search_alias ( /* search for an entry by alias key */ AddrBook *p_book, /* I: address book to navigate */ char *p_key, /* I: entry key to search for */ AddrEntry *p_entry /* O: retrieved entry */ ); /* : distribution list navigation routines */ int adrbk_load_dlist ( /* load a distribution list array for an entry */ AddrBook *p_book, /* I: book to load dlist for */ AddrEntry *p_entry /* U: entry to load dlist for */ ); int adrbk_first_member ( /* get the first member entry of a dlist */ AddrBook *p_book, /* I: book to load dlist for */ AddrEntry *p_entry, /* I: dlist entry to get member from */ AddrEntry *p_member /* U: retrieved member entry */ ); int adrbk_last_member ( /* get the first member entry of a dlist */ AddrBook *p_book, /* I: book to load dlist for */ AddrEntry *p_entry, /* I: dlist entry to get member from */ AddrEntry *p_member /* U: retrieved member entry */ ); int adrbk_next_member ( /* get the next member entry of a dlist */ AddrBook *p_book, /* I: book to load dlist for */ AddrEntry *p_entry, /* I: dlist entry to get member from */ AddrEntry *p_member /* U: retrieved member entry */ ); int adrbk_previous_member ( /* get the previous member entry of a dlist */ AddrBook *p_book, /* I: book to load dlist for */ AddrEntry *p_entry, /* I: dlist entry to get member from */ AddrEntry *p_member /* U: retrieved member entry */ ); /* : address book modification functions */ int adrbk_add_entry ( /* add a new entry to the address book */ AddrBook *p_book, /* I: address book to modify */ AddrEntry *p_entry /* I: entry to add */ ); int adrbk_update_entry ( /* update an entry in the address book */ AddrBook *p_book, /* I: address book to modify */ AddrEntry *p_entry /* I: entry to update */ ); int adrbk_delete_entry ( /* delete an entry from the address book */ AddrBook *p_book, /* I: address book to modify */ AddrEntry *p_entry /* I: entry to delete */ ); /* : distribution list modification functions */ int adrbk_add_member ( /* add a distribution list member to dlist entry */ AddrBook *p_book, /* I: address book dlist is in */ AddrEntry *p_entry, /* U: dlist entry to add member to */ AddrEntry *p_member /* I: person entry to add as member */ ); int adrbk_delete_member ( /* delete a distribution list member from a dlist entry */ AddrBook *p_book, /* I: address book to dlist is in */ AddrEntry *p_entry, /* U: dlist entry to delete member from */ AddrEntry *p_member /* I: person entry to delete as member */ ); /* : miscellaneous functions */ AddrList *adrbk_match ( /* match a set of addresses on common name wildcard */ AddrBook *p_book, /* I: address book to search */ char *p_srchstr /* I: common name wildcard search string */ ); AddrList *adrbk_match_alias ( /* match a set of addresses on alias wildcard*/ AddrBook *p_book, /* I: address book to search */ char *p_srchstr /* I: alias wildcard search string */ ); void adrbk_get_error ( /* get the error string for the last API error */ char *p_error, /* U: error string buffer */ int p_maxsize /* I: maximum size of the error string */ ); /* : private data structures and constants */ /* * These definitions are reserved for future development of the * remote address book service functionality. They are not currently * used by the address book routines. */ typedef struct { /* cache elemment */ unsigned short refnum; /* last cache reference to element */ AddrEntry entry; /* address entry */ } CacheEl; typedef struct { /* address book cache */ unsigned short refnum; /* current cache reference number */ CacheEl ca_store[CACHESIZE]; /* cache storage area */ } Cache; /* : miscellaneous variables and constants */ extern int AddrBookErrorNum; /* address book operation error code */ /* values for the address book error */ # define ADRBK_ERR_INT 0 /* Address book internal error */ # define ADRBK_ERR_MEM 1 /* Memory allocation error */ # define ADRBK_ERR_LOC 2 /* Unable to locate address book */ # define ADRBK_ERR_OPEN 3 /* Address book is already open */ # define ADRBK_ERR_NAV 4 /* Attempted navigation on closed address book */ # define ADRBK_ERR_ISAM 5 /* ISAM database error */ # define ADRBK_ERR_INVTYPE 6 /* Invalid entry type for address book operation */ /* #endif */ /* END DATA DEFINITION */ /* END MODULE: AddressBook */ --Part9307231705A-- From owner-imap@cac.washington.edu Fri Jul 23 23:24:00 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10689; Fri, 23 Jul 93 23:24:00 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15154; Fri, 23 Jul 93 23:23:36 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15148; Fri, 23 Jul 93 23:23:34 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.4/8.4) id CAA00980; Sat, 24 Jul 1993 02:23:31 -0400 Received: via switchmail; Sat, 24 Jul 1993 02:23:30 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Sat, 24 Jul 1993 02:22:15 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Sat, 24 Jul 1993 02:22:11 -0400 (EDT) Received: from mms.0.1.23.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.cortland.andrew.cmu.edu.pmax.ul4 via MS.5.6.cortland.andrew.cmu.edu.pmax_ul4; Sat, 24 Jul 1993 02:21:46 -0400 (EDT) Message-Id: Date: Sat, 24 Jul 1993 02:21:46 -0400 (EDT) From: Wallace Colyer To: imap@cac.washington.edu Subject: Re: Interactive Mail Support Protocol Cc: In-Reply-To: Excerpts from internet.computing.imap: 23-Jul-93 Re: Interactive Mail Suppor.. by Steve Hole@EDM.ISAC.CA > You will note that I support the concept of user defined > distribution lists in the address book. It would be very nice to be > able to support DL's on the remote server as well. The address > book API types entries in the address book as either a "person" > or a "distribution list". In the local database file driver (it has been > implemented as a simple ISAM database), member references in > the distribution list are maintained as a set of "member" records > in a second database file - keyed by the parent entry in the main > entry database. There are a separate set of routines for managing > and navigating the address book entries, and for managing and > navigating DL member lists. I think my idea of a distribution list and yours are probably different, so let me see if we can get to some common ground. I have traditionally thought of distribution lists as a delivery service issue (ie, they can be used as addresses by anyone who uses a named address). In AMDS you can use an addresses of the form +dist+PATHNAME@HOSTNAME to address a user created distribution list. Administrators can then create aliases with a more pleasant which forward to addresses of that format. What I think you are talking about is a list of recipients (members) that someone wants to send mail to as a group (without creating an address through which they can all keep in touch). This is seperate from a list of members of the address book with information specific to them. So you would potentially have an interface that allows creation of individual member entries and one that allows those individual members to be combined into groups. Would both the address book groups and members need to share a common name space? Could groups contain entries from other address books? I think that could be very problematic. How 'bout groups of groups? A devliery service could still implement a naming convention to allow these groups to be addressed. I am not sure how something like that would fit in, but I wanted to make sure understand what you are talking about. -Wallace From owner-imap@cac.washington.edu Sun Jul 25 18:11:32 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05337; Sun, 25 Jul 93 18:11:32 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26004; Sun, 25 Jul 93 18:10:57 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from stc06.CTD.ORNL.GOV by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25998; Sun, 25 Jul 93 18:10:55 -0700 Received: by stc06.CTD.ORNL.GOV (5.57/Ultrix3.0-C) id AA10714; Sun, 25 Jul 93 21:10:54 -0400 Date: Sun, 25 Jul 93 21:10:54 -0400 From: News poster Message-Id: <9307260110.AA10714@stc06.CTD.ORNL.GOV> To: imap@cac.washington.edu Newsgroups: ornl.mail.imap Path: stc06!jnm From: jnm@ornl.gov (Jamey Maze) Subject: Re: Nested mailboxes Message-ID: Sender: usenet@ornl.gov (News poster) Organization: Oak Ridge National Lab X-Newsreader: VersaTerm Link v1.1 References: <20Jul93.17: 34:38.20463@stc06> Distribution: local Date: Mon, 26 Jul 1993 01:10:36 GMT Lines: 31 In Article <20Jul93.17:34:38.20463@stc06>, Mark Crispin wrote: >On Tue, 20 Jul 1993 10:42:16 -0600, Steve Hole wrote: >> It seems to me that agreeing on a canonical path syntax can't be that >> bad. User's never have to see it. Perhaps I am missing something that >> complicates this? > >Yes, you are missing something. > >As soon as you define a path syntax in IMAP, you no longer have a general >purpose protocol. You are now stuck with that syntax. If it is >unimplementable, inappropriate, or inadequate, on a particular operating >system, you have just declared that IMAP can not be used on that operating >system. > >Yes, by all means, define a canonical path syntax -- but not in IMAP. This is >a layering violation. I don't understand how onw could define a path syntax that would prohibit IMAP from being implementable on some operating systems. Have you ever seen an NFS server on an IBM mainframe (mapping MVS dataset names to Unix style paths)? If you don't define the path syntax in IMAP, where do you define it? -- Jamey Maze Martin Marietta Energy Systems, Inc. Oak Ridge National Laboratory P.O. Box 2008 (615)574-6355 78 Mitchell Road FAX: (615)-576-4992 Oak Ridge, TN 37831-6283 From owner-imap@cac.washington.edu Sun Jul 25 23:59:50 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24759; Sun, 25 Jul 93 23:59:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27468; Sun, 25 Jul 93 23:59:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27462; Sun, 25 Jul 93 23:59:32 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA16192; Sun, 25 Jul 93 23:59:27 -0700 Date: Sun, 25 Jul 1993 23:04:12 -0700 (PDT) From: Mark Crispin Subject: Re: Nested mailboxes To: Jamey Maze Cc: IMAP Interest List In-Reply-To: <9307260110.AA10714@stc06.CTD.ORNL.GOV> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Jamey Maze writes: > I don't understand how onw could define a path syntax that would prohibit > IMAP from being implementable on some operating systems. Have you ever seen > an NFS server on an IBM mainframe (mapping MVS dataset names to Unix style > paths)? Consider the UNIX model, in which there is only one root, and the model used on certain other operating systems (e.g. DOS, Mac, VMS, TOPS-20), in which there are multiple roots. Now, describe a path syntax that is valid for both models and which translates unambiguously and reversibly to the internal path syntax. Be sure to consider such issues as: 1) How does the current working directory impact references to a different root? Is the current root part of the cwd? Is a separate cwd maintained for each root? 2) What is/are the path delimiter(s), and how are these escaped? 3) How is defaulting handled? > If you don't define the path syntax in IMAP, where do you define it? If you don't define the path syntax in FTP, where do you define it? FTP is much more concerned with path names, yet defines no special syntax. The answer is that the entire concept of ``path syntax definition in IMAP'' is an oxymoron. IMAP does not deal in paths; it deals with a single name string with no specific syntax. Any hierarchy is in the eyes of the beholder; so it's a client issue to present it. From owner-imap@cac.washington.edu Mon Jul 26 01:50:04 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02093; Mon, 26 Jul 93 01:50:04 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27959; Mon, 26 Jul 93 01:49:47 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27953; Mon, 26 Jul 93 01:49:46 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA16516; Mon, 26 Jul 93 01:49:41 -0700 Date: Mon, 26 Jul 1993 01:23:59 -0700 (PDT) From: Mark Crispin Subject: re: FYI: Cyrus IMAP server design To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 21 Jul 1993 23:15:16 -0400 (EDT), John Gardiner Myers wrote: > Note that this implementation seeks to address an almost completely > different set of administrative concerns than the c-client IMAP > server. Plus it deals with the ``two independent interoperable implementations'' requirement for the standardizations process. Curiously, the Cyrus design is very similar to what I originally envisioned an IMAP server to look like! Suggestion for implementaton strategy: start with a c-client driver for Cyrus format mail first, since many of the features you list are really folder format artifacts rather than server specifics. Then you can start swapping out the other stuff at leisure. > Folder names match in a case-insensitive manner. Suggestion: consider the convention of allowing a folder to be created with mixed case characters, but do case-independent matching. For example, if I create a folder named ``Random'' I shouldn't be allowed to create a folder named ``random'' since that's a conflicting name. But I should see the name ``Random'' from FIND as I originally cased it. > Non-ASCII characters, shell metacharacters, and "/" are not permitted > in folder names. A folder name may not start or end with a "." > character, nor may it contain two "." characters in a row. I don't like this it implies UNIX semantics. If . is going to be the hierarchy delimiter, restrict it and nothing else. Also, consider non-English languages; it should be perfectly reasonable to use 8-bit and multi-byte characters. At the very least, define it to be included but make it a temporary implementation restriction. > The CHECK command will scan for flags that have changed since the > client was notified about them, issuing unsolicited FETCH replies to > update the client's state. Yes, this is a very desirable feature, and the c-client based server will also have this capability in the forseeable future (it's on my whiteboard rather than buried in notes), at least for Tenex format. > The EXPUNGE operation is allowed at any time, even when other server > processes are reading the folder. Note that this is possible with the c-client based server, although no current c-client drivers (except perhaps LGL's Carmel driver) permit it. > To avoid sending unsolicited > EXPUNGE replies at inopportune times, servers keep an open file handle > on the folder header files that are replaced by the EXPUNGE operation. > The server may send unsolicited EXPUNGE commands during the execution > of the APPEND, CHECK, and EXPUNGE commands. I don't see why this is necessary. Any client that is surprised by an unsolicited EXPUNGE at any time is broken. > The > Cyrus server implementation is given the freedom to store folders on > disk in a format best suited to its needs. I'm turning green with envy... No worries about /bin/mail compatibility! > The filenames of the message files are sequentially-assigned > internal numbers, with a period appended. Once a message is appended > to a folder, its internal sequence number never changes. Recommendations: make the message numbers be unique on a system-wide basis, instead of unique per folder. That way you can make a lot of simplifying assumptions. Also, it should be possible for the same message to exist in multiple folders (via UNIX hard links but the user won't see that). This implies that the number space has to be large enough. I wonder if 2^32 is; probably it'd be safer to take the long view and make it 2^64. > Whether to allow anonymous logins Also a special ACL for anonymous. From owner-imap@cac.washington.edu Mon Jul 26 11:03:16 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09996; Mon, 26 Jul 93 11:03:16 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10428; Mon, 26 Jul 93 11:02:53 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10422; Mon, 26 Jul 93 11:02:51 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.4/8.4) id OAA00681; Mon, 26 Jul 1993 14:02:49 -0400 Received: via switchmail; Mon, 26 Jul 1993 14:02:48 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 26 Jul 1993 14:01:32 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 26 Jul 1993 14:01:29 -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, 26 Jul 1993 14:01:26 -0400 (EDT) Message-Id: Date: Mon, 26 Jul 1993 14:01:26 -0400 (EDT) From: John Gardiner Myers To: IMAP Interest List Subject: Re: FYI: Cyrus IMAP server design In-Reply-To: References: Beak: is Not Mark Crispin writes: > Suggestion for implementaton strategy: start with a c-client driver for Cyrus > format mail first, since many of the features you list are really folder > format artifacts rather than server specifics. Then you can start swapping > out the other stuff at leisure. I'm not sure what I'd gain by this approach. IMAP protocol handling isn't such a big deal and I can steal what I want from c-client's RFC-822 parsing code either way. > Suggestion: consider the convention of allowing a folder to be created with > mixed case characters, but do case-independent matching. This is what I intended to do. I'll clarify it in the text. > > Non-ASCII characters, shell metacharacters, and "/" are not permitted > > in folder names. A folder name may not start or end with a "." > > character, nor may it contain two "." characters in a row. > > I don't like this it implies UNIX semantics. If . is going to be the > hierarchy delimiter, restrict it and nothing else. To permit "/", I would have to map it to something else to get the internal folder pathname. I can't map it to "." because I use "." to keep from having conflicts between the names of files in a folder and the names of the directories for subfolders. > Also, consider non-English languages; it should be perfectly > reasonable to use 8-bit and multi-byte characters. The "no non-ascii or shell metacharacter" rule is really a site policy restriction. I should eventually make the folder name restrictions site-policy configurable. 8-bit characters are a problem on most unix filesystems--I'd have to map them. > > The server may send unsolicited EXPUNGE commands during the execution > > of the APPEND, CHECK, and EXPUNGE commands. > > I don't see why this is necessary. Any client that is surprised by an > unsolicited EXPUNGE at any time is broken. Consider the following exchange: >>> tag FETCH 7 FLAGS <<< * 3 EXPUNGE <<< * 7 FETCH (FLAGS (/SEEN)) <<< tag OK Fetch complete I'm sure most any client would be suprised that it didn't get what it asked for. (For those who say the server should have given a "* 6 FETCH" reply, I mention the possibility the server issued the EXPUNGE reply before it saw the client's FETCH request.) Even with the currently planned limitations on when the Cyrus server sends an EXPUNGE reply, this could be a problem if a client issues a FETCH command without waiting for the reply from a previous CHECK command. >>> first CHECK >>> second FETCH 7 FLAGS <<< * 3 EXPUNGE <<< * 10 EXISTS <<< * 0 RECENT <<< first OK Check complete <<< * 7 FETCH (FLAGS (/SEEN)) <<< second OK Fetch complete > Recommendations: make the message numbers be unique on a system-wide basis, > instead of unique per folder. That way you can make a lot of simplifying > assumptions. Also, it should be possible for the same message to exist in > multiple folders (via UNIX hard links but the user won't see that). Again, I'm not sure what this buys me. It adds the cost of having to lock a global file in order to assign a new number. The hard-link trick is a good suggestion. I can do it even with different message numbers across folders. > Also a special ACL for anonymous. I believe the ACL facility described in IMSP is powerful enough to handle anonymous. The ACL interpreter will be in a module with a defined interface and will be replacable. _.John From owner-imap@cac.washington.edu Mon Jul 26 12:00:43 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14804; Mon, 26 Jul 93 12:00:43 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01630; Mon, 26 Jul 93 12:00:22 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01624; Mon, 26 Jul 93 12:00:20 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA16872; Mon, 26 Jul 93 12:00:13 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA11855; Mon, 26 Jul 93 12:00:03 -0700 Date: Mon, 26 Jul 1993 11:28:54 -0700 (PDT) From: Mark Crispin Subject: Re: FYI: Cyrus IMAP server design To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi John - > I'm not sure what I'd gain by this approach. IMAP protocol handling > isn't such a big deal and I can steal what I want from c-client's > RFC-822 parsing code either way. It seemed to me that a lot of what you are going to do is folder format specifics, and that you might have something quicker if you weren't distracted by other issues too quickly. But, it's your choice. I agree that IMAP protocol handling isn't much -- I wrote imapd in about 2 days -- compared to the much more complex issues of message parsing and folder handling. > To permit "/", I would have to map it to something else to get the > internal folder pathname. I can't map it to "." because I use "." to > keep from having conflicts between the names of files in a folder and > the names of the directories for subfolders. Yes. But this is an internal implementation detail, and I think you're going to need a mapping mechanism anyway. > The "no non-ascii or shell metacharacter" rule is really a site policy > restriction. I should eventually make the folder name restrictions > site-policy configurable. 8-bit characters are a problem on most unix > filesystems--I'd have to map them. It's probably alright to permit 8-bit characters only if the local filesystem handles them, and then only in the local character set. In other words, you can't have a Japanese filename in Sweden, or a Swedish filename in Japan (although Japanese e-mail is 7-bit ISO-2022-JP, Japanese filenames are 8-bit EUC). So, at CMU, you probably wouldn't have 8-bit characters on a campus-wide facility, but maybe the Japanese studies department machine might. > Consider the following exchange: > >>> tag FETCH 7 FLAGS > <<< * 3 EXPUNGE > <<< * 7 FETCH (FLAGS (/SEEN)) > <<< tag OK Fetch complete This sounds like a bug in the IMAP specification; obviously this is an ambiguous sequence. Perhaps it needs to be made explicit that you can not give unsolicited EXPUNGE results until after completing the current request; that is, the proper order is: tag FETCH 7 FLAGS * 7 FETCH (FLAGS (/SEEN)) * 3 EXPUNGE tag OK Fetch complete There's a more serious matter, which is that this makes it unfeasible to do streamed FETCH commands; that is, doing multiple FETCH commands without waiting for the results. I remember that Stanford was really big on streaming commands, even though flow control greatly limits its usefullness. I don't know if it was ever actually implemented in any clients. Perhaps the whole streaming concept should be just tossed? If you really think streaming is important IMAP should be UDP-based instead of TCP-based. > > make the message numbers be unique on a system-wide basis, > > instead of unique per folder. > Again, I'm not sure what this buys me. It adds the cost of having to > lock a global file in order to assign a new number. I don't understand why a global file needs to be locked, as long as foo++ is an atomic operation and there is only one instance of foo in the system. You could do this by implementing a system call saying ``give me a foo''. Some flavors of UNIX already have such an operation, I think. The reason for doing this is that then you'll have a UID that is valid for all instances of the same message. That'd be rather neat for disconnected use operation, since then you have UID uniqueness across multiple folders instead of just within a single folder, and you can build a copy of the linked model on the client. It also makes cross-post handling trivial, if message 12345 is read, then it is read, and you don't have to deal with cross references to eliminate duplicates (I am *not* looking forward to writing xref and threading code in the c-client based server). I guess the bottom line is, there's a chance to do it at this point with fairly small cost; at worst, it will turn out to be unnecessary. The cost of not doing it is losing a characteristic that may turn out to be important. I can't think of any advantages of not having the message UIDs be globally unique, other than perhaps a space size issue. But 2^32 should be enough for today's needs, and moving to 2^64 should not be rocket science should it ever happen that a single repository ends up having processed more than 2^32 messages!!! By the time that happens, we can hope that ANSI will give us ``double long'' in C like I've been wanting for years.... -- Mark -- From owner-imap@cac.washington.edu Mon Jul 26 12:03:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15144; Mon, 26 Jul 93 12:03:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12768; Mon, 26 Jul 93 12:03:10 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12762; Mon, 26 Jul 93 12:03:09 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA19454; Mon, 26 Jul 93 12:03:08 -0700 Date: Mon, 26 Jul 1993 11:51:12 -0700 (PDT) From: Laurence Lundblade Subject: Re: Nested mailboxes To: Mark Crispin Cc: Jamey Maze , IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mark, I think you're comments are based on idea that the IMAP name space (or at least the proposed standard for a hierarchical name space) has to be able map to all possible OS file name spaces. This is clearly an intractable problem as you've made quite clear. I think the NetNews hierarchy is an example of a standard where a hierarchy was clearly defined and implementors have been free to map it (or not) to the file system as they see fit. This would be the only way to go about this in IMAP. ...not seriously advocating a standard for hierarchy, as I stated before, just thought this was important to make clear and to say that this in and of itself is not sufficient to say that a standard hierarchy is bad thing. If the requirement is that the hierarchy must map to file space then this argument does make hierarchy a bad thing. LL On 25 Jul 1993, Mark Crispin wrote: > Jamey Maze writes: > > I don't understand how onw could define a path syntax that would prohibit > > IMAP from being implementable on some operating systems. Have you ever seen > > an NFS server on an IBM mainframe (mapping MVS dataset names to Unix style > > paths)? > > Consider the UNIX model, in which there is only one root, and the model used > on certain other operating systems (e.g. DOS, Mac, VMS, TOPS-20), in which > there are multiple roots. Now, describe a path syntax that is valid for both > models and which translates unambiguously and reversibly to the internal path > syntax. Be sure to consider such issues as: > 1) How does the current working directory impact references to a different > root? Is the current root part of the cwd? Is a separate cwd maintained > for each root? > 2) What is/are the path delimiter(s), and how are these escaped? > 3) How is defaulting handled? > > > If you don't define the path syntax in IMAP, where do you define it? > > If you don't define the path syntax in FTP, where do you define it? FTP is > much more concerned with path names, yet defines no special syntax. > > The answer is that the entire concept of ``path syntax definition in IMAP'' is > an oxymoron. IMAP does not deal in paths; it deals with a single name string > with no specific syntax. Any hierarchy is in the eyes of the beholder; so > it's a client issue to present it. > > > From owner-imap@cac.washington.edu Mon Jul 26 13:10:18 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20304; Mon, 26 Jul 93 13:10:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15035; Mon, 26 Jul 93 13:09:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15027; Mon, 26 Jul 93 13:09:52 -0700 Received: from Mac-Treister.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA07472; Mon, 26 Jul 93 13:09:50 PDT Date: Mon, 26 Jul 93 13:09:40 -0800 From: Adam Treister To: imap@cac.washington.edu Subject: Freq. of Multi-Folder users Message-Id: Content-Type: TEXT/plain; charset=US-ASCII Can Mailstrom make a distinction of "power users" as those people who access multiple mail folders, where "novice users" just access their inbox? I'm adding a Short Menus / Full Menus option, and if the above statement is true, the short menus can exclude the Move / Copy commands, and replace Open Mailbox (which has scrolling lists, paths and hostnames) with a parameterless Open Inbox command. It doesn't make the menus much shorter, but does hide a fair amount of complexity from the beginner. (or can I just send the sniveling wimps explanatory messages in raw MIME and base-64 :) Adam -------------------------------------------------- Adam Treister Polya Hall 205, Stanford CA 94305 - (415) 725-9449 -------------------------------------------------- From owner-imap@cac.washington.edu Mon Jul 26 13:26:01 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21418; Mon, 26 Jul 93 13:26:01 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15683; Mon, 26 Jul 93 13:25:46 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15675; Mon, 26 Jul 93 13:25:44 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.4/8.4) id QAA00805; Mon, 26 Jul 1993 16:25:41 -0400 Received: via switchmail; Mon, 26 Jul 1993 16:25:40 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 26 Jul 1993 16:24:19 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 26 Jul 1993 16:24:15 -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, 26 Jul 1993 16:24:12 -0400 (EDT) Message-Id: Date: Mon, 26 Jul 1993 16:24:12 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: IMSP vs ECSMail address books In-Reply-To: References: Beak: is Not One of the major differences between the IMSP and ECSmail view of address books is that IMSP puts no limit on the number of fields or the length of field values. Clients should not impose their own limits on top of IMSP address books. As Wallace mentioned, we view distribution lists as primarily a delivery service issue. You want to be able to name them through the delivery service. The delivery-service naming syntax will most likely be ugly, however, system-wide aliases can make them more user-friendly. Distribution lists have at least the following attributes: * a list of delivery addresses * a maintainer addres, to put in the envelope return address * an optional delivery "precedence" * an ACL permission (p) contolling who may deliver to the list We tend to see distribution lists as lists of e-mail addresses (CRLF-separated in the "e-mail" field), not as a list of address book entries, though you could do it either way by defining a "members" field with CRLF-separated alias names. I find it interesting that ECSMail has separate fields for "common_name" and "alias". Every other mailer we have seen (except our own AMS) indexes address book entries by name only. As a result, we are considering dropping the "alias must be ATOM" restriction and allowing clients to use full names as aliases. To be addressable from the delivery system, however, an alias would probably have to conform to the syntax for an RFC-822 local-part. Could you describe how your UI handles separate aliases and common_names? -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Mon Jul 26 13:48:12 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23190; Mon, 26 Jul 93 13:48:12 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16611; Mon, 26 Jul 93 13:47:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16605; Mon, 26 Jul 93 13:47:48 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.4/8.4) id QAA00811; Mon, 26 Jul 1993 16:47:45 -0400 Received: via switchmail; Mon, 26 Jul 1993 16:47:44 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 26 Jul 1993 16:46:41 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 26 Jul 1993 16:46:35 -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, 26 Jul 1993 16:46:31 -0400 (EDT) Message-Id: Date: Mon, 26 Jul 1993 16:46:31 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: unsolicited EXPUNGE In-Reply-To: References: Beak: is Not Mark Crispin writes: > This sounds like a bug in the IMAP specification; obviously this is an > ambiguous sequence. It's certainly a weakness in the IMAP specification. If, on the other hand, I had to implement CHECK and APPEND without the possibility of giving unsolicited EXPUNGE replies, I'd probably go insane. Oh, add COPY to that list. Then again, maybe APPEND and COPY don't have to give EXISTS notification when appending to the currently-open folder. > Perhaps it needs to be made explicit that you can not > give unsolicited EXPUNGE results until after completing the current request; > that is, the proper order is: I think the proper wording is something like "must be done during some request, after giving any responses that refer to specific message numbers, but before giving the solicited response. I think a better restriction should be "during some request other than FETCH, PARTIAL, or STORE." SEARCH may want to be added to the list. > Perhaps the whole streaming concept should be just tossed? If you > really think streaming is important IMAP should be UDP-based instead > of TCP-based. I don't think we should toss streaming. Clients (and/or servers) that are smart enough to do streaming can be made smart enough to deal with flow control properly--select() is very handy for this. We just have to nail down unsolicited EXPUNGE replies well enough for them to have a chance at making streaming effective. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Jul 27 15:14:19 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10028; Tue, 27 Jul 93 15:14:19 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10934; Tue, 27 Jul 93 15:13:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10928; Tue, 27 Jul 93 15:13:46 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA21809; Tue, 27 Jul 93 15:13:42 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA19347; Tue, 27 Jul 93 15:10:41 PDT Received: from ford by air.airco.co.jp (4.1/6.4J.6) id AA26004; Tue, 27 Jul 93 20:24:44 JST Return-Path: Message-Id: <9307271124.AA26004@air.airco.co.jp> Date: Tue, 27 Jul 1993 20:19:30 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Re: Nested mailboxes To: Mark Crispin Cc: IMAP Interest List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 25 Jul 1993 23:04:12 -0700 (PDT) Mark Crispin wrote... > The answer is that the entire concept of ``path syntax definition in IMAP'' is > an oxymoron. IMAP does not deal in paths; it deals with a single name string > with no specific syntax. Any hierarchy is in the eyes of the beholder; so > it's a client issue to present it. > I agree that a ``path syntax definition'' doesn't belong in the IMAP protocol, necessarily. But it is more than just a client's responsibility to present. It's also a server's responsibility to implement. What we want is a standard representation defined (possibly in the protocol itself??). Having a ``standard'' hierarchical representation leaves the ``standard'' to local representation conversions as the responsibility of the server. I don't believe that such a requirement would make a server unimplementable on a given system. I have a few questions: o Why should a client have to be aware of system specific details such as file naming conventions of a particular server's host? o What does a folder name have to do with a filename anyway? o IF each server is different, how do I then keep track of which server uses which methods? Suppose there are thousands of servers each different however slightly. o How is a client that uses '/' as a folder path component separator going to interoperate correctly with a server that uses '.' and doesn't allow '/' in names? o If we don't have a folder name standard, how is a server going to tell the client about its naming conventions? o Suppose a server decides to limit the depth of a hierarchy, how do I find out about that? Probably what we need is a document which defines/recommends a name space for mailboxes and bboards. I have no preference for the punctuation used. But I don't want to have to implement 15 different folder name syntaxes and invent code to GUESS which one to use for each server to which I connect. Here are some possible folder hierarchy notation schemes: folder->subfolder->subsubfolder C pointers [folder.subfolder]subsubfolder.; VMS [folder][subfolder][subsubfolder] Neat little boxes (folder(subfolder(subsubfolder))) Lisp folder(subfolder(subsubfolder)) Functional folder/subfolder/subsubfolder "UNIX" folder.subfolder.subsubfolder News ((subsubfolder)subfolder)folder Post Functional I could go on for a long time. Each is equally valid though maybe not optimal; but, because IMAP says nothing about hierarchical folder names, each is possible. It doesn't take long before software can't figure out which method to use. What we are trying to do is represent a hierarchy, which punctuation is used is irrelevant. All I want is an agreement on the notation. Is that too much to ask for? Remember that we are eventually going to be fielding products to customers and that will mean explaining to them why they can't connect to server-XYZ (which you have no access to or knowledge of) and do this that or some other thingy. I would rather have a standard notation defined somewhere so that bizarre hierarchical representations (like some of the aforementioned) are LESS likely. My client couldn't connect to the Cyrus IMAP server and give me a hierarchical representation. It would give me a flat list and I would only be able to create toplevel folders; however, since dots are allowed in folder names the results of create could get interesting. makr PS. As this topic seems to be getting pretty hot, I hope I haven't offended anyone with my o(pi)nions. :-) From owner-imap@cac.washington.edu Tue Jul 27 15:14:18 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10023; Tue, 27 Jul 93 15:14:18 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10942; Tue, 27 Jul 93 15:13:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10936; Tue, 27 Jul 93 15:13:52 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA21815; Tue, 27 Jul 93 15:13:47 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA19353; Tue, 27 Jul 93 15:10:43 PDT Received: from ford by air.airco.co.jp (4.1/6.4J.6) id AA26551; Tue, 27 Jul 93 20:31:45 JST Return-Path: Message-Id: <9307271131.AA26551@air.airco.co.jp> Date: Tue, 27 Jul 1993 20:26:31 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Question about create, delete and rename? To: IMAP@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What kind of name does create, delete and rename take? A fullname with the complete path or relative to the current mailbox? makr From owner-imap@cac.washington.edu Tue Jul 27 18:18:53 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23879; Tue, 27 Jul 93 18:18:53 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12049; Tue, 27 Jul 93 18:18:39 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12043; Tue, 27 Jul 93 18:18:37 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.5/8.5) id VAA00633; Tue, 27 Jul 1993 21:18:35 -0400 Received: via switchmail; Tue, 27 Jul 1993 21:18:34 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 27 Jul 1993 21:17:18 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 27 Jul 1993 21:17:15 -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, 27 Jul 1993 21:17:13 -0400 (EDT) Message-Id: <0gJRCNW00WBwMwLXh0@andrew.cmu.edu> Date: Tue, 27 Jul 1993 21:17:13 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Question about create, delete and rename? In-Reply-To: <9307271131.AA26551@air.airco.co.jp> References: <9307271131.AA26551@air.airco.co.jp> Beak: Is Create, delete, and rename take mailbox names. While RFC 1176 states that the interpretation of mailbox names other than INBOX is implementation defined (actually the wording is "The format of other mailbox names is operating system dependent"), I believe the intent is to have the interpretation be independent of any currently selected mailbox or bboard. At least, no IMAP server I am aware of takes any currently selected mailbox or bboard into account when interpreting a mailbox name. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Jul 27 19:33:04 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28204; Tue, 27 Jul 93 19:33:04 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13447; Tue, 27 Jul 93 19:32:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13441; Tue, 27 Jul 93 19:32:46 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.5/8.5) id WAA00656; Tue, 27 Jul 1993 22:32:43 -0400 Received: via switchmail; Tue, 27 Jul 1993 22:32:43 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 27 Jul 1993 22:32:00 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 27 Jul 1993 22:31:54 -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, 27 Jul 1993 22:31:53 -0400 (EDT) Message-Id: <8gJSING00WBwMwLYFo@andrew.cmu.edu> Date: Tue, 27 Jul 1993 22:31:53 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Nested mailboxes In-Reply-To: <9307271124.AA26004@air.airco.co.jp> References: <9307271124.AA26004@air.airco.co.jp> Beak: Is Mark Keasling writes: > I have a few questions: > o Why should a client have to be aware of system specific details > such as file naming conventions of a particular server's host? The client implementation doesn't necessarily have to be aware of them, but the user necessarily has to know about the particular server's folder naming conventions. Details like the character set allowed in folder names will vary from site to site. > o What does a folder name have to do with a filename anyway? In an abstract sense, nothing. In a practical sense, sites frequently have good reasons to export folder names which correspond to filenames. If a folder can be accessed through multiple protocols (FTP and IMAP, for example), it can be advantageous to have the name of the folder be the same in both access mechanisms. > o IF each server is different, how do I then keep track of which > server uses which methods? Suppose there are thousands of servers > each different however slightly. Some differences you can make configurable. Other differences will boil down to "try it and the server says NO". > o How is a client that uses '/' as a folder path component separator > going to interoperate correctly with a server that uses '.' and > doesn't allow '/' in names? All folders will appear as top level names and the user will only be able to create top level folders. (Where "top level" is in the eyes of the client implementation.) > o If we don't have a folder name standard, how is a server going to > tell the client about its naming conventions? I'm not convinced the server needs to tell the client about its naming conventions. > o Suppose a server decides to limit the depth of a hierarchy, > how do I find out about that? The client tries to create a folder and the server says NO. Suppose a server decides to limit something entirely different, such as the total number of mailboxes, the allowable character set, the length of a mailbox name, etc. How many types of limits is your client going to know about? > What we are trying to do is represent a hierarchy, which punctuation is > used is irrelevant. All I want is an agreement on the notation. > Is that too much to ask for? With the exception of "VMS" (and the unmentioned "TWENEX", of which "VMS" is a variant), all of the notations I suspect anyone would actually use each have a single path delimiter character. I think an agreement on a specific path delimiter character is too much to ask for. At CMU, we are for a number of reasons quite solidly behind using "." as the delimiter character. We have for a number of years had netnews newsgroups appear in our bboard namespace with non-netnews names ("comp.lang.c" appears as "netnews.comp.lang.c") and the resulting user confusion convinces us that we want them to show up in IMAP as their "native" netnews names. Our existing mail system presents hierarchical mailbox names with a path delimiter of "." and our users are quite accustomed to it. Some of our users desire to have "private bboards" and we envision the possiblity of allowing users to make mailboxes visible to others in the bboard namespace. I'm sure other people are quite solidly behind using "/" for equally justifiable reasons. I believe any attempt to settle on a single standard path delimiter is doomed to turn into a religious war. > My client couldn't connect to the Cyrus IMAP server and give me a hierarchical > representation. It would give me a flat list and I would only be able to > create toplevel folders; however, since dots are allowed in folder names the > results of create could get interesting. With the Cyrus IMAP server, you can create the mailbox "foo.bar.baz" even though the mailboxes "foo" and "foo.bar" don't exist. You just can't create folder names that start or end with "." characters or have two "." characters in a row. > PS. As this topic seems to be getting pretty hot, I hope I haven't offended > anyone with my o(pi)nions. :-) No offense taken, I can certainly understand where you're coming from. Let me suggest a strategy: Instead of having your client recognize a single path delimiter, allow it to use a possibly-configurable set of path delimiters. By default, the set should contain both "." and "/". I'd have to know what kind of UI you have for create/rename before I can suggest a strategy for them. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Wed Jul 28 12:48:50 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09281; Wed, 28 Jul 93 12:48:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18217; Wed, 28 Jul 93 12:48:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18211; Wed, 28 Jul 93 12:48:28 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA19732; Wed, 28 Jul 93 12:47:59 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA20319; Wed, 28 Jul 93 12:47:47 -0700 Date: Wed, 28 Jul 1993 12:23:09 -0700 (PDT) From: Mark Crispin Subject: RFC-1176 to Prototype Status? To: IMAP Interest List Cc: John C Klensin , braden@ISI.EDU Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have spoken with Bob Braden and John Klensin about the possibility of advancing RFC-1176 to Prototype (from Experimental) status. This is a side- step, because in a few weeks I will be presenting to the WG a draft of a new document to replace RFC-1176. Following WG review, this new document will be submitted as a Proposed Standard. [I'm hard at work on it now...] A document in Prototype status is not in standards track, but it is indicated as something that is more than an ``experiment'' -- that is, that there are stable implementations. Prototype status is a new class of status, introduced to separate ``experiments'' from ``production work not yet in standards track.'' I just learned of the existance of Prototype status today. I believe that labelling RFC-1176 as a Prototype reflects the status quo, and would be a useful exercise. All known IMAP software is at least up to RFC- 1176 compliance. This doesn't address the IMAP2bis extensions, but this is alright. Not all IMAP implementations have IMAP2bis extensions (they are, after all, technically unpublished), and the Proposed Standard will take care of blessing IMAP2bis anyway. Why do it: 1) It labels RFC-1176, and not RFC-1203, as the path of IMAP work. 2) It labels RFC-1176 as a prototype for the eventual standard. 3) It gives distributors of commercial software that uses IMAP something more than just ``an experiment'' to base their software. 4) It represents the status quo. RFC-1176 is in production use at a number of sites. 5) It provides a background for the work of the IMAP WG. Why not do it: 1) With a Proposed Standard (hopefully) only weeks away it isn't worth the bother. 2) ??? My answer to the ``why bother'' question is essentially the comments under ``why do it''. There's a benefit gained, at (hopefully) minimal cost. I would like to hear if there are any other objections to doing this. If there's only positive comments (or dead silence), we'll ask the IESG to consider doing this for us. Terry Gray will have to make the actual request since he's the WG chair, but he's on vacation now, so I'm just trying to get some groundwork done. -- Mark -- From owner-imap@cac.washington.edu Wed Jul 28 13:46:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13777; Wed, 28 Jul 93 13:46:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18205; Wed, 28 Jul 93 13:46:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from THOR.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18199; Wed, 28 Jul 93 13:46:29 -0700 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H121MKX58W984NNW@INNOSOFT.COM>; Wed, 28 Jul 1993 13:46:07 PST Date: Wed, 28 Jul 1993 13:43:32 -0800 (PST) From: Ned Freed Subject: Re: RFC-1176 to Prototype Status? In-Reply-To: Your message dated "Wed, 28 Jul 1993 12:23:09 -0700 (PDT)" To: Mark Crispin Cc: IMAP Interest List , John C Klensin , braden@ISI.EDU Message-Id: <01H12THDCU06984NNW@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT > I believe that labelling RFC-1176 as a Prototype reflects the status quo, and > would be a useful exercise. All known IMAP software is at least up to RFC- > 1176 compliance. This doesn't address the IMAP2bis extensions, but this is > alright. Not all IMAP implementations have IMAP2bis extensions (they are, > after all, technically unpublished), and the Proposed Standard will take care > of blessing IMAP2bis anyway. I think this is a very good idea. A lot of people get confused by RFC1203. You might also want to consider publication of the IMAPbis document as an Internet Draft if it turns out integrating the documents is taking some time. Ned From owner-imap@cac.washington.edu Wed Jul 28 22:38:09 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20124; Wed, 28 Jul 93 22:38:09 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21660; Wed, 28 Jul 93 22:37:45 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21654; Wed, 28 Jul 93 22:37:43 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA07752; Wed, 28 Jul 93 22:37:36 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA25181; Wed, 28 Jul 93 22:12:29 PDT Received: from ford by air.airco.co.jp (4.1/6.4J.6) id AA04271; Thu, 29 Jul 93 10:57:48 JST Return-Path: Message-Id: <9307290157.AA04271@air.airco.co.jp> Date: Thu, 29 Jul 1993 10:52:24 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Re: Question about create, delete and rename? To: John Gardiner Myers Cc: IMAP@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 27 Jul 1993 21:17:13 -0400 (EDT) John Gardiner Myers wrote... > Create, delete, and rename take mailbox names. While RFC 1176 states > that the interpretation of mailbox names other than INBOX is > implementation defined (actually the wording is "The format of other > mailbox names is operating system dependent"), I believe the intent is > to have the interpretation be independent of any currently selected > mailbox or bboard. > > At least, no IMAP server I am aware of takes any currently selected > mailbox or bboard into account when interpreting a mailbox name. > > -- > _.John G. Myers Internet: jgm+@CMU.EDU > LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up > It was my understanding that the complete name was used. I just wanted clarification. However, phrases like "implementation defined" and "operating system dependent" are going to throw one big monkey wrench into everyone's plans for and expectations of interoperability between servers and clients from different vendors. makr From owner-imap@cac.washington.edu Thu Jul 29 01:31:17 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00980; Thu, 29 Jul 93 01:31:17 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22426; Thu, 29 Jul 93 01:30:55 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22420; Thu, 29 Jul 93 01:30:53 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA20427; Thu, 29 Jul 93 01:30:44 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA22642; Thu, 29 Jul 93 01:30:36 -0700 Date: Thu, 29 Jul 1993 01:28:58 -0700 (PDT) From: Mark Crispin Subject: Re: Question about create, delete and rename? To: Mark Keasling Cc: John Gardiner Myers , IMAP@cac.washington.edu In-Reply-To: <9307290157.AA04271@air.airco.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 29 Jul 1993 10:52:24 +0900 (JST), Mark Keasling wrote: > It was my understanding that the complete name was used. I just wanted > clarification. However, phrases like "implementation defined" > and "operating system dependent" are going to throw one big monkey wrench > into everyone's plans for and expectations of interoperability between > servers and clients from different vendors. Not at all. FTP implementations on systems with quite different file naming conventions interoperate quite well. What it means is that implementors are forced to think of interoperability concerns without being able to cheat based upon superficial naming characteristics. From owner-imap@cac.washington.edu Fri Jul 30 12:13:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23601; Fri, 30 Jul 93 12:13:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17214; Fri, 30 Jul 93 12:12:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17208; Fri, 30 Jul 93 12:12:27 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA04428; Fri, 30 Jul 93 12:12:22 -0700 Date: Fri, 30 Jul 1993 11:30:42 -0700 (PDT) From: Laurence Lundblade Subject: Re: Question about create, delete and rename? To: Mark Keasling Cc: John Gardiner Myers , IMAP@cac.washington.edu In-Reply-To: <9307290157.AA04271@air.airco.co.jp> Message-Id: References: <0909099009@09090909> <878787878@87878787> <3343434@2323232> <12121212@1212121> <9307290157.AA04271@air.airco.co.jp> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On 29 Jul 1993, Mark Keasling wrote: > It was my understanding that the complete name was used. I just wanted > clarification. However, phrases like "implementation defined" > and "operating system dependent" are going to throw one big monkey wrench > into everyone's plans for and expectations of interoperability between > servers and clients from different vendors. >=20 > makr >=20 This is my biggest concern about IMAP. I don't think I've made myself=20 entirely clear about it so I'll give it a stab here.=20 From=20reading 1176 on the way FIND works one get the impression that the= =20 name space is pretty simple. The client just issues a FIND * and gets=20 back a nice list of mailboxes suitable for presentation to the user. =20 I think this is a good idea and should be supported by all IMAP clients and all servers. All clients should have a notion of the a users main set of folders and all clients should present that list to the user for browsing. It's fine for clients and servers to have much larger name spaces and more complex ways to navigate the name space, but I believe this minimum level should be supported.=20 I think this was the original idea about the way it was supposed to work when we weren't trying to make mail, news and archives in other formats available all at the same time. Now it seems we're overtaxing the name space now and need to define a clear subset of current usage for the sake of interoperability. I don't know any client or server that actually operates this way(!) though I certainly haven't looked closely at all the clients out there.=20 Here's an example of a situation, in case I haven't been clear: Someone used to use ELM on a UNIX box and now he wants to try some IMAP clients. He's got mail from the last few years filed in 250 mailboxes. He's heard that the IMAP server supports the ELM format and knows the address of the machine that he's been doing mail on and which the IMAP server is on. He installs the client and finds that his 250 mailboxes aren't shown in the mailbox list. For one client he has to add them manually one by one, for another client he has to figure out that he has to configure something like "Mail/*" and then his mailbox list is full of extra path and host names. What I think should happen is for his list of 250 mailboxes to show up with no effort at all no matter what client or server he is using.= =20 This example isn't water tight. For example, there's a problem if some users on the UNIX box use ELM and other use MH, but the point here is more about how the system should work than implementation problems. That is, I don't think these problems are sufficient to abandon the idea of a minimal level of interoperability in the name space.=20 I think it's vital in this day and age that users have a nice easily obtainable on screen list to browse/manage/select their mailboxes. If there's disagreement over this point please let me know and I won't bring this up any more. Internet mail is going to face increased competition from LAN based e-mail that has these sort of features.=20 LL From owner-imap@cac.washington.edu Fri Jul 30 12:45:55 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25236; Fri, 30 Jul 93 12:45:55 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17811; Fri, 30 Jul 93 12:45:32 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17805; Fri, 30 Jul 93 12:45:31 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA05853; Fri, 30 Jul 93 12:45:30 -0700 Date: Fri, 30 Jul 1993 12:42:14 -0700 (PDT) From: Laurence Lundblade Subject: Re: Nested mailboxes To: Mark Crispin Cc: Jamey Maze , IMAP Interest List In-Reply-To: Message-Id: References: <0909099009@09090909> <878787878@87878787> <3343434@2323232> <12121212@1212121> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 25 Jul 1993, Mark Crispin wrote: > If you don't define the path syntax in FTP, where do you define it? FTP is > much more concerned with path names, yet defines no special syntax. > > The answer is that the entire concept of ``path syntax definition in IMAP'' is > an oxymoron. IMAP does not deal in paths; it deals with a single name string > with no specific syntax. Any hierarchy is in the eyes of the beholder; so > it's a client issue to present it. > Just to keepe things clear, FTP does deal with heirarchy though in a way independent of name syntax. It has the cd command along with the dir command. We don't have cd in IMAP so we're trying to make syntax do the job. LL From owner-imap@cac.washington.edu Fri Jul 30 15:46:15 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05096; Fri, 30 Jul 93 15:46:15 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03949; Fri, 30 Jul 93 15:45:55 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03943; Fri, 30 Jul 93 15:45:53 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA26011; Fri, 30 Jul 93 15:38:10 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA02155; Fri, 30 Jul 93 15:11:56 PDT Received: from ford by air.airco.co.jp (4.1/6.4J.6) id AA05486; Fri, 30 Jul 93 16:33:07 JST Return-Path: Message-Id: <9307300733.AA05486@air.airco.co.jp> Date: Fri, 30 Jul 1993 16:27:40 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Re: Question about create, delete and rename? To: Mark Crispin Cc: John Gardiner Myers , IMAP@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 29 Jul 1993 01:28:58 -0700 (PDT) Mark Crispin wrote... > On Thu, 29 Jul 1993 10:52:24 +0900 (JST), Mark Keasling wrote: > > It was my understanding that the complete name was used. I just wanted > > clarification. However, phrases like "implementation defined" > > and "operating system dependent" are going to throw one big monkey wrench > > into everyone's plans for and expectations of interoperability between > > servers and clients from different vendors. > > Not at all. > > FTP implementations on systems with quite different file naming conventions > interoperate quite well. > > What it means is that implementors are forced to think of interoperability > concerns without being able to cheat based upon superficial naming > characteristics. > In that case, the ability to set or determine file naming characteristics should be added to the protocol as it is in ftp. But, IMAP isn't FTP. FTP deals with "physical" entities specifically files. It also allows limited file manipulations. It leaves figuring out the filenaming conventions of the remote system up to the user. As a consequence there aren't (m)any FTP clients that provide high level user interfaces. IMAP clients shouldn't need to be concerned with the actual name of the system resource used to represent mail folders or messages on the host of an IMAP server. It should be able to provide to the user a consistent hierarchical folder structure (possibly graphically) regardless of the server currently in use. But since folder names are just strings whose semantics are defined by each and every IMAP server (differently), what is the point of a client even trying to automatically represent and manage a folder hierarchy? Why should servers support hierarchies, since clients won't be able to represent them reliably? If I make the claim of IMAP compatibility, I am concerned with how users are going to react when my client fails due to interoperability problems. The intended target of the product is NON-TECHNICAL users. People who do data entry, secretaries, company executives and even COBOL programmers. :-) They understand hierarchical structures in the form of filing cabinets and such like. Making these people aware of esoteric and obscure technical details, reduces the ease of use that we are trying to provide. These questions need to be answered: 1. Are hierarchies necessary? If yes then: a. Should hierarchy support be put directly into IMAP? b. How does a client insure a consistent hierarchical representation when connecting to a variety of different IMAP servers? 2. If hierarchies are not directly supported by IMAP, how does a client determine if the server supports a folder hierarchy and how that hierarchy if supported is represented? 3. Do you want to have to parse IMAP telemetry messages to try and figure out which IMAP server you've connected to so that you can attempt to determine what type of naming scheme to use? Do we really want to create the interoperablilty problems that already exist in things like RFC822 mail all over again and from scratch? Lets hear some answers. makr From owner-imap@cac.washington.edu Sat Jul 31 00:03:21 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21725; Sat, 31 Jul 93 00:03:21 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05762; Sat, 31 Jul 93 00:03:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05756; Sat, 31 Jul 93 00:03:01 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA22554; Sat, 31 Jul 93 00:02:54 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA01692; Sat, 31 Jul 93 00:02:47 -0700 Date: Fri, 30 Jul 1993 23:48:31 -0700 (PDT) From: Mark Crispin Subject: Re: Question about create, delete and rename? To: Mark Keasling Cc: IMAP Interest List In-Reply-To: <9307300733.AA05486@air.airco.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You have convinced me that servers should not have heirarchy at all. That is, heirarchy should be solely a client function. As soon as you put heirarchy in IMAP you open a huge can of worms. If IMAP presents anything other than a flat space, you end up having a server to IMAP heirarchy mapping problem. One you realize that heirarchy is, in fact, totally in the mind of the beholder then it belongs as a client function. Pine 3.85 does this in a very elegant fashion that allows much better user control over the mail views than the UNIX hierarchy does. Consider this. Is the list you get from foo* any less of a heirarchy than foo/*, particularly if you are using a client-based heirarchy manager that extracts the member name from the results? If so, then why do you need to deal with any server based hierarchy at all? The / is a UNIXism that you're reluctantly stuck with, perhaps only if you want to be since you're a UNIX wizard who knows what you're doing, but J.Random User won't bother with. The more I play with Pine 3.85's new ``collections'' facility, the more I am convinced it is the way to go. From owner-imap@cac.washington.edu Sat Jul 31 11:18:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10633; Sat, 31 Jul 93 11:18:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27773; Sat, 31 Jul 93 11:18:11 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27767; Sat, 31 Jul 93 11:18:10 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id OAA06972; Sat, 31 Jul 1993 14:18:06 -0400 Received: via switchmail; Sat, 31 Jul 1993 14:18:05 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 31 Jul 1993 14:17:55 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 31 Jul 1993 14:17:53 -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; Sat, 31 Jul 1993 14:17:50 -0400 (EDT) Message-Id: Date: Sat, 31 Jul 1993 14:17:50 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Question about create, delete and rename? In-Reply-To: References: <0909099009@09090909> <878787878@87878787> <3343434@2323232> <12121212@1212121> <9307290157.AA04271@air.airco.co.jp> Beak: Is I think we're confusing a number of issues. It is a fairly well understood concept in standardization that there is a point where standards stop and implementations begin. If a standard tries to over-specify certain things, it end up prohibiting implementations from doing useful things. At that point, implementors either are stifled in providing useful services or ignore the standard. The ANSI C standard, for example, has a number of things which are explicitly "implementation defined". This has not thrown any big monkey wrenches into portability of C sources. There are some forms of stupidity that simply cannot be legislated against. If someone were to implement an IMAP-ish server where the interpretation of mailbox names depended on the phase of the moon, I doubt they would be dissuaded by any sort of wording, be it in the IMAP standard or in some informal naming convention. What would dissuade them would be fear of constant harassment from their user base. And who's to say--maybe there is some possible use for phase-of-the-moon dependent mailbox name interpretation. Now, Laurence is right about how FIND is supposed to work. Depending on what one is trying to do, a client does a FIND MAILBOXES or FIND ALL.MAILBOXES command to get a nice list of mailboxes suitable for presentation to the user. The current c-client imapd has bugs and other deficiencies related to the FIND commands. For example, for FIND ALL.MAILBOXES the wildcards don't match the "/" character in the berkeley driver. Most of these bugs are in the process of being fixed, and some the deficiencies are in the process of being addressed. While this is being done, however, one should not confuse the specification with one of its imperfect implemntations. The problems Laurence mentions with ELM are mostly server configuration issues, made by the assumption that the user cares where and in in what format their mail is actually stored. These problems don't come up in the vaporware Cyrus IMAP server, where I've defined them out of existence. How many LAN based e-mail systems can read ELM format mailboxes? -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sat Jul 31 11:25:11 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10821; Sat, 31 Jul 93 11:25:11 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07994; Sat, 31 Jul 93 11:24:57 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07988; Sat, 31 Jul 93 11:24:55 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA22903; Sat, 31 Jul 93 11:24:49 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA03584; Sat, 31 Jul 93 11:24:41 -0700 Date: Sat, 31 Jul 1993 11:22:51 -0700 (PDT) From: Mark Crispin Subject: Re: Question about create, delete and rename? To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 31 Jul 1993 14:17:50 -0400 (EDT), John Gardiner Myers wrote: > The current c-client imapd has bugs and other deficiencies related to > the FIND commands. For example, for FIND ALL.MAILBOXES the wildcards > don't match the "/" character in the berkeley driver. Is this still true? If so, that is news to me. I thought this was all fixed to everyone's satisfaction a few weeks ago. > one should not confuse the specification with one of its imperfect > implemntations. Yes, even if the implementation is a reference implementation or the most widely deployed one. Sendmail is undeniably the most widely deployed implementation of RFC-822/SMTP, but it defines neither! From owner-imap@cac.washington.edu Sat Jul 31 11:43:52 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11332; Sat, 31 Jul 93 11:43:52 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27904; Sat, 31 Jul 93 11:43:39 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO6.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27898; Sat, 31 Jul 93 11:43:38 -0700 Received: from localhost (postman@localhost) by po6.andrew.cmu.edu (8.5/8.5) id OAA00531; Sat, 31 Jul 1993 14:43:35 -0400 Received: via switchmail; Sat, 31 Jul 1993 14:43:35 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 31 Jul 1993 14:43:21 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 31 Jul 1993 14:43:20 -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; Sat, 31 Jul 1993 14:43:18 -0400 (EDT) Message-Id: <0gKfp6_00WBw05VkVE@andrew.cmu.edu> Date: Sat, 31 Jul 1993 14:43:18 -0400 (EDT) From: John Gardiner Myers Subject: Re: Question about create, delete and rename? To: IMAP Interest List In-Reply-To: References: Beak: is Not Mark Crispin writes: > Is this still true? If so, that is news to me. I thought this was all fixed > to everyone's satisfaction a few weeks ago. Sorry, I am working from outdated knowledge. I don't keep completely up to date with c-client releases--re-integrating Kerberos and other local changes is such a pain. From owner-imap@cac.washington.edu Sat Jul 31 12:35:41 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12919; Sat, 31 Jul 93 12:35:41 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28243; Sat, 31 Jul 93 12:35:20 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28237; Sat, 31 Jul 93 12:35:18 -0700 Received: from localhost (postman@localhost) by andrew.cmu.edu (8.5/8.5) id PAA09255; Sat, 31 Jul 1993 15:35:12 -0400 Received: via switchmail; Sat, 31 Jul 1993 15:35:12 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 31 Jul 1993 15:35:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 31 Jul 1993 15:35: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; Sat, 31 Jul 1993 15:34:57 -0400 (EDT) Message-Id: Date: Sat, 31 Jul 1993 15:34:57 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: hierarchy/the FTP analogy In-Reply-To: References: <0909099009@09090909> <878787878@87878787> <3343434@2323232> <12121212@1212121> Beak: Is I think a lot of people are seeing a lot of red herrings in the FTP analogy. The CWD/CDUP/SMNT/PWD FTP commands are for client convenience. They are not necessary for or fundamental to FTP's support of hierarchy, except in that FTP presupposes the existence of "directories". Their existence does not invalidate the point of the analogy, which is that FTP manages to support hierarchy without defining a naming convention for it. The observation that FTP deals with "physical" entities, specifically files is outright wrong. There are a number of FTP servers which export entities with no direct correlation to the implementation's underlying filesystem. For example, the wuarchive ftp server exports virtual files which it will generate on the fly by running programs such as "tar" and "compress". I have seen a number of high-level interfaces to FTP. GNU Emacs has one, a GUI exists on the NeXT, and a filesystem driver exits on the NeXT. Mark Keasling writes: > But since folder names are just strings whose semantics are > defined by each and every IMAP server (differently), what is the point > of a client even trying to automatically represent and manage a folder > hierarchy? Why should servers support hierarchies, since clients won't > be able to represent them reliably? Because hierarchy exists in the eye of the beholder. > These questions need to be answered: > 1. Are hierarchies necessary? If yes then: Hierarchies are useful, if not always absolutely necessary. > a. Should hierarchy support be put directly into IMAP? No. It is unnecessary, engenders religious wars as to the syntax, and potentially prevents people from doing useful things. > b. How does a client insure a consistent hierarchical representation > when connecting to a variety of different IMAP servers? Through flexibility. I've already posted some suggestions on how to do this. > 2. If hierarchies are not directly supported by IMAP, how does a > client determine if the server supports a folder hierarchy and > how that hierarchy if supported is represented? The server's view of hierarchy is irrelevant. It doesn't really matter how the server interprets the names to get to some internal storage format. What does matter is what set of folder names the server will allow you to create. There are many more issues here than the server's interpretation of hierarchy--there are administrative site policies on such things as character set, total length, length of component, number of folders, access control on parts of the namespace, and who knows what. That problem effectively boils down to "try it and see if the server says OK"--there is no way to encode all possible namespace restrictions. > 3. Do you want to have to parse IMAP telemetry messages to try and figure > out which IMAP server you've connected to so that you can attempt to > determine what type of naming scheme to use? The view of the namespace is up to the user/client, not up to the server. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sat Jul 31 13:43:11 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14533; Sat, 31 Jul 93 13:43:11 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28513; Sat, 31 Jul 93 13:42:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from THOR.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28507; Sat, 31 Jul 93 13:42:46 -0700 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H14ISBPQUO984NNW@INNOSOFT.COM>; Sat, 31 Jul 1993 13:42:37 PST Date: Sat, 31 Jul 1993 13:34:44 -0800 (PST) From: Ned Freed Subject: Re: hierarchy/the FTP analogy In-Reply-To: Your message dated "Sat, 31 Jul 1993 15:34:57 -0400 (EDT)" To: John Gardiner Myers Cc: imap@cac.washington.edu Message-Id: <01H17091QSMC984NNW@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > I have seen a number of high-level interfaces to FTP. GNU Emacs has > one, a GUI exists on the NeXT, and a filesystem driver exits on the > NeXT. Perhaps the most important one in widespread use is Archie, which has to walk FTP directory hierarchies to gather its data. However, the fact that these things exist should never be construed to indicate that it is possible for FTP clients to deal with directory hierarchies in full generality. The unfortunate truth of the matter is that many of these systems assume semantics that goes far beyond the FTP specification, and therefore are incapable of dealing with FTP servers that aren't running on UNIX systems. As such, their supposed functionality is indeed something of a red herring. I really like idea of clients imposing their own structuring conventions on whatever the IMAP servers provide, as Pine does. Ned From owner-imap@cac.washington.edu Sun Aug 1 22:14:10 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04613; Sun, 1 Aug 93 22:14:10 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14380; Sun, 1 Aug 93 22:13:36 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14374; Sun, 1 Aug 93 22:13:34 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA26343; Sun, 1 Aug 93 22:13:28 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA09603; Sun, 1 Aug 93 22:11:35 PDT Received: from ford by air.airco.co.jp (4.1/6.4J.6) id AA02972; Mon, 2 Aug 93 13:21:21 JST Return-Path: Message-Id: <9308020421.AA02972@air.airco.co.jp> Date: Mon, 2 Aug 1993 13:15:39 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Re: hierarchy/the FTP analogy To: John Gardiner Myers Cc: imap@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 31 Jul 1993 15:34:57 -0400 (EDT) John Gardiner Myers wrote... > The observation that FTP deals with "physical" entities, specifically > files is outright wrong. There are a number of FTP servers which > export entities with no direct correlation to the implementation's > underlying filesystem. For example, the wuarchive ftp server exports > virtual files which it will generate on the fly by running programs > such as "tar" and "compress". > > I have seen a number of high-level interfaces to FTP. GNU Emacs has > one, a GUI exists on the NeXT, and a filesystem driver exits on the > NeXT. > The only connection I have to the internet is through UUCP. Therefore, my association with FTP has been strictly a local experience. I conceed the point as apparently I am in error. > The server's view of hierarchy is irrelevant. It doesn't really > matter how the server interprets the names to get to some internal > storage format. > > What does matter is what set of folder names the server will allow you > to create. There are many more issues here than the server's > interpretation of hierarchy--there are administrative site policies on > such things as character set, total length, length of component, > number of folders, access control on parts of the namespace, and who > knows what. That problem effectively boils down to "try it and see if > the server says OK"--there is no way to encode all possible namespace > restrictions. > Which means, the user doesn't know what is going to happen until after the command is executed. Really friendly. makr From owner-imap@cac.washington.edu Mon Aug 2 01:10:01 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09810; Mon, 2 Aug 93 01:10:01 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14877; Mon, 2 Aug 93 01:09:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14871; Mon, 2 Aug 93 01:09:40 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA24168; Mon, 2 Aug 93 01:09:24 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA09631; Mon, 2 Aug 93 01:09:15 -0700 Date: Sun, 1 Aug 1993 23:33:39 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: Mark Keasling Cc: John Gardiner Myers , imap@cac.washington.edu In-Reply-To: <9308020421.AA02972@air.airco.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Aug 1993 13:15:39 +0900 (JST), Mark Keasling wrote: > On Sat, 31 Jul 1993 15:34:57 -0400 (EDT) John Gardiner Myers wrote... > > That problem effectively boils down to "try it and see if > > the server says OK"--there is no way to encode all possible namespace > > restrictions. > Which means, the user doesn't know what is going to happen until after the > command is executed. Really friendly. Strawman. First, *users* (as opposed to programs) have an idea of what constitutes a reasonable name; and for the most part reality coincides with that idea. A user rarely uses a machine blindly; she usually has had some basic orientation with its capabilities and restrictions. Second, only a stupid client would force the user to deal with names directly without some handling layer in the client. Smart clients create their own view which the user sees, and the user is insulated from server dependencies. We're not talking rocket science here, just good user interface design. IMAP, however, is not a user interface. It is a protocol for two *programs* to communicate with each other, not a user with a program. The more user interface semantics you burden IMAP with, the less useful it becomes. You have still not offered any justification for your claim that IMAP has to provide explicit heirarchy support. Clients already exist which permit user views that are much more sophisticated than most heirarchical filesystems offer. They aren't dependent upon any semantics in IMAP. If anything, adding such semantics to IMAP would break these clients. Seems to me you're advocating a step backward for no net gain. From owner-imap@cac.washington.edu Mon Aug 2 02:31:49 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12850; Mon, 2 Aug 93 02:31:49 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08022; Mon, 2 Aug 93 02:31:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08016; Mon, 2 Aug 93 02:31:28 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <02624-2@ppsw1.cam.ac.uk>; Mon, 2 Aug 1993 10:31:12 +0100 Date: Mon, 02 Aug 93 10:31:11 BST From: A.Grant@ucs.cam.ac.uk To: imap@cac.washington.edu Subject: Re: hierarchy/the FTP analogy Message-Id: In-Reply-To: > First, *users* (as opposed to programs) have an idea of what constitutes a > reasonable name; and for the most part reality coincides with that idea. A > user rarely uses a machine blindly; she usually has had some basic orientation > with its capabilities and restrictions. This is not true. If IMAP is being used to provide email points of presence throughout a heterogenous distributed system, users quite often need to read their mail from a machine they've never done it from before. They may have spent years creating a big folder structure from a PC, and then want to use it from their new VMS system. There are plenty of cases where the preferred DOS, Windows and OS/2 implementations of a client are all different. The user will have basic familiarity with the machine (i.e. if using a Mac, they will know how to work the windows; if using DOS, they will know the common editing and menu conventions; they will _not_ necessarily be familiar with VT100 style); they will know roughly what features they can expect from the client (i.e. that it lets them access their mail); and they will of course know what data they have got on the mailstore (unless they've forgotten). You can't assume the user is familiar with using e-mail from that machine. > Second, only a stupid client would force the user to deal with names directly > without some handling layer in the client. Smart clients create their own > view which the user sees, and the user is insulated from server dependencies. Can you expand on this please? How can you be sure that the 'view' is consistent across all client implementations? Where is the 'view' specified? > We're not talking rocket science here, just good user interface design. Good user interface design for a client consists of making something that is intuitively obvious how to use for people who have a basic familiarity with (a) the machine and (b) the client-server application in question. There are two extremes which must be avoided - clients which are so tightly integrated with the system that they completely obscure what is going on, i.e. what might be seen from a client on another machine; and clients which don't make use of the standard system interface at all, and which make the protocol intrude on the interface. There are plenty of examples of how to do it right - e.g. Trumpet which is almost perfect, PC Gopher III which is not bad, etc. etc. > IMAP, however, is not a user interface. It is a protocol for two *programs* > to communicate with each other, not a user with a program. The more user > interface semantics you burden IMAP with, the less useful it becomes. IMAP may not be a user interface itself, but it is a protocol to provide user interfaces to a remote mailstore. Any state, folder structure etc. cannot be 'private' to a particular client; i.e. you may have to specify the kinds of state that must be present at the server, and put support for it into the protocol, to provide consistent user-interface views across different clients. I could write a Mac FTP client that had a private filename encoding so that names with spaces, mixed case etc. could be stored on and retrieved from monocase filing systems. I could even use private files at the filestore end to provide a hierarchical 'view' on to a non-hierarchical filing system. But nobody would use it because it wouldn't of itself provide access to those files from other systems besides Macs. Isn't IMAP the same, with 'filestore' replaced by 'mailstore'? If all servers are to provide a consistent view to clients, at the protocol level, this view must be defined; otherwise, the server must have some way of indicating its capabilities to the client. Both of these are 'burdening IMAP with user-interface semantics' but I don't see how it becomes less useful. > Seems to me you're advocating a step backward for no net gain. I've never yet seen a protocol that provided a common interface to users of distributed systems _not_ take a step backward from what might be available by being system-specific. From owner-imap@cac.washington.edu Mon Aug 2 10:43:42 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00836; Mon, 2 Aug 93 10:43:42 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12812; Mon, 2 Aug 93 10:43:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12806; Mon, 2 Aug 93 10:43:13 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA16160; Mon, 2 Aug 93 10:43:09 -0700 Date: Mon, 2 Aug 1993 10:07:09 -0700 (PDT) From: Laurence Lundblade Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: <8gHWX1G00WBwEYZVRX@andrew.cmu.edu> Message-Id: References: <0909099009@09090909> <878787878@87878787> <3343434@2323232> <12121212@1212121> <8gHWX1G00WBwEYZVRX@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Catching up on some old mail here.... On 22 Jul 1993, John Gardiner Myers wrote: > Laurence Lundblade writes: > > > > On the responses to the FIND command that now include the ¥SUBSCRIBED > > status of the mailbox, I would like to see it also include the number of > > messages and the number of new messages. > > ... > > The primary concerns I have with including the number of messages, > etc. are ones of implementation. For performance reasons, the IMSP > server presumably does not want to poll all the relevant IMAP servers > while processing the client's FIND request. That means the IMAP > server's information will necessarily be out of date. Highly visible > out of date information will tend to confuse and/or annoy the user > (who will then proceed to annoy the implementor). We currently run a > mail system (AMS) which has a feature similar to IMSP's FIND.UNSEEN. > As it is, I get an occasional bug report of the form "the folder list > said the foo bboard had no new messages, but when I opened it there > were in fact new messages." I would hate to have to fend off users > who were told that there were 7 new messages when in fact there were > 13. > > ... > > Do you define "new" as IMAP defines "NEW" (RECENT and UNSEEN)? I have > to admit I don't really understand /RECENT and tend to think only in > terms of /SEEN. > > ... I see, I was hoping we had an opportunity to get around the current IMAP limitation, but didn't it didn't occur to me that IMSP would be talking to IMAP. I still think this makes for *much* nicer management of folders and would like to see it in the protocol even if it is often unsupported so we have the possibility of implementing it in the future. Agreed that the out of date data is probably worse and that /RECENT is not so important as /SEEN. The basis for a lot of my concern is that Internet mail is going to face increasing competition from LAN based mail and the user interface is what most folks see and make their decisions on. > ... > > > Last, most operations seem like they will be very quick, but for the ones > > that might take more than 5 seconds or so, it would be really nice if > > there was some way that progress could be reported to the user. > > This is a hard one. No clean, simple solution comes to mind. > > I assume you're only interested in network transfer time. The IMSP > server would be hard-pressed to guess how much CPU it's going to burn > before coming up with an answer. Besides, CPU's are fast, SLIP > connections are slow. > > .... I think a very nice simple solution would be to have the protocol send the size or number of items before they're actually sent. For example the current message or body part size is sent first in IMAP. The only other place I can see at the moment where it would be nice to send a size first would be for the FIND operation, since it can take a while. This will take care of transfer time, and could even be used for processing time depending on the implementation. > ... > > > It would also be nice to be able > > to abort operations that are taking too long. > > You can always close the connection... > > I'm not sure anything less drastic is going to be effective. What about an ABORT command with tag matching the operation in progress to abort. Granted it makes client writing harder, but we're generally evolving to more sophisticated clients anyway. LL From owner-imap@cac.washington.edu Mon Aug 2 11:43:36 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04232; Mon, 2 Aug 93 11:43:36 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17660; Mon, 2 Aug 93 11:43:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from stc06.CTD.ORNL.GOV by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17654; Mon, 2 Aug 93 11:43:00 -0700 Received: by stc06.CTD.ORNL.GOV (5.57/Ultrix3.0-C) id AA27433; Mon, 2 Aug 93 14:42:43 -0400 Message-Id: Date: Mon, 2 Aug 93 14:42:42 EDT From: "Jamey Maze" Subject: Re: hierarchy/the FTP analogy To: imap@cac.washington.edu X-Mailer: VersaTerm Link v1.1 >If IMAP is being used to provide email points of >presence throughout a heterogenous distributed system, users quite often >need to read their mail from a machine they've never done it from before. This is part of my motivation for wanting to eventually use IMAP. (Today, I use POP3/Eudora.) When I'm moving around and want to look at my mail, I may have to use a machine that's quite different from the machine in my office. I'd really like for that to be as transparent as possible. If you leave it to the MUA to decide how to store heirarchy information, then it seems the MUA must be smart enough to try the most common schemes and possibly allow the end-user to configure additional schemes that arise in the future. I'm assuming MUA implementors would use the "path" to encode the heirarchy. If some other mechanism were used (separate file, first message in each mailbox, etc.), then all bets are off. It seems you ought to at least make some recommendations regarding how to encode heirarchy. -- Jamey Maze Martin Marietta Energy Systems, Inc. Oak Ridge National Laboratory P.O. Box 2008 (615)574-6355 78 Mitchell Road FAX: (615)-576-4992 Oak Ridge, TN 37831-6283 From owner-imap@cac.washington.edu Mon Aug 2 13:00:10 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07543; Mon, 2 Aug 93 13:00:10 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18016; Mon, 2 Aug 93 12:59:49 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18010; Mon, 2 Aug 93 12:59:47 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA24503; Mon, 2 Aug 93 12:59:42 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA11555; Mon, 2 Aug 93 12:59:34 -0700 Date: Mon, 2 Aug 1993 12:11:34 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If you wish for me to define mailbox_other (the term in the new grammar for any folder other than INBOX) in a fashion that is guaranteed to work across all possible server implementations in a heterogenous environment, that definition would be: An uppercase alphabetic character followed by 0 to 5 uppercase alphanumeric characters That is, I don't know of any operating systems what have less than 6 character filenames or which object to you having numerics after the first character. I really don't think you want that defined as the ``standard format'' of a mailbox name in IMAP. There is no reason that a mailbox name has to have any relationship whatsoever to an operating system file name. Nor is there any reason to require syntax to support a heirarchy view. The horror stories about using an IMAP server with an unknown operating system are strawmen. Operating system-dependent file heirarchy on the server is completely irrelevant to mailbox name heirarchy. Consider the Macintosh, which does an excellent job of hiding its OS file naming from the user. I suspect that most Mac users don't even know what a Mac file name looks like. Before continuing this debate any further, please answer the following questions: 1) Why should the server care what heirarchy view the user sees? 2) Why should the client care if foo/bar is a file named ``foo/bar'' or a file named ``bar'' in a directory named ``foo'', as long as "foo/*" returns the right results in FIND? 3) a) Why should syntax be necessary to have a user view of heirarchy? b) Since "foo*" does the right thing, why can't I as the user have my client show me "foobar" as "bar in heirarchy foo"? [Hint: Pine already does this.] From owner-imap@cac.washington.edu Mon Aug 2 13:40:09 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09667; Mon, 2 Aug 93 13:40:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15843; Mon, 2 Aug 93 13:39:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15837; Mon, 2 Aug 93 13:39:46 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11502; Mon, 2 Aug 93 13:39:39 -0700 Date: Mon, 2 Aug 1993 13:06:03 -0700 (PDT) From: David L Miller Subject: Re: hierarchy/the FTP analogy To: Mark Crispin Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Aug 1993, Mark Crispin wrote: > If you wish for me to define mailbox_other (the term in the new grammar for > any folder other than INBOX) in a fashion that is guaranteed to work across > all possible server implementations in a heterogenous environment, that > definition would be: > An uppercase alphabetic character followed by 0 to 5 > uppercase alphanumeric characters > That is, I don't know of any operating systems what have less than 6 character > filenames or which object to you having numerics after the first character. > > I really don't think you want that defined as the ``standard format'' of a > mailbox name in IMAP. > > There is no reason that a mailbox name has to have any relationship whatsoever > to an operating system file name. Nor is there any reason to require syntax > to support a heirarchy view. > > The horror stories about using an IMAP server with an unknown operating system > are strawmen. Operating system-dependent file heirarchy on the server is > completely irrelevant to mailbox name heirarchy. > > Consider the Macintosh, which does an excellent job of hiding its OS file > naming from the user. I suspect that most Mac users don't even know what a > Mac file name looks like. > I completely agree that mailbox naming need have nothing to do with OS file naming or storage hierarchy. If the server implementation uses a hierarchy or flat directory it doesn't matter. > Before continuing this debate any further, please answer the following > questions: > > 1) Why should the server care what heirarchy view the user sees? > Ideally it should not. But, if some heirarchy is to be presented by a client there must be a way to make it self-consistent from client to client of the same server. i.e. The hierarchy must exist as some sort of "shared state." > 2) Why should the client care if foo/bar is a file named ``foo/bar'' or a file > named ``bar'' in a directory named ``foo'', as long as "foo/*" returns the > right results in FIND? > The key here is that the user must be presented a result that has a one-to-one correspondence between different client implementations. > 3) a) Why should syntax be necessary to have a user view of heirarchy? > b) Since "foo*" does the right thing, why can't I as the user have my > client show me "foobar" as "bar in heirarchy foo"? [Hint: Pine already does > this.] > Let's complicate this a bit and see what happens... Say we have a file "foo.bar/stuff" represented without hierarchy on the server. Now assume client-a defines a hierarchy based on '.' and client-b defines a hierarchy based on '/'. A user of client-a will see file "bar/stuff" in directory "foo" whereas moving to client-b the user will see file "stuff" in directory "foo.bar"!!! To go back to the FTP analogy, it is true that FTP is independent of server naming conventions. BUT, it enforces whatever conventions exist on the server. Even such super-servers as wuarchive enforce the hierarchy, they just define a larger virtual-hierarchy to include compressed files, archives, etc. On the other hand, IMAP ignores any modicum of organization whatsoever! I think the key point here is that with the current definition, there is no way to make use of hierarchy without a severe loss of information between clients that make different assumptions. -- |¥ | |¥/| 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 From owner-imap@cac.washington.edu Mon Aug 2 14:36:20 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11598; Mon, 2 Aug 93 14:36:20 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18664; Mon, 2 Aug 93 14:35:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18658; Mon, 2 Aug 93 14:35:56 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA24559; Mon, 2 Aug 93 14:35:48 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA11867; Mon, 2 Aug 93 14:35:43 -0700 Date: Mon, 2 Aug 1993 13:42:24 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: David L Miller Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Then the client should make no assumptions about what syntax confers heirarchy and instead any/all heirarchy conventions should be defined by the user. It isn't as if Pine doesn't already do this. It isn't a choice between client-imposed heirarchy, server-imposed heirarchy, IMAP-imposed heirarchy, and no heirarchy. It's a choice between imposed heirarchy and no imposed heirarchy. I need to emphasize again that any extraneous naming rules have the implicit side effect of creating restrictions. If you restrict the namespace to create heirarchy, and justify those restrictions with the ``it is not user friendly if the software doesn't know what it can or cannot do'', then you must also restrict the namespace to accomodate restrictions in individual operating systems. Otherwise the justification falls flat -- there would still be ways in which the server would reject a name that is valid in the namespace. People are quite right in saying that they shouldn't be concerned if their server is UNIX or VMS or OS/360. That's why the server should not be involved in the namespace decisions. This does suggest that c-client should walk down directory trees, and perhaps its implementation of create should create directories as necessary. But whether or not it does that is a problem local to a particular implementation on a particular operating system. It is not an IMAP issue. The fact that one or more implementations has restrictions based upon local characteristics does not invalidate the model. From owner-imap@cac.washington.edu Mon Aug 2 15:35:30 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14826; Mon, 2 Aug 93 15:35:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17848; Mon, 2 Aug 93 15:35:11 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17842; Mon, 2 Aug 93 15:35:09 -0700 Received: from (Mac-Treister.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA26584; Mon, 2 Aug 93 15:27:36 PDT Date: Mon, 2 Aug 93 15:27:25 -0800 From: Adam Treister To: Mark Crispin Subject: Re: hierarchy/the FTP analogy Cc: IMAP Interest List Message-Id: In-Reply-To: Your message of Mon, 2 Aug 1993 12:11:34 -0700 (PDT) Content-Type: TEXT/plain; charset=US-ASCII > > 1) Why should the server care what heirarchy view the > user sees? > > 2) Why should the client care if foo/bar is a file named > ``foo/bar'' or a file named ``bar'' in a directory named > ``foo'', as long as "foo/*" returns the right results in > FIND? > > 3) a) Why should syntax be necessary to have a user view > of heirarchy? b) Since "foo*" does the right thing, > why can't I as the user have my client show me "foobar" > as "bar in heirarchy foo"? [Hint: Pine already does > this.] Its not that the server should care, its that every client shouldn't have to jump thru major hoops, to overcome limitations of the protocol. As a client implementor I'm faced with the following scenario: A user may have 1000 messages in the total hierarchy of their mail (certainly not a worst case, as I know of folks with 100 times that). A nice hierarchical view may have 7 +/- 2 messages per folder. Thats somewhere around 150 mail folders, which as I understand your messages (and I dont really claim to), you expect me to implement with independent connections for each one. Sounds pretty hairy. And all I need to make this managable is the ability to write a Path header to a message as the user adds it to a folder. Then when they open the folder, I'll search for messages with that path, and show them those messages. The advantages of this is that messages could be in multiple places simultaneously (by having extra headers lines) and that others who don't want hierarchy, but do want keyword retrieval could get that from the same feature. The down side is that the server has to learn to let users modify their mail (headers) and the protocol needs an extra command or two. Adam From owner-imap@cac.washington.edu Mon Aug 2 15:50:26 1993 Received: by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15384; Mon, 2 Aug 93 15:50:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from robin.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15378; Mon, 2 Aug 93 15:50:25 -0700 Received: by robin. (5.0/SMI-SVR4) id AA15660; Mon, 2 Aug 93 15:47:29 PDT Date: Mon, 2 Aug 1993 15:23:25 -0700 (PDT) From: David L Miller Subject: Re: hierarchy/the FTP analogy To: Mark Crispin Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2260 OK, I agree with (almost) everything you say... The problem is that if c-client creates directories, it is making certain assumptions as to what the syntactic definition of heirarchy is, but there is currently no way of communicating those assumptions to some other client. Now, if there was a way to communicate these assumptions, then we still have a completely generic namespace *and* heirarchy! Now, what are the necessary assumptions? 1. char-set -- valid character (sub)set for filenames. 2. delimiter-set -- valid delimiters for defining heirarchy. 3. ??? Then, we need some way of querying/negotiating these options... On Mon, 2 Aug 1993, Mark Crispin wrote: > Then the client should make no assumptions about what syntax confers heirarchy > and instead any/all heirarchy conventions should be defined by the user. > > It isn't as if Pine doesn't already do this. > > It isn't a choice between client-imposed heirarchy, server-imposed heirarchy, > IMAP-imposed heirarchy, and no heirarchy. It's a choice between imposed > heirarchy and no imposed heirarchy. > > I need to emphasize again that any extraneous naming rules have the implicit > side effect of creating restrictions. If you restrict the namespace to create > heirarchy, and justify those restrictions with the ``it is not user friendly > if the software doesn't know what it can or cannot do'', then you must also > restrict the namespace to accomodate restrictions in individual operating > systems. Otherwise the justification falls flat -- there would still be ways > in which the server would reject a name that is valid in the namespace. > > People are quite right in saying that they shouldn't be concerned if their > server is UNIX or VMS or OS/360. That's why the server should not be involved > in the namespace decisions. > > This does suggest that c-client should walk down directory trees, and perhaps > its implementation of create should create directories as necessary. But > whether or not it does that is a problem local to a particular implementation > on a particular operating system. It is not an IMAP issue. The fact that one > or more implementations has restrictions based upon local characteristics does > not invalidate the model. > > From owner-imap@cac.washington.edu Mon Aug 2 15:50:39 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15397; Mon, 2 Aug 93 15:50:39 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19244; Mon, 2 Aug 93 15:50:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19238; Mon, 2 Aug 93 15:50:24 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA24657; Mon, 2 Aug 93 15:50:16 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA12106; Mon, 2 Aug 93 15:50:10 -0700 Date: Mon, 2 Aug 1993 15:37:01 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: Adam Treister Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Adam - > Its not that the server should care, its that every client shouldn't have to > jump thru major hoops, to overcome limitations of the protocol. Let me get this straight. You want a network protocol to cover for the weakness of a client implementation? > A nice hierarchical view may have 7 +/- 2 messages per folder. Thats > somewhere > around 150 mail folders, which as I understand your messages (and I dont > really > claim to), you expect me to implement with independent connections for each > one. No. Take a look at how FIND works, and in particular at its wildcarding capability. Then take a look at how Pine 3.85 (I think you have an account on Shiva) handles folder collections. > And all I need to make this managable is the ability to write a Path header > to a > message as the user adds it to a folder. Then when they open the folder, > I'll > search for messages with that path, and show them those messages. No!!!!!!!!!! The Path: header has a particular meaning in netnews. We would be (quite justifiably IMHO) crucified for applying some completely unrelated semantics to it. Then too, it commits a layering violation between RFC-822 and message store, and we'll be (again, quite justifiably) crucified for this too. Don't just blame me; the IESG would reject it on both grounds as well. -- Mark -- From owner-imap@cac.washington.edu Mon Aug 2 16:05:37 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15962; Mon, 2 Aug 93 16:05:37 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19340; Mon, 2 Aug 93 16:05:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19334; Mon, 2 Aug 93 16:05:23 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA24682; Mon, 2 Aug 93 16:05:17 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA12178; Mon, 2 Aug 93 16:05:10 -0700 Date: Mon, 2 Aug 1993 16:02:23 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: David L Miller Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Aug 1993 15:23:25 -0700 (PDT), David L Miller wrote: > Now, what are the necessary assumptions? > > 1. char-set -- valid character (sub)set for filenames. US-ASCII. If you have ever had the misfortune of using a filesystem which supports multi-national characters (Mac and to a lesser extent NeXT are examples), and had the current system language be different from the language in which the files had been named, you would see the problem. You have to have a common denominator, otherwise there is no interoperability > 2. delimiter-set -- valid delimiters for defining heirarchy. Not needed, since the issue is entirely local to whatever agent is dealing with the actual file store. In the IMAP case, the client is completely clueless about such things and should remain so; the server worries about such nasty issues. From owner-imap@cac.washington.edu Mon Aug 2 16:13:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16270; Mon, 2 Aug 93 16:13:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18599; Mon, 2 Aug 93 16:13:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18593; Mon, 2 Aug 93 16:13:28 -0700 Received: from localhost (postman@localhost) by andrew.cmu.edu (8.5/8.5) id TAA20442; Mon, 2 Aug 1993 19:13:21 -0400 Received: via switchmail; Mon, 2 Aug 1993 19:13:19 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 2 Aug 1993 19:12:35 -0400 (EDT) Received: via niftymail; Mon, 2 Aug 1993 19:12:28 -0400 (EDT) Date: Mon, 2 Aug 1993 19:12:27 -0400 (EDT) From: Chris Newman Subject: Re: hierarchy/the FTP analogy To: IMAP Interest List In-Reply-To: References: Message-Id: <744333147.1079.0@nifty.andrew.cmu.edu> In attempt to clarify the issue, here's two sceneros: Client-A presents the user with a list of mailbox names from the IMAP server. The user may name their mailboxes as they wish using whatever "logical" hierarchy they wish. The server/client don't care what the hierarchy is -- only the user. This is how most netnews readers I've seen work. Client-B presents the folders in a rigid Macintosh-like hierarchy. Folder names are never shown to the user -- only hierarchy elements of the names. The server, however, still doesn't care what the hierarchy is. Only the client cares. The problem that people are arguing about only exists for client-B. The issue is: how does client-B know what hierarchy system to use? John Myer's strawman is that client-B should have a configurable "hierarchy separator character" (or set of characters), and suggests that `/' (UNIX) and `.' (netnews) are a good default set of such characters. The idea here is that there are different religious beliefs of what the hierarchy separator should be (CMU follows the `.' religion, and *will* make all "Client-A"s show `.' as the separator no matter what is decided). UW's strawman, if I understand it, is some sort of client-determined hierarchy based on mailbox prefixes, such that the "foo" hierarchy is every mailbox matching "foo*". I guess by default there would be a flat list of names, which the user could break into hierarchies as she wishes. Other alternatives are to "declare" a hierarchy separator character that must be used (this *will* piss off someone, and client-A's will probably add separator mappings to make the separator look more familiar to the user). Or create a concept of "mailbox directories" like ftp's concept of directories (adding tons of unnecessary bulk to IMAP & IMSP, IMHO). I'd also like to point out that the "hierarchy separator character" as well as the user-defined hierarchy UW suggests could be stored as IMSP options so that users get *exactly* the same interface when they move to another client using the client-B scenero. If we made a convention for these IMSP options, there would be no mobility problems. To remain constructive on this issue, I'd suggest people either support one or both of the strawmen above, or come up with a new strawman. Then we can choose one or more strawmen at the WG at the end of this month. - Chris From owner-imap@cac.washington.edu Mon Aug 2 16:25:33 1993 Received: by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16703; Mon, 2 Aug 93 16:25:33 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from robin.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16697; Mon, 2 Aug 93 16:25:32 -0700 Received: by robin. (5.0/SMI-SVR4) id AA15686; Mon, 2 Aug 93 16:22:42 PDT Date: Mon, 2 Aug 1993 16:04:28 -0700 (PDT) From: David L Miller Subject: Re: hierarchy/the FTP analogy To: Mark Crispin Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1193 On Mon, 2 Aug 1993, Mark Crispin wrote: > On Mon, 2 Aug 1993 15:23:25 -0700 (PDT), David L Miller wrote: > > > 2. delimiter-set -- valid delimiters for defining heirarchy. > > Not needed, since the issue is entirely local to whatever agent is dealing > with the actual file store. In the IMAP case, the client is completely > clueless about such things and should remain so; the server worries about such > nasty issues. > I should have been more explicit. I am presuming that the client will impose some kind of delimiter when talking to the IMAP server (even the Mac uses a delimiter). What is needed is a way for the client that creates the heirarchy to tell the client that reads the heirarchy about it. The way Pine accomplishes this is via the .pinerc file. This is fine as long as 1) only Pine is dealing with that heirarchy *and* 2) only one user is dealing with that heirarchy *and* 3) that user deals with that heirarchy on _one_machine_ [ignoring NFS for 2 and 3]. What is not dealt with is how does Pine communicate the structure of a completely generic IMAP message store to another application, or even to another instance of itself in a generic fashion? From owner-imap@cac.washington.edu Mon Aug 2 16:36:30 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16988; Mon, 2 Aug 93 16:36:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18902; Mon, 2 Aug 93 16:36:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18896; Mon, 2 Aug 93 16:36:16 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA27853; Mon, 2 Aug 93 16:36:13 -0700 Date: Mon, 2 Aug 1993 16:24:56 -0700 (PDT) From: Laurence Lundblade Subject: Re: hierarchy/the FTP analogy To: Chris Newman Cc: IMAP Interest List In-Reply-To: <744333147.1079.0@nifty.andrew.cmu.edu> Message-Id: References: <0909099009@09090909> <878787878@87878787> <3343434@2323232> <12121212@1212121> <744333147.1079.0@nifty.andrew.cmu.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII That was really helpful, Chris. I think it would be useful if we got some good examples of how the UW patterns can be used to implement hierarchy. Mark keeps mentioning it but I don't think all of us know specifically how it would work. Personally, I'm more concerned about at least having the base level of interoperability I mentioned last week rather than hierarchy, but I suppose if you get the hierarchy stuff hashed out that might come out of it too. LL From owner-imap@cac.washington.edu Mon Aug 2 16:39:30 1993 Received: by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17323; Mon, 2 Aug 93 16:39:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from robin.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17317; Mon, 2 Aug 93 16:39:29 -0700 Received: by robin. (5.0/SMI-SVR4) id AA15694; Mon, 2 Aug 93 16:36:42 PDT Date: Mon, 2 Aug 1993 16:29:13 -0700 (PDT) From: David L Miller Subject: Re: hierarchy/the FTP analogy To: Chris Newman Cc: IMAP Interest List In-Reply-To: <744333147.1079.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 856 On Mon, 2 Aug 1993, Chris Newman wrote: > > I'd also like to point out that the "hierarchy separator character" as > well as the user-defined hierarchy UW suggests could be stored as IMSP > options so that users get *exactly* the same interface when they move > to another client using the client-B scenero. If we made a convention > for these IMSP options, there would be no mobility problems. > Yes, that is where the information should be. I don't particularly care which strawman is accepted, as long as it is defined such that both client-A and client-B know how to define/interpret the heirarchy. > To remain constructive on this issue, I'd suggest people either > support one or both of the strawmen above, or come up with a new > strawman. Then we can choose one or more strawmen at the WG at the > end of this month. > > - Chris > From owner-imap@cac.washington.edu Mon Aug 2 16:44:30 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17423; Mon, 2 Aug 93 16:44:30 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19537; Mon, 2 Aug 93 16:44:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19531; Mon, 2 Aug 93 16:44:11 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA03410; Tue, 3 Aug 93 01:36:16 +0200 Message-Id: <9308022336.AA03410@nada.kth.se> To: Mark Crispin Cc: IMAP Interest List Subject: Re: hierarchy/the FTP analogy In-Reply-To: Your message of "Mon, 02 Aug 1993 15:37:01 PDT." Date: Tue, 03 Aug 1993 01:36:14 +0200 From: Peter Svanberg Quoting: Mark Crispin > > No. Take a look at how FIND works, and in particular at its wildcarding > capability. Then take a look at how Pine 3.85 (I think you > have an account on > Shiva) handles folder collections. I think this discussion would benefit from if you (or someone else) could briefly describe the Pine solution to this problem. (Is the Unix version of Pine 3.85 even released yet?) One question I have is where the information about a users folder collection is kept. Although I can find reasons for having client-specific collections - one for the office-client, one at home - there is certainly needs to have all those specifications on the server: For example when I run a never-used-before-client (when traveling) I want to be able to choose if I am running in "office-mode" or "from-home-mode", and have the collections applied (or down-loaded). --- 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-imap@cac.washington.edu Mon Aug 2 16:54:14 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17732; Mon, 2 Aug 93 16:54:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19070; Mon, 2 Aug 93 16:53:59 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19062; Mon, 2 Aug 93 16:53:57 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id TAA18343; Mon, 2 Aug 1993 19:53:53 -0400 Received: via switchmail; Mon, 2 Aug 1993 19:53:49 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 2 Aug 1993 19:52:34 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 2 Aug 1993 19:52:30 -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, 2 Aug 1993 19:52:26 -0400 (EDT) Message-Id: Date: Mon, 2 Aug 1993 19:52:26 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: hierarchy/the FTP analogy In-Reply-To: References: Beak: Is It is extremely desirable to have a user interface which is consistent from platform to platform. It significantly reduces training time, user confusion, and other support costs. This is true not only for the presentation of the folder namespace, but also for presentation of messages, address books, menus, available features, etc. Unfortunately, this is not an area which lends itself to formal standardaization. Nobody has anything approaching the One True Interface. The consistency problem can only be solved within an organization. People can steal useful UI concepts from each other, but there will always be disagreement and innovation in user interfaces. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Mon Aug 2 17:05:16 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18321; Mon, 2 Aug 93 17:05:16 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19725; Mon, 2 Aug 93 17:05:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from eco.twg.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19705; Mon, 2 Aug 93 17:04:58 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA04196; Mon, 2 Aug 93 20:05:00 -0400 Message-Id: <9308030005.AA04196@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <4537-0@apache.twg.com>; Mon, 2 Aug 1993 17:04:30 -0700 From: "David Herron" Subject: Re: hierarchy/the FTP analogy To: David L Miller (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) Date: Mon, 2 Aug 93 17:04:28 PDT In-Reply-To: Your message of Mon, 2 Aug 1993 16:04:28 -0700 (PDT). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 32 TEXT , 4 TEXT There's a choice here between two kinds of pattern matches? One is a regular pattern, eg `foo*' The other includes some sort of hierarchy seperation character and would instead be `foo.*' (or `foo/*' depending on religion). One difference is that `foo*' will match things which accidently fit the pattern as well as things which are intended to match the pattern. Suppose the folders in your `foo' group are foobert foobleep footrap and you also have a `fooslop' which isn't supposed to be in the group... If instead you enforced a hierarchy then footrap does not match in the foo.* group (containing foo.bert, foo.bleep and foo.trap). Depending on how difficult it is to retrofit hierarchical names into the protocol it would probably be a bad idea to try. There is another way. Instead of `hieararchies' of names, howzabout `groups' of names. This might be what Mark is naming `collections' (I haven't been reading too closely..). The protocol would define commands to create a group of folders. Each element in the group is a folder name (including whatever special characters are necessary to make it refer to usenet group names or bboards). You allow for an arbitrarily long list of group names. The user interface is free to present the list of group names however it wants to. <- David Herron (work) (home) <- <- All hard work brings a profit, but mere talk leads only to poverty. <- Proverbs 14:23 From owner-imap@cac.washington.edu Mon Aug 2 19:33:49 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20764; Mon, 2 Aug 93 19:33:49 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20343; Mon, 2 Aug 93 19:33:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20337; Mon, 2 Aug 93 19:33:23 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id WAA21349; Mon, 2 Aug 1993 22:33:19 -0400 Received: via switchmail; Mon, 2 Aug 1993 22:33:18 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 2 Aug 1993 22:33:03 -0400 (EDT) Received: via niftymail; Mon, 2 Aug 1993 22:33:00 -0400 (EDT) Date: Mon, 2 Aug 1993 22:32:59 -0400 (EDT) From: Chris Newman Subject: Strawman for IMSP option naming conventions To: imap@cac.washington.edu Message-Id: <744345179.1079.0@nifty.andrew.cmu.edu> One of the issues that needs to be resolved in IMSP is how options are named and standardized. I'm putting up this strawman, and am interested in suggestions for improvement (anyone think of a better word than "option" for the first group listed below?). WARNING: The option names listed in the IMSP spec and cyrus-IMSP implementation documents are subject to change. -------------------------------------- Namespace is case-insensitive: -------------------------------------- option.[user/info].* These are "registered" options useful to most clients. The "option.user" tree are those options which should be presented in a preferences interface to the user (with only READ-WRITE options changable). Options in the "option.info" tree are options for use by the client, but not the user. Examples: option.user.from, option.user.sent.mailbox, option.user.bboard.listorder, option.info.date, option.info.domain -------------------------------------- .[user/info].* These are "registered" options useful to clients on the given system. The user and info subtrees follow the same rules as above. Examples: macintosh.user.file.encoding, macintosh.info.either.zone, dos.info.default.novell.server, dos.user.cache.in.ramdisk, macintosh.user.ftp.client -------------------------------------- imsp.* Reserved for IMSP server implementation specific options. A server implementation may place any restrictions it desires on this namespace. Examples: imsp.new.bboard.servers, imsp.admin.all, imsp.required.bbsubs -------------------------------------- .* Reserved for client-specific options. should be "registered". Examples: mailstrom.user.browse.window.position, pine.user.collection.list, ximap.user.xresources, mailstrom.info.appleshare.server -------------------------------------- desc.* Reserved for verbose descriptions of other options which may be used by user-friendly interfaces. It is probably only useful to have descriptions of the "user" options. Examples: desc.option.user.from, desc.macintosh.user.file.encoding -------------------------------------- x.* Namespace which will remain unspecified and unrestricted. Useful for testing options shared by a few clients. -------------------------------------- Discussion: With this, a client can use three gets to get all pertinent information: "get option.*", "get .*", "get .*". The "user" and "info" subtrees allow clients to make intelligent decisions about what to present the user (in addition to the READ-ONLY/READ-WRITE flag). The "desc" tree allows user help for the options to be stored centrally. - Chris From owner-imap@cac.washington.edu Tue Aug 3 04:15:22 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28981; Tue, 3 Aug 93 04:15:22 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22275; Tue, 3 Aug 93 04:14:57 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22269; Tue, 3 Aug 93 04:14:56 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA14058; Tue, 3 Aug 93 04:14:54 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA15246; Tue, 3 Aug 93 04:10:34 PDT Received: from ford by air.airco.co.jp (4.1/6.4J.6) id AA02535; Tue, 3 Aug 93 18:40:46 JST Return-Path: Message-Id: <9308030940.AA02535@air.airco.co.jp> Date: Tue, 3 Aug 1993 18:35:01 +0900 (JST) From: Mark Keasling Reply-To: Mark Keasling Subject: Re: hierarchy/the FTP analogy To: imap@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The reason I would like to have some sort of hierarchical behavior in IMAP is that my client allows me to have more than one folder open at a time using multiple streams. If I manipulate the hierarchy in some fashion, the client has to be able to figure out if the some of the other open folders were affected by the change. If for instance I delete a folder in the hierarchy and the subfolders get deleted as well then the client should close the windows on the now deleted subfolders. If I rename a folder and have one or more of its subfolders open, the client must update those folders so that they don't try to update now non-existant files. makr From owner-imap@cac.washington.edu Tue Aug 3 08:42:19 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03381; Tue, 3 Aug 93 08:42:19 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25485; Tue, 3 Aug 93 08:41:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25479; Tue, 3 Aug 93 08:41:53 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12181; Tue, 3 Aug 93 08:41:48 -0700 Date: Tue, 3 Aug 1993 08:29:02 -0700 (PDT) From: David L Miller Reply-To: David L Miller Subject: Re: hierarchy/the FTP analogy To: Mark Keasling Cc: imap@cac.washington.edu In-Reply-To: <9308030940.AA02535@air.airco.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII In that case you still have to walk the heirarchy to see if any stream is connected to a subfolder of the to-be-deleted folder. The pattern matching behavior of the current UW IMAPd can be seen as a (possibly more efficient) generalization of a heirarchy. It has been suggested that IMSP is the appropriate place to keep the heirarchy information. That would keep IMAP from getting cluttered up with an extra layer of convolution and confusion. -- |¥ | |¥/| 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, 3 Aug 1993, Mark Keasling wrote: > The reason I would like to have some sort of hierarchical behavior > in IMAP is that my client allows me to have more than one folder > open at a time using multiple streams. If I manipulate the hierarchy > in some fashion, the client has to be able to figure out if the some of > the other open folders were affected by the change. If for instance > I delete a folder in the hierarchy and the subfolders get deleted as > well then the client should close the windows on the now deleted > subfolders. If I rename a folder and have one or more of its subfolders > open, the client must update those folders so that they don't try to > update now non-existant files. > > makr > > From owner-imap@cac.washington.edu Tue Aug 3 09:24:18 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04864; Tue, 3 Aug 93 09:24:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26285; Tue, 3 Aug 93 09:23:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26279; Tue, 3 Aug 93 09:23:55 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <17113-0@ppsw1.cam.ac.uk>; Tue, 3 Aug 1993 17:23:49 +0100 Date: Tue, 03 Aug 93 17:23:42 BST From: A.Grant@ucs.cam.ac.uk To: imap@cac.washington.edu Subject: Re: hierarchy/the FTP analogy Message-Id: In-Reply-To: > The pattern matching behavior of the current UW IMAPd can be seen as a > (possibly more efficient) generalization of a heirarchy. In what sense? Hierarchy is used to reduce the clutter, i.e. to minimise the number of choices seen at any one stage of navigation through a large information base. On pure windowing systems this is essential. Pattern matching _can_ be used to reduce the clutter, e.g. by saying "present all folders matching xxx* as a single folder xxx" (I do similar things on the flat filing systems of MVS and CMS, using simple pattern matching), but the question is where to store rules like this - at the server, or the client? Obviously for a multi-client system like IMAP, storing it at the client is no good as the user would have to transport their rules between clients. So it has to be at the server. In which case, it seems logical to do the 'presenting', i.e. the grouping of folders into a logical hierarchy, at the server, and hence supported by the protocol. And if it's done at the server there is little point in allowing users to create individual schemes for themselves. Also, it is likely that someone will one day want to move a mailbase from one operating system to another. You had better be sure that folder names (including path separators) end up _exactly_ the same if you are relying entirely on pattern matching at the client end. From owner-imap@cac.washington.edu Tue Aug 3 09:42:37 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05290; Tue, 3 Aug 93 09:42:37 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26516; Tue, 3 Aug 93 09:42:22 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26510; Tue, 3 Aug 93 09:42:21 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15540; Tue, 3 Aug 93 09:42:13 -0700 Date: Tue, 3 Aug 1993 09:34:26 -0700 (PDT) From: David L Miller Subject: Re: hierarchy/the FTP analogy To: A.Grant@ucs.cam.ac.uk Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The heirarchy should be stored in the IMSP server, not the IMAP server. That way, you have the more general ability to allow the IMAP server to store information in the most effecient way possible for it and IMSP can take care of the mapping. Otherwise, you will end up with something that may be OK for some implementations, but pure hell for others. -- |¥ | |¥/| 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, 3 Aug 1993 A.Grant@ucs.cam.ac.uk wrote: > > The pattern matching behavior of the current UW IMAPd can be seen as a > > (possibly more efficient) generalization of a heirarchy. > > In what sense? Hierarchy is used to reduce the clutter, i.e. to minimise > the number of choices seen at any one stage of navigation through a large > information base. On pure windowing systems this is essential. Pattern > matching _can_ be used to reduce the clutter, e.g. by saying "present all > folders matching xxx* as a single folder xxx" (I do similar things on the > flat filing systems of MVS and CMS, using simple pattern matching), but the > question is where to store rules like this - at the server, or the client? > Obviously for a multi-client system like IMAP, storing it at the client is > no good as the user would have to transport their rules between clients. > So it has to be at the server. In which case, it seems logical to do the > 'presenting', i.e. the grouping of folders into a logical hierarchy, at the > server, and hence supported by the protocol. And if it's done at the server > there is little point in allowing users to create individual schemes for > themselves. > > Also, it is likely that someone will one day want to move a mailbase > from one operating system to another. You had better be sure that folder > names (including path separators) end up _exactly_ the same if you are > relying entirely on pattern matching at the client end. > From owner-imap@cac.washington.edu Tue Aug 3 09:49:41 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05412; Tue, 3 Aug 93 09:49:41 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23619; Tue, 3 Aug 93 09:49:27 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23613; Tue, 3 Aug 93 09:49:25 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA25905; Tue, 3 Aug 93 09:49:20 -0700 Date: Tue, 3 Aug 1993 09:30:10 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: Mark Keasling Cc: IMAP Interest List In-Reply-To: <9308030940.AA02535@air.airco.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 3 Aug 1993 18:35:01 +0900 (JST), Mark Keasling wrote: > The reason I would like to have some sort of hierarchical behavior > in IMAP is that my client allows me to have more than one folder > open at a time using multiple streams. If I manipulate the hierarchy > in some fashion, the client has to be able to figure out if the some of > the other open folders were affected by the change. If for instance > I delete a folder in the hierarchy and the subfolders get deleted as > well then the client should close the windows on the now deleted > subfolders. If I rename a folder and have one or more of its subfolders > open, the client must update those folders so that they don't try to > update now non-existant files. This sounds like an implementation issue to me. None of the current c-client based drivers have anything like mail folders within folders, so we're talking about some other implementation. It doesn't seem reasonable to me to permit the deletion of a folder if there are active subfolders inside it. You seem to be worried about confusion within the same client (that is, a ``one hand doesn't know what the other hand is doing'' problem) and not of two conflicting clients. This is a sensible approach; locking against hostile action is much harder than locking in a cooperative environment. But, within the same client this is arguably an intra-client communication issue that is solvable with programming in the client. From owner-imap@cac.washington.edu Tue Aug 3 09:52:31 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05576; Tue, 3 Aug 93 09:52:31 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23649; Tue, 3 Aug 93 09:52:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23643; Tue, 3 Aug 93 09:52:18 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA25910; Tue, 3 Aug 93 09:52:07 -0700 Date: Tue, 3 Aug 1993 09:50:12 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: A.Grant@ucs.cam.ac.uk Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 03 Aug 93 17:23:42 BST, A.Grant@ucs.cam.ac.uk wrote: > Also, it is likely that someone will one day want to move a mailbase > from one operating system to another. You had better be sure that folder > names (including path separators) end up _exactly_ the same if you are > relying entirely on pattern matching at the client end. This is an excellent argument for heirarchy viewing to be implemented as a client function. If servers do not impose their own view of heirarchy, it doesn't matter if the server's operating system changes. From owner-imap@cac.washington.edu Tue Aug 3 10:28:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06901; Tue, 3 Aug 93 10:28:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27214; Tue, 3 Aug 93 10:28:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27208; Tue, 3 Aug 93 10:28:34 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <19446-2@ppsw1.cam.ac.uk>; Tue, 3 Aug 1993 18:28:11 +0100 Date: Tue, 03 Aug 93 18:27:50 BST From: A.Grant@ucs.cam.ac.uk To: Mark Crispin Cc: imap@cac.washington.edu Subject: Re: hierarchy/the FTP analogy Message-Id: In-Reply-To: Mark Crispin wrote: > This is an excellent argument for heirarchy viewing to be implemented as a > client function. If servers do not impose their own view of heirarchy, it > doesn't matter if the server's operating system changes. Suppose a user normally is presented with a folder menu Misc Archive Temp and they know when they click on 'Archive' that they will get another folder menu Work Play The essential thing is that they must see the same 'shape' of the hierarchy, certainly (a) across all clients and ideally (b) across underlying re-implementation of the mailbase too. Cosmetic changes in the actual folder names (e.g. uppercasing and truncation) are just about acceptable, if necessary, but the shape must always be constant. Compare this with the way Novell NetWare's filing system has multiple name spaces yet a single hierarchy. If a client tries to derive a logical hierarchy from unstructured (flat) folder names, it must have rules for doing so. Assuming that a mechanism for propagating rules between clients without reference to a server is ludicrously complicated, either the rules have to be imposed from outside, (e.g. "interpret '/' as hierarchy in MAILBOXes, interpret '.' as hierarchy in BBOARDs"), or stored on a server and retrieved somehow. If they are stored on a server, it seems more logical to let the server do some of the work, e.g. cutting down the amount of information transferred when the user asks for a list of all folders, even if client-end pattern-matching would present the same list. Otherwise there must at least be a retrieval mechanism for clients to find out the rules. Server implementations would need to ensure that any change of complete folder paths as a result of mailbase migration would not create or remove any nodes in the hierarchy, so they would also have to know the rules for hierarchy derivation from filenames. David L. Miller writes: > The heirarchy should be stored in the IMSP server, not the IMAP server. Maybe. I assumed that if the IMSP server existed at all, it would be an adjunct of the IMAP server, hence the distinction is not particularly interesting, at least not as interesting as the one between server and clients. How do you propose to store the hierarchy in the IMSP server? From owner-imap@cac.washington.edu Tue Aug 3 10:40:22 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07125; Tue, 3 Aug 93 10:40:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27394; Tue, 3 Aug 93 10:40:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27385; Tue, 3 Aug 93 10:39:59 -0700 Received: from (Mac-Treister.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA15844; Tue, 3 Aug 93 10:39:57 PDT Date: Tue, 3 Aug 93 10:39:47 -0800 From: Adam Treister To: Mark Crispin Subject: Re: hierarchy/the FTP analogy Cc: IMAP Interest List Message-Id: In-Reply-To: Your message of Tue, 3 Aug 1993 09:50:12 -0700 (PDT) Content-Type: TEXT/plain; charset=US-ASCII Mark, I trashed my comment to this list and your reply yesterday, so the following is without the benefit of the actual messages in front of me: Basically, I stated that my preferred way of implementing hierarchy on the client is to write a "path header" back to the message. You flamed back [no offense taken] that "path header" already had meaning in the netnews world, and that it was a layering violation with 822. The former is a question of naming, and I dont care what we call it. The latter is, as you would say, implementation independent. It is only a layering violation if the server comingles the headers. If the server saves the message unaltered, but tagged with client defined attributes about how and where it is to be presented, thats no violation. Its only if you alter the message in a way indifferentiable (if thats a word) from changes made in transport, that you're guilty of layering violations (layering, schmayering...I just want my mail in the right place :) And how does this differ from the ability to set keywords in mm mailboxes (other than being harder to implement)? I just want the same feature, with more power. As you well know, I view mail as a database pb (not that I claim to know anything on the subject), and the ability to attach attributes to a record in a database, even after its been added, is pretty universally supported. If and when someone actually gets around to implementing a message store on top of a database, it would be a shame if they have to abandon IMAP to do so. I have no objections to adding this to IMSP aot IMAP, since it is more maliable, and the end result is the same, but what I'm talking about is adding access fields, and all else being equal, I'd rather see it as part of IMAP. Finally you accused me of wanting the network protocol to overcome the limitations of my weak client. No. The protocol does nothing but let me talk to the server. I want the server to overcome the limitations of my weak client! :) Adam From owner-imap@cac.washington.edu Tue Aug 3 10:42:54 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07210; Tue, 3 Aug 93 10:42:54 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27462; Tue, 3 Aug 93 10:42:39 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27454; Tue, 3 Aug 93 10:42:36 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id NAA07679; Tue, 3 Aug 1993 13:42:32 -0400 Received: via switchmail; Tue, 3 Aug 1993 13:42:31 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 3 Aug 1993 13:42:05 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 3 Aug 1993 13:42:01 -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, 3 Aug 1993 13:41:59 -0400 (EDT) Message-Id: Date: Tue, 3 Aug 1993 13:41:59 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: hierarchy/the FTP analogy In-Reply-To: <9308030940.AA02535@air.airco.co.jp> References: <9308030940.AA02535@air.airco.co.jp> Beak: Is Renaming or deleting a folder will not necessarily rename or delete its subfolders. In any case, I see it as the server's job to close the connection. It knows best which folders got renamed or deleted, especially if it was some other client which did the renaming or deleting. The Cyrus IMAP server is designed to close connections when folders get renamed/deleted from underneath them. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Aug 3 11:03:49 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08011; Tue, 3 Aug 93 11:03:49 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24100; Tue, 3 Aug 93 11:03:35 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24094; Tue, 3 Aug 93 11:03:33 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA26279; Tue, 3 Aug 93 11:03:29 -0700 Date: Tue, 3 Aug 1993 10:20:07 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: Chris Newman Cc: IMAP Interest List In-Reply-To: <744333147.1079.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Chris - A more accurate characterization of ``UW's strawman'' (actually, what Pine has implemented) is that there is a categorization of a mailbox folder name based upon characteristics of its name. It isn't limited to prefix. I don't see why we have to choose between any of these. Mailbox classification models are like opinions -- everybody's got one. If anything, I think that a tree-structured heirarchy is rather limited as a classification model. It's annoying enough that I have to deal with something as restrictive as heirarchies for files; I'd hate to have mail folders stuck in that rut as well. Nor do I want to be limited to the folder ::= name / name DELIM folder name ::= 1* model of naming. -- Mark -- From owner-imap@cac.washington.edu Tue Aug 3 11:26:44 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08636; Tue, 3 Aug 93 11:26:44 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24231; Tue, 3 Aug 93 11:26:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24225; Tue, 3 Aug 93 11:26:28 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA26285; Tue, 3 Aug 93 11:26:20 -0700 Date: Tue, 3 Aug 1993 11:07:31 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: A.Grant@ucs.cam.ac.uk Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This discussion is going nowhere. What is essentially being argued is whether or not IMAP should dictate a particular user interface -- in this case, a folder heirarchy view -- to the exclusion of all others. A tree-shaped heirarchy is not the only possible view. But, supposing you want a tree-shaped heirarchy with a heirarchy level delimiter, what keeps you from setting your favorite delimiter in the configuration for a particular user agent? I think we all understand how a delimiter-character heirarchical name works. Maybe you might also have a switch saying which endian the name is as well. If you are worried about a user agent wiring in a particular delimiter instead of making it a user option, then don't buy that user agent and/or nag the vendor to fix it. If it's public domain, fix it yourself. I certainly wouldn't want to use a program that was so poorly written that it was impossible to add a single character preference... If you are worried about a user agent using some other model, think carefully about what you are really saying. You are saying, in effect, ``somebody may come up with an innovative idea of mailbox organization that doesn't match up with any other extant user agents. This would cause inconsistency, and to prevent this from happening we want IMAP to legislate against it.'' From owner-imap@cac.washington.edu Tue Aug 3 13:23:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11606; Tue, 3 Aug 93 13:23:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29872; Tue, 3 Aug 93 13:22:45 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29866; Tue, 3 Aug 93 13:22:44 -0700 Received: from localhost (postman@localhost) by andrew.cmu.edu (8.5/8.5) id QAA14207; Tue, 3 Aug 1993 16:22:41 -0400 Received: via switchmail; Tue, 3 Aug 1993 16:22:39 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 3 Aug 1993 16:21:54 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 3 Aug 1993 16:21:52 -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, 3 Aug 1993 16:21:50 -0400 (EDT) Message-Id: <0gLgXSa00WBwM1An1y@andrew.cmu.edu> Date: Tue, 3 Aug 1993 16:21:50 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: hierarchy/IMSP In-Reply-To: References: Beak: is Not I believe IMSP should not directly support/constrain hierarchy for the same reasons that IMAP should not do so. If, however, a client wishes to present a configurable hierarchical view of the folder namespace, it can (and should) store the relevant configuration information as IMSP options. Should two or more clients share a viewing methodology, they can share the configuration information by sharing the relevant IMSP options. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Aug 3 21:08:08 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20386; Tue, 3 Aug 93 21:08:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04928; Tue, 3 Aug 93 21:07:46 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04922; Tue, 3 Aug 93 21:07:43 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42125-1>; Tue, 3 Aug 1993 22:07:34 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Tue, 3 Aug 93 17:23 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0oNVmO-000cuvC; Tue, 3 Aug 93 17:28 MDT Date: Tue, 3 Aug 1993 18:23:06 -0600 From: Steve Hole Subject: Re: Interactive Mail Support Protocol To: Laurence Lundblade Cc: imap@cac.washington.edu Message-Id: Priority: Normal X-Read-Ack: No X-Delivery-Ack: No Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 Aug 1993 11:07:09 -0600 Laurence Lundblade wrote: > From: Laurence Lundblade > Date: Mon, 2 Aug 1993 11:07:09 -0600 > Subject: Re: Interactive Mail Support Protocol > To: John Gardiner Myers > Cc: imap@cac.washington.edu > > > I think a very nice simple solution would be to have the protocol send the > size or number of items before they're actually sent. For example the > current message or body part size is sent first in IMAP. The only other > place I can see at the moment where it would be nice to send a size first > would be for the FIND operation, since it can take a while. This will > take care of transfer time, and could even be used for processing time > depending on the implementation. I like this idea very much John. We have found that constant feedback to the user - especially on slow links - is essential for their acceptance. This is a simple solution that we have been able to use quite successfully with IMAP. It really makes the interface look nice when you can throw up a % complete histogram. > What about an ABORT command with tag matching the operation in progress > to abort. Granted it makes client writing harder, but we're generally > evolving to more sophisticated clients anyway. Yes to this too. It would be nice especially when manipulating News stores. -- 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-imap@cac.washington.edu Wed Aug 4 02:30:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25445; Wed, 4 Aug 93 02:30:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06582; Wed, 4 Aug 93 02:30:32 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06576; Wed, 4 Aug 93 02:30:28 -0700 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <17486-0@ppsw1.cam.ac.uk>; Wed, 4 Aug 1993 10:30:18 +0100 Date: Wed, 04 Aug 93 10:30:06 BST From: A.Grant@ucs.cam.ac.uk To: Mark Crispin Cc: imap@cac.washington.edu Subject: Re: hierarchy/the FTP analogy Message-Id: In-Reply-To: > This discussion is going nowhere. > What is essentially being argued is whether or not IMAP should dictate a > particular user interface -- in this case, a folder heirarchy view -- Providing support for a cross-client hierarchy is not 'user interface' any more than the support for hierarchy in FTP is 'user interface'. A client is free to present folders as icons, directories, or whatever. The question is whether the mapping from the folder structure as seen by one client should map one-to-one on to the folder structure as seen by another client. > But, supposing you want a tree-shaped heirarchy with a heirarchy level > delimiter, what keeps you from setting your favorite delimiter in the > configuration for a particular user agent? So I'm near department X, I go into their local workstation room, see a computer I've never used before, but it has a mail client on the menu, and the first thing I have to do is some weird stuff with regexps so it understands my folder structure! For every person who is going to use IMAP for the mail client on their personal portable (with local state) there are thousands who will use it as part of systems which provide e-mail at multiple points of presence at shared workstations (without local state). > If you are worried about a user agent wiring in a particular delimiter instead > of making it a user option, then don't buy that user agent and/or nag the > vendor to fix it. If it's public domain, fix it yourself. I certainly > wouldn't want to use a program that was so poorly written that it was > impossible to add a single character preference... Sure, we could make sure that every IMAP client had the same delimiter. You then get the problem where visiting Prof X tries to use one of our IMAP clients, set up our way, to read the mail at his own university, which uses a different convention. Are you asking professors of Sanskrit to fiddle with regexps just to read their mail? Most users have no choice over the user agent they use. If you are buying for 20,000 users you don't buy site licences for four products (for the same machine) just so users have a different folder view. Many people use user agents specified and purchased by completely different people with different ideas of how things should work. > If you are worried about a user agent using some other model, think carefully > about what you are really saying. You are saying, in effect, ``somebody may > come up with an innovative idea of mailbox organization that doesn't match up > with any other extant user agents. This would cause inconsistency, and to > prevent this from happening we want IMAP to legislate against it.'' Not at all. I would be quite happy if IMAP had features to allow people to define innovative organisations for mailboxes, as long as all user agents would see the same organisation. Imagine if someone had said that FTP should not have hierarchical features because it did not give client-end implementors enough freedom. I.e. that it would not allow full access to weird filing systems, and that it did not support innovative file organisations. FTP client implementors would then have to invent their own hierarchy schemes. I bet they would settle on '/' as a default delimiter, with extensions to the protocol to allow the server to specify other delimiters if appropriate for a filing system such as MVS. In other words, neither the user nor the user agent implementor has a choice. The only thing you have gained is that 'LS' is now extraordinarily slow as files are not hidden behind directories. FTP's hierarchy features are not 'legislation against' anything; they are common support for things which people really want. Can you fault this analogy? The fact is that people don't want 'innovation' - they want commonality and simplicity, things working at the level of their understanding of computers. Most political science majors would be happy with folders numbered 1 to 10. From owner-imap@cac.washington.edu Wed Aug 4 03:53:05 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26783; Wed, 4 Aug 93 03:53:05 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28188; Wed, 4 Aug 93 03:52:45 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28182; Wed, 4 Aug 93 03:52:44 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA26974; Wed, 4 Aug 93 03:52:37 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA18302; Wed, 4 Aug 93 03:52:32 -0700 Date: Wed, 4 Aug 1993 02:37:10 -0700 (PDT) From: Mark Crispin Subject: Re: hierarchy/the FTP analogy To: A.Grant@ucs.cam.ac.uk Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII FTP has no heirarchy support at all. There is not a single command in FTP which has as its explicit purpose the support of heirarchy. It has been emphatically stated by server implementors that they do not want to have their hands tied by a ``One True Model'' of mail store organization. The current c-client based server simultaneously supports 5 or 6 different models now (I've lost count). One of my colleagues is working on yet another model of his own design. The CMU folks have stated their intent to have a totally different model of mail store in their future Cyrus server. However, in spite of that, these server models attempts to interact and in general work well with clients which are (and should be) clueless about the internal details of the server. Nor do I think that client implementors want to have their hands tied by a ``One True Model'', not even by a heirarchical One True Model. Heirarchy is not the only view possible of a mail store. Most users don't care at all about heirarchy for their personal mail archives, but care very much about being able to group them into named collections with certain characteristics. Heirarchy is a possible means to an end, not the end itself. However, in spite of that, these clients attempt to interact and in general work well with servers which are (and should be) clueless about how the client intends to present the information. If a server model doesn't affect the client's behavior, then it is irrelevant. Any syntax in the name that is significant to the server is just noise to the client. If a client model doesn't affect the server's behavior, then it is irrelevant to the server. Thus, the only point of relevancy is between the client and the user, and IMAP is out of the picture. It has been suggested how organization view qualifiers can be defined, and even how they can be distributed to multiple clients (and even form a convention) via IMSP. Implementing this in a friendly way is hardly rocket science. I'm getting a bit tired of arguing this, especially when the same road is driven and the same dead end is reached over and over again. This unproductive issue has wasted entirely too much time. There are important functional issues to be resolved before IMAP can possibly be made into an Internet Standard; problems such as ``how is disconnected operation going to be accomplished?'' From owner-imap@cac.washington.edu Wed Aug 4 12:10:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08940; Wed, 4 Aug 93 12:10:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12704; Wed, 4 Aug 93 12:09:56 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12698; Wed, 4 Aug 93 12:09:51 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id PAA10282; Wed, 4 Aug 1993 15:09:42 -0400 Received: via switchmail; Wed, 4 Aug 1993 15:09:37 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 4 Aug 1993 15:08:20 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 4 Aug 1993 15:08:15 -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, 4 Aug 1993 15:08:13 -0400 (EDT) Message-Id: <4gM0YRC00WBwILln1r@andrew.cmu.edu> Date: Wed, 4 Aug 1993 15:08:13 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: August IMSP draft Beak: is Not *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* Network Working Group J. G. Myers Request for Comments: ???? Carnegie Mellon August 1993 IMSP -- Interactive Mail Support Protocol Status of this memo This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Introduction The intent of the Interactive Mail Support Protocol (IMSP) is to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the IMAP2bis protocol [RFC-1176] [IMAP2bis], providing services which are either outside the scope of mail access or which pertain to environments which must run more than one IMAP2 server in the same mail domain. The protocol The IMSP protocol consists of a sequence of client commands and server responses, with server data interspersed between the responses. To simplify the implementation of clients, the IMSP protocol has a command structure similar to the IMAP protocol. Many of the IMSP commands and responses have the same or similar syntax and semantics of their IMAP2 counterparts. Like the IMAP2 protocol, commands and responses are tagged. That is, a command begins with a unique identifier (typically a short alphanumeric sequence such as a Lisp "gensym" function would generate e.g., A0001, A0002, etc.), called a tag. The response to this command is given the same tag from the server. Additionally, the server may send an arbitrary amount of "unsolicited data", which is identified by the special reserved tag of "*". There is another special reserved tag, "+", discussed below. The server must be listening for a connection on TCP port 406. When a connection is opened the server sends an unsolicited OK or PREAUTH response as a greeting message and then waits for commands. The client opens a connection and waits for the greeting. The client must not send any commands until it has received the greeting from the server. Once the greeting has been received, the client may begin sending commands and is not under any obligation to wait for a server response to this command before sending another command, within the constraints of TCP flow control. When commands are received the server acts on them and responds with command responses, often interspersed with data. The effect of a command can not be considered complete until a command response with a tag matching the command is received from the server. Although all known IMSP servers at the time of this writing process commands to completion before processing the next command, it is not required that a server do so. However, many commands can affect the results of other commands, creating processing-order dependencies (or, for FIND and GETACL, ambiguities about which data is associated with which command). All implementations that operate in a non- lockstep fashion must recognize such dependencies and defer or synchronize execution as necessary. Generally, the first command from the client is a LOGIN command with user name and password arguments to establish identity and access authorization, unless this has already been accomplished through other means, e.g. connecting via the BSD "RSH" protocol. Until identity and access authorization have been established, no operations other than LOGIN or LOGOUT are permitted. The client terminates the session with the LOGOUT command. The server returns a "BYE" followed by an "OK". A Typical Scenario Client Server ------ ------ {Wait for Connection} {Open Connection} --> <-- * OK IMSP Server Ready {Wait for command} A001 LOGIN Fred Secret --> <-- A001 OK User Fred logged in {Wait for command} A002 FIND ALL.MAILBOXES INBOX --> <-- * MAILBOX INBOX () (imap3.do.main) <-- A0002 OK Find complete {Wait for command} A003 SUBSCRIBE BBOARD comp.mail.mime --> <-- A003 OK Subscribe complete {Wait for command} A004 LOGOUT --> <-- * BYE IMSP server quitting <-- A004 OK Logout complete {Close Connection} --><-- {Close connection} {Go back to start} Base functionality Commands tag NOOP The NOOP command returns an OK to the client. By itself, it does nothing, but certain things may happen as side effects. Responses tag OK text This response identifies successful completion of the command with that tag. The text is a line of human-readable text that may be useful in a protocol telemetry log for debugging purposes. tag NO text This response identifies unsuccessful completion of the command with that tag. The text is a line of human-readable text that probably should be displayed to the user in an error report by the client. tag BAD text This response identifies faulty protocol received from the client; The text is a line of human-readable text that should be recorded in any telemetry as part of a bug report to the maintainer of the client. * BYE text This response identifies that the server is about to close the connection. The text is a line of human-readable text that should be displayed to the user in a status report by the client. This may be sent as part of a normal logout sequence, or as a panic shutdown announcement by the server. It is also used by some servers as an announcement of an inactivity autologout. * OK text This response identifies normal operation on the server. No special action by the client is called for, however, the text should be displayed to the user in some fashion. This is currently only used by servers at startup as a greeting message to show they are ready to accept the first command. * NO text This response identifies a warning from the server that does not affect the overall results of any particular request. The text is a line of human-readable text that should be presented to the user as a warning of improper operation. * BAD text This response identifies a serious error at the server; it may also indicate faulty protocol from the client in which a tag could not be parsed. The text is a line of human-readable text that should be presented to the user as a serious or possibly fatal error. It should also be recorded in any telemetry as part of a bug report to the maintainer of the client and server. + text This response identifies that the server is ready to accept the text of a literal from the client. Normally, a command from the client is a single text line. If the server detects an error in the command, it can simply discard the remainder of the line. It cannot do this for commands that contain literals, since a literal can be an arbitrarily long amount of text, and the server may not even be expecting a literal. This mechanism is provided so the client knows not to send a literal until the server expects it, preserving client/server synchronization. In practice, this condition is rarely encountered. In the current protocol, the only client command likely to contain a literal is the LOGIN command. Consider a server that validates the user before checking the password. If the password contains "funny" characters and hence is sent as a literal, then if the user is invalid an error would occur before the password is parsed. No such synchronization protection is provided for literals sent from the server to the client, for performance reasons. Any synchronization problems in this direction would be caused by a bug in the client or server. Identification and Authorization Commands tag LOGIN user password The LOGIN command identifies the user to the server and carries the password authenticating this user. This information is used by the server to control access to commands. EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with password SESAME. tag LOGOUT The LOGOUT command informs the server that the client is done with the session. The server will send an unsolicited BYE response before the (tagged) OK response, and then close the network connection. Responses * PREAUTH A pre-authenticated IMSP server should recognize that authentication has already happened, and enter the post-login state. In its greeting message, it should use the unsolicited reply "PREAUTH" instead of "OK" to indicate that external authentication has taken place. Server location and new message information Commands tag FIND MAILBOXES pattern The FIND MAILBOXES command accepts as an argument a pattern (including wildcards) that specifies some set of mailbox names that are usable by connecting to an IMAP2 server and using the SELECT command. The format of mailboxes is implementation dependent. Only those mailboxes that the user has declared as being "subscribed" are returned. Two wildcard characters are defined; "*" specifies any number (including zero) characters may match at this position and "%" specifies a single character may match at this position. For example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas FOO%BAR will match only FOO.BAR. "*" will match all mailboxes. The FIND MAILBOXES command will return some set of unsolicited MAILBOX replies that have as their value a single mailbox name, a list of mailbox attributes, and a list of hosts on which the mailbox resides. EXAMPLE: A002 FIND MAILBOXES * * MAILBOX INBOX (¥SUBSCRIBED) (imap3.do.main) * MAILBOX FOOBAR (¥SUBSCRIBED ¥UNSEEN) (imap3.do.main) * MAILBOX GENERAL (¥SUBSCRIBED ¥UNSEEN) (imap12.do.main) A002 OK Find completed Although the use of explicit file or path names for mailboxes is discouraged by this standard, it may be unavoidable. It is important that the value returned in the MAILBOX unsolicited reply be usable in a SELECT command given to an IMAP server running on each of the returned hosts without remembering any path specification that may have been used in the FIND MAILBOXES pattern. The SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX commands manipulate the list returned by this command. tag FIND ALL.MAILBOXES pattern The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES; however, it returns a complete list of all mailboxes available to the user. Data is returned as in FIND MAILBOXES. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `mailboxes available to the user' may not be meaningful for a particular server or server implementation. The command must at least return the set of mailboxes that FIND MAILBOXES does. tag FIND UNSEEN.MAILBOXES pattern The FIND UNSEEN.MAILBOXES command is similar to FIND MAILBOXES; however, only those "subscribed" mailboxes in which there are messages without the ¥SEEN flag are returned. Data is returned as in FIND MAILBOXES. Should an implementation be unable to determine which mailboxes have unread messages, it should return the same information returned by FIND MAILBOXES. tag FIND BBOARDS pattern The FIND BBOARDS command accepts as an argument a pattern that specifies some set of bulletin board names that are usable by connecting to an IMAP2 server and using the BBOARD command. Wildcards are permitted as in FIND MAILBOXES. Only those bboards that the user has declared as being "subscribed" are returned. The FIND BBOARDS command will return some set of unsolicited BBOARD replies that have as their value a single bulletin board name, a list of attributes, and a list of hosts on which the bboard resides. EXAMPLE: A002 FIND BBOARDS * * BBOARD comp.mail.mime (¥SUBSCRIBED ¥UNSEEN) (imap2.do.main) * BBOARD GENERAL (¥SUBSCRIBED) (imap7.do.main imap8.do.main) A002 OK Find completed tag FIND ALL.BBOARDS pattern The FIND ALL.BBOARDS command is similar to FIND BBOARDS; however, it returns a complete list of all bulletin boards available to the user. Data is returned as in FIND BBOARDS. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `bboards available to the user' may not be meaningful for a particular server or server implementation. The command must at least return the set of bboards that FIND BBOARDS does. tag FIND UNSEEN.BBOARDS pattern The FIND UNSEEN.BBOARDS command is similar to FIND BBOARDS; however, only those "subscribed" bboards for which there are messages without the ¥SEEN flag are returned. Data is returned as in FIND BBOARDS. Should an implementation be unable to determine which bboards have unread messages, it should return the same information returned by FIND BBOARDS. tag FIND ALL.ADDRESSBOOKS pattern The FIND ALL.ADDRESSBOOKS command accepts as an argument a pattern that specifies some set of address book names that are usable by the SEARCHADDRESS command. It returns a complete list of all address books available to the user. The FIND ALL.ADDRESSBOOKS command will return some set of unsolicited ADDRESSBOOK replies that have as their value a single address book name and a set of address book attributes. EXAMPLE: A002 FIND ALL.ADDRESSBOOKS * * ADDRESSBOOK Fred () * ADDRESSBOOK Fred.public () A002 OK Find completed Responses * MAILBOX string attributes server_list This response occurs as a result of a FIND MAILBOXES, FIND ALL.MAILBOXES, or FIND UNSEEN.MAILBOXES command. The string is a mailbox name that matches the pattern in the command. attributes is an S-expression list of mailbox attributes. server_list is an S-expression list of the fully qualified domain names of the hosts on which the mailbox resides. The defined mailbox attributes are: ¥SUBSCRIBED FIND MAILBOXES command will return mailbox ¥UNSEEN FIND UNSEEN.MAILBOXES command will return mailbox An IMSP client must be able to accept attributes it does not understand. Should the server_list contain more than one host name, the client should access the mailbox by attempting to connect to each server until one connection succeeds. The client should attempt each possible host in the sequence listed unless it has good reason to do otherwise (such as an already-open connection or geographic information). * BBOARD string attributes server_list This response occurs as a result of a FIND BBOARDS, FIND ALL.BBOARDS, or FIND UNSEEN.BBOARDS command. The string is a bboard name that matches the pattern in the command. attributes is an S-expression list of bboard attributes. server_list is an S-expression list of the fully qualified domain names of the hosts on which the bboard resides. The defined bboard attributes are: ¥SUBSCRIBED FIND BBOARDS command will return bboard ¥UNSEEN FIND UNSEEN.BBOARDS command will return bboard An IMSP client must be able to accept attributes it does not understand. Should the server_list contain more than one host name, the client should access the bboard by attempting to connect to each server until one connection succeeds. The client should attempt each possible host in the sequence listed unless it has good reason to do otherwise (such as an already-open connection or geographic information). * ADDRESSBOOK string attributes This response occurs as a result of a FIND ALL.ADDRESSBOOKS command. The string is an address book name that matches the pattern in the command. attributes is an S-expression list of addressbook attributes. There are no defined addressbook attributes. An IMSP client must be able to accept attributes it does not understand. Discussion When a user asks a client to read a bboard by name, the client should issue a "FIND ALL.BBOARDS" command to the IMSP server in order to determine which server it is on. The attribute list corrects a minor design flaw in IMAP2bis: without it the MAILBOX/BBOARD unsolicited response has an ambiguous meaning--one can only tell if the folder is subscribed or not by figuring out whether it is a response to a FIND foo or a FIND ALL.foo command. The following is a possible implementation of the FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS commands: When a message is appended to a folder, the IMAP server notifies the IMSP server of some unique (within the folder) attribute of the message. Possibile attributes include the message-id and the internaldate. This could be done using an IMSP extension: tag LAST MAILBOX mailbox attribute user tag LAST BBOARD bboard attribute When a user switches folders or closes a connection and has seen all messages in that folder, the IMAP server notifies the IMSP server that the user has read all of the messages, including the attribute of the last message. This too could be done using an IMSP extension: tag SEEN MAILBOX mailbox attribute user tag SEEN BBOARD bboard attribute user When asked for folders with messages unseen by the user, the IMSP server can check the attribute of the message last reported for the user against the attribute of the message last appended to the folder. In the interest of having the IMAP server/IMSP server communications be the same across implementation, it might be worthwhile to propose this method of implementing FIND UNSEEN.MAILBOXES and FIND UNSEEN.BBOARDS as a standard. Subscription management tag SUBSCRIBE MAILBOX mailbox The SUBSCRIBE MAILBOX command adds the specified mailbox name to the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE MAILBOX mailbox The UNSUBSCRIBE MAILBOX command removes the specified mailbox name from the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. tag SUBSCRIBE BBOARD bboard The SUBSCRIBE BBOARD command adds the specified mailbox name to the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the subscription is successful. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE BBOARD bboard The UNSUBSCRIBE BBOARD command removes the specified mailbox name from the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the unsubscription is successful. Unsubscriptions should be preserved between sessions. Mailbox and BBoard management tag CREATE mailbox tag CREATE mailbox server_partition_list The CREATE command creates a mailbox with the given name. This command returns an OK response only if a new mailbox with that name has been created. It is an error to attempt to create a mailbox with a name that refers to an extant mailbox. Any error in creation will return a NO response. Creating INBOX is not permitted. If there is a primary or default mailbox for this user, it MUST exist and be called INBOX; hence it may not be created. Otherwise, the name INBOX can not be used; see section VI, "INBOX Requirement Loosened", of IMAP2bis [IMAP2bis] for more details. If server_partition_list is specified, it indicates the server or set of servers on which the mailbox is to be created. Each hostname in the list may be followed by a slash character and an atom. The atom specifies in an implementation-dependent manner where to store the mailbox on the server. EXAMPLE: A002 CREATE FOOBAR (imap2.do.main/a imap4.do.main) A002 OK Create completed If server_partition_list is not specified, the placement of the mailbox is up to the implementation. tag DELETE mailbox tag DELETE mailbox hostname The DELETE command deletes a mailbox with the given name. This command returns an OK response only if a mailbox with that name has been deleted. It is an error to attempt to delete a mailbox name that does not exist. Any error in deletion will return a NO response. A server SHOULD NOT attempt to test that a mailbox is empty prior to permitting deletion; this would prevent the deletion of a mailbox which for some reason can not be opened or expunged, leaving to possible denial of service problems. Any such checking should be left to the discretion of the client. Deleting INBOX is not permitted. If hostname is specified, the mailbox is deleted on that host. If it is not specified, the mailbox is deleted on all hosts on which the mailbox resides. tag RENAME oldmailbox newmailbox The RENAME command changes the name of a mailbox. This command returns an OK response only if a mailbox with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old mailbox name that does not exist or a new mailbox name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to "oldmailbox", they will subsequently be subscribed to "newmailbox". Renaming INBOX is permitted. A new, empty INBOX is created in its place. Should users be subscribed to the INBOX, they will remain subscribed to the new, empty INBOX as well as being subscribed to "newmailbox". tag MOVE mailbox hostname server_partition_list The MOVE command moves a mailbox between servers and/or replicates a mailbox. Hostname specifies where the move is to be made from and server_partition_list specifies where the move is to be made to. The interpretation of server_partition_list is the same as for the CREATE command. tag CREATE.BBOARD bboard tag CREATE.BBOARD bboard server_partition_list The CREATE.BBOARD command creates a bboard with the given name. This command returns an OK response only if a new bboard with that name has been created. It is an error to attempt to create a bboard with a name that refers to an extant bboard. Any error in creation will return a NO response. If server_partition_list is specified, it indicates the server or set of servers on which the bboard is to be created. Each hostname in the list may be followed by a slash character and an atom. The atom specifies in an implementation-dependent manner where to store the bboard on the server. EXAMPLE: A002 CREATE.BBOARD FOOBAR (imap2.do.main/a map4.do.main) A002 OK Create completed If server_partition_list is not specified, the placement of the bboard is up to the implementation. tag DELETE.BBOARD bboard tag DELETE.BBOARD bboard hostname The DELETE.BBOARD command deletes a bboard with the given name. This command returns an OK response only if a bboard with that name has been deleted. It is an error to attempt to delete a bboard name that does not exist. Any error in deletion will return a NO response. If hostname is specified, the bboard is deleted on that host. If it is not specified, the bboard is deleted on all hosts on which the bboard resides. tag RENAME.BBOARD oldbboard newbboard The RENAME.BBOARD command changes the name of a bboard. This command returns an OK response only if a bboard with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old bboard name that does not exist or a new bboard name which already exists. Any error in renaming will return a NO response. Should any users be subscribed to "oldbboard", they will subsequently be subscribed to "newbboard". tag REPLACE.BBOARD oldbboard newbboard The REPLACE.BBOARD command deletes a bboard, automatically changing subscriptions to a new bboard. This command returns an OK response only if a bboard with the old name exists, a bboard with the new name exists, and if the bboard with the old name has successfully been deleted. It is an error to attempt to delete a bboard name or change subscriptions to a bboard name that does not exist. Any error in deletion will return a NO response. Should any users be subscribed to "oldbboard", they will subsequently be subscribed to "newbboard". tag MOVE.BBOARD bboard hostname server_partition_list The MOVE.BBOARD command moves a bboard between servers and/or replicates a bboard. Hostname specifies where the move is to be made from and server_partition_list specifies where the move is to be made to. The interpretation of server_partition_list is the same as for the CREATE command. Discussion Of course, local administrative policy may restrict use of these commands. Implementations may use this as justification for not implementing partitions, multiple locations for mailboxes/bboards, or the MOVE and MOVE.BBOARD commands. MOVE and MOVE.BBOARD cannot be implemented without some non-IMAP2 communication with the IMAP servers. Replication requires some communication between IMAP servers. CREATE.BBOARD, DELETE.BBOARD, and RENAME.BBOARD, and partitions require IMAP protocol extensions. Everything else can be implemented through the use of IMAP2bis commands. User configuration information Commands tag GET pattern The GET command accepts as an argument a pattern that specifies some set of configuration options. Wildcards are permitted as in FIND MAILBOXES. Option names are case-insensitive. The GET command will return some set of unsolicited OPTION replies, giving the names and values of matching options. Example: A002 GET SENT* * OPTION SENT.MAILBOX SENT-MAIL [READ-WRITE] A002 OK Get completed tag SET option value The SET command accepts as arguments the name of an option and a string value. The value of the option is set to the specified string. If the option with that name does not already exist, it is created. Option names are case-insensitive atoms. SET is not allowed if the named option is read-only. tag UNSET option The UNSET command accepts as an argument the name of an option. Depending on the implementation, the option is either removed or its value reverts to the implementation-defined default. UNSET is not allowed if the named option is read-only. Responses * OPTION atom string string This response occurs as a result of a GET command. The first string is an option name that matches the pattern in the command. The second string is the value of the option. The third string is either [READ-WRITE] if the user may change the option or [READ-ONLY] if the user may not. Discussion Options can be site wide or per-user. Possible uses include: User preferences (e.g. mailbox to store copies of outgoing mail) Site configuration information (e.g. names of SMTP servers) Per-user configuration information (e.g. contents of From: header) The option namespace could be split into a section for standard options and sections for client-specific options. Possible standard options include: DATE (current time, in rfc822 format) DOMAIN (local mail domain) FROM (string to use for From: header) DELIVERY.HOSTS (list of smtp hosts for mail submission) SENT.MAILBOX (mailbox to store copies of outgoing mail) Address book Commands tag SEARCHADDRESS addressbook lookup_criteria The SEARCHADDRESS command searches the specified address book for entries that express the intersection (AND function) of all of the specified criteria. The names matching the criteria are returned in an unsolicited SEARCHADDRESS repliey. If no criterea are specified, all names in the address book are provided. The lookup_criteria is a sequence of "field pattern" pairs, each specifying entries where the value of field matches the specified pattern in a case-independent manner. The pattern may optionally be an RFC-1342 format multinational character string. The reserved field "name" specifies entries whose name matches the specified pattern. EXAMPLE: A0340 SEARCHADDRESS Fred name "* Rubble" email "*@bedrock" * SEARCHADDRESS "Barney Rubble" "Betty Rubble" A0340 OK Searchaddress completed tag FETCHADDRESS addressbook names Fetches the contents of the entries in the specified address book for the specified names. The entries are returned in a series of unsolicited FETCHADDRESS replies. Entry names are case-insensitive. EXAMPLE: A0341 FETCHADDRESS Fred "Barney Rubble" * FETCHADDRESS Fred "Barney Rubble" hair "blond" email "barney@bedrock" A0341 OK Fetchaddress completed tag STOREADDRESS addressbook name field_data Creates or modifies the entry in the specified addressbook for the specified name. Fields not specified in the command are not changed. Setting the value of a field to the null string removes the field. Entry names are case-insensitive strings. The reserved field name "name" may not be specified in field_data. EXAMPLE: A0342 STOREADDRESS Fred "Barney Rubble" phone "555" email "" * FETCHADDRESS Fred "Barney Rubble" hair "blond" phone "555" A0342 OK Storeaddress completed tag DELETEADDRESS addressbook name Removes the entry in the specified addressbook for the specified name. Responses * SEARCHADDRESS addressbook <1#name> This response occurs as a result of a SEARCHADDRESS command. The name(s) refer to those address book entries that match the search criteria. * FETCHADDRESS addressbook name field_data This is the means by which address book entries are returned to the client. The entry for name in addressbook contains field_data. Discussion Address books provide a way for users to store and search typed information. They are primarily intended to be used for storing information about entities with which the user communicates. The addressbook field to the various commands allows users to access address books belonging to other users, should they have the appropriate access. Servers are expected to at least allow the client to manipulate the address book with the same name as the "user" specified in the LOGIN command. Servers may accept "addressbook" values that do not correspond to users that may LOGIN. Each address book contains some number of entries. Each entry has a name and any number of fields. Each field has an atom name and a string value. The standard fields are: EMAIL CRLF-separated list of electronic mail addresses MEMBERS CRLF-separated list of address book entries which should be recursively expanded when sending mail to the address book entry. PHONE CRLF-separated list of phone numbers ADDRESS Postal address An entry may also have additional, user-defined fields. Clients are expected to allow the user to view and modify all fields of an entry, even if they do not recognize some field names. [Need to define syntax for MEMBERS entries which refer to other address books.] Advisory Locking Commands tag LOCK OPTION option The LOCK OPTION command accepts as an argument the name of an option and attempts to acquire an exclusive semaphore. The named option need not exist. If the command is successful, the server must ensure that no other client will be able to successfully lock the named option until the successful client either performs a matching UNLOCK OPTION command or closes the connection. If the named option exists, the server then must ensure that the client's cached value of the option is up to date, by sending an unsolicited OPTION reply if necessary. If some other client has obtained the semaphore, the server must send a NO response, with the first word of the text being the token "[LOCKED]". The server should ensure that the client has permission to perform a SET operation on the option. Even though other clients may not perform a LOCK OPTION operation on the option, servers should not prevent them from performing SET operations on the option. EXAMPLE: A0067 LOCK OPTION SENT.MAILBOX * OPTION SENT.MAILBOX SENT-1993 A0067 OK Lock completed A0068 LOCK OPTION DELIVERY.HOSTS A0068 NO [LOCKED] Locked by Fred on client3.do.main tag UNLOCK OPTION option The UNLOCK OPTION command accepts as an argument the name of an option and releases any exclusive semaphore the client may have previously obtained on that option by using the LOCK OPTION command. tag LOCK ADDRESSBOOK addressbook name The LOCK ADDRESSBOOK command accepts as arguments an addressbook and the name of an entry. It attempts to acquire an exclusive semaphore. The addressbook must exist, but the named entry need not. If the command is successful, the server must ensure that no other client will be able to successfully lock the named entry in the addressbook until the successful client either performs a matching UNLOCK ADDRESSBOOK command or closes the connection. If the named option exists, the server then must ensure that the client's cached value of the entry is up to date, by sending an unsolicited FETCHADDRESS reply if necessary. If some other client has obtained the semaphore, the server must send a NO response, with the first word of the text being the token "[LOCKED]". The server should ensure that the client has permission to perform a STOREADDRESS operation on the entry. Even though other clients may not perform a LOCK ADDRESSBOOK operation on the entry, servers should not prevent them from performing STOREADDRESS operations on the entry. EXAMPLE: A0069 LOCK ADDRESSBOOK Fred barney * FETCHADDRESS Fred barney email "barney@bedrock" A0069 OK Lock completed A0070 LOCK ADDRESSBOOK Shared-book "Bam Bam" A0070 NO [LOCKED] Locked by Barney on client7.do.main tag UNLOCK ADDRESSBOOK addressbook name The UNLOCK ADDRESSBOOK command accepts as an arguments an adressbook and the name of an entry. It releases any exclusive semaphore the client may have previously obtained on that option by using the LOCK ADDRESSBOOK command. Discussion These commands allow cooperating clients to synchronize their updates to options and addressbooks. The ability to lock nonexistent options or address book entries allows clients to synchronize the addition of new options or address book entries. Although the locking interface is specified with a per-option and per-entry granularity, a server may implement the commands with a coarser granularity, say, per-user for options and per-addressbook for addressbooks. Access control lists Commands tag SETACL MAILBOX mailbox identifier rights Changes the access control list on the specified mailbox so that the specified identifier is granted the permissions enumerated in rights. Identifier has implementation-defined semantics. Possible variations of identifier interpretation include: * User names, as specified in the LOGIN command. * Named groups of users, presumably managed by some authorization service. * Only allowing identifiers supported by the operating system (e.g. ``user'', ``group'', and ``other'' for the Unix filesystem) * Whether rights granted to other mailboxes in an implementation-defined hierarchy are inherited * A portion of the identifier specifying an "authentication type". As an example, an implementation may control posting to a group based on the contents of the From: header: from$user p * Whether the union of rights for matching identifiers are granted to a user or whether the rights for the most specific matching identifier is granted. As an example, for a mailbox with the following ACL: user lrsa group-user-is-in lrsw One implementation may grant the user 'lrswa' rights, another may only grant the user 'lrsa'. * A prefix to an identifier name specifying the listed rights are to be removed from users who match the prefixed identifier. As an example, for a mailbox with the following ACL: group-user-is-in lrsw -user w An implementation may grant the user 'lrs' rights. Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations which is being controlled. Letters [lowercase?] are reserved for ``standard'' rights, listed below. Digits are reserved for implementation or site defined rights. The standard rights are: l - lookup (folder is visible to FIND commands) r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, SEARCH, COPY from mailbox) s - keep seen/unseen information across sessions (STORE ¥SEEN flag) w - write (STORE flags other than ¥SEEN and ¥DELETED) i - insert (perform APPEND, COPY into mailbox) p - post (send mail to submission address for mailbox, not enforced by IMAP2/IMSP itself) c - create (CREATE new sub-folders in any implementation-defined hierarchy) d - delete (STORE ¥DELETED flag, perform EXPUNGE) a - administer (perform SETACL) An implementation may tie rights together or may force rights to always or never be granted. For example, in an implementation that uses unix mode bits, the rights "wisd" are tied. The "a" right is always granted to the owner and is never granted to another user. If rights are tied in an implementation, it should be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none should be used. Numeric rights may not be tied. tag SETACL BBOARD bboard identifier rights Changes the access control list on the specified bboard so that the specified identifier is granted the permissions enumerated in rights. Identifier and rights are as specified for SETACL MAILBOX. tag SETACL ADDRESSBOOK addressbook identifier rights Changes the access control list of the specified addressbook so that the specified identifier is granted the permissions enumerated in rights. Identifier and rights are as specified for SETACL MAILBOX. Not all rights specified in SETACL MAILBOX will be meaningful for an address book. tag DELETEACL MAILBOX mailbox identifier Removes any portion of the access control list for mailbox for the specified identifier. tag DELETEACL BBOARD bboard identifier Removes any portion of the access control list for bboard for the specified identifier. tag DELETEACL ADDRESSBOOK addressbook identifier Removes any portion of the access control list for the specified addressbook for the specified identifier. tag GETACL MAILBOX mailbox Returns the access control list for mailbox in some set of unsolicited ACL replies. There may not be more than one ACL reply specifying any given identifier. EXAMPLE: A002 GETACL MAILBOX INBOX * ACL MAILBOX INBOX Fred rwipslda A002 Ok Getacl complete tag GETACL BBOARD bboard Returns the access control list for bboard in some set of unsolicited ACL replies. EXAMPLE: A002 GETACL BBOARD comp.mail.mime * ACL BBOARD comp.mail.mime anybody-else rpsl * ACL BBOARD comp.mail.mime news rwipcsld A002 Ok Getacl complete tag GETACL ADDRESSBOOK addressbook Returns the access control list for the specified addressbook in some set of unsolicited ACL replies. EXAMPLE: A002 GETACL ADDRESSBOOK Fred * ACL ADDRESSBOOK Fred anybody-else r * ACL ADDRESSBOOK Fred Fred rwipd A002 Ok Getacl complete tag MYACL MAILBOX mailbox Returns the set of rights that the user has to mailbox in an unsolicited MYACL reply. tag MYACL BBOARD mailbox Returns the set of rights that the user has to bboard in an unsolicited MYACL reply. tag MYACL ADDRESSBOOK addressbook Returns the set of rights that the user has to the specified addressbook in an unsolicited MYACL reply. Responses * ACL MAILBOX string string string This response occurs as a result of a GETACL MAILBOX command. The first string is the mailbox name for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * ACL BBOARD string string string This response occurs as a result of a GETACL BBOARD command. The first string is the bboard name for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * ACL ADDRESSBOOK string string string This response occurs as a result of a GETACL ADDRESSBOOK command. The first string is the addressbook for which this ACL entry applies. The second string is the identifier for which this entry applies. The third string is the set of rights that the identifier has. * MYACL MAILBOX string string This response occurs as a result of a MYACL MAILBOX command. The first string is the mailbox name for which this ACL entry applies. The third string is the set of rights that the client has. * MYACL BBOARD string string This response occurs as a result of a MYACL BBOARD command. The first string is the bboard name for which this ACL entry applies. The third string is the set of rights that the client has. * MYACL ADDRESSBOOK string string This response occurs as a result of a MYACL ADDRESSBOOK command. The first string is the addressbook for which this ACL entry applies. The second string is the set of rights that the client has. Discussion The assignment of letters to rights is AFS-centric. Alternatively we could change i->a, l->v, a->what?. The set of rights should make some sense in other messaging domains, particularly NNTP. The IMSP and NNTP ACL specifications should be similar. The IMSP author will work with the author of the NNTP ACL extension in order to resolve this. It is not resolved whether address book ACLs should be per-addressbook (as specified here) or per-entry. Unresolved issues The following mail support issues have been raised, but not resolved in IMSP. * User forwarding address This probably belongs in a separate user directory service. * Mail filing control (e.g. ``vacation'', delivery of mail to folders other than INBOX based on subject, sender) This probably belongs in a separate service, quite possibly a user directory service. * Administrative issues: Purge rates for bboards (not necessarily age related) Quotas for users or bboards (not necessarily megabyte related) Quotas probably should be done through private extensions to IMAP. Purge rates may want to be stored in private extensions to IMSP. * Notification issues Current use of quota Exhaustion of quota Renamed/deleted folders/bboards For quota exhaustion, use IMAP unsolicited OK/NO messages. For renamed/deleted/replaced folders/bboards, server should notify, then change or delete subscription as necessary. Minimal conformance Implementation of the following commands is mandatory: NOOP LOGIN LOGOUT FIND MAILBOXES FIND ALL.MAILBOXES FIND UNSEEN.MAILBOXES FIND BBOARDS FIND ALL.BBOARDS FIND UNSEEN.BBOARDS FIND ALL.ADDRESSBOOKS SUBSCRIBE MAILBOX SUBSCRIBE BBOARD UNSUBSCRIBE MAILBOX UNSUBSCRIBE BBOARD CREATE (server_partition_list argument is optional) DELETE RENAME GET SET SEARCHADDRESS FETCHADDRESS STOREADDRESS DELETEADDRESS LOCK UNLOCK Backwards compatibility When a client is directed by a user or an initial configuration to contact a server, it should first attempt to reach the IMSP service. If that fails with connection refused, it should fall back to the IMAP2 protocol. Conventions The following terms are used in a meta-sense in the syntax specification below: An ASCII-STRING is a sequence of arbitrary ASCII characters. A CHARACTER is any ASCII character except """", CR, or LF. An ATOM is a sequence of CHARACTERs delimited by SP or CRLF. An ATOM may not start with a "{". A CRLF is an ASCII carriage-return character followed immediately by an ASCII linefeed character. A NUMBER is a sequence of the ASCII characters that represent decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or ":". A SP is the ASCII space character. A TEXT_LINE is a human-readable sequence of ASCII characters up to but not including a terminating CRLF. A common field in the IMSP protocol is a STRING, which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), or a LITERAL. A literal consists of an open brace ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, where n is the value of the number inside the brace. In general, a string should be represented as an ATOM or QUOTED-STRING if at all possible. Literals are most often sent from the server to the client; in the rare case of a client to server literal there is a special consideration (see the "+ text" response above). Note the set of allowable CHARACTERs is larger than specified for IMAP2. Formal syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma. acl_reply ::= "ACL" acl_option SP string SP string SP string acl_option ::= "MAILBOX" / "BBOARD" / "ADDRESSBOOK" address_reply ::= "ADDRESSBOOK" SP string SP "(" 0#name ")" alias_bboard ::= "ALIAS.BBOARD" SP string SP string bboard_reply ::= "BBOARD" SP string SP "(" 0#atom ")" SP "(" 1#hostname ")" create ::= "CREATE" SP mailbox [ SP server_partition_list ] create_bboard ::= "CREATE.BBOARD" SP string [ SP server_partition_list ] delete ::= "DELETE" SP mailbox [ SP hostname ] deleteaddress ::= "DELETEADDRESS" SP userid SP name delete_bboard ::= "DELETE.BBOARD" SP string [ SP hostname ] fetchaddress ::= "FETCHADDRESS" SP userid 1#( SP name ) fetchaddress_r ::= "FETCHADDRESS" SP userid SP name field_data field_data ::= 1#key_value find ::= "FIND" SP find_option SP string find_option ::= "MAILBOXES" / "ALL.MAILBOXES" / "UNSEEN.MAILBOXES / "BBOARDS" / "ALL.BBOARDS" / "UNSEEN.BBOARDS" / "ALL.ADDRESSBOOKS" get ::= "GET" SP string getacl ::= "GETACL" SP acl_option SP string hostname ::= atom ; Fully qualified domain name key_value ::= SP atom SP string literal ::= "{" NUMBER "}" CRLF ASCII-STRING login ::= "LOGIN" SP userid SP password logout ::= "LOGOUT" lookup_criterea ::= 0#( SP key SP pattern ) mailbox ::= "INBOX" / string mailbox_reply ::= "MAILBOX" SP string SP "(" 0#atom ")" SP "(" 1#hostname ")" move ::= "MOVE" SP mailbox SP hostname SP server_partition_list move_bboard ::= "MOVE.BBOARD" SP string SP hostname SP server_partition_list myacl ::= "MYACL" SP acl_option SP string myacl_reply ::= "MYACL" acl_option SP string SP string name ::= quoted-string / atom noop ::= "NOOP" option_reply ::= "OPTION" SP atom SP string SP ("[READ-ONLY]" / "[READ-WRITE]") rename ::= "RENAME" SP mailbox SP string rename_bboard ::= "RENAME.BBOARD" SP string SP string request ::= tag SP (noop / login / logout / find / subscribe / unsubscribe / create / delete / rename / move / create_bboard / delete_bboard / rename_bboard / move_bboard / alias_bboard / get / set / searchaddress / fetchaddress / storeaddress / deleteaddress / getacl / setacl / myacl) CRLF response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF searchaddress ::= "SEARCHADDRESS" SP userid lookup_criteria searchaddress_r ::= "SEARCHADDRESS" SP userid 1#( SP name ) server_partition ::= hostname [ "/" atom ] server_partition_list ::= "(" 1#server_partition ")" set ::= "SET" SP atom SP string setacl ::= "SETACL" SP acl_option SP string SP string SP atom storeaddress ::= "STOREADDRESS" SP userid SP name field_data string ::= atom / """" 1*character """" / literal subscribe ::= "SUBSCRIBE" SP subscribe_opt SP string subscribe_opt ::= "MAILBOX" / "BBOARD" unsolicited ::= "*" SP (mailbox_reply / bboard_reply / address_reply / option_reply / searchaddress_r / fetchaddress_r / acl_reply / myacl_reply) CRLF unsubscribe ::= "UNSUBSCRIBE" SP subscribe_opt SP string userid ::= string References [RFC-1176] Crispin, Mark R. Interactive Mail Access Protocol - Version 2. August 1990. RFC-1176. [IMAP2bis] Crispin, Mark R. IMAP2bis - Extensions to the IMAP2 Protocol, December 1992 Author's Address John G. Myers Carnegie-Mellon University 5000 Forbes Ave. Pittsburgh PA, 15213-3890 Email: jgm+@cmu.edu From owner-imap@cac.washington.edu Wed Aug 4 12:10:33 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08964; Wed, 4 Aug 93 12:10:33 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12712; Wed, 4 Aug 93 12:10:12 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12706; Wed, 4 Aug 93 12:10:09 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id PAA10298; Wed, 4 Aug 1993 15:09:58 -0400 Received: via switchmail; Wed, 4 Aug 1993 15:09:57 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 4 Aug 1993 15:08:55 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 4 Aug 1993 15:08:54 -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, 4 Aug 1993 15:08:53 -0400 (EDT) Message-Id: <0gM0Z5y00WBw8LlnIV@andrew.cmu.edu> Date: Wed, 4 Aug 1993 15:08:53 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Changes to IMSP draft Beak: is Not *************** *** 4,10 **** Network Working Group J. G. Myers Request for Comments: ???? Carnegie Mellon ! July 1993 IMSP -- Interactive Mail Support Protocol --- 4,10 ---- Network Working Group J. G. Myers Request for Comments: ???? Carnegie Mellon ! August 1993 IMSP -- Interactive Mail Support Protocol *************** *** 716,724 **** The SEARCHADDRESS command searches the specified address book for entries that express the intersection (AND function) of all ! of the specified criteria. The aliases matching the criteria ! are returned in an unsolicited SEARCHADDRESS repliey. If no ! criterea are specified, all aliases in the address book are provided. The lookup_criteria is a sequence of "field pattern" pairs, each --- 716,724 ---- The SEARCHADDRESS command searches the specified address book for entries that express the intersection (AND function) of all ! of the specified criteria. The names matching the criteria are ! returned in an unsolicited SEARCHADDRESS repliey. If no ! criterea are specified, all names in the address book are provided. The lookup_criteria is a sequence of "field pattern" pairs, each *************** *** 725,775 **** specifying entries where the value of field matches the specified pattern in a case-independent manner. The pattern may optionally be an RFC-1342 format multinational character string. EXAMPLE: A0340 SEARCHADDRESS Fred name "* Rubble" email "*@bedrock" ! * SEARCHADDRESS barney betty A0340 OK Searchaddress completed ! tag FETCHADDRESS addressbook aliases Fetches the contents of the entries in the specified address ! book for the specified aliases. The entries are returned in a ! series of unsolicited FETCHADDRESS replies. ! ! EXAMPLE: A0341 FETCHADDRESS Fred barney ! * FETCHADDRESS Fred barney name "Barney Rubble" email ! "barney@bedrock" A0341 OK Fetchaddress completed ! tag STOREADDRESS addressbook alias field_data Creates or modifies the entry in the specified addressbook for ! the specified alias. Fields not specified in the command are not changed. Setting the value of a field to the null string removes the field. ! EXAMPLE: A0342 STOREADDRESS Fred barney phone "555" email "" ! * FETCHADDRESS Fred barney name "Barney Rubble" phone "555" A0342 OK Storeaddress completed ! tag DELETEADDRESS addressbook alias Removes the entry in the specified addressbook for the ! specified alias. Responses ! * SEARCHADDRESS addressbook <1#alias> This response occurs as a result of a SEARCHADDRESS command. ! The alias(es) refer to those address book entries that match the search criteria. ! * FETCHADDRESS addressbook alias field_data This is the means by which address book entries are returned to ! the client. The entry for alias in addressbook contains field_data. Discussion --- 725,781 ---- specifying entries where the value of field matches the specified pattern in a case-independent manner. The pattern may optionally be an RFC-1342 format multinational character string. + The reserved field "name" specifies entries whose name matches + the specified pattern. EXAMPLE: A0340 SEARCHADDRESS Fred name "* Rubble" email "*@bedrock" ! * SEARCHADDRESS "Barney Rubble" "Betty Rubble" A0340 OK Searchaddress completed ! tag FETCHADDRESS addressbook names Fetches the contents of the entries in the specified address ! book for the specified names. The entries are returned in a ! series of unsolicited FETCHADDRESS replies. Entry names are ! case-insensitive. ! ! EXAMPLE: A0341 FETCHADDRESS Fred "Barney Rubble" ! * FETCHADDRESS Fred "Barney Rubble" hair "blond" ! email "barney@bedrock" A0341 OK Fetchaddress completed ! tag STOREADDRESS addressbook name field_data Creates or modifies the entry in the specified addressbook for ! the specified name. Fields not specified in the command are not changed. Setting the value of a field to the null string removes the field. ! Entry names are case-insensitive strings. The reserved field ! name "name" may not be specified in field_data. ! ! EXAMPLE: A0342 STOREADDRESS Fred "Barney Rubble" phone "555" email "" ! * FETCHADDRESS Fred "Barney Rubble" hair "blond" phone "555" A0342 OK Storeaddress completed ! tag DELETEADDRESS addressbook name Removes the entry in the specified addressbook for the ! specified name. Responses ! * SEARCHADDRESS addressbook <1#name> This response occurs as a result of a SEARCHADDRESS command. ! The name(s) refer to those address book entries that match the search criteria. ! * FETCHADDRESS addressbook name field_data This is the means by which address book entries are returned to ! the client. The entry for name in addressbook contains field_data. Discussion *************** *** 787,800 **** "addressbook" values that do not correspond to users that may LOGIN. ! Each addres book contains some number of entries. Each entry ! is named by an alias and has any number of fields. Each field ! has an atom name and a string value. The standard fields are: - NAME A full name EMAIL CRLF-separated list of electronic mail addresses PHONE CRLF-separated list of phone numbers ADDRESS Postal address --- 793,808 ---- "addressbook" values that do not correspond to users that may LOGIN. ! Each address book contains some number of entries. Each entry ! has a name and any number of fields. Each field has an atom ! name and a string value. The standard fields are: EMAIL CRLF-separated list of electronic mail addresses + MEMBERS CRLF-separated list of address book entries + which should be recursively expanded when sending + mail to the address book entry. PHONE CRLF-separated list of phone numbers ADDRESS Postal address *************** *** 802,808 **** --- 810,910 ---- are expected to allow the user to view and modify all fields of an entry, even if they do not recognize some field names. + [Need to define syntax for MEMBERS entries which refer to other + address books.] + + Advisory Locking + + Commands + + tag LOCK OPTION option + The LOCK OPTION command accepts as an argument the name of an + option and attempts to acquire an exclusive semaphore. The + named option need not exist. + + If the command is successful, the server must ensure that no + other client will be able to successfully lock the named option + until the successful client either performs a matching UNLOCK + OPTION command or closes the connection. If the named option + exists, the server then must ensure that the client's cached + value of the option is up to date, by sending an unsolicited + OPTION reply if necessary. + + If some other client has obtained the semaphore, the server + must send a NO response, with the first word of the text being + the token "[LOCKED]". + + The server should ensure that the client has permission to + perform a SET operation on the option. Even though other + clients may not perform a LOCK OPTION operation on the option, + servers should not prevent them from performing SET operations + on the option. + + EXAMPLE: A0067 LOCK OPTION SENT.MAILBOX + * OPTION SENT.MAILBOX SENT-1993 + A0067 OK Lock completed + A0068 LOCK OPTION DELIVERY.HOSTS + A0068 NO [LOCKED] Locked by Fred on client3.do.main + + tag UNLOCK OPTION option + + The UNLOCK OPTION command accepts as an argument the name of an + option and releases any exclusive semaphore the client may have + previously obtained on that option by using the LOCK OPTION + command. + + tag LOCK ADDRESSBOOK addressbook name + + The LOCK ADDRESSBOOK command accepts as arguments an addressbook + and the name of an entry. It attempts to acquire an exclusive + semaphore. The addressbook must exist, but the named entry need + not. + + If the command is successful, the server must ensure that no + other client will be able to successfully lock the named entry + in the addressbook until the successful client either performs a + matching UNLOCK ADDRESSBOOK command or closes the connection. + If the named option exists, the server then must ensure that the + client's cached value of the entry is up to date, by sending an + unsolicited FETCHADDRESS reply if necessary. + + If some other client has obtained the semaphore, the server + must send a NO response, with the first word of the text being + the token "[LOCKED]". + + The server should ensure that the client has permission to + perform a STOREADDRESS operation on the entry. Even though + other clients may not perform a LOCK ADDRESSBOOK operation on + the entry, servers should not prevent them from performing + STOREADDRESS operations on the entry. + + EXAMPLE: A0069 LOCK ADDRESSBOOK Fred barney + * FETCHADDRESS Fred barney email "barney@bedrock" + A0069 OK Lock completed + A0070 LOCK ADDRESSBOOK Shared-book "Bam Bam" + A0070 NO [LOCKED] Locked by Barney on client7.do.main + + tag UNLOCK ADDRESSBOOK addressbook name + + The UNLOCK ADDRESSBOOK command accepts as an arguments an + adressbook and the name of an entry. It releases any exclusive + semaphore the client may have previously obtained on that option + by using the LOCK ADDRESSBOOK command. + + Discussion + + These commands allow cooperating clients to synchronize their + updates to options and addressbooks. The ability to lock + nonexistent options or address book entries allows clients to + synchronize the addition of new options or address book entries. + + Although the locking interface is specified with a per-option + and per-entry granularity, a server may implement the commands + with a coarser granularity, say, per-user for options and + per-addressbook for addressbooks. + + Access control lists Commands *************** *** 1085,1090 **** --- 1187,1194 ---- FETCHADDRESS STOREADDRESS DELETEADDRESS + LOCK + UNLOCK Backwards compatibility *************** *** 1141,1147 **** acl_option ::= "MAILBOX" / "BBOARD" / "ADDRESSBOOK" ! address_reply ::= "ADDRESSBOOK" SP string SP "(" 0#atom ")" alias_bboard ::= "ALIAS.BBOARD" SP string SP string --- 1245,1251 ---- acl_option ::= "MAILBOX" / "BBOARD" / "ADDRESSBOOK" ! address_reply ::= "ADDRESSBOOK" SP string SP "(" 0#name ")" alias_bboard ::= "ALIAS.BBOARD" SP string SP string *************** *** 1154,1166 **** delete ::= "DELETE" SP mailbox [ SP hostname ] ! deleteaddress ::= "DELETEADDRESS" SP userid SP atom delete_bboard ::= "DELETE.BBOARD" SP string [ SP hostname ] ! fetchaddress ::= "FETCHADDRESS" SP userid 1#( SP atom ) ! fetchaddress_r ::= "FETCHADDRESS" SP userid SP atom field_data field_data ::= 1#key_value --- 1258,1270 ---- delete ::= "DELETE" SP mailbox [ SP hostname ] ! deleteaddress ::= "DELETEADDRESS" SP userid SP name delete_bboard ::= "DELETE.BBOARD" SP string [ SP hostname ] ! fetchaddress ::= "FETCHADDRESS" SP userid 1#( SP name ) ! fetchaddress_r ::= "FETCHADDRESS" SP userid SP name field_data field_data ::= 1#key_value *************** *** 1200,1205 **** --- 1304,1311 ---- myacl_reply ::= "MYACL" acl_option SP string SP string + name ::= quoted-string / atom + noop ::= "NOOP" option_reply ::= "OPTION" SP atom SP string SP *************** *** 1222,1228 **** searchaddress ::= "SEARCHADDRESS" SP userid lookup_criteria ! searchaddress_r ::= "SEARCHADDRESS" SP userid 1#( SP atom ) server_partition ::= hostname [ "/" atom ] --- 1328,1334 ---- searchaddress ::= "SEARCHADDRESS" SP userid lookup_criteria ! searchaddress_r ::= "SEARCHADDRESS" SP userid 1#( SP name ) server_partition ::= hostname [ "/" atom ] *************** *** 1233,1239 **** setacl ::= "SETACL" SP acl_option SP string SP string SP atom ! storeaddress ::= "STOREADDRESS" SP userid SP atom field_data string ::= atom / """" 1*character """" / literal --- 1339,1345 ---- setacl ::= "SETACL" SP acl_option SP string SP string SP atom ! storeaddress ::= "STOREADDRESS" SP userid SP name field_data string ::= atom / """" 1*character """" / literal From owner-imap@cac.washington.edu Wed Aug 4 12:38:58 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09568; Wed, 4 Aug 93 12:38:58 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13176; Wed, 4 Aug 93 12:38:40 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13168; Wed, 4 Aug 93 12:38:38 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id PAA10767; Wed, 4 Aug 1993 15:38:35 -0400 Received: via switchmail; Wed, 4 Aug 1993 15:38:34 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 4 Aug 1993 15:38:13 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 4 Aug 1993 15:38:11 -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, 4 Aug 1993 15:38:09 -0400 (EDT) Message-Id: Date: Wed, 4 Aug 1993 15:38:09 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Interactive Mail Support Protocol In-Reply-To: References: Beak: Is Laurence Lundblade writes: > I think a very nice simple solution would be to have the protocol send the > size or number of items before they're actually sent. I'm still trying to figure out how one would define this within the unsolicited data model, in a way that doesn't preclude streaming and/or concurrency. For FIND, my personal opinion is that an interface which permits a user to view/browse a scrolled object while the object is still being filled in is better than one which gives the user a progress bar which must reach 100% before the user is permitted to perform any actions. > What about an ABORT command with tag matching the operation in progress > to abort. Granted it makes client writing harder, but we're generally > evolving to more sophisticated clients anyway. This presumes the server is listening and handling commands while doing the operation. We want to permit concurrency, but not require it. I'm also reluctant to define something which is unlikely to be implemented. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Wed Aug 4 13:18:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10709; Wed, 4 Aug 93 13:18:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13837; Wed, 4 Aug 93 13:18:21 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13831; Wed, 4 Aug 93 13:18:20 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21182; Wed, 4 Aug 93 13:18:17 -0700 Date: Wed, 4 Aug 1993 13:12:52 -0700 (PDT) From: David L Miller Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 4 Aug 1993, John Gardiner Myers wrote: > For FIND, my personal opinion is that an interface which permits a > user to view/browse a scrolled object while the object is still being > filled in is better than one which gives the user a progress bar which > must reach 100% before the user is permitted to perform any actions. > How do you apply a sort to the results of a find and display it while it is being filled in? An on-screen insertion sort maybe? There are many cases, like threaded newsreading, that require a sort operation between a FIND and the display operation. A status bar makes much more sense in that case. -- |¥ | |¥/| 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 From owner-imap@cac.washington.edu Wed Aug 4 14:09:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12298; Wed, 4 Aug 93 14:09:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14670; Wed, 4 Aug 93 14:08:47 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14664; Wed, 4 Aug 93 14:08:46 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA09481; Wed, 4 Aug 93 14:08:42 -0700 Date: Wed, 4 Aug 1993 14:02:16 -0700 (PDT) From: Laurence Lundblade Reply-To: Laurence Lundblade Subject: Re: Interactive Mail Support Protocol To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On 4 Aug 1993, John Gardiner Myers wrote: > Laurence Lundblade writes: > > I think a very nice simple solution would be to have the protocol send the > > size or number of items before they're actually sent. > > I'm still trying to figure out how one would define this within the > unsolicited data model, in a way that doesn't preclude streaming > and/or concurrency. > > For FIND, my personal opinion is that an interface which permits a > user to view/browse a scrolled object while the object is still being > filled in is better than one which gives the user a progress bar which > must reach 100% before the user is permitted to perform any actions. Sure, that's great, but the user will still probably want to know when the list is complete and how long it's going to take before it is complete. I must admit I don't understand what the concurrency buys you in case of something like a FIND. (can you give an example?) Also in a sense a FIND is somewhat serialized in that first the client sends the FIND, then the results are sent by the server and then the tagged OK is sent by the server. How would adding a tagged response with the size of the result before the actual data upset any concurrency? > > What about an ABORT command with tag matching the operation in progress > > to abort. Granted it makes client writing harder, but we're generally > > evolving to more sophisticated clients anyway. > > This presumes the server is listening and handling commands while > doing the operation. We want to permit concurrency, but not require > it. I'm also reluctant to define something which is unlikely to be > implemented. Yes, I know what you mean, having implemented such a server once. It wasn't that hard on a UNIX box when the server was designed from the ground up with this in mind. Perhaps this is a problem on some other potential (and with aging OS's) platforms. Seems like a trade off between server implementation complexity and end usability. Most of my concerns are based on the fact that PC, Mac, NeXT and other software keeps upping the usability standard users are familiar with. These sorts of improvements will help IMAP & Internet mail spread beyond its current usage. That is, users will chose technology based on how usable it is, not on underlying technical merits. LL From owner-imap@cac.washington.edu Wed Aug 4 23:52:50 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22025; Wed, 4 Aug 93 23:52:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03889; Wed, 4 Aug 93 23:52:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03883; Wed, 4 Aug 93 23:52:30 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA27957; Wed, 4 Aug 93 23:52:29 -0700 Date: Wed, 4 Aug 1993 23:50:24 -0700 (PDT) From: Mark Crispin Subject: [Bruce Lilly: Suggested extension to IMAP2bis] To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I don't have any particular strong feelings about this either way, but here it is on the table anyway. Considering the bad experiences people had with the infamous Internet Worm and the SMTP debug command, it won't go into the specification unless there is a strong vote of support for it. ** Begin Forwarded Message ** Date: Wed, 4 Aug 1993 12:08:10 -0400 (EDT) From: Bruce Lilly Subject: Suggested extension to IMAP2bis To: Mark Crispin Mark, I'm still working on porting imap3.0 and pine3.07 to SVR2.2. In order to facilitate debugging, I've added some syslog calls to the c-client code (for both pine and imapd). Eventually, I plan to disable the syslog calls at the LOG_DEBUG level, however it may be desirable to enable such debugging output at run time. I propose an additional command, "DEBUG", which would perform some implementation dependent action to facilitate debugging of the client-server communications without affecting the protocol exchange. Otherwise it should behave as a NOOP command. An optional argument of ON or OFF is permitted, with ON being the default. -- Bruce Lilly, Product Manager, | Routers, Peripherals & Still Store,| uupsi!monymsys!sonyd1!bruce Sony, 3 Paragon Drive, Montvale, | lillyb@ccmail.nhq.sony.com NJ 07645-1735 | Telephone: +1 201 358 4161 | FAX: +1 201 358 4274 From owner-imap@cac.washington.edu Thu Aug 5 04:17:04 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27004; Thu, 5 Aug 93 04:17:04 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04943; Thu, 5 Aug 93 04:16:44 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04937; Thu, 5 Aug 93 04:16:42 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA06151; Thu, 5 Aug 93 04:16:41 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA25216; Thu, 5 Aug 93 04:10:57 PDT Date: Thu, 5 Aug 93 04:10:57 PDT From: uucp@twinsun.com Message-Id: <9308051110.AA25216@twinsun.com> Apparently-To: imap@cac.washington.edu ons against legislating "a ``One True Model''" in IMAP, finally. I also almost like the idea of collections. The problem being that the items that can go into a collection seem to be really limited by the fact that find isn't very powerful. Could we add expressiveness to the current find to make it more useful? Or better yet add a regular expression find (perhaps making it optional)? Or should I just do a "FIND *", cache the results and then do regexp searches on the cache? makr From owner-imap@cac.washington.edu Thu Aug 5 10:36:50 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04437; Thu, 5 Aug 93 10:36:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06470; Thu, 5 Aug 93 10:36:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06464; Thu, 5 Aug 93 10:36:28 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA28353; Thu, 5 Aug 93 10:36:21 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA23793; Thu, 5 Aug 93 10:36:16 -0700 Date: Thu, 5 Aug 1993 10:32:32 -0700 (PDT) From: Mark Crispin Subject: (response to message of Thu, 5 Aug 93 04:10:57 PDT) To: IMAP Interest List In-Reply-To: <9308051110.AA25216@twinsun.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > find isn't very powerful. Could we add expressiveness to the current > find to make it more useful? Or better yet add a regular expression find It's been suggested, but the problem is how do you make it work with servers using an older version? That is, if you have to write the code to handle the old server case anyway, you'll just be duplicating code and perhaps have inconsistant behavior in subtle ways. > Or should I just do a "FIND *", cache the results and then do regexp > searches > on the cache? Or a FIND with a more restrictive wildcard that is still within what you want to do with the regexp, then use the regexp to narrow it down. Actually, this isn't all that bad or all that costly, and Pine does something very much like this now with its collections syntax. From owner-imap@cac.washington.edu Thu Aug 5 11:21:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05862; Thu, 5 Aug 93 11:21:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25607; Thu, 5 Aug 93 11:21:08 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25601; Thu, 5 Aug 93 11:21:07 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA16087; Thu, 5 Aug 93 11:21:06 -0700 Date: Thu, 5 Aug 1993 11:12:16 -0700 (PDT) From: Laurence Lundblade Subject: Patterns in FIND To: Imap Interest List In-Reply-To: <9308051110.AA25216@twinsun.com> Message-Id: References: <9308051110.AA25216@twinsun.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I don't think you can do a FIND * because that's not gauranteed to return the *whole* name space. It could be extremely large. I do think we need get a strawman out in the open on how the current FIND and patterns can be used to implement a heirarchy. Do you execute a FIND *, get back a list of names that can be used as prefixes for further FINDs? For example FIND * returns "foo", "goo" and "zue". Then you can do a FIND "foo*" to get stuff under that? This doesn't seem to work so well. Other ideas? LL P.S. You mail message didn't look so great when I received it. On 5 Aug 1993 uucp@twinsun.com wrote: >..... > > Or should I just do a "FIND *", cache the results and then do regexp searches > on the cache? > > makr > > > From owner-imap@cac.washington.edu Thu Aug 5 19:01:08 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17125; Thu, 5 Aug 93 19:01:08 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08943; Thu, 5 Aug 93 18:57:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08937; Thu, 5 Aug 93 18:57:56 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA28924; Thu, 5 Aug 93 18:57:53 -0700 Date: Thu, 5 Aug 1993 18:54:08 -0700 (PDT) From: Mark Crispin Subject: re: Patterns in FIND To: Laurence Lundblade Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 5 Aug 1993 11:12:16 -0700 (PDT), Laurence Lundblade wrote: > I don't think you can do a FIND * because that's not gauranteed to return > the > *whole* name space. This is arguably a bug or misfeature in the c-client based IMAP server, and as such may be fixed. > It could be extremely large. Such as all of the newsgroups? :-) > I do think we need get a > strawman out in the open on how the current FIND and patterns can be used to > implement a heirarchy. Better to suggest a couple of strawmen, so that people see that this is in fact an implementation views issue. From owner-imap@cac.washington.edu Thu Aug 5 22:14:05 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18969; Thu, 5 Aug 93 22:14:05 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09583; Thu, 5 Aug 93 22:13:40 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09577; Thu, 5 Aug 93 22:13:38 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA07962; Thu, 5 Aug 93 22:13:35 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA07677; Thu, 5 Aug 93 22:11:10 PDT Received: from ford.airco.co.jp by air.airco.co.jp (4.1/6.4J.6) id AA13055; Fri, 6 Aug 93 10:27:19 JST Received: from ford (localhost) by ford.airco.co.jp (4.1/6.4J.6) id AA09294; Fri, 6 Aug 93 10:21:19 JST Return-Path: Message-Id: <9308060121.AA09294@ford.airco.co.jp> Date: Fri, 6 Aug 1993 10:21:16 +0900 (JST) From: Mark Keasling Reply-To: Mark A Keasling Subject: Re: Patterns in FIND To: Laurence Lundblade Cc: Imap Interest List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 5 Aug 1993 11:12:16 -0700 (PDT) Laurence Lundblade wrote... > I don't think you can do a FIND * because that's not gauranteed to return the > *whole* name space. It could be extremely large. I do think we need get a > strawman out in the open on how the current FIND and patterns can be used to > implement a heirarchy. > Basically what I would like to have is the capability to specify a range of characters to match or not match depending on what I'm trying to do. One example for a hierarchy would be: FIND "some.folder.name[$PATH_SEPARATOR][^$PATH_SEPARATOR]*" Where $PATH_SEPARATOR is a user configurable variable. As it is I can Find "some.folder.name*" then process the results myself. However, if the number of names returned is large and the processed list is small it would be more efficient for the server to do the processing. > Do you execute a FIND *, get back a list of names that can be used as > prefixes for further FINDs? For example FIND * returns "foo", "goo" and > "zue". Then you can do a FIND "foo*" to get stuff under that? This > doesn't seem to work so well. Other ideas? > > LL > > P.S. You mail message didn't look so great when I received it. Ouch, I got bit by an UNTAMED feature. I hope this one looks better. :-S makr From owner-imap@cac.washington.edu Thu Aug 5 22:14:08 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18975; Thu, 5 Aug 93 22:14:08 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09591; Thu, 5 Aug 93 22:13:51 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Delphi.CS.UCLA.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09585; Thu, 5 Aug 93 22:13:49 -0700 Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA08014; Thu, 5 Aug 93 22:13:45 -0700 Received: by twinsun.com (4.1/SMI-4.1) id AA07689; Thu, 5 Aug 93 22:11:15 PDT Received: from ford.airco.co.jp by air.airco.co.jp (4.1/6.4J.6) id AA14669; Fri, 6 Aug 93 11:10:10 JST Received: from ford (localhost) by ford.airco.co.jp (4.1/6.4J.6) id AA09319; Fri, 6 Aug 93 11:04:09 JST Return-Path: Message-Id: <9308060204.AA09319@ford.airco.co.jp> Date: Fri, 6 Aug 1993 11:04:06 +0900 (JST) From: Mark Keasling Reply-To: Mark A Keasling Subject: Re: (response to message of Thu, 5 Aug 93 04:10:57 PDT) To: Mark Crispin Cc: imap@cac.washington.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 5 Aug 1993 10:32:32 -0700 (PDT) Mark Crispin wrote... > > find isn't very powerful. Could we add expressiveness to the current > > find to make it more useful? Or better yet add a regular expression find > > It's been suggested, but the problem is how do you make it work with servers > using an older version? That is, if you have to write the code to handle the > old server case anyway, you'll just be duplicating code and perhaps have > inconsistant behavior in subtle ways. > You have a point there. How many currently available servers would this effect? If the number is relatively small, a change now would hurt less than waiting. However, if we added a REGFIND or some such command old servers wouldn't necessarily have to be changed. When a client does a REGFIND and gets a BAD response, it could switch to the FIND command and the appropriate pattern syntax, notifying the user as necessary. > > Or should I just do a "FIND *", cache the results and then do regexp > > searches > > on the cache? > > Or a FIND with a more restrictive wildcard that is still within what you want > to do with the regexp, then use the regexp to narrow it down. Actually, this > isn't all that bad or all that costly, and Pine does something very much like > this now with its collections syntax. > This is would be reasonable in most cases. I just realized that if we modify FIND then SEARCH would also need to be changed since it uses the same pattern semantics. Hmmm. I think that having regular expressions as search pattens for FIND and SEARCH would be very useful but maybe not absolutely necessary. makr From owner-imap@cac.washington.edu Fri Aug 6 10:08:10 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01634; Fri, 6 Aug 93 10:08:10 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07673; Fri, 6 Aug 93 10:07:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07667; Fri, 6 Aug 93 10:07:18 -0700 Received: from localhost (postman@localhost) by andrew.cmu.edu (8.5/8.5) id NAA07696; Fri, 6 Aug 1993 13:07:12 -0400 Received: via switchmail; Fri, 6 Aug 1993 13:07:11 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 6 Aug 1993 13:06:08 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 6 Aug 1993 13:06:06 -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; Fri, 6 Aug 1993 13:06:00 -0400 (EDT) Message-Id: Date: Fri, 6 Aug 1993 13:06:00 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Patterns in FIND In-Reply-To: <9308060121.AA09294@ford.airco.co.jp> References: <9308060121.AA09294@ford.airco.co.jp> Beak: is Not There's a slight problem with this in that if you do: FIND ALL.BBOARDS "comp[.][^.]*" You'll probably lose in the case where "comp.lang" does not exist, yet "comp.lang.c" does. _.John From owner-imap@cac.washington.edu Fri Aug 6 12:13:59 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04574; Fri, 6 Aug 93 12:13:59 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09393; Fri, 6 Aug 93 12:13:36 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from norman.nwnet.net by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09387; Fri, 6 Aug 93 12:13:35 -0700 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA03857; Fri, 6 Aug 93 12:13:34 -0700 Date: Fri, 6 Aug 1993 12:08:52 -0700 (PDT) From: Laurence Lundblade Subject: re: Patterns in FIND To: Mark Crispin Cc: IMAP Interest List In-Reply-To: Message-Id: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 5 Aug 1993, Mark Crispin wrote: > On Thu, 5 Aug 1993 11:12:16 -0700 (PDT), Laurence Lundblade wrote: > > I don't think you can do a FIND * because that's not gauranteed to return > > the > > *whole* name space. > > This is arguably a bug or misfeature in the c-client based IMAP server, and as > such may be fixed. I kind of thought this was the case, but wasn't sure.... > > It could be extremely large. > > Such as all of the newsgroups? :-) Or the whole file space in the server and connected NFS servers. Since any file is potentially a mail folder with the Berkeley mail file format. > > I do think we need get a > > strawman out in the open on how the current FIND and patterns can be used to > > implement a heirarchy. > > Better to suggest a couple of strawmen, so that people see that this is in > fact an implementation views issue. Yes, yes, a couple of strawmen would be a good idea. Think it would be helpful to get a concrete example of how it should work with patterns. I'm kind of interested in putting one together, but I'll be off-line and moving across the country for the next two weeks or so.... LL From owner-imap@cac.washington.edu Fri Aug 6 12:19:52 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04762; Fri, 6 Aug 93 12:19:52 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09520; Fri, 6 Aug 93 12:19:39 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09514; Fri, 6 Aug 93 12:19:37 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14560; Fri, 6 Aug 93 12:19:33 -0700 Date: Fri, 6 Aug 1993 12:15:30 -0700 (PDT) From: Terry Gray Subject: Re: IMAP WG August meeting To: mwalnut@CNRI.RESTON.VA.US Cc: John C Klensin , scoya@CNRI.RESTON.VA.US, Erik Huizer , imap@cac.washington.edu In-Reply-To: <744338479.89422.KLENSIN@INFOODS.UNU.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Megan, Per John's msg, here is the info for the upcoming WG mtg, for reposting to ietf-announce. Thanks. -teg -------------------- WHAT: Interactive Mail Access protocol (IMAP) Working Group meeting WHEN: August 30-31, 1993 (Monday-Tuesday) WHERE: University of Washington, Seattle, WA, USA WHY: To work on refining the revised IMAP specification (draft to be released shortly.) CONTACT: imap-rsvp@cac.washington.edu Terry Gray, WG Chair University of Washington gray@cac.washington.edu From owner-imap@cac.washington.edu Mon Aug 9 12:07:44 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00470; Mon, 9 Aug 93 12:07:44 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04771; Mon, 9 Aug 93 12:06:49 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from timbuk.cray.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04765; Mon, 9 Aug 93 12:06:48 -0700 Received: from crmunich0 (crmunich0.cray.com) by cray.com (4.1/CRI-MX 2.19) id AA11914; Mon, 9 Aug 93 14:06:45 CDT Received: from crmunich46.cray.com by crmunich0 id AA06144; 4.1/CRI-5.6a; Mon, 9 Aug 93 21:06:43 +0200 Received: by crmunich46.cray.com; Mon, 9 Aug 93 21:05:08 +0200 Date: Mon, 9 Aug 1993 21:04:35 +0200 (MET DST) From: Hans-Ulrich Schaefer Subject: To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII help From owner-imap@cac.washington.edu Tue Aug 10 12:55:08 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08252; Tue, 10 Aug 93 12:55:08 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04217; Tue, 10 Aug 93 12:54:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from log.css.itd.umich.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04211; Tue, 10 Aug 93 12:54:37 -0700 Received: from stimpy.css.itd.umich.edu by css.itd.umich.edu (5.67/2.2) id AA10070; Tue, 10 Aug 93 15:54:35 -0400 Received: by stimpy.css.itd.umich.edu (5.67/dumb-1.0) id AA00552; Tue, 10 Aug 93 15:54:40 -0400 Date: Tue, 10 Aug 1993 15:50:01 -0400 (EDT) From: Alex Tang Subject: Windows IMAP clients To: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. I'm trying to find out some information about windows IMAP clients. I've downloaded ECS, but i am running LAN Workplace for DOS. and I don't think that this supports it. If it does, please let me know. Are there any other windows clients? Thanx...alex... ps. i would like to be subscribed to this group. Alex Tang -- ALTITUDE@UMICH.EDU...USERW00Y@UMICHUM.BITNET U of M, SNRE: Student and Computer Consultant II ITD/CSS Consultant and...General Fun Loving Guy :) From owner-imap@cac.washington.edu Tue Aug 10 22:17:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20184; Tue, 10 Aug 93 22:17:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25740; Tue, 10 Aug 93 22:17:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25734; Tue, 10 Aug 93 22:17:21 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13072; Tue, 10 Aug 93 22:17:21 -0700 Date: Tue, 10 Aug 1993 22:07:05 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Proposal to simplify IMAP2bis To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII IMAP2 has traditionally assumed that the clients cache FETCH data, and if a server has sent specific FETCH data once, it need not send it again, even if explicitly asked again. Clients with insufficient memory (can you spell DOS??) have a hard time coping with this assumption, and therefore forced the addition of several PURGE commands to the IMAP2bis spec, in order to change the assumption of client caching and tell the server to always respond to a FETCH with the requested data, even if it has sent the same data previously. It has occurred to several of us that the value of the client-caching assumption is probably over-rated, and it would be nice to simplify the protocol by elminating the four PURGE commands. I personally favor eliminating this from the spec before submitting it as an Internet Draft later this week, but I'd first like hear whether anyone has a strong attachment to PURGE and the implicit caching assumption. Said differently: in the absence of objections from this list in the next day or so, I'm going to recommend to Mark that the caching assumption and related purging commands be immediately purged from the new draft spec ... -teg From owner-imap@cac.washington.edu Tue Aug 10 22:38:00 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20597; Tue, 10 Aug 93 22:38:00 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06902; Tue, 10 Aug 93 22:37:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06896; Tue, 10 Aug 93 22:37:40 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA05528; Tue, 10 Aug 93 22:37:39 -0700 Date: Tue, 10 Aug 1993 22:19:56 -0700 (PDT) From: Mark Crispin Subject: re: Proposal to simplify IMAP2bis To: Terry Gray Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Aug 1993 22:07:05 -0700 (PDT), Terry Gray wrote: > It has occurred to several of us that the value of the client-caching > assumption is probably over-rated, and it would be nice to simplify the > protocol by elminating the four PURGE commands. As well as deleting the notion that IMAP2 servers are not obliged to send data that they have already sent. Replacing it is an explicit requirement (already in the new draft) that IMAP2bis clients MUST remember EXISTS and RECENT values. IMAP2bis servers SHOULD automatically send mailbox size (= new mail) and flag updates without the client having to ask. The behavior of certain clients of sending a CHECK each and every time it needs to know the EXISTS/RECENT value is specifically forbidden (it may beat on a server, and there's no guarantee that CHECK will actually return any data). This too is already in the draft. RFC-1176 was mealy-mouthed when it came to caching texts. The only other thing besides EXISTS/RECENT stuff were flags and static message overhead data (internal dates, envelopes, rfc822 sizes). Of these, it turned out that a DOS client couldn't cache even the static stuff (particular envelopes). That left flags, which would have been the primary beneficiary of the old caching rule. You could fetch flags for all messages and only get the ones that changed. But, the problem with this kind of polling was that it would be terribly slow if the server didn't do the cache remembering, so no client ever did it. Plus, a requirement that the server notice updates and send them without being asked accomplished the same thing without putting the burden on the client. > I personally favor eliminating this from the spec before submitting it as > an Internet Draft later this week, but I'd first like hear whether anyone > has a strong attachment to PURGE and the implicit caching assumption. > > Said differently: in the absence of objections from this list in the next > day or so, I'm going to recommend to Mark that the caching assumption and > related purging commands be immediately purged from the new draft spec ... Mark will accept and act upon this recommendation if there are no objections from the list, on the grounds that this is a major simplification, it will eliminate yet another of the complaints of the ``IMAP3'' crew, and that nobody seems to have implemented a server that took advantage of this capability. The only reason for my objecting is that I felt that such a major functional removal needed to be brought up on the list first. I personally am in favor of this proposal. -- Mark -- From owner-imap@cac.washington.edu Thu Aug 12 05:36:37 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00987; Thu, 12 Aug 93 05:36:37 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14903; Thu, 12 Aug 93 05:36:11 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from stc06.CTD.ORNL.GOV by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14897; Thu, 12 Aug 93 05:36:07 -0700 Received: by stc06.CTD.ORNL.GOV (5.57/Ultrix3.0-C) id AA06899; Thu, 12 Aug 93 08:35:57 -0400 Date: Thu, 12 Aug 93 08:35:57 -0400 From: News poster Message-Id: <9308121235.AA06899@stc06.CTD.ORNL.GOV> To: imap@cac.washington.edu Newsgroups: ornl.mail.imap Path: stc06!jnm From: jnm@ornl.gov (Jamey Maze) Subject: Re: IMAP WG mtg summary and minutes Message-ID: Sender: usenet@ornl.gov (News poster) Organization: Oak Ridge National Lab X-Newsreader: VersaTerm Link v1.1 References: <14Jul93.09: 47:17.14638@stc06> Distribution: local Date: Thu, 12 Aug 1993 12:35:38 GMT Lines: 101 In Article <14Jul93.09:47:17.14638@stc06>, Terry Gray wrote: > >IMAP WG meeting summary and minutes: 13 July 1993 (Amsterdam IETF) > >SUMMARY > >21 people participated. For several it was their first exposure to >IMAP, so a few minutes was spent summarizing what IMAP is, how it >compares/relates to other alternatives, and what the working group is >chartered to do. The WG charter and notes from the Columbus BOF were >reviewed and questions answered. The status of the protocol spec and >known IMAP implementations was reviewed. (An Internet Draft is being >composed that integrates and updates RFC-1176 and the imap2bis >extensions.) Existing practice on the use of IMAP for news, archive, and >document access --in addition to mail-- was covered. Discussion on >possible IMAP extensions followed. Finally, the next working group >meeting (in Seattle, Aug 30-31), was announced. > > >AGENDA > >Introductions >IMAP overview >Comments on the WG Charter? >Status of implementations >Status of protocol spec >Comments on Columbus BOF notes? >Additional IMAP change requests? >Seattle WG meeting >References: /imap/imap* on ftp.cac.washington.edu > > >DISCUSSION POINTS > >Disconnected operation support, ala DMSP, continues to be widely desired. > >There is considerable interest in using IMAP to access message archives. > >Several people asked about extensions to support binary message part >access, without Base64 or QP encoding: > -Possible? > -Impact on s-expression model? > -Can unencoded binary attachments be transferred without charset concerns? > >The question of signalling when large blocks of data are being transferred: > -Congestion of pipe; need to have multiple channels or out-of-band signals > >Can we have an IMAP server capabilities command, ala new SMTP? > >Be sure to look at URL/I work before settling on uniqe message ID scheme. > >Is IMAP a distribution list alternative: shared but limited access mailbox? > >Can IMAP "integrate" two mailboxes (remote mail archive plus local subset)? > >Should IMAP become "Interactive Message Access Protocol"? > > >ACTION ITEMS > >Gray needs to maintain (or cause to be maintained?) an IMAP >enhancement/request list, sorted into the following categories: > o Protocol bug fixes > o Upward compatible extensions, > -high priority > -lower priority > o Non-upward compatible changes, > -high priority > -lower priority > o Bad, or not clearly good, ideas > >A subset of that list must then be defined as the target for the >immediate standardization effort, with other ideas being deferred for >future consideration. Given the desire to preserve compatibility with >the installed base, and move ahead promptly in getting a base IMAP >standard defined, extensions will be necessarilly limited to those >deemed to have an extremely high priority. > >Crispin needs to integrate RFC-1176 text with IMAP2BIS text and submit >as Internet draft not later than Aug 15th. > >IMAP implementors/interested parties are encouraged to come to the next >WG meeting in Seattle, Aug 30-31. > >-teg > > > > > > > > -- Jamey Maze Martin Marietta Energy Systems, Inc. Oak Ridge National Laboratory P.O. Box 2008 (615)574-6355 78 Mitchell Road FAX: (615)-576-4992 Oak Ridge, TN 37831-6283 From owner-imap@cac.washington.edu Thu Aug 12 22:09:34 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22293; Thu, 12 Aug 93 22:09:34 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22900; Thu, 12 Aug 93 22:09:11 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22894; Thu, 12 Aug 93 22:09:09 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29477; Thu, 12 Aug 93 22:09:06 -0700 Date: Thu, 12 Aug 1993 22:02:10 -0700 (PDT) From: Terry Gray Subject: Re: Windows IMAP clients To: Alex Tang Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Alex, The silence in response to your inquiry has been deafening! I guess ECS is the only viable Windows IMAP client right now. When Wollongong gets their Pathways Messenger Windows client to speak MIME and Winsock, it may be worth looking into. I think the new version is due in the first quarter of next year. -teg On Tue, 10 Aug 1993, Alex Tang wrote: > Hi. I'm trying to find out some information about windows IMAP clients. > I've downloaded ECS, but i am running LAN Workplace for DOS. and I don't > think that this supports it. If it does, please let me know. Are there > any other windows clients? > > Thanx...alex... > > ps. i would like to be subscribed to this group. > > Alex Tang -- ALTITUDE@UMICH.EDU...USERW00Y@UMICHUM.BITNET > U of M, SNRE: Student and Computer Consultant II > ITD/CSS Consultant and...General Fun Loving Guy :) > > > From owner-imap@cac.washington.edu Fri Aug 13 16:12:46 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17115; Fri, 13 Aug 93 16:12:46 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24073; Fri, 13 Aug 93 16:12:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24067; Fri, 13 Aug 93 16:12:16 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA08599; Fri, 13 Aug 93 16:12:08 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA18036; Fri, 13 Aug 93 16:12:01 -0700 Date: Fri, 13 Aug 1993 16:01:18 -0700 (PDT) From: Mark Crispin Subject: new IMAP2bis document submitted as an Internet draft To: IMAP Interest List Cc: Internet-Drafts@CNRI.Reston.VA.US Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As promised, a new draft specification of the IMAP2bis protocol has been submitted to the Internet Drafts, two days before the August 15 deadline. There should be an announcement of it in the next couple of days. This document is also available via anonymous FTP on ftp.cac.washington.edu, in the file mail/imap2bis-draft-01.txt If you do not have FTP access and would like a copy mailed to you, please let me know and I'll e-mail it to you. This document is the first public draft, ready for general review by the entire working group. It is intended that this document, following review, modification, and approval by the Working Group as a whole, be submitted as a Proposed Standard. If you have comments or suggestions on IMAP2bis, now is the time to make them! -- Mark -- From owner-imap@cac.washington.edu Tue Aug 17 06:11:27 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26792; Tue, 17 Aug 93 06:11:27 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04958; Tue, 17 Aug 93 06:10:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ietf.cnri.reston.va.us by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04952; Tue, 17 Aug 93 06:10:48 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02952; 17 Aug 93 9:05 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: imap@cac.washington.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-imap-imap2bis-00.txt Date: Tue, 17 Aug 93 09:05:25 -0400 Message-Id: <9308170905.aa02952@IETF.CNRI.Reston.VA.US> --NextPart A New Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Mail Access Protocol Working Group of the IETF. Title : INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis Author(s) : M. Crispin Filename : draft-ietf-imap-imap2bis-00.txt Pages : 46 Abstract not provided. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-imap-imap2bis-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-imap-imap2bis-00.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-imap-imap2bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imap-imap2bis-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From owner-imap@cac.washington.edu Thu Aug 19 07:41:01 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03165; Thu, 19 Aug 93 07:41:01 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23683; Thu, 19 Aug 93 07:40:02 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO2.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23677; Thu, 19 Aug 93 07:40:01 -0700 Received: from localhost (postman@localhost) by po2.andrew.cmu.edu (8.5/8.5) id KAA07773; Thu, 19 Aug 1993 10:39:58 -0400 Received: via switchmail; Thu, 19 Aug 1993 10:39:58 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Thu, 19 Aug 1993 10:39:41 -0400 (EDT) Received: via niftymail; Thu, 19 Aug 1993 10:39:38 -0400 (EDT) Date: Thu, 19 Aug 1993 10:39:37 -0400 (EDT) From: Chris Newman Subject: New alpha release of IMSP server To: imap@cac.washington.edu Message-Id: <745771177.4690.0@nifty.andrew.cmu.edu> Alpha release 3 of the IMSP server is now available from export.acs.cmu.edu in /pub/cyrus-mail/cyrus-imspd-v1.00a3.tar.gz The file is tar'd and gzip'd. This version includes some bugfixes, the advisory locking commands and the proposed option naming conventions. The latest version of the IMSP specification is available for ftp from the same directory. Any comments would be appreciated. - Chris Newman Carnegie Mellon University Computing Services From owner-imap@cac.washington.edu Mon Aug 23 08:42:24 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05822; Mon, 23 Aug 93 08:42:24 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15844; Mon, 23 Aug 93 08:41:38 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Aug 23 10:00:48 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08595; Mon, 23 Aug 93 10:00:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13854; Mon, 23 Aug 93 10:00:16 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Aug 23 10:31:08 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09501; Mon, 23 Aug 93 10:31:08 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16437; Mon, 23 Aug 93 10:30:49 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16429; Mon, 23 Aug 93 10:30:46 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05381; Mon, 23 Aug 93 19:30:39 +0200 Message-Id: <9308231730.AA05381@nada.kth.se> To: "David Herron" Cc: IMAP Interest List Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: Your message of "Mon, 23 Aug 1993 09:59:39 PDT." <9308231700.AA06595@eco.twg.com> Date: Mon, 23 Aug 1993 19:30:36 +0200 From: Peter Svanberg Quoting: "David Herron" > >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. You mean the inaccuracy can be long enough to contain message delivery and the composing and sending of a new message (referring to the A-B example)? Maybe possible, but not normal, is it? A good search tool should probably have some margins for this. (Another problem in this area is that Date-fields sometimes have wrong time zone.) > >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. Well, I assumed the reader and the searcher to be the same person. Then there is no (significant) difference between the arrival date and the moment it is avaliable for the reader to read. --- Peter Svanberg, Nada, KTH From owner-imap@cac.washington.edu Mon Aug 23 15:15:23 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23078; Mon, 23 Aug 93 15:15:23 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18063; Mon, 23 Aug 93 15:14:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Aug 24 04:27:19 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06224; Tue, 24 Aug 93 04:27:19 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20955; Tue, 24 Aug 93 04:26:56 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Aug 24 18:32:26 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00766; Tue, 24 Aug 93 18:32:26 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25590; Tue, 24 Aug 93 18:31:57 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Aug 24 19:35:33 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01717; Tue, 24 Aug 93 19:35:33 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25808; Tue, 24 Aug 93 19:35:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 08:38:52 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15964; Wed, 25 Aug 93 08:38:52 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28745; Wed, 25 Aug 93 08:38:21 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 10:00:51 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19094; Wed, 25 Aug 93 10:00:51 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13174; Wed, 25 Aug 93 10:00:20 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 11:34:30 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22351; Wed, 25 Aug 93 11:34:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14926; Wed, 25 Aug 93 11:34:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 12:08:23 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23618; Wed, 25 Aug 93 12:08:23 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15503; Wed, 25 Aug 93 12:08:02 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 13:51:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26978; Wed, 25 Aug 93 13:51:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17110; Wed, 25 Aug 93 13:51:25 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 14:12:23 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27854; Wed, 25 Aug 93 14:12:23 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17425; Wed, 25 Aug 93 14:12:02 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 14:20:01 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28207; Wed, 25 Aug 93 14:20:01 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00931; Wed, 25 Aug 93 14:19:41 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 16:44:12 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04394; Wed, 25 Aug 93 16:44:12 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01759; Wed, 25 Aug 93 16:43:49 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Aug 25 17:06:26 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05300; Wed, 25 Aug 93 17:06:26 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01917; Wed, 25 Aug 93 17:06:06 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01911; Wed, 25 Aug 93 17:06:04 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19403; Thu, 26 Aug 93 02:06:02 +0200 Message-Id: <9308260006.AA19403@nada.kth.se> To: IMAP Interest List Subject: Message's originator (SMTP envelope sender) In-Reply-To: Your message of "Wed, 25 Aug 1993 13:50:48 PDT." <9308252050.AA04469@eco.twg.com> Date: Thu, 26 Aug 1993 02:06:01 +0200 From: Peter Svanberg Next subject (as David brought it up): David Herron wrote: > 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) IMAP doesn't say anything about the SMTP envelope sender address - it isn't among the "data that is associated with a message as an entity in the mailbox" items so it can't be fetched by the client. This SMTP envelope sender is sometimes important, for example for determining if the message was sent to a certain mailing list or not. (There are cases where this address is the _only_ way of determining this.) There are two solutions: 1) Adding a new IMAP message item described as "Definitive information about the address to the message's originator, as for example provided by the sender in the SMTP envelope" 2) Recommending IMAP server implementors to put this address in a "Return-Path:" field in the header, removing any existing such field. This is in my opinion allowed, according to RFC 822: 4.3.1. RETURN-PATH This field is added by the final transport system that delivers the message to its recipient. The field is intended to contain definitive information about the address and route back to the message's originator. Note: The "Reply-To" field is added by the originator and serves to direct replies, whereas the "Return-Path" field is used to identify a path back to the origina- tor. Which do you prefer? --- Peter Svanberg, Nada, KTH From owner-imap@cac.washington.edu Thu Aug 26 07:59:30 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21284; Thu, 26 Aug 93 07:59:30 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25602; Thu, 26 Aug 93 07:58:56 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25596; Thu, 26 Aug 93 07:58:54 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14321; Thu, 26 Aug 93 07:58:54 -0700 Date: Thu, 26 Aug 1993 07:45:49 -0700 (PDT) From: Terry Gray Subject: IMAP Working Group meeting: time/location To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As you all know, UW will be hosting an interim ("in between IETFs") WG meeting Mon-Tues of next week (8/30-31). The agenda is to make progress on refining the draft document you already know about, including discussing unique identifiers, hierarchy support, and a bunch of easier issues :) TIME: We'll plan on getting started around 9am each day. PLACE: The "2nd floor conference room" at 4501 15th Ave NE. This is a building we share with a bank, at the NW corner of campus. It is at the corner of 15th Ave NE and NE 45th St. in the University district. (45th St is an exit on Interstate 5; Go East 1/2 mile) There is parking in an adjacent structure and also across the street. Those of you who RSVPd got a list of hotels, several of which are within walking distance. Go inside the the building, next to the automatic teller machine, and take the elevator to the 2nd floor. The door closest to the elevator (which hopefully we will have remembered to prop open :) is the right one. Local arrangements questions to "imap-rsvp@cac.washington.edu" -teg From owner-imap@cac.washington.edu Thu Aug 26 16:58:59 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08492; Thu, 26 Aug 93 16:58:59 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07979; Thu, 26 Aug 93 16:58:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07973; Thu, 26 Aug 93 16:58:28 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA00615; Fri, 27 Aug 93 01:58:25 +0200 Message-Id: <9308262358.AA00615@nada.kth.se> To: imap@cac.washington.edu Subject: Short other IMAP opinions (before the meeting) Date: Fri, 27 Aug 1993 01:58:24 +0200 From: Peter Svanberg The time before the meeting is running out... > IMAP2bis implementations MAY transmit 8-bit characters in literals, > but should do so only when the character set is identified. ... Better to call it "high octets" than "8-bit characters", to not limit ourselves for the future. The UCS UTF-2 transformation could well be used, but its octets are not characters. > The string may be in RFC 1342 format to express a character set > other than US-ASCII. In this case, the criteria matches if the > string matches the character set and characters of a substring of > that field. ... This is not so good: 1) It is strange to require a searcher (user or client?) to know which character set a certain non-ASCII character is coded with. How would she know? For example, certain such characters are present in several of the 8859 parts, so to be sure, you must do one search for each possible character set... 2) Not even substrings containing only ASCII characters (but coded in a non-ASCII character set) will be found: SEARCH FROM "andersson" will not find a message with From: =?ISO-8859-1?Q?=C5sa_Andersson?= I quote Olle Jarnefors, from a discussion on this issues with Chris Newman, in connection with IMSP: * A server doesn't have to be able to handle all coded character * sets, it's sufficient that it can represent all _characters_ by * means of one coded character set, if UTF-2 is used between * server and client. To allow several overlapping coded character * sets between server and client (like MIME and Kermit) increases * the complexity of the protocol and makes implementation of IMSP * programs more difficult without giving any increased * functionality or any substantial gain in cmmunication * performance. * * > How is the server informed about the character set? * > * > A) 1342-type-strings * > * > B) Through a new command CHARSET in the the protocols. * * A third possibility is to use escape sequences according to ISO * 2022. But all this talk about identification of coded character * sets as a means of internationalizing IMSP is leading you astray, * in my opinion. It only introduces unnecessary complexity and * doesn't solve any genuine problems. > ... A server implementation may omit case-independent > matching on RFC 1342 strings. This is evidently a probable interoperability problem. It could also increase the net trafic, as it may force some clients to send 2**N search commands to be sure to find a string containing N non-ASCII characters... We also have lots of opinions about SEARCH command extensions. --- Peter Svanberg, Nada, KTH From owner-imap@cac.washington.edu Fri Aug 27 07:26:50 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21984; Fri, 27 Aug 93 07:26:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11111; Fri, 27 Aug 93 07:26:22 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11105; Fri, 27 Aug 93 07:26:19 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08614; Fri, 27 Aug 93 16:26:16 +0200 Message-Id: <9308271426.AA08614@nada.kth.se> To: imap@cac.washington.edu Subject: More IMAP questions and suggestions (before the meeting) Date: Fri, 27 Aug 1993 16:26:15 +0200 From: Peter Svanberg Some more I had: * How does a client discover if a server is IMAP2bis compliant or just IMAP2bis compatible? I can't find any way to do this. The only way to know if a command is implemented is to "go fishing", i.e. test and look for a OK/NO or BAD response. It is important for the client to know which commands are implemented, to be able to enable/disable menu choices, for example. * Clarify the second paragraph of page 4. > No distinction is made in IMAP2bis between data transmitted as > a result of a client command and data which is unilaterally > transmitted by the server. One form of unilaterally transmitted data > which commonly occurs is an alert of a change to the mailbox made by > some process other than the IMAP2bis client or server; for example, > changes in the size of the mailbox (new mail) or in the status of > individual messages. I suggest that parts of the explanation in the Design Discussion ("Although it is permitted for a server ...") is repeated in this paragraph. As it now stands, nothing is said in the RFC about when unliateral responses are sent until in the NOOP commmand description. * Clarify the second paragraph of page 5. > It is not required that a server process a command to completion > before beginning processing of the next command, except when the > processing of the previous command may affect the results of the next > command by changing the state of the current mailbox. This has > certain other effects; for example, this implies that an EXPUNGE > response can not be transmitted as part of a response to a request > that may be streamed with another response. Can unsolisited "bilateral" data from different commands be mixed? So it's up to the client to just "stream" such commands which are unaffected of mixing? This should then be explained. I also suggest the example at the end of the paragraph is explained clearer. * Clarify the EXPUNGE text on page 28. The text > An unsolicited EXPUNGE response MUST NOT be sent except > while responding to a request other than FETCH, STORE, > or SEARCH. could be rephrased An unsolicited EXPUNGE response MAY ONLY be sent while responding to a request other than FETCH, STORE, or SEARCH. or even An unsolicited EXPUNGE response can be sent while responding to a request, EXCEPT while responding to FETCH, STORE or SEARCH. * Unique ids - make them global. > The unique id is an > identifier which is guaranteed to refer to this message and to none > other and which, unlike IMAP2bis sequence numbers, persists across > sessions. "...to none other in the same mailbox..." was probably the intention here, but as has been discussed on the IMAP mailing list, these _must_ be global - preferably on the system, but at least amongst a users personal mailboxes. Otherwise handling of off-line moving of messages between mailboxes will be very difficult to implement. * Please don't assume the user uses the same language as the server! > tag NO response_text > > This response identifies unsuccessful completion of the command > with that tag. The text is a line of human-readable text that > probably should be displayed to the user in an error report by the > client. > * BYE text > > This response identifies that the server is about to close the > connection. The text is a line of human-readable text that should > be displayed to the user in a status report by the client. This > may be sent as part of a normal logout sequence, or as a panic > shutdown announcement by the server. It is also used by some > servers as an announcement of an inactivity autologout. > > This response is also one of three possible greetings at session > startup. It indicates that the server is not willing to accept a > session from this client at the present time. This only works if the user and the server uses the same language. At least the most common explanatory texts in these responses should be coded in some way, so the client can show them in the users language. * Clarify the ¥RECENT explanations > On a successful selection, the server will send a list of valid > flags, number of messages, and number of messages arrived since last > access for this mailbox as unsolicited data, followed by an OK --- > RECENT The specified number of messages have arrived since the > previous time this mailbox was read. --- > ¥RECENT Message arrived since the > previous time this mailbox > was read I suppose both "last acccess" and "previous ... read" should actually be "selected"? Also, it doesn't apply to read-only mailboxes, does it? * Clarify on page 34, para. 4: > Because 8-bit characters are permitted in the argument to APPEND, a > server in the 7-bit world MUST, if it implements the APPEND command, > be able to make a reversible conversion of the 8-bit APPEND data to > 7-bit data using MIME. What is meant by "a server in the 7-bit world"? Isn't all servers required to do this? --- 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-imap@cac.washington.edu Sat Aug 28 01:11:54 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15963; Sat, 28 Aug 93 01:11:54 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15528; Sat, 28 Aug 93 01:11:18 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15522; Sat, 28 Aug 93 01:11:16 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA01616; Sat, 28 Aug 93 01:11:09 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA18325; Sat, 28 Aug 93 01:11:02 -0700 Date: Sat, 28 Aug 1993 00:07:25 -0700 (PDT) From: Mark Crispin Subject: re: More IMAP questions and suggestions (before the meeting) To: Peter Svanberg Cc: IMAP Interest List In-Reply-To: <9308271426.AA08614@nada.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Answers to your comments: 1) You are correct. The only way to tell if a command is implement is to try the command and see if you get a BAD response or an OK/NO response. An IMAP2bis-compliant server MUST implement ALL of the functionality described in the IMAP2bis specification. Otherwise it is not IMAP2bis-compliant. It is impossible to enumerate the possible versions of IMAP2 servers which have existed in the past. IMAP2 has been an evolving protocol, and many of the new capabilities introduced in IMAP2bis have been in production servers for quite some time. Well-written clients will have an error fallback when communicating with an older IMAP2 server that is not IMAP2bis-compliant. The notes in the IMAP2bis document about ``optional'' functionality are to give notice to client implementors about what capabilities that may be missing in older servers, so they have some idea of what sort of error fallback code they will need to write. Note that a VERSION command would be useless. At best, it might tell you of a server's claim to be IMAP2bis compliant, but it will not tell you what any older server is capable of. It would be extremely objectionable behavior for a client to turn off all menu items that use functionality not defined in the original RFC-1064, since most servers are capable of quite a bit more. Nor is a VERSION command any guarantee that the server is, in fact, truly IMAP2bis compliant. 2) I don't see why there needs to be any change in the second paragraph on page 4. Unilateral data can be sent at any time, for any reason that the server elects. The NOOP command description contains a specific example of unilateral data that illustrates one particularly common example. It does not define any sort of limit to this. Well-written clients MUST be willing to handle any kind of unsolicited data (with the * tag) at any time. 3) Yes, unsolicited ``bilateral'' data from different commands can be mixed. Data is not associated with commands; only a command completion state is. In general, you will cache the data you get back, and when you get command completion you will look at your cache to see what the results are. 4) The suggestion rephrase to EXPUNGE is less clear, and more ambiguous, than the original. ``MAY ONLY'' is not used in IETFese, and is ambiguous English. 5) The possibility of making unique ID's global has been discussed, and while it would provide some interesting capabilities it is entirely too difficult to implement (read: impossible) in many environments. It also creates a problem with the COPY command; since UIDs are required to be strictly ascending this would mean that globally unique UIDs would force the COPY command to insert the copied message somewhere in the middle of the target mailbox. UIDs are per-folder, and a message moved by COPY or APPEND will get a new UID in the new folder. Everyone I spoke to who actually works with UID type software vehemently objected to making UIDs global. Although I originally supported global UIDs, I concur with their objections. 6) Abandoning human-readable texts in favor of binary that is more readily multi-national: I will entertain the idea of making those texts be multi- national when you convince the IETF to do the same for POP3, TFTP, FINGER, FTP, SMTP, NNTP, and every other TCP/IP protocol. I am vehemently opposed to making IMAP2, which is a relatively minor player in the TCP/IP protocol suite, do the pioneering work in multi-national response strings. This is orthogonal to the goals of IMAP2, and will only serve to delay its deployment. Human-readable text messages is one of the reasons why TCP/IP protocols have been readily implemented and debugged. It is actually possible to debug a TCP/IP based server on the implementor's terminal. This can not be said for certain other protocol suites, e.g. ISO. It is simply not possible to enumerate all the possible messages a server may generate -- many of which may be implementation-specific to that server -- without ending up with a mismash of generic conditions that tell nobody anything useful about what actually happened. For example, I doubt that the garbage which is currently being spewed out by X.400 mailers is easier to understand than the text ``No such mailbox'' in English, even to a person who is a native speaker of some other language. Furthermore, the only important thing about the server responses are the response codes themselves: OK (meaning the command was understood and completed successfully), NO (meaning the command was understand and completed unsuccessfully), and BAD (meaning the command was not understood). Any further text is completely a function of the server. Your client implementation does not have to show the human-readable text messages; it just offers the opportunity to clarify why the server said NO or BAD. 7) The precise handling of ¥RECENT including the interaction with read-only mailboxes is server implementation dependent. I do not wish to legislate the behavior of a particular server implementation (e.g. the c-client based server) as being the only valid behavior. 8) A server in the 7-bit world is a server on a system that uses 7-bit characters, e.g. uses 7-bit SMTP. If such a server supports the APPEND command, it must be able to convert incoming 8-bit APPEND data to 7-bit using MIME. From owner-imap@cac.washington.edu Sat Aug 28 08:06:03 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20563; Sat, 28 Aug 93 08:06:03 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16868; Sat, 28 Aug 93 08:05:39 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16862; Sat, 28 Aug 93 08:05:37 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA18511; Sat, 28 Aug 93 16:57:59 +0200 Message-Id: <9308281457.AA18511@nada.kth.se> To: Mark Crispin Cc: IMAP Interest List Subject: Re: More IMAP questions and suggestions (before the meeting) In-Reply-To: Your message of "Sat, 28 Aug 1993 00:07:25 PDT." Date: Sat, 28 Aug 1993 16:57:57 +0200 From: Peter Svanberg Quoting: Mark Crispin > > 1) You are correct. The only way to tell if a command is implement is to try > the command and see if you get a BAD response or an OK/NO response. : > It would be extremely objectionable behavior for > a client to turn off all menu items that use functionality not defined in the > original RFC-1064, since most servers are capable of quite a bit more. You could also argue it from a users veiw being objectionable to have an unusable menu item enabled. Isn't there any other solution? The ESMTP way? A new command IMPLEMENTED? > 4) The suggestion rephrase to EXPUNGE is less clear, and more ambiguous, than > the original. ``MAY ONLY'' is not used in IETFese, and is ambiguous English. Well, I just reacted to the tripple negation (NOT...except ...other than). > 6) Abandoning human-readable texts in favor of binary that is more readily > multi-national: I will entertain the idea of making those texts be multi- > national when you convince the IETF to do the same for POP3, TFTP, FINGER, > FTP, SMTP, NNTP, and every other TCP/IP protocol. : : > It is simply not possible to enumerate all the possible messages a server may > generate -- many of which may be implementation-specific to that server -- > without ending up with a mismash of generic conditions that tell nobody > anything useful about what actually happened. : Well well well, calm down. (Do you _want_ suggestions and comments to IMAP? The way you answer almost makes me wonder...) I was not referring to debug usage, just to user interface. You say it isn't possible to separate a set of maybe 10 most-common error cases and make them parsable for the client. Maybe you are right. > 7) The precise handling of ¥RECENT including the interaction with read-only > mailboxes is server implementation dependent. I do not wish to legislate the > behavior of a particular server implementation (e.g. the c-client based > server) as being the only valid behavior. But isn't this a behavior-compatibility issue for the user? Which are the criteria for considering an issue implementation dependent? I would appreciate some comments to my other message, at least the 1342-search issue. --- Peter Svanberg, Nada, KTH From owner-imap@cac.washington.edu Sat Aug 28 09:55:38 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21504; Sat, 28 Aug 93 09:55:38 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17174; Sat, 28 Aug 93 09:55:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17168; Sat, 28 Aug 93 09:55:17 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA01860; Sat, 28 Aug 93 09:55:09 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA19969; Sat, 28 Aug 93 09:55:03 -0700 Date: Sat, 28 Aug 1993 09:19:32 -0700 (PDT) From: Mark Crispin Subject: Re: More IMAP questions and suggestions (before the meeting) To: Peter Svanberg Cc: IMAP Interest List In-Reply-To: <9308281457.AA18511@nada.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 28 Aug 1993 16:57:57 +0200, Peter Svanberg wrote: > You could also argue it from a users veiw being objectionable > to have an unusable menu item enabled. Isn't there any other > solution? The ESMTP way? A new command IMPLEMENTED? There is another solution, which is to write your code in such a way that you do not have unusable commands. That is, have fallbacks to alternative methods of accomplishing the same thing. > I was not referring to debug usage, just to user interface. You > say it isn't possible to separate a set of maybe 10 most-common > error cases and make them parsable for the client. Maybe you > are right. I don't think there is an easily identifiable ``10 most common error cases'' that is applicable to all server implementations. In fact, a great many messages from the c-client implementation are applicable only to the c-client implementation. Many of these messages have additional data items (numbers and strings) which appear in the text of the message. I think also that you misunderstand what I am supposed to be doing at this point. Many people have many ideas of what to do in IMAP. Some of these ideas are very good. But it is impossible to do everything that people may suggest. What I must do is to find things that are wrong with an idea, so that only the very best and most important ideas make it into IMAP. The cost of not doing this is very high: we end up with something like X.400. >>[¥RECENT behavior] > But isn't this a behavior-compatibility issue for the user? > Which are the criteria for considering an issue implementation > dependent? I don't believe that there is an important difference between ``reading a mailbox'' and ``selecting a mailbox''. This difference may not exist at all in some implementations. Or it may be very important. Or, the mailbox may be read by some means outside of IMAP. The idea of using the term ``read'' instead of the most IMAP-specific ``select'' is to convey the idea of ¥RECENT; these are messages that there is a reasonable supposition that the user has not seen before. Similarly, with read-only mailboxes, it is not necessarily the case that there is no state maintained on what the user has or has not read in that mailbox. Consider netnews in this; it is quite reasonable to expect that there be server state and useful ¥RECENT flags. At the other hand, there are other kinds of read-only mailboxes where the user can not manipulate state at all, and no way to determine anything like ¥RECENT status. That is why I consider it a server implementation issue. > I would appreciate some comments to my other message, at least > the 1342-search issue. To tell you the truth, I do not know how to react to the 1342-search issue you raised. I defined 1342-search as a means of helping out people in Sweden and Japan who wanted a way to do searches with their national character sets. I made repeated questions about whether or not it would be helpful. I received one answer from Sweden saying it would be helpful, and no answers from Japan. Frankly, given that 1342-search would be complicated to implement, and given your complaints about it, the most likely thing to happen is that 1342-search would be removed from IMAP2bis and there will be no way at all to do searches on strings of non-ASCII characters. I don't understand your complaint about ``which character set to use'' at all. I would assume that someone who is searching for a Swedish word would select the appropriate character set for Swedish and not search for it using another character set. IMAP protocol uses the 7-bit ASCII character set. This is the ONLY character set which is reliably available on all systems on the network. Not even the ISO-8859-1 character set can make that claim. Any non-ASCII characters must be rendered into 7-bit ASCII. 1342-search was offered as a way to do this. We are not going to convert IMAP from ASCII to Unicode; if you think that the Internet world should adopt Unicode to replace ASCII that should be brought up with the general IETF, not snuck in to a relatively minor protocol as IMAP. If you wish to offer an alternative to 1342-search, you will need to consider certain problems: 1) The question ``why is there Yet Another way to represent international characters in mail, when we have charsets in MIME and 1342?'' 2) Euro-centricism: any proposal which handles European languages but not non-alphabetic scripts (and in particular East Asian languages) will be rejected. Mnemonic, while excellent for European languages, fails because of this problem. 3) Clear and unambiguous definition. 4) Obvious distinction from an ``ordinary'' string, which is ASCII. 5) Other compatibility with the past issues; there are many existing IMAP servers already installed. 1342-search was picked because it addressed these problems, and all other proposed solutions must do so as well. It was certainly not picked for ease of implementation. I think that the bottom line is to decide whether or not 1342-search is better than no international search at all, because that will probably end up being the choice. From owner-imap@cac.washington.edu Sat Aug 28 17:47:05 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25729; Sat, 28 Aug 93 17:47:05 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18543; Sat, 28 Aug 93 17:46:39 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18537; Sat, 28 Aug 93 17:46:36 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21723; Sun, 29 Aug 93 02:39:01 +0200 Message-Id: <9308290039.AA21723@nada.kth.se> To: Mark Crispin Cc: IMAP Interest List Subject: Re: More IMAP questions and suggestions (before the meeting) In-Reply-To: Your message of "Sat, 28 Aug 1993 09:19:32 PDT." Date: Sun, 29 Aug 1993 02:38:59 +0200 From: Peter Svanberg Quoting: Mark Crispin > There is another solution, which is to write your code in such > a way that you do not have unusable commands. That is, have > fallbacks to alternative methods of accomplishing the same > thing. OK, but I assumed it to be impossible in some cases -- APPEND, SUBSCRIBE ... > I think also that you misunderstand what I am supposed to be > doing at this point. ... What I must do is to find things that > are wrong with an idea, so that only the very best and most > important ideas make it into IMAP. Sure, I understand. I just think there are different ways of saying no to a person taking time to understand, suggest and ask. > The idea of using the term ``read'' > instead of the most IMAP-specific ``select'' is to convey the > idea of ¥RECENT; these are messages that there is a reasonable > supposition that the user has not seen before. But why not explain that? Better to speak out (in a few words) than leave open for misinterpretations? Now I just found that in the response RECENT the number of new messages in the mailbox "new message" means ¥RECENT, but in FIND NEW it means (¥RECENT and not(¥SEEN)) -- isn't that confusing? (I suggest a change to "newly arrived" in the first case.) > At the other hand, there are other > kinds of read-only mailboxes where the user can not manipulate > state at all, and no way to determine anything like ¥RECENT status. Does the protocol say what to put in the RECENT response after SELECT in that case? > I defined 1342-search as a means of helping out people > in Sweden and Japan who wanted a way to do searches with > their national character sets. I made repeated questions > about whether or not it would be helpful. I received > one answer from Sweden saying it would be helpful, and no > answers from Japan. I was the one answering, but I said yes on the following conditions (to which I got no reaction): Yes, it would help us, if this is what you meant: 1) The user types his search string as any other text, i.e. with eightbit characters. 2) The client encodes the user string into RFC1342 format and sends it to the server. 3) The server decodes it and compares it with (a decoded version of) the specified part of each letter. The text in the current draft does not comply with 3) here: > The string may be in RFC 1342 format to express a character set > other than US-ASCII. In this case, the criteria matches if the > string matches the character set and characters of a substring of > that field. You added a match of character set (see below). > I don't understand your complaint about ``which character > set to use'' at all. I would assume that someone who is > searching for a Swedish word would select the appropriate > character set for Swedish and not search for it using another > character set. I know this is difficult but I'll try: Given that it _is_ a word of language L and that the usage of that language uniquely identifies which the character set must be, then it will work. Unfortunately, those conditions will very seldom be met: Many languages, Swedish included, could be (and is) encoded in several different character sets, even in the small 8859-x set. Also, all words and names containing just A-Z but which happen to be part of a 1342-encoded line (as Andersson in my example) will not be found. Example: If you do SEARCH FROM "=?ISO-8859-1?Q?Borg?=" you would find the Swedish name "Bjn Borg", as it must be 1342-encoded, but probably not the Swedish name "Anders Borg" as it will not be 1342-encoded. > We are not going to convert IMAP from ASCII to Unicode; if you think > that the Internet world should adopt Unicode to replace ASCII > that should be brought up with the general IETF, not snuck in > to a relatively minor protocol as IMAP. Discussions about UCS/Unicode and IETF is already going on - there was a BOF on the subject on the latest IETF meeting in Amsterdam. Some protocol must be the first to try UCS and that should not be one of the most used ones. I don't think it would delay IMAP much if you specify it well and non-demanding. And non-ASCII-support could make IMAP spread very fast in Euorpe... (Calm down, I have no hope for you to buy this, I just had to say it anyhow.) > If you wish to offer an alternative to 1342-search, you will > need to consider certain problems: Give me some time, I'll think about it. I will try (no promises) to come up with something before Tuesday morning. --- Peter Svanberg, Nada, KTH From owner-imap@cac.washington.edu Sun Aug 29 21:04:44 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10830; Sun, 29 Aug 93 21:04:44 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23186; Sun, 29 Aug 93 21:04:05 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from csgrad.cs.vt.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23180; Sun, 29 Aug 93 21:04:03 -0700 Received: by csgrad.cs.vt.edu (5.65/DEC-Ultrix/4.3) id AA23752; Mon, 30 Aug 1993 00:03:57 -0400 Date: Sun, 29 Aug 1993 23:24:03 -0400 (EDT) From: Laurence Lundblade Subject: Comments on IMAP2bis draft To: Imap Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You can probably guess what my comments are about, but first let me say that the draft looks good. The intro about on-line, off-line, etc. will be helpful for the larger circle of readers. On to mailbox namespaces, the main problem I have with the current state of affairs. First, why I think this is important. If there's no consensus that this is important we can forget the whole issue. Basically, I believe that presenting a list of mailboxes to the user for selection in operations like open and save is really important. I also I think that most IMAPware, that implementing FIND, should interoperate and give the user pretty much the same list of mailboxes. This ought to make IMAP clients more competitive with the stuff coming out of Microsoft and friends, not to mention other Internet mailer. I'd be happy to let this be implementation dependent, but current evidence suggest to me that there is a problem. Of the five IMAP clients that I've used only two operate in in this way at all and those not even with each other. There is currently *no* namespace interoperability at all which is of course what I think is important. What I'd really like to see happen is some stuff added to the IMAP2bis draft to tighten this up. Either suggest that clients be prepared for any sort of namespace at the server (ala Pine) or that servers return the users set of active mailboxes with FIND *, or both. The later seems to be implied by the current draft, though it's not what I've seem implemented. Maybe the solution to this is to leave IMAP2bis the way it is and create a second document on IMAP name spaces? Laurence Lundblade lgl@csgrad.cs.vt.edu 703-552-2537 Virginia Tech -- Blacksburg, Virginia From owner-imap@cac.washington.edu Mon Aug 30 11:20:35 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00403; Mon, 30 Aug 93 11:20:35 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09707; Mon, 30 Aug 93 11:20:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09701; Mon, 30 Aug 93 11:19:58 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42406-2>; Mon, 30 Aug 1993 12:19:49 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Mon, 30 Aug 93 11:42 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.26.7 #1) id m0oXDLX-000cvxC; Mon, 30 Aug 93 11:48 MDT Date: Mon, 30 Aug 1993 11:41:10 -0600 From: Steve Hole Subject: Re: Comments on IMAP2bis draft To: Laurence Lundblade Cc: imap@cac.washington.edu Message-Id: Priority: Normal X-Read-Ack: No X-Delivery-Ack: No Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 29 Aug 1993 21:24:03 -0600 Laurence Lundblade wrote: > From: Laurence Lundblade > Date: Sun, 29 Aug 1993 21:24:03 -0600 > Subject: Comments on IMAP2bis draft > To: Imap Interest List > > Basically, I believe that presenting a list of mailboxes to the user for > selection in operations like open and save is really important. I also I > think that most IMAPware, that implementing FIND, should interoperate and > give the user pretty much the same list of mailboxes. This ought to make > IMAP clients more competitive with the stuff coming out of Microsoft and > friends, not to mention other Internet mailer. > > I'd be happy to let this be implementation dependent, but current evidence > suggest to me that there is a problem. Of the five IMAP clients that I've > used only two operate in in this way at all and those not even with each > other. There is currently *no* namespace interoperability at all which is > of course what I think is important. > > What I'd really like to see happen is some stuff added to the IMAP2bis > draft to tighten this up. Either suggest that clients be prepared for any > sort of namespace at the server (ala Pine) or that servers return the > users set of active mailboxes with FIND *, or both. The later seems to be > implied by the current draft, though it's not what I've seem implemented. > Maybe the solution to this is to leave IMAP2bis the way it is and create a > second document on IMAP name spaces? I concur with Laurence here. Basically, we have been *requested* by just about everyone seriously considering our MUA to relieve them of the host namespace conventions. 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-imap@cac.washington.edu Mon Aug 30 16:05:15 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07532; Mon, 30 Aug 93 16:05:15 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27977; Mon, 30 Aug 93 16:04:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27971; Mon, 30 Aug 93 16:04:46 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA10698; Tue, 31 Aug 93 01:04:43 +0200 Message-Id: <9308302304.AA10698@nada.kth.se> To: IMAP Interest List Cc: Mark Crispin Subject: Better 1342-handling-spec Date: Tue, 31 Aug 1993 01:04:42 +0200 From: Peter Svanberg Quoting myself: > Give me some time, I'll think about it. I will try (no promises) > to come up with something before Tuesday morning. Well, a quick answer. The problematic part is > The string may be in RFC 1342 format to express a character set > other than US-ASCII. In this case, the criteria matches if the > string matches the character set and characters of a substring of > that field. Suggested minimal change ======================== Change the criteria statement to: The string may be in the MIME-part-2-representation, to express characters other than those in the US-ASCII repertoir. In this case, the criteria matches if the string - after being decoded - matches characters of a substring of the message field in question. (With "characters" is here meant the actual meaning of the coded value in the specified character set.) (The RFC will probably get an other number than 1342 before it becomes a standard, so don't refer to "1342".) Add somewhere a "conformance statement" like: An IMAP2bis server implementing the SEARCH command with MIME-part-2-representation must at least be able to match ASCII characters against the ASCII part of the ISO-8859-* character sets. (This is a parallell to the conformance statement of the current MIME-part2-01 draft.) Implementation discussion ========================= Implementation of the SEARCH-compare-handling in the general case is complicated if you allow many possible character sets on both sides of the comparison. On the other hand, if just _one_ character set is allowed, it will be rather simple. Suggested improvement of "minimal change" ========================================= Allow only UCS/Unicode with the UTF-2-encoding (FSS, "file system safe") in the MIME-part-2-representation-string (charset= ISO-UCS or what will be decided), at let it be given either as 8-bit in a "literal" (encoding=) or as 7-bit with Q or B-encoding (I don't know which is best). > 1) The question ``why is there Yet Another way to represent international > characters in mail, when we have charsets in MIME and 1342?'' Not applicable - it's just an extension of the current. > 2) Euro-centricism: any proposal which handles European languages... No problem. > 3) Clear and unambiguous definition. Easily done. > 4) Obvious distinction from an ``ordinary'' string, which is ASCII. No problem. > 5) Other compatibility with the past issues; there are many existing IMAP > servers already installed. Not applicable - new functionality. (1342-handling isn't implemented anywhere, is it?) Decoding of UTF-2 is easy. The character set problems in compare-handling is minimized: The server converts from the message-text-character sets to UCS. The client just converts from local character set to UCS. What more could you ask? This is a solution for the future, but doesn't interfere with current usage. (Editorial comment to the draft: The SEARCH FROM alternative is missing from the formal "BNF" part.) --- 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-imap@cac.washington.edu Tue Aug 31 10:32:31 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26037; Tue, 31 Aug 93 10:32:31 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22495; Tue, 31 Aug 93 10:31:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22489; Tue, 31 Aug 93 10:31:47 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <42358-2>; Tue, 31 Aug 1993 11:31:41 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Tue, 31 Aug 93 09:44 MDT Received: from 58.22.2.115 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0oXXyL-000cvyC; Tue, 31 Aug 93 09:50 MDT Date: Tue, 31 Aug 1993 10:44:19 -0600 From: Joel King Subject: Re: Comments on IMAP2bis draft To: IMAP@cac.washington.edu Message-Id: Priority: Normal X-Read-Ack: No X-Delivery-Ack: No Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 29 Aug 1993 21:24:03 -0600 Laurence Lundblade wrote: > From: Laurence Lundblade > Date: Sun, 29 Aug 1993 21:24:03 -0600 > Subject: Comments on IMAP2bis draft > To: Imap Interest List > > > > On to mailbox namespaces, the main problem I have with the current state > of affairs. First, why I think this is important. If there's no consensus > that this is important we can forget the whole issue. > > Basically, I believe that presenting a list of mailboxes to the user for > selection in operations like open and save is really important. I also I > think that most IMAPware, that implementing FIND, should interoperate and > give the user pretty much the same list of mailboxes. This ought to make > IMAP clients more competitive with the stuff coming out of Microsoft and > friends, not to mention other Internet mailer. Based on feedback obtained from corporate users of ECSMail, I agree completely. There is much competition out there from people who do things their own way but in so doing, provide the product features people want. A user wants a list of folders (mailboxes) presented to him, since his user interface is mouse-based. He cares little where they are stored, as long as he can access the same list from ALL the MUA's he uses. The best place to have this mailbox path resolved is at the server and to make it either standard or configurable at the server end. There is currently no way for an imap client to create a remote mailbox holding area (such as ‾/Mail on a UNIX server), and having new folders appear in a user's home directory (on a UNIX host) is untidy. I still favor the idea of a hierarchical name space but it must be transparent to a user. Joel King - ISA Corp. From owner-imap@cac.washington.edu Wed Sep 1 06:15:43 1993 Received: by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21646; Wed, 1 Sep 93 06:15:43 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailbox.syr.EDU by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21640; Wed, 1 Sep 93 06:15:42 -0700 Received: from spider.syr.EDU by mailbox.syr.edu (4.1/CNS) id AA26688; Wed, 1 Sep 93 09:17:06 EDT Received: by spider.syr.EDU (4.1/Spike-2.0) id AA20290; Wed, 1 Sep 93 09:15:35 EDT Message-Id: <9309011315.AA20290@spider.syr.EDU> To: IMAP Interest List Cc: jmwobus@mailbox.syr.edu Subject: Re: More IMAP questions and suggestions (before the meeting) In-Reply-To: Your message of "Sat, 28 Aug 93 00:07:25 PDT." Date: Wed, 01 Sep 93 09:15:34 -0400 From: "John M. Wobus" In message Mark writes: >Answers to your comments: > >1) You are correct. The only way to tell if a command is implement is to try >the command and see if you get a BAD response or an OK/NO response. > >An IMAP2bis-compliant server MUST implement ALL of the functionality described >in the IMAP2bis specification. Otherwise it is not IMAP2bis-compliant. > >It is impossible to enumerate the possible versions of IMAP2 servers which >have existed in the past. IMAP2 has been an evolving protocol, and many of >the new capabilities introduced in IMAP2bis have been in production servers >for quite some time. > >Well-written clients will have an error fallback when communicating with an >older IMAP2 server that is not IMAP2bis-compliant. The notes in the IMAP2bis >document about ``optional'' functionality are to give notice to client >implementors about what capabilities that may be missing in older servers, so >they have some idea of what sort of error fallback code they will need to >write. > >Note that a VERSION command would be useless. At best, it might tell you of a >server's claim to be IMAP2bis compliant, but it will not tell you what any >older server is capable of. It would be extremely objectionable behavior for >a client to turn off all menu items that use functionality not defined in the >original RFC-1064, since most servers are capable of quite a bit more. > >Nor is a VERSION command any guarantee that the server is, in fact, truly >IMAP2bis compliant. A VERSION (or perhaps "COMPLIANCE") command could carry out this useful function: it would allow clients to be written with the knowledge that a particular set of commands was available. To do this, it need not reflect the exact set of commands supported, only the largest of the standardized sets of commands which the server completely covers. Today's leading-edge IMAP2bis commands will (hopefully) be in tomorrow's minimal subset and it is tomorrow that knowing the server's IMAP2bis-compliance "nearly up front" will be a real aid to developing clients. Graceful handling of BAD responses seems a suitable way for a client to foray past the version-level that a server claims to support, and allows servers to usefully offer partial compliance with an new level, or other experimental commands. A broken VERSION command certainly can spoil the party for a client, but that doesn't make it any different from other server commands. Broken servers deserve a certain amount of the client-developers' attention: mostly flamage and ostracism. John Wobus Syracuse University From owner-imap@cac.washington.edu Thu Sep 2 10:47:16 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28030; Thu, 2 Sep 93 10:47:16 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22440; Thu, 2 Sep 93 10:46:46 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22434; Thu, 2 Sep 93 10:46:44 -0700 Received: from localhost (postman@localhost) by andrew.cmu.edu (8.5/8.5) id NAA12054; Thu, 2 Sep 1993 13:46:41 -0400 Received: via switchmail; Thu, 2 Sep 1993 13:46:39 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 2 Sep 1993 13:46:23 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 2 Sep 1993 13:46:16 -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, 2 Sep 1993 13:46:14 -0400 (EDT) Message-Id: Date: Thu, 2 Sep 1993 13:46:14 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Comments on IMAP2bis draft In-Reply-To: References: Beak: is Not Joel King writes: > There is currently no way for an imap client to create a > remote mailbox holding area (such as ‾/Mail on a UNIX server), and > having new folders appear in a user's home directory (on a UNIX > host) is untidy. I still favor the idea of a hierarchical name space > but it must be transparent to a user. We spent an entire day discussing hierarchy at the WG meeting. Terry Gray will before too long be posting a summary of issues. At the risk of starting up the debate before the summary is posted, I will point out that in the current flat-namespace model the way for an IMAP client to create a remote mailbox holding area is to create a mailbox in that remote mailbox holding area. The fact that the c-client imapd does not automatically create directories as necessary is arguably a bug. The current model does not provide a mechanism/concept for a client to create an *empty* "mailbox holding area" which is not itself a mailbox and which a later client would be able to see. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Mon Sep 6 22:33:03 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26857; Mon, 6 Sep 93 22:33:03 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08452; Mon, 6 Sep 93 22:32:27 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08446; Mon, 6 Sep 93 22:32:25 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06772; Mon, 6 Sep 93 22:32:23 -0700 Date: Mon, 6 Sep 1993 22:03:42 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Notes from IMAP WG Mtg 8/30-31 To: imap@cac.washington.edu Cc: minutes@CNRI.Reston.VA.US, John C Klensin , Erik Huizer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Note: These notes have not been reviewed by the other attendees; I am responsible for all errors. (Attendees are invited to submit additions and/or corrections.) -teg ---------------------------------------------------------------------------- SUMMARY An interim IMAP WG meeting was held at the University of Washington on August 30 and 31, 1993. Eight people attended. Twenty-three issues were discussed. A consensus position was achieved on 20 of those 23 issues; there was no consensus, but some progress, on the issues related to namespace semantics and hierarchy support. A separate message, attempting to summarize this particular issue, will be forthcoming. A new Internet Draft, incorporating the results of this meeting and several suggestions made via email, will be forthcoming shortly for general review and comment. ---------------------------------------------------------------------------- ISSUE 1: Extensibility of IMAP -Envelope headers -Body structure changes (e.g. content-disposition, MD5) DISCUSSION: -There are some IMAP primitives that don't return as much info as would now be desirable. For example, it would be nice if the ENVELOPE structure included RESENT fields. Moreover, the BODY structure does not now return content-disposition or MD5 information. -Modifying the existing primitives will break existing IMAP software; therefore, new functionality often implies a new primitive. -There is a difference between defining a protocol extension and defining a protocol extensibility mechanism. When considering the need to accommodate protocol evolution, it would be ideal to define a mechanism that would allow "old" clients to discover new fields and do something useful with them... but this is not viewed as a realistic expectation because how the new values would be presented to the client depends upon the type of data, and fully describing the data type, whether or not it is parsed or presented literally, etc, can lead to an overly complex protocol. (In short, a simple name=value property list is not sufficient.) -Even if we can't build a client that will never have to be updated, (to track protocol evolution), at least we should strive to minimize the need to change clients and servers at the same time. We can define new primitives in such a way that clients receiving *lists* of elements can interoperate with a new server that will return more elements in the list than the client understands. That is, the primitive is specified so that the client will discard list elements beyond those it is expecting, rather than choke on them. -In order to accommodate MIME evolution, it is proposed that a new BODY type be defined along the above lines. It will return an S expression list including newly defined MIME elements, and will have new list elements defined over time as needed. -Doing the same thing for the ENVELOPE data structure was thought to be not worth the effort because there is now a primitive to fetch arbitrary groups of header lines --although they are returned as unparsed strings. ENVELOPE contains info to aid the client (e.g. by pre-parsing the basic addresses), but a client can request all or any headers using other primitives. While this places an additional burden on the client to be able to parse these other header lines, that burden is not considered more egregious than the effort to implement an ENVELOPE2 structure. ACTION: a. Define "BODY2" which will allow for unanticipated fields b. Part 0 (zero) in encapsulated messages is defined to mean header c. No change re ENVELOPE ---------------------------------------------------------------------------- ISSUE 2: Mstring grammar DISCUSSION: -In RFC1176, a FIND is defined to return "* mailbox string" but C-client actually returns "* mailbox text-line" -Change existing implementation to match spec? Define a new FIND? ACTION: -Table until other FIND issues (i.e. namespace semantics) are resolved. ---------------------------------------------------------------------------- ISSUE 3: BBOARDS are 2nd class citizens (can't CREATE, APPEND, etc) DISCUSSION: -What does the BBOARDs really do? 1. Defines a different namespace -Global, rather than per-user 2. Implies Read-Only (of course mailboxes *may* be Read-Only) ACTION: -Action deferred until the namespace semantics discussion. If that leads to a more general way to specify a namespace, then the BBOARD construct becomes superfluous ---------------------------------------------------------------------------- ISSUE 4. 8Bit DISCUSSION: -Should IMAP have a way to transmit 8 bit characters? YES, if the character set is discoverable, but NO for the raw 822 text case. -Should IMAP allow unencoded binary transfer? NO, due to robustness concerns about mixing binary transfer in an ascii-oriented protocol. Better to wait on this one, especially in view of the null problem described below. The only real downside to encoding before transfer is the cost of transmitting extra characters due to the encoding overhead. -Should IMAP allow nulls in strings without Base64 encoding? NO, because so much software is based on the "null-terminated-string" model, and tends to break when presented with a null. But clients should be encouraged to be "null tolerant" in any case. -Should IMAP allow 8bit characters in mailbox and flag names? NO, not yet. Let the dust settle on other efforts to extend Internet protocols to 8 bit rather than claiming to have the answer. ACTION: -Revise pg 34 to clarify intent as per above discussion. ---------------------------------------------------------------------------- ISSUE 5. "Optionals" in the spec DISCUSSION: -Having "OPTIONALS" tends to perpetuate disparity across the set of IMAP servers. We want to encourage all new servers (and clients) to fully implement the new spec. Hence make all the primitives mandatory, but provide info on backward-compatibility issues. Also avoid using term "COMPATIBLE" as this will be an invitation for sub-standard implementations to claim IMAP2bis compatibility. -Should primitives such as SUBSCRIBE really be mandatory? YES, better to have a degenerate implemenation that always returns "NO" than to have a truly "optional forever" command. (Note: a full implementation of SUBSCRIBE may also have occassion to return "NO") ACTION: Make all IMAP2bis primitives mandatory and create an appendix documenting backward compatibility issues. ---------------------------------------------------------------------------- ISSUE 6. Versioning or command discovery DISCUSSION: -There are existing clients and servers with different capabilities. There will be new commands added over time. Should IMAP have a way to discover what commands exist before they are executed "for real"? YES, but... -Alternatives: A. Version string... deprecated because advertised version may not really match what is implemented in the software. It is an assertion of compliance to a certain level, but history has shown many deviations. B. Discovery command... still some sentiment for this, but not useful for clients/servers that predate the Discovery command. (Absence of Discovery command does not mean that other commands, e.g. CREATE, are missing.) C. Define non-destructive, reversible behavior for all new primitives, so that a client can test for their existence before actually using them "in action". Example: CREATE INBOX should return either BAD or NO, depending on whether the server is old (doesn't know anything about CREATE) or new (wherein that particular operation is an error.) ACTION: Attempt to define safe "probe" operations for CREATE, DELETE, RENAME, APPEND, etc. ---------------------------------------------------------------------------- ISSUE 7. IMAP command interruption DISCUSSION: -Would be nice, but assumes server will be listening while sending. -Hard to do with TCP and Standard I/O-based software. -Therefore, widespread implementation is unlikely. ACTION: None. ---------------------------------------------------------------------------- ISSUE 8. Returning size info so client can present "progress bars" DISCUSSION: -Highly desirable. -Extremely hard to implement efficiently... to the point that it is unlikely that a client could depend upon having the info ACTION: Defer until someone proposes a sufficiently efficient solution to expect widespread implementation. ---------------------------------------------------------------------------- ISSUE 9. Preserving flags/date on COPY, setting on APPEND DISCUSSION: -Should APPEND provide a way to set flags? YES. -Should COPY preserve flags? YES (if access controls allow). ACTION: -Change COPY definition to include SHOULD preserve flags -Change APPEND definition to add *optional* argument for flags ---------------------------------------------------------------------------- ISSUE 10. International error strings DISCUSSION: -Should IMAP spec define a way for client to tell server what language to use for messages? NO, because... -Internationalization is non-trivial. -Server needs to be able to generate implementation-specific messages, in whatever language it chooses. -Maybe IMSP can tell server what language the client likes? -Best we can do is to make it easy for a client to localize/modify messages from server if it doesn't like the default language... see Error Codes! ACTION: None. (See Error Codes.) ---------------------------------------------------------------------------- ISSUE 11. Error codes DISCUSSION: -There will always be more error cases than can be specified in the doc. -It would be nice if major categories were presented so that client could easily localize or make program flow decisions (e.g. TRYCREATE) -You don't need a numeric code to achieve the above. ACTION: -An effort will be made to identify some common error cases and define a short descriptor to go at the beginning of all msgs in the category, similar to [PARSE] and [TRYCREATE]. Unlike the rest of the error string, these would become required constant parts of an error string. ---------------------------------------------------------------------------- ISSUE 12. TRYCREATE DISCUSSION: Should TRYCREATE be part of solicited "NO" response on COPY and APPEND? (Right now it is an *unsolicited* NO response) YES, because it is providing information tied specifically to the COPY or APPEND operation. ACTION: Change spec accordingly. ---------------------------------------------------------------------------- ISSUE 13. ISTRING/RFC-1342 SEARCH argument DISCUSSION: -Multiple character set searches are a can of worms. ACTION: -John and Mark to take Peter's suggestions and come up with revised text. ---------------------------------------------------------------------------- ISSUE 14. UID operations for disconnected operation DISCUSSION: -Proposed UID op definitions appear to be satisfactory, for achieving the disconnected operation goal, but BEFORE doesn't add much value... ACTION: -Drop BEFORE operation as superfluous. ---------------------------------------------------------------------------- ISSUE 15. UID uniqueness DISCUSSION: -Regarding the desire to have UIDs be globally unique: there is a conflict between the global uniqueness goal and the goal of having UIDs within a single mailbox always be ascending. Global uniqueness is desirable if it allows detecting that a msg saved in a different or multiple mailboxes is identical to the one in the client cache. However, it is not --in general-- possible to take an arbitrary message with a globally unique ID, and *append* it to a different mailbox while preserving the "UIDs must be in ascending order with a mailbox" requirement. (We ruled out the possibility of inserting a message in the middle of a mailbox to preserve UID ascendancy as this would violate user expectations, especially for APPEND!) -Conclude: global uniqueness is desirable, but cannot be required. (Nor should it be forbidden in the spec.) ACTION: -Define UIDs as unique within a folder, but not *necessarily* across folders. -Note that globally unique UID will conflict with "UIDs are always ascending in a mailbox", assuming we always append/copy rather than insert a msg in the middle of a mailbox. ---------------------------------------------------------------------------- ISSUE 16. RECENT description DISCUSSION: -Current definition is incomplete/inconsistent ACTION: -Make wording changes on pg 15 based on Peter's suggestions (avoid word "new" in RECENT defn; specify read-only case). ---------------------------------------------------------------------------- ISSUE 17. New SEARCH DISCUSSION: -Understood to be needed -A starting point for a definition: Be able to search on Composed DATE Be able to search on Received DATE Be able to search on MessageID Be able to search on general header text NOT operator Deprecate "UN..." constructs OR operator operator grouping If not regular expressions, at least wild cards in strings Better international searching ACTION: -Solicit IMAP developers to flesh out a detailed proposal for new SEARCH ---------------------------------------------------------------------------- ISSUE 18. Mailbox Reorder DISCUSSION: -Legitimate reasons to want to (permanently) reorder a mailbox, but hard to anticipate all possible sort requirements... -COPY provides a moderately efficient way for client to create a new mailbox in the order desired by the client. -For now, best to leave as a client issue. ACTION: -None now; revisit if support for sorted/filtered views is ever added. ---------------------------------------------------------------------------- ISSUE 19. Sorted/Filtered Views DISCUSSION: -A goal of some clients is to present to the user (possibly multiple) message selections (subsets) in an order other than the natural order of the mailbox. -A perrennial question is how much support should the protocol and server provide to the client for this type of situation. -This is (as is often the case) a performance tradeoff. Client-based sorts, even if based only on header info, can be quite time-consuming on current desktop hardware. -A downside of trying to do this on the server is that the protocol must anticipate all the potentially interesting sort and selection criteria. -An open question is whether increasing desktop computer performance, relative to per-user server performance, will mitigate the need for server-based processing; however, server-based search/selection is expected to remain important, especially when connecting via low-speed lines. ACTION: -Defer for further study. ---------------------------------------------------------------------------- ISSUE 20. Message annotation DISCUSSION: -It would be desirable to allow messages to be annotated, perhaps with keywords, perhaps with additions to the text. -It has been proposed that it be possible to rewrite a message in a mailbox (with additional flags or annotations) without having to delete the original version and append the new version to the end of the mailbox, as the change of mailbox order is undesirable. Unfortunately, this approach to annotation is at odds with disconnected operation, wherein it is expected that the client cache copy of a message matches the original. If the content of the original changes, so should the UID, but then it cannot stay in the same place in the mailbox without violating the "UIDs must be in ascending order" rule. -Additional work must be done to explore alternatives for annotation, whether they be via a "threads" model, or external annotation by reference, or invalidation and regeneration of UIDs... ACTION: -Defer for further study. ---------------------------------------------------------------------------- ISSUE 21. Accessing definitive address of message originator DISCUSSION: -It is desired that client can obtain the SMTP envelope address most likely to definitively get a reply back to originator. -Some delivery agents do terrible things to the SMTP envelope addresses, e.g. when the delivery agent creates a "From " address. -RFC1123 (Sec 5.2.8) requires the receiver SMTP to make the "MAIL FROM:" address of the SMTP envelope available via the Return-Path header line. -IMAP spec allows fetching individual header line (e.g. Return-Path) even though it is not part of the IMAP envelope structure. ACTION: -None. Current IMAP behavior is sufficient if host adheres to RFC1123. ---------------------------------------------------------------------------- ISSUE 22. Concern about lack of multi-threading DISCUSSION: -A concern was reported having to do with accessing multiple mailboxes/views at the same time. The concern was that this might not be possible in IMAP because IMAP does not have multiple threads on a single connection. -It is believed that this concern is a misunderstanding. While an IMAP stream does map to a single TCP connection, it is acceptable and often desirable to have multiple streams open concurrently. Existing IMAP clients routinely allow access to multiple mailboxes concurrently. ACTION: None needed. ---------------------------------------------------------------------------- ISSUE 23. Namespace semantics and hierarchy support DISCUSSION: -This one's long... a separate doc will be forthcoming. ACTION: -Develop detailed plan for how a context-free name scheme could adequately support hierarchy. -Define hierachy primitives desired in c-client API. -Compare; assess tradeoffs between implementing hierarchy in the client vs. adding protocol support for it. =========================================================================== Summary of items from 3/93 BOF =========================================================================== -Support for disconnected operation -Offline sorting of mailbox -Background server searching and sorting -Shared mailbox per-user state (like a .newsrc, but for mailboxes) -Function to determine where to submit messages -Storage/retrieval of MUA configuration data -Minimal non-plaintext authentication -Minimal confidentiality (XOR with shared secret) -Test assertion that PEM does not affect IMAP -Remote printing (from IMAP server's copy of msg) -Improved searching =========================================================================== Summary of items from 7/93 WG Mtg =========================================================================== -Disconnected operation support, ala DMSP, continues to be widely desired. -There is considerable interest in using IMAP to access message archives. -Several people asked about extensions to support binary message part access, without Base64 or QP encoding: +Possible? +Impact on s-expression model? +Can unencoded binary attachments be transferred without charset concerns? -The question of signalling when large blocks of data are being transferred: +Congestion of pipe; need to have multiple channels or out-of-band signals -Can we have an IMAP server capabilities command, ala new SMTP? -Be sure to look at URL/I work before settling on uniqe message ID scheme. -Is IMAP a distribution list alternative: shared but limited access mailbox? -Can IMAP "integrate" two mailboxes (remote mail archive plus local subset)? -Should IMAP become "Interactive Message Access Protocol"? =========================================================================== Summary of items from 6/92 CMU-UW meeting =========================================================================== -Clearly needed IMAP Futures: +Fetch partial text +Add Create, Delete, Rename folder +Clarify Find folder semantics +Put/append +Subscribe,Unsubscribe -Functions needed with multiple IMAP servers +Directory service -Desired, but deferred: +Search multiple mailboxes on multiple servers +Put/Replace +Extend IMAP to subsume DMSP (Disconnected operation) +Add IMAPd driver to access arbitrary files -Possibilities outside the scope of remote mailbox access +Change password +Get disk usage +Get disk quota +Set disk quota +Change protections on folder +Message posting facility (Send via other than SMTP?) -Believed to be upward-compatible changes: +Disconnected operation +Internationalization of error strings (add numbers while we're at it?) +Internationalization of search strings +Server generated browser lines? -Extensions where old functions must be retained for compatibility: +More powerful search command +New envelope fetch with additional headers -Possibly incompatible changes; +8-bit operation +Using unique IDs as fundamental key instead of sequence number +Rename Fetch operations for greater clarity +Return additional fields after a mail_find(), e.g. count, unseen count -Low bandwidth issues (outside the scope of Remote Mailbox Manipulation): +Printing messages from server +Forwarding messages from server From owner-imap@cac.washington.edu Tue Sep 7 11:41:02 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13055; Tue, 7 Sep 93 11:41:02 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15811; Tue, 7 Sep 93 11:40:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15805; Tue, 7 Sep 93 11:40:08 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA06867; Tue, 7 Sep 93 11:39:21 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA11491; Tue, 7 Sep 93 11:35:15 -0700 Date: Tue, 7 Sep 1993 11:14:07 -0700 (PDT) From: William Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: Notes from IMAP WG Mtg 8/30-31 To: Terry Gray Cc: imap@cac.washington.edu, minutes@cnri.reston.va.us, John C Klensin , Erik Huizer In-Reply-To: Terry Gray's message of Mon, 6 Sep 1993 22:03:42 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > ISSUE 19. Sorted/Filtered Views > > DISCUSSION: > -A goal of some clients is to present to the user (possibly > multiple) > message selections (subsets) in an order other than the natural > order of > the mailbox. > -A perrennial question is how much support should the protocol and > server > provide to the client for this type of situation. > -This is (as is often the case) a performance tradeoff. > Client-based > sorts, even if based only on header info, can be quite > time-consuming > on current desktop hardware. > -A downside of trying to do this on the server is that the > protocol must > anticipate all the potentially interesting sort and selection > criteria. > -An open question is whether increasing desktop computer > performance, > relative to per-user server performance, will mitigate the need > for > server-based processing; however, server-based search/selection is > expected to remain important, especially when connecting via > low-speed > lines. > > ACTION: > -Defer for further study. I suggest those of you who have unix based workstationsclients with X11R5 support give "Xlview" a try. We've created this system over the last year here and it is ready for a pretty general release. It addresses most of the issues listed above for high bandwidth connections. We've found no real processing power limitation with respect to current desktop computers(here we mean decstations or suns). The real problem was the imapserver's inability to handle general boolean searches. To get by this we do the bulk of our searches locally when possible on cached data and default to the server when this information is not present. It ends up now that with the exception of text searches nearly all searches are done locally. This gives a tremendous gain in speed for the user, and took about two days to implement because the c-client provides the bulk of the code required to do the actual searches. Interested parties can contact Mike Macgirvin (mtm@camis.stanford.edu) for more information. Xlview is freeware. We use it and we love it. Bill From owner-imap@cac.washington.edu Thu Sep 9 10:11:17 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15766; Thu, 9 Sep 93 10:11:17 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01071; Thu, 9 Sep 93 10:10:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01065; Thu, 9 Sep 93 10:10:28 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16543; Thu, 9 Sep 93 10:10:23 -0700 Date: Thu, 9 Sep 1993 08:55:31 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: IMAP Hierarcy Support: Part 2 of Notes from 8/31 mtg To: imap@cac.washington.edu Cc: minutes@CNRI.Reston.VA.US, John C Klensin , Erik Huizer Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Folks, Belatedly, here is "part two" of the notes from the Interim IMAP WG meeting held at UW on 8/30-31. The bulk of the second day was devoted to discussion, occassionally heated, of hierarchy support and namespace semantics. These notes consist of three parts: 1. A background/overview section I wrote. 2. A summary of the two leading alternatives prepared by the CMU team. 3. An elaboration of problems with adding hierarchy support to the protocol for VMS namespaces by Wallace Colyer of CMU. Again, in the interest of not being any tardier than I already am, I'm sending this without prior review by the participants, who are again encouraged to send additions/corrections/etc. -teg ========================================================================== PART 1: BACKGROUND/OVERVIEW ========================================================================== GOAL: Our System (servers, clients, protocol) must support hierarchy and collections in a consistent way across different clients (and ideally across different servers as well). APPROACHES: 1. Client gets to pick its own hierarchy model, treating server namespace as "flat" --that is, it only sends and receives context-free names, and any notion of hierarchy is "in the eye of the client". The server must figure out how to accommodate the client's view if/when it conflicts with server's natural hierarchy. 2. Server has a natural hierarchy mechanism; client discovers and expoits the server's natural hierarchy. 3. Protocol defines a lowest-common-denominator hierarchy model that is believed to be useful for most clients and implementable on most servers. Options 1 and 2 are not mutually exclusive. That is, from a protocol perspective, one can imagine a design that would allow either a client having its own view of hierarchy, interacting with the server only via flat (context-free) names, while also allowing other clients to discover and use the servers' natural hierarchy. However, consistent behavior across clients remains an important goal. ISSUES: 1. Defining scope of name set to be returned by FIND. It is essential that the client be able to bound the scope of a FIND search, both on the "prefix" and "suffix" sides of the search string. (Note: c-client FIND does not implement the IMAP spec because it does not follow directories at the moment. This needs to be fixed for clients implementing Approach #1, but those implementing Approach #2 will then need a new mechanism to bound the search to a single directory.) 2. Defining what server will do with "directory" names found within the specified scope. A non-terminal name must be distinguishable from a terminal name. Alternatives for FIND include: a. Return an attribute for non-terminal names designating them as such. b. Ignore non-terminal names; define new primitive to find them. c. Return non-terminal names with the hierarchy delimiter included. d. Server flattens namespace and traverse directories, returning only context-free names. (This supports only approach #1.) 3. There is a distinction between hierarchy created by the user and hierarchy that is pre-existing (designed by someone other than the user, as in an anonymous archive or netnews hierarchy). 4. A mechanism is needed for common name semantics across clients. We all agree that it's really important that different clients can see a common view of the same namespace. If namespace semantics are not an inherent characteristic of the protocol, nor is there a way to discover it via protocol primitives, then there must be an external agreement on how to describe hierarchy, and a mechanism for clients to share hierarchy definitions. IMSP has been suggested as one way various clients could access a common hierarchy definition. 5. Clients should not have any built-in knowledge of server file system semantics. They should be able to discover what they need to know from the server or from client config info. 6. If the conversation with the client is via context-free names, a client needs to be able to easily recombine locally maintained context information, e.g. prefixes, with FIND responses in order to generate arguments for SELECT and other primitives. There wasn't much support for building a "lowest common denominator" model of hierarchy into the protocol, so the discussion centered on approaches #1 and #2. Number #1, where hierarchy is in the "eye of the client" came to known as the "flatlander" view, since names going to and from the server are always flat (context-free) names. Approach #2, wherein the client discovers and uses the natural hierarchy of the server is referred to below as "server exported hierarchy". As you will see, neither approach is without problems... ========================================================================== PART 2: SUMMARY OF THE TWO LEADING ALTERNATIVES ========================================================================== Date: Thu, 2 Sep 1993 11:58:41 -0400 (EDT) From: John Gardiner Myers Subject: hierarchy notes Here is what Wally, Chris, and I wrote up following the meeting: -------------------------------------------------- Two models: Flatlander Server Exported Hierarchy ------------------------------ Flatlander: - Server flattens any internal hierarchy in FIND. Current c-client bezerkely behavior is a bug--it needs to recurse down directories. - CREATE needs to automatically create any necessary internal directories. The client does not know the internal structure of the server and can not be expected to create internal directories. The directory structure may limit the ability to create certain named objects because of internal hierarchical limitations (eg, a unix based server which maps . to / may not allow .. because // can not be maped to the unix filesystem.) or for other administrative reasons. - Need a facility for clients to limit results of FIND results to substring matches based on hierarchical delimiters. Proposal: extension to FIND to allow the client to specify a set of 'stop' characters: a FIND ALL.MAILBOXES comp.* ./ * MAILBOX comp.ai * MAILBOX comp.lang. * MAILBOX comp.baz/ a OK Done comp.ai is a folder. There are folders which start with "comp.lang." and "comp.baz/", but a subsequent FIND is necessary in order to find out what they are. The non-terminals can be identified as such by the fact that they are both longer than the prefix and end with a stop character. They could alterately be identified by using either a new unsolicited reply for non-terminals or by IMSP-style attributes. - The set of stop characters is a client configuration problem. A client can start with a "default" set (probably ./¥) which is modified by a configuration file or IMSP option. (John Myers view: Netnews convention will eventually just win) >>>>> TEG COMMENT: The default set of stop characters is a problem. >>>>> On a single IMAP server, it is possible to have multiple >>>>> hierarchies using different stop characters, e.g. netnews with >>>>> a dot, and a Unix filesystem with a slash. There may be cases >>>>> where having multiple stop characters makes sense, but I certainly >>>>> do NOT want all the dots in my Unix file names to be interpreted >>>>> as hierarchy delimiters. (And the existence of zillions of files >>>>> with dots in their names makes me skeptical of John M's prediction >>>>> that dot will win out as the one true hierarchy delimiter.) Drawbacks: - There is no way to create empty non-terminals which persist. If a folder browser was used to create a "directory", the client would have to handle that information virtually. If the user did not subsequently create a mailbox in that directory, the virtual directory would not persist across sessions. (Chris Newman proposal: add concept of "namespace extender", which can be manipulated through the protocol. A client could create the placeholder "comp.lang." which is neither a folder nor the initial substring of a folder, but shows up as a non-folder when doing FIND with a (possibly empty) set of stop characters.) Counterpoint: in some domains, such as netnews, the concept of an empty nonterminal does not exist. Either the concept would have to be hacked on top of the domain or users would see inconsistent behavior. Is the feature worth the cost? - An anonymous IMAP server may have a pre-defined hierarchy for its data with stop characters which are unknown to the client. One possible solution would be for anonymous IMAP servers to use one of the "default" stop characters for any predefined hierarchy. Another solution would be for the anonymous IMAP server to have an IMSP server which advertises the appropriate stop characters. (reluctant proposal: Add a wart to the protocol to obtain the set of separator characters.) - The "stop character" mechanism will view a VMS-style namespace in an unexpected way. The namespace can still be used and viewed in a hierarchical manner. - Flattening out some namespaces may take an inordinate amount of resources. e.g. FIND /* in c-client berkeley driver will thrash server. This problem exists in other domains (e.g. SEARCH BODY) and is usually solved with administrative limits on such things as depth of search, CPU use, or total number of matches. ------------------------------ Server exported hierarchy: - Need server determined directory concept MKDIR, RMDIR commands Drawback: in some domains, such as netnews, the concept of creating and removing directories does not exist. - NFIND returns both folders and directories. Does not recurse down directories. - Still need flatlander view Flatlander clients Folder discovery (FIND *mail* or similar) Flatlander FIND needs to return directory structure info - Client needs to know the characteristics of the namespace. Protocol has to mandate restrictions on the namespace and/or communicate to the client those characteristics which aren't mandated. In order to implement a Macintosh-style folder browser or a hierarchical browser, client needs to obtain fully qualified name from directory and relative name components. In order to enter such a browser from a flatlander search or Pine-style rubber-room path, client also needs to know how to obtain the sequence of relative names to get to a fully qualified name. This suggests two commands, JOINPATH and EXPANDPATH. Drawbacks: Mandated restrictions will prohibit servers from exporting otherwise useful views. Attempting to describe characteristics which have insufficient restrictions is overly complex. This leaves the possibility of a "convert between relative and absolute paths" command. Examples: In the VMS namespace, the absolute path name: sys$user:[bovik.foo]bar converts to the relative name sequence: sys$user:[000000] [bovik] [.foo] bar Drawbacks: - IMSP server has to know about the characteristics of the namespaces for its IMAP servers. Comments: - CD/PWD is orthogonal to hierarchy, except in that they provide, as a side effect, a JOINPATH mechanism. They are not sufficient to provide a EXPANDPATH mechanism. =========================================================================== PART 3: ELABORATION OF HIERARCHY SUPPORT ISSUES FOR VMS NAMESPACES =========================================================================== Date: Thu, 2 Sep 1993 11:43:00 -0400 (EDT) From: Wallace Colyer Subject: Re: Hierarchy Terry, We ended up at the airport yesterday for a few hours so we wrote up both what it would take to implement hierarchy in the flatlander view and the server exported hierarchy view of the world. That is what John sent you. I will expand on what I mean by doing hierarchy properly. This comes from a view that the server needs to export its hierarchy to the client. If restrictions were put on the hierarchy such that you could make assumptions about the namespace and a namespace like the vms filesystem were disallowed this would not be as bad. What I see as the basic problem in the hierarchy view of the world is how to represent a hierarchical namespace such as vms. In vms you have a hierarchy that looks like: for the file: sys$user:[wally.foo.bar]baz.txt;1 the relative hierarchy used by something like a cd command: (all the devices and logicals which you can't find with a dir command) sys$user:[000000] [wally] [.foo] [.bar] baz.txt;1 And their fully qaulified names for discovery: sys$user:[000000] sys$user:[wally] sys$user:[wally]foo.dir;1 sys$user:[wally.foo]bar.dir;1 sys$user:[wally.foo.bar]baz.txt;1 To use this namespace from an ftp client you need to know something about the namespace. For example, to properly represent a vms namespace fetch knows that mail.dir;1 should be shown to the user as [.mail] In your pine client you want to be able to jump to a "rubber room" in the namespace given a name in a config file. Now if you specified that you wanted to jump to: sys$user:[wally.foo.bar] A macintosh folder browser would want to fill in the bottom parts in the pop of menu denoting where in the namespace you are in. Fetch cannot do this, so shows you the places you cd'ed from and then a special "parent directory" marker. It also gets confused frequently, especially if I cd to the parent directory which is sys$user:[0000000]. Also to continue to support a flat namespace (which we would need very much), for something like *imap* to work you would need to be able to return hierarchy information. This would be needed to fill a hierarchy map of the entire namespace or portion of the namespace. So, given a name or pattern you need to return typed information of the name and its hierarchy, and the relative name from the previous level: find *imap* sys$user:[000000] sys$user:[000000] (/directory) sys$user:[wally] [wally] (/directory) sys$user:[wally.foo] [.foo] (/directory) sys$user:[wally.foo.bar] [.bar] (/directory) sys$user:[wally.foo.bar]imap.txt;1 imap.txt (/folder) This is the hierarchical tree for imap.txt;1. Now this does not explain it if there are multiple ways of getting there in the tree and probably is more complicated than I am explaining it. =========================================================================== From owner-imap@cac.washington.edu Thu Sep 23 19:10:36 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11920; Thu, 23 Sep 93 19:10:36 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24159; Thu, 23 Sep 93 19:10:05 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sat Sep 25 10:59:44 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03387; Sat, 25 Sep 93 10:59:44 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10602; Sat, 25 Sep 93 10:59:10 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailhost2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10596; Sat, 25 Sep 93 10:59:08 -0700 Received: from shiva2.cac.washington.edu by mailhost2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00870; Sat, 25 Sep 93 10:59:07 -0700 Date: Sat, 25 Sep 1993 10:42:20 -0700 (PDT) From: Terry Gray Subject: An inventory of IMAP-ware To: imap@cac.washington.edu Cc: Erik Lawaetz In-Reply-To: <9309210917.AA00347@mx1.cac.washington.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, I think it would be very beneficial for us to maintain a list of IMAP clients and servers (past, present, and future). This has become an FAQ. In presentations I've done on Email architecture, I've usually shown a feeble attempt at such a list (the latest incarnation included below), but I'd like to have your help in making it more accurate and complete. So please send additions/corrections/comments to me for inclusion. Even rumors would be of interest. After the first round of feedback, I'll put the file on ftp.cac.washington.edu under the name /mail/imap.software Thanks. -teg ---------------------------------------------------------------------------- Client MIME? Source/Vendor Status ---------------------------------------------------------------------------- UNIX-Character MS No UWashington Obsolete, except for testing Pine 3.85 Yes UWashington Released UMAIL ? UMaryland In use; availability unknown UNIX-GUI Ximap ? Stanford U. Obsolete? XLView Yes Stanford U. Beta Cyrus Yes CMU In development DOS PC-Pine 3.85 Yes UWashington Released WINDOWS ECSMail 2.1 Yes ISA Corp. Released?? TWG Pathways No Wollongong Released, but not WinSock MACINTOSH MacMS No Stanford U. Obsolete Mailstrom 1.0x No Stanford U. Released, but a bit buggy Mailstrom 2.0x Yes Stanford U. In development TWG Pathways No Wollongong Released NeXT MailManager Yes UWashington Released EasyMail Yes UWashington Released VMS PMDF tools ? Innosoft ??? Lisp Machines MM-D, etc No Stanford U. Obsolete? ---------------------------------------------------------------------------- IMAP Servers ---------------------------------------------------------------------------- UNIX (imapd) UWashington Stanford (obsolete?) CMU (in development) VMS Innosoft (part of PMDF product) TENEX ? ---------------------------------------------------------------------------- CONTACTS ---------------------------------------------------------------------------- University of Washington (Pine, PC-Pine, MailManager, EasyMail, IMAPd, IPOP) ftp.cac.washington.edu: /mail pine@cac.wasington.edu (for pine inquiries/comments) pine-bugs@cac.wasington.edu (for pine bug reports) c-client-request@cac.washington.edu (for c-client developers) imap-request@cac.washington.edu (for imap discussion) pine-info-request@cac.washington.edu (for pine discussion) pine-announce-request@cac.washington.edu (to get announcements) Stanford University: (Mailstrom, XLView) sumex-aim.stanford.edu: /imap/clients mailstrom-develop@camis.stanford.edu (for mailstrom developers) mailstrom-announce@camis.stanford.edu (for general announcements) mailstrom-report@camis.stanford.edu (for mailstrom bug reports) mailstrom-request@camis.stanford.edu (to subscribe to the others) Integrated Systems Applications (ISA) Corp. (ECSMail) Alberta, CA "ECS Sales" (403-420-8081) ecs-info-request@edm.isac.ca The Wollongong Group Inc. (Pathways Messenger mail software) Palo Alto, CA, USA (800) 872-8649 Innosoft (PMDF mail software for VMS) Claremont, CA, USA From owner-imap@cac.washington.edu Mon Sep 27 11:39:00 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17219; Mon, 27 Sep 93 11:39:00 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29111; Mon, 27 Sep 93 11:34:54 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29102; Mon, 27 Sep 93 11:34:50 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA24327; Mon, 27 Sep 93 11:34:44 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA20378; Mon, 27 Sep 93 11:30:12 -0700 Date: Mon, 27 Sep 1993 11:29:50 -0700 (PDT) From: William Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: RE: An inventory of IMAP-ware To: Terry Gray Cc: imap@cac.washington.edu, Erik Lawaetz In-Reply-To: Terry Gray's message of Sat, 25 Sep 1993 10:42:20 -0700 (PDT): Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > UNIX-GUI > Ximap ? Stanford U. Obsolete? > XLView Yes Stanford U. Beta > Yes, XImap is obsoleted by XLView. Bill From owner-imap@cac.washington.edu Mon Sep 27 12:00:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18189; Mon, 27 Sep 93 12:00:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29617; Mon, 27 Sep 93 12:00:11 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29611; Mon, 27 Sep 93 12:00:06 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18583-2>; Mon, 27 Sep 1993 12:59:41 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Mon, 27 Sep 93 11:50 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0ohLfr-000cy3C; Mon, 27 Sep 93 10:43 MDT Date: Mon, 27 Sep 1993 10:43:40 -0600 From: Steve Hole Subject: Re: An inventory of IMAP-ware To: Terry Gray Cc: imap@cac.washington.edu, Erik Lawaetz Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have added a bit more information on the ECSMail products. Cheers. On Sat, 25 Sep 1993 11:42:20 -0600 Terry Gray wrote: > From: Terry Gray > Date: Sat, 25 Sep 1993 11:42:20 -0600 > Subject: An inventory of IMAP-ware > To: imap@cac.washington.edu > Cc: Erik Lawaetz > > ---------------------------------------------------------------------------- > Client MIME? Source/Vendor Status > ---------------------------------------------------------------------------- > > UNIX-Character > MS No UWashington Obsolete, except for testing > Pine 3.85 Yes UWashington Released > UMAIL ? UMaryland In use; availability unknown > > UNIX-GUI > Ximap ? Stanford U. Obsolete? > XLView Yes Stanford U. Beta > Cyrus Yes CMU In development ECSMail Motif Yes ISA Corp. In development > > DOS > PC-Pine 3.85 Yes UWashington Released ECSMail DOS Yes ISA Corp. In Development > > WINDOWS > ECSMail 2.1 Yes ISA Corp. Released > TWG Pathways No Wollongong Released, but not WinSock WINDOWS NT ECSMail 2.1 Yes ISA Corp. Released OS/2 ECSMail OS/2 Yes ISA Corp. Development > > MACINTOSH > MacMS No Stanford U. Obsolete > Mailstrom 1.0x No Stanford U. Released, but a bit buggy > Mailstrom 2.0x Yes Stanford U. In development > TWG Pathways No Wollongong Released ECSMail Mac Yes ISA Corp. 2.1 Alpha 2 > > NeXT > MailManager Yes UWashington Released > EasyMail Yes UWashington Released > > VMS > PMDF tools ? Innosoft ??? ECSMail VMS Yes ISA Corp. Planned > > Lisp Machines > MM-D, etc No Stanford U. Obsolete? > > > ---------------------------------------------------------------------------- > IMAP Servers > ---------------------------------------------------------------------------- > > UNIX (imapd) > UWashington > Stanford (obsolete?) > CMU (in development) > > VMS > Innosoft (part of PMDF product) > > TENEX > ? > > ---------------------------------------------------------------------------- > CONTACTS > ---------------------------------------------------------------------------- > > University of Washington (Pine, PC-Pine, MailManager, EasyMail, IMAPd, IPOP) > ftp.cac.washington.edu: /mail > pine@cac.wasington.edu (for pine inquiries/comments) > pine-bugs@cac.wasington.edu (for pine bug reports) > c-client-request@cac.washington.edu (for c-client developers) > imap-request@cac.washington.edu (for imap discussion) > pine-info-request@cac.washington.edu (for pine discussion) > pine-announce-request@cac.washington.edu (to get announcements) > > Stanford University: (Mailstrom, XLView) > sumex-aim.stanford.edu: /imap/clients > mailstrom-develop@camis.stanford.edu (for mailstrom developers) > mailstrom-announce@camis.stanford.edu (for general announcements) > mailstrom-report@camis.stanford.edu (for mailstrom bug reports) > mailstrom-request@camis.stanford.edu (to subscribe to the others) > > Integrated Systems Applications (ISA) Corp. (ECSMail) > Alberta, CA "ECS Sales" (403-420-8081) > ecs-info-request@edm.isac.ca > > The Wollongong Group Inc. (Pathways Messenger mail software) > Palo Alto, CA, USA (800) 872-8649 > > Innosoft (PMDF mail software for VMS) > Claremont, CA, USA > -- 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-imap@cac.washington.edu Mon Sep 27 20:14:18 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05870; Mon, 27 Sep 93 20:14:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08219; Mon, 27 Sep 93 20:13:56 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from cari.telecom.uqam.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08213; Mon, 27 Sep 93 20:13:52 -0700 Received: from nobel.si.uqam.ca by cari.telecom.uqam.ca (4.1/SMI-4.2.1.pop NIS) id AA08579; Mon, 27 Sep 93 23:13:48 EDT Received: by nobel.si.uqam.ca (1.37.109.4/16.2) id AA22550; Mon, 27 Sep 93 23:13:55 -0400 Date: Mon, 27 Sep 1993 23:13:21 +0500 (EST) From: "Lavallee, Marc" Subject: Subscription To: IMAP@CAC.Washington.EDU Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please add me to the IMAP mailing list From owner-imap@cac.washington.edu Tue Sep 28 11:43:15 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27812; Tue, 28 Sep 93 11:43:15 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17751; Tue, 28 Sep 93 11:42:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17745; Tue, 28 Sep 93 11:42:32 -0700 Received: from mcs-ss1-1.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA23896; Tue, 28 Sep 93 11:42:30 PDT Date: Tue, 28 Sep 1993 10:50:26 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: mail_append() ... how? To: mrc@camis.stanford.edu Cc: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is from the recently frozen 3.0 c-client. I'm trying to implement a function which calls mail_append(), and I'm probably having troubles initializing the STRING structure. Working from other sections of the c-client where this structure is used, I've tried: (generalized code) extern STRINGDRIVER mail_string; /* ??? */ STRING bs; INIT(&bs,mail_string,text,strlen(text)); mail_append(ms,mailboxname,&bs); ...where the value for mailboxname is "{host.fqn}existing.mailbox", and "text" is a char * to a complete mail message (header and body) in RFC822 format. The mail_append() function fails in mail_valid() due to (stream->dtb != factory) where factory is "imap2", i.e. the first driver in the chain. "ms" above is an open/active MAILSTREAM (i.e. the main mailbox, and is on the same host as specified in the mailboxname). Replacing STRINGDRIVER with one in my own space (not extern) dumps with SIGILL, which I believe is due to an uninitialized STRINGDRIVER. I believe I should be using one in my own space, but need to know how to go about setting it up correctly, or other pointers to the error in my ways. Any clues appreciated. "mike" (Mike Macgirvin) Mike_Macgirvin@MED.Stanford.EDU Unix Server Administrator Center for Advanced Medical Informatics at Stanford From owner-imap@cac.washington.edu Tue Sep 28 18:32:55 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14698; Tue, 28 Sep 93 18:32:55 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22842; Tue, 28 Sep 93 18:32:25 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22836; Tue, 28 Sep 93 18:32:23 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA09295; Tue, 28 Sep 93 18:32:20 -0700 Date: Tue, 28 Sep 1993 18:24:35 -0700 (PDT) From: Mark Crispin Subject: re: mail_append() ... how? To: Mike_Macgirvin@CAMIS.Stanford.EDU Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Mike - c-client questions should go to the c-client mailing list, not IMAP. Thanks. mail_string is the name of a built-in stringstruct driver in c-client which deals with in-memory strings that are entirely in memory. Other stringstruct drivers are possible (for example, there is a file-oriented one in the DOS dawz.c module). A stringstruct driver is a vector of function pointers. So, if you ``have one in your own space'', if you simply allocate space but fail to define the vector then you end up with a vector of zeros (or randomness!) which will then be invoked as a function pointer. Guaranteed crash. In terms of your failing mail_append() call with the factory not being the same as the stream->dtb, I suggest that you check that the ms really is open on an IMAP stream. Check to see if factory->name and stream->dtb->name are the same thing. I bet they are not. Please let me know if you're still having problems. -- Mark -- From owner-imap@cac.washington.edu Sun Oct 3 18:04:41 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25514; Sun, 3 Oct 93 18:04:41 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23243; Sun, 3 Oct 93 18:03:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailhost2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23237; Sun, 3 Oct 93 18:03:25 -0700 Received: from shiva1.cac.washington.edu by mailhost2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06180; Sun, 3 Oct 93 18:03:22 -0700 Date: Sun, 3 Oct 1993 17:54:40 -0700 (PDT) From: Terry Gray Subject: IMAP-ware inventory To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Revised: 93.10.3 T. Gray File: {ftp.cac.washington.edu} /mail/imap.software ---------------------------------------------------------------------------- Client MIME? Source/Vendor Status ---------------------------------------------------------------------------- UNIX-Character MS No UWashington Demonstration/test program Pine 3.85 Yes UWashington Released (3.86 due 10/7/93) UMAIL ? UMaryland In use; availability unknown UNIX-GUI Ximap ? Stanford U. Obsolete XLView 1.22 Yes Stanford U. Released Palm Yes? UMiami In development (C-client + TCL/TK) Cyrus Yes CMU In development ECSMail Motif Yes ISA Corp. In development DOS PC-Pine 3.85 Yes UWashington Released ECSMail DOS Yes ISA Corp. In development WINDOWS ECSMail 2.1 Yes ISA Corp. Released TWG Pathways No Wollongong Released, but not WinSock PC-Pine Yes UWashington Planned (same UI, but Windows App) WinPine* Yes UWashington Proposed (GUI version) WINDOWS NT ECSMail 2.1 Yes ISA Corp. Released OS/2 ECSMail OS/2 Yes ISA Corp. In development MACINTOSH MacMS No Stanford U. Obsolete Mailstrom 1.0x No Stanford U. Released, but a bit buggy Mailstrom 2.0x Yes Stanford U. In development TWG Pathways No Wollongong Released ECSMail Mac Yes ISA Corp. 2.1 Alpha 2 NeXT MailManager Yes UWashington Released EasyMail Yes UWashington Released VMS ECSMail VMS Yes ISA Corp. Planned Pine Yes ??? Rumored to exist for PMDF Lisp Machines MM-D No Stanford U. Obsolete Yes-Way Yes Stanford U. ? Amiga Pine 3.8x Yes D. Miller (UW) In development * GUI versions of Pine for several platforms have been proposed, but none are in development at this time. ---------------------------------------------------------------------------- IMAP Servers ---------------------------------------------------------------------------- UNIX (imapd) UWashington (Released, but evolving with IMAP2bis spec) Stanford (obsolete, but widely used to support MacMS) CMU (in development) VMS Innosoft (Version 4.2 released Mar 93; part of PMDF product) TOPS-20 Crispin ("MAPSER"; not IMAP2bis compliant) ---------------------------------------------------------------------------- CONTACTS ---------------------------------------------------------------------------- University of Washington (Pine, PC-Pine, MailManager, EasyMail, IMAPd, IPOP) FTP: ftp.cac.washington.edu: /mail pine@cac.wasington.edu (for pine inquiries/comments) pine-bugs@cac.wasington.edu (for pine bug reports) c-client-request@cac.washington.edu (for c-client developers) imap-request@cac.washington.edu (for imap discussion) pine-info-request@cac.washington.edu (for pine discussion) pine-announce-request@cac.washington.edu (for pine announcements) Stanford University: (Mailstrom, XLView) FTP: sumex-aim.stanford.edu: /imap/clients macms@camis.stanford.edu (for general discussion) xlview@camis.stanford.edu (general info, developer hotline) xlview-request@camis.stanford.edu (for release announcements) mailstrom@camis.stanford.edu (for general discussion) mailstrom-announce@camis.stanford.edu (for announcements) mailstrom-develop@camis.stanford.edu (for mailstrom developers) mailstrom-report@camis.stanford.edu (for mailstrom bug reports) mailstrom-request@camis.stanford.edu (to subscribe to the others) Integrated Systems Applications (ISA) Corp. (ECSMail) FTP: ftp.srv.ualberta.ca: (demo version only) Suite 835, 10040 - 104 St. Edmonton, Alberta, CA T5J 0Z2 ECS Sales: (403) 420-8081 FAX: (403) 420-8037 ecs-info-request@edm.isac.ca The Wollongong Group Inc. (Pathways Messenger mail software) Palo Alto, CA, USA (800) 872-8649 Innosoft International Inc. (PMDF mail software for VMS) 250 W. First Street, #240, Claremont CA 91711 (909) 624-7907, FAX (909) 621-5319 sales@innosoft.com (for literature and general info) service@innosoft.com (for technical questions) From owner-imap@cac.washington.edu Mon Oct 4 08:12:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08373; Mon, 4 Oct 93 08:12:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28335; Mon, 4 Oct 93 08:10:57 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ietf.cnri.reston.va.us by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28329; Mon, 4 Oct 93 08:10:54 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa29592; 4 Oct 93 11:02 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: imap@cac.washington.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-imap-imap2bis-01.txt Date: Mon, 04 Oct 93 11:02:03 -0400 Message-Id: <9310041102.aa29592@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Mail Access Protocol Working Group of the IETF. Title : INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis Author(s) : M. Crispin Filename : draft-ietf-imap-imap2bis-01.txt Pages : 53 The Interactive Mail Access Protocol, Version 2bis (IMAP2bis) allows a client to access and manipulate electronic mail on a server. IMAP2bis is designed to permit manipulations of remote mailboxes as if they were local. IMAP2bis includes operations for creating, deleting, and renaming mailbox folders; checking for new mail; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-imap-imap2bis-01.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-imap-imap2bis-01.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-imap-imap2bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imap-imap2bis-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From owner-imap@cac.washington.edu Tue Oct 5 12:15:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29230; Tue, 5 Oct 93 12:15:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22763; Tue, 5 Oct 93 12:09:07 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22757; Tue, 5 Oct 93 12:08:59 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA08014; Tue, 5 Oct 1993 15:08:55 -0400 Received: via switchmail; Tue, 5 Oct 1993 15:08:53 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 5 Oct 1993 15:07:49 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 5 Oct 1993 15:07:42 -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, 5 Oct 1993 15:07:40 -0400 (EDT) Message-Id: Date: Tue, 5 Oct 1993 15:07:40 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: ¥Seen flag Beak: is Not The current IMAP2bis specification implies that the ¥Seen flag must be included in the flag_list returned in the * FLAGS unsolicited response. I think it would be useful for the Cyrus imapd to only return the ¥Seen flag in the * FLAGS unsolicited response when the server is actually maintaining ¥Seen state for the user. This would be useful for situations, such as "Anonymous IMAP", where the server does not wish to preserve the ¥Seen state for the user. There has been previous discussion expressing interest in clients which maintain their own ¥Seen state in this situation. In order to interoperate, such clients should let the server maintain ¥Seen state when the server is willing to do so. For this to be possible, the clients need some way to detect whether or not the server is preserving ¥Seen state across sessions. Checking for the presence of the ¥Seen flag in the * FLAGS unsolicited response seems the simplest and most obvious method for doing this. Comments? -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Wed Oct 6 23:13:51 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29782; Wed, 6 Oct 93 23:13:51 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13166; Wed, 6 Oct 93 23:12:43 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13160; Wed, 6 Oct 93 23:12:42 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA22640; Wed, 6 Oct 93 23:12:39 -0700 Date: Wed, 6 Oct 1993 22:48:15 -0700 (PDT) From: Mark Crispin Subject: re: ¥Seen flag To: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I disagree with John Myers' suggestion that ¥Seen should be optional. It is perfectly reasonable for flags to be maintained and updated in the session, even with read-only sessions in which the server does not preserve state. For example, the c-client based server uses the ¥Deleted flag to mark state updates to .newsrc, and uses ¥Seen to mark message reading state. Additionally, I consider the acts of setting and clearing ¥Flagged, ¥Seen, ¥Deleted, and ¥Answered to be basic and fundamental actions in IMAP. If these were to become optional, then clients would be forced to validate whether or not they can use these flags. To my knowledge, none do at present. I have to admit that I am no longer sure why the system flags (the flags beginning with ¥) were included in the * FLAGS response in the first place if they are mandatory. It is clear that they have been mandatory since RFC 1064. Any other opinions? -- Mark -- From owner-imap@cac.washington.edu Thu Oct 7 07:19:22 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08765; Thu, 7 Oct 93 07:19:22 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15130; Thu, 7 Oct 93 07:19:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15124; Thu, 7 Oct 93 07:18:59 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id KAA02823; Thu, 7 Oct 1993 10:18:56 -0400 Received: via switchmail; Thu, 7 Oct 1993 10:18:56 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 7 Oct 1993 10:18:20 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 7 Oct 1993 10:18:18 -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, 7 Oct 1993 10:18:11 -0400 (EDT) Message-Id: Date: Thu, 7 Oct 1993 10:18:11 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: ¥Seen flag In-Reply-To: References: Beak: Is Well, I can't disagree with Mark more. As a server implementor, it never occured to me and still seems incorrect to allow the user to STORE any flag if the user does not have permission to alter the permanent state of that flag. To instead keep local flag state which is then discarded at the end of the session strikes me as leading the client (and the user) down the garden path. The user should get direct, obvious, feedback concerning the set of operations they are or are not allowed to perform. Both 1176 and the current internet-draft both state "The STORE command alters data associated with a message in the mailbox" and refer to such things as "the message's flag list". I reasonably interpret this as meaning The (singular) list of flags for the message. There is no mention of per-session data. 1176 further states "STORE is not allowed if the user does not have write access to this mailbox", which seems to contradict Mark's statments about what should happen in read-only sessions. (I asked Mark to remove this sentence from the internet-draft because a protocol specification should say nothing about site policy and the concept of "write access" is not well defined in an implementation with fine-grain access control.) A sufficiently intelligent client that cared could maintain per-session flag state itself, without the aid of the server. If the client used UIDs, the state could survive severed connections. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Thu Oct 7 09:10:09 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11945; Thu, 7 Oct 93 09:10:09 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15713; Thu, 7 Oct 93 09:06:55 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15707; Thu, 7 Oct 93 09:06:43 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id MAA04901; Thu, 7 Oct 1993 12:06:36 -0400 Received: via switchmail; Thu, 7 Oct 1993 12:06:31 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Thu, 7 Oct 1993 12:05:49 -0400 (EDT) Received: via niftymail; Thu, 7 Oct 1993 12:05:44 -0400 (EDT) Date: Thu, 7 Oct 1993 12:05:39 -0400 (EDT) From: Chris Newman Subject: Re: ¥Seen flag To: IMAP Interest List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750009939.28712.0@nifty.andrew.cmu.edu> I actually see two somewhat separate issues which need to be resolved. 1) Difference between ¥Seen usage in c-client, and description in spec. * ¥Seen is defined as "Message has been read" in the spec and is sometimes used to mean"Message has been read this session" by c-client. * The ¥Seen flag is required by the spec. * Spec says: "The STORE command alters data associated with a message in the mailbox." Problem: a strict reading of the spec would require ¥Seen state to always be kept across sessions. This is not reasonable. 2) Clients need to determine if ¥Seen information will be stored between sessions. Without such a method all clients would always have to keep ¥Seen state locally and ignore the ¥Seen flag in order to preserve ¥Seen information. I would guess we can all agree these are both problems which need to be solved. John has argued that changing the spec to make ¥Seen optional solves both of these problems with minimal fuss. This is based on a belief that per-session ¥Seen information is of marginal or no usefulness to a client (do client implementers out there agree?). An alternate solution would be to add a magic cookie which MUST be sent when ¥Seen information is per-session, and change the specification (including the definition of the ¥Seen flag) accordingly. Since [READ-ONLY]/[READ-WRITE] are already used in the SELECT response, this magic cookie would (probably) have to be in an unsolicited OK. I support John's solution because it is simpler. What do client implementors out there think? (Adam? Steve?) - Chris From owner-imap@cac.washington.edu Thu Oct 7 10:13:36 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14670; Thu, 7 Oct 93 10:13:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00376; Thu, 7 Oct 93 10:08:35 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00367; Thu, 7 Oct 93 10:08:28 -0700 Received: from jouez.stanford.EDU (ssrg-ds5000-1.Stanford.EDU) by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA14207; Thu, 7 Oct 93 10:08:26 PDT Received: by jouez.stanford.EDU (5.57/Ultrix4.0-(Rev. 174)) id AA26177; Thu, 7 Oct 93 10:03:44 -0700 Date: Thu, 7 Oct 1993 09:46:25 -0700 (PDT) From: Bill Yeager Reply-To: Bill_Yeager@camis.stanford.edu Subject: Re: ¥Seen flag To: Chris Newman Cc: IMAP Interest List In-Reply-To: Chris Newman's message of Thu, 7 Oct 1993 12:05:39 -0400 (EDT): <750009939.28712.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, since mm-d in 1986 all of the IMAP clients we've written (mm-d, macms, mailstrom, and XLView) have always taken advantage of the ¥SEEN flag as part of both the client mail browsers, and view based browsers. Messages that are not seen and not recent for example are flagged as Unseen in the former case, and placed in the UNSEEN view in the latter. Thus differentiating UNSEEN from NEW (not seen and recent). I recall that the imapservers(unix and tops20) also always kept the seen state for each message which was never written back to the mailbox in the case of bboards or readonly mailboxes. In these cases, this state was discovered for each message, much like one does in news, by the server and survived across sessions. And, searches for SEEN / UNSEEN messages have always been useful. The major drawback is the necessity for some sort of server accessible, user data base containing the mechanism for discovering seen messages when the mailbox is not user-writeable. We always thought it was worthwhile, and rely heavily on it in our client implementations. This latter position is most likely historical given the long history of email access using the SEEN flag in this manner which goes back to 1973 or so at Stanford. Bill From owner-imap@cac.washington.edu Thu Oct 7 22:47:15 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09881; Thu, 7 Oct 93 22:47:15 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12666; Thu, 7 Oct 93 22:46:10 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12660; Thu, 7 Oct 93 22:46:07 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18735-2>; Thu, 7 Oct 1993 23:45:45 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Thu, 7 Oct 93 16:32 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0ol3zf-000cvoC; Thu, 7 Oct 93 16:39 MDT Date: Thu, 7 Oct 1993 16:39:25 -0600 From: Steve Hole Subject: Re: ¥Seen flag To: Chris Newman Cc: IMAP Interest List Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 7 Oct 1993 10:05:39 -0600 Chris Newman wrote: > From: Chris Newman > Date: Thu, 7 Oct 1993 10:05:39 -0600 > Subject: Re: ¥Seen flag > To: IMAP Interest List > > I actually see two somewhat separate issues which need to be resolved. > > 1) Difference between ¥Seen usage in c-client, and description in spec. > > * ¥Seen is defined as "Message has been read" in the spec and is > sometimes used to mean"Message has been read this session" by c-client. > * The ¥Seen flag is required by the spec. > * Spec says: "The STORE command alters data associated with a > message in the mailbox." > Problem: a strict reading of the spec would require ¥Seen state to > always be kept across sessions. This is not reasonable. I must confess to having always been confused on this point. Reading the spec led me to believe that state should always be maintained. The c-client does not always maintain state - something that I thought was a bug. In fact, correction of seen flag handling in News has been on our bug list for some time. I was never able to figure out why per-session information would be useful unless the *expectation* was that the client would deal with maintaining it. I was not kean on this at all because either we maintained it *always* or not at all by our definition. The spec seemed to confirm this. > 2) Clients need to determine if ¥Seen information will be stored > between sessions. > > Without such a method all clients would always have to keep ¥Seen state > locally and ignore the ¥Seen flag in order to preserve ¥Seen information. It is always preferable to store ¥Seen information on the server. Otherwise (obviously) it must be maintained with the client - something we would rather not do. In order to do this and retain the location independence of the client, we would have to store the ¥Seen information in the IMSP database. This will not be practical in all cases. Basically, the stance that we have taken with ECSMail is that: (1) the server retains state information iff the user has established an authenticated session. (2) anonymous session retain no state information - either in the client or in the server. This is the price paid for an anonymous session. There are practical circumstances where state information does not need to be held - some types of bulletin boards that hold *announcement* type information only. > I would guess we can all agree these are both problems which need to be > solved. Agreed. > John has argued that changing the spec to make ¥Seen optional solves > both of these problems with minimal fuss. This is based on a belief > that per-session ¥Seen information is of marginal or no usefulness to > a client (do client implementers out there agree?). I agree. We would like to receive ¥Seen information that is permanent across sessions. Per-session information is confusing to the users who see items marked as seen, then when they come back it appears to be unread again. > An alternate solution would be to add a magic cookie which MUST be > sent when ¥Seen information is per-session, and change the > specification (including the definition of the ¥Seen flag) > accordingly. Since [READ-ONLY]/[READ-WRITE] are already used in the > SELECT response, this magic cookie would (probably) have to be in an > unsolicited OK. > > I support John's solution because it is simpler. What do client > implementors out there think? (Adam? Steve?) > Seems to make sense to me. Once again, per-session state information is of very little use to us. If in fact we cannot depend on the state information being returned as multi-sessional, then we will simply ignore it altogther and start keeping track of it ourselves - something we would rather not do. If the state information is optional, then we will simply pay attention to it when offerred. The server *should* always save state information for authenticated sessions however. 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-imap@cac.washington.edu Fri Oct 8 07:59:22 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20974; Fri, 8 Oct 93 07:59:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16768; Fri, 8 Oct 93 07:58:09 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16762; Fri, 8 Oct 93 07:58:00 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id KAA03874; Fri, 8 Oct 1993 10:57:55 -0400 Received: via switchmail; Fri, 8 Oct 1993 10:57:45 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 8 Oct 1993 10:57:26 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 8 Oct 1993 10:57: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; Fri, 8 Oct 1993 10:57:21 -0400 (EDT) Message-Id: Date: Fri, 8 Oct 1993 10:57:21 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: ¥Seen flag In-Reply-To: References: Beak: is Not In the case of the Cyrus imapd, it will be perfectly capable of storing per-user ¥Seen information for any mailbox on the server. The permission bit for "server will preserve ¥Seen state" can be set independently of the other permission bits. The only reasons I can think of where one would want to not set the bit are: * Anonymous IMAP (since "Anonymous" is just another user, it *could* preserve the ¥Seen state across sessions, but...) * Extremely high-load bboards. Site policy might dictate that a certain class of users (those authenticating from certain remote Kerberos realms) or all users don't get ¥Seen state preserved for performance reasons. * The relevant user doesn't have read access to the mailbox anyway. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Oct 8 12:30:07 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02256; Fri, 8 Oct 93 12:30:07 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22253; Fri, 8 Oct 93 12:28:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22247; Fri, 8 Oct 93 12:28:31 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA15382; Fri, 8 Oct 93 12:28:23 PDT Date: Fri, 8 Oct 93 12:28:06 -0800 From: Adam Treister To: mailstrom-dev@forsythe.stanford.edu, IMAP@cac.washington.edu Subject: Re: New MailstromV2Dev master up at NADA Message-Id: In-Reply-To: our message of Thu, 7 Oct 1993 23:47 Content-Type: TEXT/plain; charset=US-ASCII > > The new master is available by ftp from ftp.nada.kth.se. > It's in the directory > /home/d89-jbe/Mailstrom, and it's called > MailstromV2Dev7_10.sea.hqx. I grabbed it last night and integrated the changes I made in the meantime. I was able to compose and send a message with rich text and an attachment, send it to myself, and it arrived intact. There are loads of update pbs, wrong fonts, and unimplemented features, but we are on the way! Unless folks are real anxious, I don't think I'd recommend working with this version, cuz I've already made substantial changes to what Johan put up. I'm going to play with it over the weekend and hopefully repost an integrated version sometime next week. Unless anyone objects, (or it still looks too rough) I'll also build a demo version, to give the world a preview of what we're doing. One thing that I'm very concerned about is how ugly MIME messages (or Mailstrom's current version, which doesn't make multipart-alternative, and doesn't add any explanations) look to a non-MIME reader. I want the number of people who love Mailstrom to be greater than the number who hate it, and I don't think recipients are going to be too happy about getting pages of Base64 encoding. Have any of you imappers who are ahead of us in Mime implementation gotten user feedback (ie hate mail), on this, or come up with nice ways to cater to the old school? Thanks for all of your work, Johan. It looks fabulous! Adam From owner-imap@cac.washington.edu Fri Oct 8 18:52:34 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15246; Fri, 8 Oct 93 18:52:34 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25902; Fri, 8 Oct 93 18:51:55 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25896; Fri, 8 Oct 93 18:51:53 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA25598; Fri, 8 Oct 93 18:51:52 -0700 Date: Fri, 8 Oct 1993 18:38:59 -0700 (PDT) From: Mark Crispin Reply-To: Mark Crispin Subject: Re: ¥Seen flag To: IMAP Interest List In-Reply-To: <750009939.28712.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > 1) Difference between ¥Seen usage in c-client, and description in spec. Good point. c-client's view is what was always the intention in the original IMAP design, whether or not the specification makes this clear. It is also how this has been handled in the historical clients. On the other hand, there *are* valid arguments for the CMU view. > 2) Clients need to determine if ¥Seen information will be stored > between sessions. This is difficult because of older servers. See below. > This is based on a belief > that per-session ¥Seen information is of marginal or no usefulness to > a client (do client implementers out there agree?). I disagree. We use per-session ¥Seen information with netnews in Pine. This doesn't mean that this function is a sacred cow that can't be changed. It does mean that it is entrenched and needs to be uprooted. In other words, this is a defense of the status quo. CMU's model *is* probably the better one. Is it ``better enough'' to push through an incompatible change? I'm concerned because we're still dealing with the bad effects from the last time an incompatible change (not automatically creating mailboxes on COPY) was pushed thorough. > An alternate solution would be to add a magic cookie which MUST be > sent when ¥Seen information is per-session, and change the > specification (including the definition of the ¥Seen flag) > accordingly. How do we achieve compatibility with older servers? From owner-imap@cac.washington.edu Sat Oct 9 12:15:28 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28462; Sat, 9 Oct 93 12:15:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04952; Sat, 9 Oct 93 12:14:07 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04946; Sat, 9 Oct 93 12:14:05 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA04174; Sat, 9 Oct 1993 15:13:44 -0400 Received: via switchmail; Sat, 9 Oct 1993 15:13:31 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Sat, 9 Oct 1993 15:12:32 -0400 (EDT) Received: via niftymail; Sat, 9 Oct 1993 15:12:27 -0400 (EDT) Date: Sat, 9 Oct 1993 15:12:26 -0400 (EDT) From: Chris Newman Subject: Re: ¥Seen flag To: IMAP Interest List In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <750193946.9319.0@nifty.andrew.cmu.edu> Mark Crispin writes: > I disagree. We use per-session ¥Seen information with netnews in Pine. > This doesn't mean that this function is a sacred cow that can't be > changed. It does mean that it is entrenched and needs to be uprooted. > > In other words, this is a defense of the status quo. CMU's model *is* > probably the better one. Is it ``better enough'' to push through an > incompatible change? I'm not convinced it is an incompatible change. Are there any clients which will break if they don't get a ¥Seen flag in the "* FLAGS" or in the message flags after having read it? I seriously doubt it. > How do we achieve compatibility with older servers? I don't think this is a problem. Currently, when a user reads a message on an old server with no cross-session ¥Seen information, quits and then checks again, the message comes up as unread. Thus the status-quo has user astonishment. If we accept John's suggestion, there will still be user astonishment with old servers although it may take the form of the ¥Seen icon always showing unread (which I consider less misleading that flipping it on, then off between sessions). What makes John's suggestion worth the trouble of a minor change is that a new client with a new server would have no situations of user astonishment. - Chris From owner-imap@cac.washington.edu Sat Oct 9 14:19:03 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29975; Sat, 9 Oct 93 14:19:03 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29899; Sat, 9 Oct 93 14:18:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29893; Sat, 9 Oct 93 14:18:18 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA26183; Sat, 9 Oct 93 14:18:11 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA14722; Sat, 9 Oct 93 14:17:57 -0700 Date: Sat, 9 Oct 1993 13:33:36 -0700 (PDT) From: Mark Crispin Subject: Re: ¥Seen flag To: Chris Newman Cc: IMAP Interest List In-Reply-To: <750193946.9319.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII [Note: there is a possible compromise in my next message. This message is just a continuation of debate. Feel free to skip to the next message.] On Sat, 9 Oct 1993 15:12:26 -0400 (EDT), Chris Newman wrote: > I'm not convinced it is an incompatible change. Are there any clients > which will break if they don't get a ¥Seen flag in the "* FLAGS" or in > the message flags after having read it? I seriously doubt it. Alas, some client software will crash if the * FLAGS list is empty, because of an unfortunate assumption that the list is guaranteed non-empty. There is no reason to believe that if ¥Seen is made non-mandatory that any of the other system flags (¥Deleted, ¥Answered, ¥Flagged) would remain mandatory either. > If we accept John's suggestion, > there will still be user astonishment with old servers although it may > take the form of the ¥Seen icon always showing unread (which I > consider less misleading that flipping it on, then off between > sessions). Aren't you presuming that preservation of these flags is what the user necessarily wants. There is a purpose in life for session flags; people have been using them for 7+ years. I would find this quite annoying when reading netnews (which in our software filters out the deleted -- marked in .newsrc -- messages). I regularly use all four system flags in a session, even though I know perfectly well that only ¥Deleted will be preserved. > What makes John's suggestion worth the trouble of a minor change is > that a new client with a new server would have no situations of user > astonishment. It isn't a minor change. It would be a fairly complex change for c-client. In c-client's IMAP driver, there is no mechanism for ``local'' manipulation of flags on an IMAP stream; flag state is totally under the control of the server. The client can only request that the server do something to the flag state. In order to handle this, c-client would need to keep track of which flags are local and which are remote, and ignore what appears to be a server request to manipulate a local flag. Then there are the error states (suppose a flag is local, but the server explicitly says ``turn this flag on''?). [I would also suffer the personal indignity of having to read, and (shudder!) modify, a chunk of C code that I wrote in 1988 when I had all of 4 hours of experience in C (``Here's what a C program looks like, here's a copy of K&R and the MPW C manual, now write code''). Here be dragons. ;-) More likely than not, it'd be a complete rewrite. Maybe not a bad thing, but I hate to rewrite code (no matter how embarassing) that works, when I have a long list of new code that has to be written...] From owner-imap@cac.washington.edu Sat Oct 9 14:23:40 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00179; Sat, 9 Oct 93 14:23:40 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29931; Sat, 9 Oct 93 14:23:20 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29925; Sat, 9 Oct 93 14:23:18 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA26187; Sat, 9 Oct 93 14:22:57 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA14737; Sat, 9 Oct 93 14:22:45 -0700 Date: Sat, 9 Oct 1993 14:12:40 -0700 (PDT) From: Mark Crispin Subject: ¥Seen flag possible compromise To: Chris Newman Cc: IMAP Interest List In-Reply-To: <750193946.9319.0@nifty.andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Possible wretched compromise, based upon John's suggestion but with a doggie bone to the ravening wolves of ``compatibility with the past'': A new unsolicited OK carries a special information token and a list of which flags are preserved on the server (which differs from the list of valid flags). In the absence of this information, the two lists are defined to be the same. We can't dictate that a client must not preserve flags locally. But we don't have to bless such behavior either. The new behavior kicks in only if the server is new AND if the client wishes to use the new behavior (if I ever use such a client, it had better respect *my* wishes in this regard!!). Otherwise, it's the old behavior. This presumes that for the 95% percentile (e.g. internally you can force all systems to run new servers) this would be OK. I don't belive it forces any changes to old clients. Presumably, it is easier to update servers than clients; even if there are religious objections to the new behavior an argument can be made to put it in servers to help out the clients. [The idea is that only a fanatic would refuse to help out a client with a different religion if it doesn't impact the clients with his religion.] Bouquets? Brickbats? From owner-imap@cac.washington.edu Sat Oct 9 17:29:37 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02173; Sat, 9 Oct 93 17:29:37 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07114; Sat, 9 Oct 93 17:26:25 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07108; Sat, 9 Oct 93 17:26:22 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id UAA10223; Sat, 9 Oct 1993 20:26:20 -0400 Received: via switchmail; Sat, 9 Oct 1993 20:26:20 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 9 Oct 1993 20:26:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 9 Oct 1993 20:26:02 -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; Sat, 9 Oct 1993 20:25:58 -0400 (EDT) Message-Id: Date: Sat, 9 Oct 1993 20:25:58 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: ¥Seen flag possible compromise In-Reply-To: References: Beak: Is I have to agree with Mark, that's a pretty wretched compromise. :-) Mark mixes the concepts "preserved on the server" and "user has permission to change the server preserved state." I see two separate issues here: what to do with ¥Seen, and what to do with the rest of the system and/or user flags. I think we can make a resonable case for allowing ¥Seen to be non-mandatory while keeping the other system flags mandatory. ¥Seen is inherently per-user, not per-mailbox. It is quite reasonable for per-user state to not be applicable for a mailbox. ¥Deleted is inherently per-mailbox. While ¥Answered, ¥Flagged, and user flags could be debated, I consider them per-mailbox. I am aware of no IMAP server which preserves flags other than ¥Seen and ¥Recent per-user across sessions. It is reasonable for a server to show per-mailbox flags to clients which do not have permission to alter those flags. It is also reasonable for a server to propagate changes to these flags to those same clients. flag_list is currently guaranteed to be non-empty--the grammar requires it to have at least one flag. I don't think this should be changed. The flags ¥Deleted, ¥Answered, and/or ¥Flagged can be defined as always being applicable, even if a server never allows any client to actually set them. CMU, having had AMS, considers it quite natural to prohibit users from setting flags they don't have permission to preserve. While Mark likes to be able to set per-session ¥Deleted in netnews, we consider that leading the user down the garden path. As a server implementor, I'm a bit concerned about what it would take to implement per-session flags. I would have to keep an additional list of the per-session changes to (non-¥Seen) flags, separate from the true state of the flags. I would then have to make sure flag updates don't undo any of the per-session flag changes. This is more or less the the same set of changes Mark mentions as being needed for implementing per-session state in the c-client imap2 driver (except I'm writing the chunk of code starting Monday). The error state Mark mentions isn't particularly new--suppose the server says to ``turn this flag on'' when the flag hadn't been previously mentioned in a "* FLAGS". In either case, the options are to set the flag or to ignore the directive. Breaking down the compatibility combinations for my suggestion, we have: * old client, old server -- status quo * new client, old server -- status quo, user led down garden path * old client, new server -- user does not see flag changes. User may see errors when STORE commands elicit tagged NO responses. * new client, new server -- whatever the client implements. If client gets a tagged NO response when doing a STORE, it may decide to handle per-session state for that flag locally. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sat Oct 9 22:08:25 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05539; Sat, 9 Oct 93 22:08:25 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01533; Sat, 9 Oct 93 22:07:45 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Mordor.Stanford.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01527; Sat, 9 Oct 93 22:07:44 -0700 Received: from UCSF-PM-DIAL1.BARRNET.NET by Mordor.Stanford.EDU (5.65/inc-1.0) id AA08318; Sat, 9 Oct 93 22:07:38 -0700 Date: Sat, 9 Oct 93 22:07:03 -0800 From: RL "Bob" Morgan To: John Gardiner Myers Subject: Re: ¥Seen flag possible compromise Cc: imap@cac.washington.edu Message-Id: In-Reply-To: Your message of Sat, 9 Oct 1993 20:25:58 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII > ¥Deleted is inherently per-mailbox. While ¥Answered, > ¥Flagged, and user flags could be debated, I consider > them per-mailbox. I'm just a poor user who hasn't followed the whole of this voluminous discussion, but I have to object here. I recall making the suggestion a while ago that there are at least two different kinds of shared mailboxes, each meeting a different need. In a "trouble-ticket" shared mailbox you'd want all the state to be per-mailbox, so if somebody's answered or flagged something I'd see that. In a "newsgroup" shared mailbox you'd want all the state to be per-user (even ¥Deleted, if it's interpreted as "don't show this to me any more"). I recall others agreeing with this at the time, and maybe even suggesting other flavors. So was this functionality a) never considered, b) consciously dropped, c) lost in the shuffle, or d) postponed? If the next great IMAP can't support both of these kinds of shared mailboxes I for one will be sorely disappointed. - RL "Bob" Morgan Networking Systems Stanford From owner-imap@cac.washington.edu Sun Oct 10 08:14:15 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12829; Sun, 10 Oct 93 08:14:15 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11612; Sun, 10 Oct 93 08:11:17 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11606; Sun, 10 Oct 93 08:11:15 -0700 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18112; Sun, 10 Oct 93 08:11:14 -0700 Date: Sun, 10 Oct 1993 08:06:11 -0700 (PDT) From: Terry Gray Subject: Re: ¥Seen flag possible compromise To: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Like Bob, I have not fully absorbed the whole discussion here, but from a "user requirements" view, I completely agree with Bob's observation that there are indeed two distinct flavors of shared mailbox, and that it would be very disappointing if the protocol design precluded use of either one... -teg On Sat, 9 Oct 1993, RL Bob Morgan wrote: > > > ¥Deleted is inherently per-mailbox. While ¥Answered, > > ¥Flagged, and user flags could be debated, I consider > > them per-mailbox. > > I'm just a poor user who hasn't followed the whole of this voluminous > discussion, but I have to object here. I recall making the suggestion a while > ago that there are at least two different kinds of shared mailboxes, each > meeting a different need. In a "trouble-ticket" shared mailbox you'd want all > the state to be per-mailbox, so if somebody's answered or flagged something I'd > see that. In a "newsgroup" shared mailbox you'd want all the state to be > per-user (even ¥Deleted, if it's interpreted as "don't show this to me any > more"). I recall others agreeing with this at the time, and maybe even > suggesting other flavors. > > So was this functionality a) never considered, b) consciously dropped, c) lost > in the shuffle, or d) postponed? If the next great IMAP can't support both of > these kinds of shared mailboxes I for one will be sorely disappointed. > > - RL "Bob" Morgan > Networking Systems > Stanford From owner-imap@cac.washington.edu Sun Oct 10 11:32:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14767; Sun, 10 Oct 93 11:32:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12606; Sun, 10 Oct 93 11:32:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12600; Sun, 10 Oct 93 11:32:12 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id OAA04357; Sun, 10 Oct 1993 14:32:08 -0400 Received: via switchmail; Sun, 10 Oct 1993 14:32:08 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 10 Oct 1993 14:31:44 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 10 Oct 1993 14:31:39 -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, 10 Oct 1993 14:31:36 -0400 (EDT) Message-Id: <0gi5I8600WBwRbYW97@andrew.cmu.edu> Date: Sun, 10 Oct 1993 14:31:36 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: ¥Seen flag possible compromise In-Reply-To: References: Beak: Is In standard netnews, it's the equivalent of ¥Seen that means "don't show this to me any more". Moving this functionality to ¥Deleted is *extremely* dangerous--it requires the user to shift gears when moving between mailboxes with per-user ¥Deleted state and mailboxes where they have permission to actually delete messages. In any case, I don't think my suggestion changes the protocol to precludes a server from preserving additional flags on a per-user basis. It is the Cyrus server *implementation* as currently designed that precludes per-user state for flags other than ¥Seen and ¥Recent. Andrew.cmu.edu currently has 2,298 local bboards (shared mailboxes) with a wide variety of access control settings. Not all of them distinctly fit into one of the two flavors. If the IMAP prococol design requires a server to switch to per-user or per-session flag state when the user is not allowed to change the per-mailbox flag state, that would preclude some useful models. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sun Oct 10 12:30:52 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15535; Sun, 10 Oct 93 12:30:52 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04366; Sun, 10 Oct 93 12:30:08 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04360; Sun, 10 Oct 93 12:30:06 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA27057; Sun, 10 Oct 93 12:30:06 -0700 Date: Sun, 10 Oct 1993 12:16:34 -0700 (PDT) From: Mark Crispin Subject: Re: ¥Seen flag possible compromise To: Terry Gray Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 10 Oct 1993, Terry Gray wrote: > Like Bob, I have not fully absorbed the whole discussion here, but from a > "user requirements" view, I completely agree with Bob's observation that > there are indeed two distinct flavors of shared mailbox, and that it would > be very disappointing if the protocol design precluded use of either one... I hope that nobody disagrees with this sentiment. Hopefully, the discussion rests on these issues: . does the proposed change provide a net benefit . does the proposed change hurt existing software I think that CMU has made a convincing case for the former. It's the latter issue that is of concern. The removal of implicit mailbox create in COPY was a debacle. Lots of people wanted it, and it was an improvement to the protocol. But it broke extant clients and now we have old IMAP servers, without any of the new stuff, still running just to maintain support of these old clients. [It doesn't help when I get asked, ``Why weren't you stubborn on this issue and stop it?''. ;-)] We MUST satisfy ourselves that we won't make this mistake again. The burden is on the proposal to prove that it is harmless to known existing clients (and to unknown existing clients!). The costs of the proposal MUST be borne by implementations that wish to take advantage of it. When changes are mandated, they should be in servers ONLY. It is much easier to change servers than it is to change clients. From owner-imap@cac.washington.edu Sun Oct 10 13:01:13 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16002; Sun, 10 Oct 93 13:01:13 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04483; Sun, 10 Oct 93 13:00:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04477; Sun, 10 Oct 93 13:00:35 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA27084; Sun, 10 Oct 93 13:00:25 -0700 Date: Sun, 10 Oct 1993 12:56:52 -0700 (PDT) From: Mark Crispin Reply-To: Mark Crispin Subject: Re: ¥Seen flag possible compromise To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sat, 9 Oct 1993, John Gardiner Myers wrote: > I think we can make a resonable case for allowing ¥Seen to be > non-mandatory while keeping the other system flags mandatory. Anyone looking at this outside of context is going to see it as a kludge. I cannot justify in my mind anything other than ``all system flags are mandatory'' or ``no system flags are mandatory'', and I think the former is entrenched in implementations. > ¥Seen > is inherently per-user, not per-mailbox. It is quite reasonable for > per-user state to not be applicable for a mailbox. I strongly disagree!! This is a characteristic of an implementation, not of a general case that you wish to impose on anyone. A shared mailbox (e.g. a help action inbox) may well possess per-mailbox ¥Seen flags. In fact, I implement this in c-client and we are deploying it. > ¥Deleted is inherently per-mailbox. While ¥Answered, ¥Flagged, and > user flags could be debated, I consider them per-mailbox. I am aware > of no IMAP server which preserves flags other than ¥Seen and ¥Recent > per-user across sessions. Our IMAP server preserves ¥Deleted per-user across sessions with newsgroups. > flag_list is currently guaranteed to be non-empty--the grammar > requires it to have at least one flag. I don't think this should be > changed. As soon as you make any system flags optional, you will open the question as to why all of them shouldn't be optional. I don't think you have given a convincing argument why this won't happen. > While Mark > likes to be able to set per-session ¥Deleted in netnews, we consider > that leading the user down the garden path. Actually, Mark opposed this design, because it represented a break with the past of how news was handled in other newsreading tools. However, it has shown itself to be a viable and successful model. I may still be skeptical that it is ``better'' than the traditional model, but it's hard to argue with something that works. > As a server implementor, I'm a bit concerned about what it would take > to implement per-session flags. I would have to keep an additional > list of the per-session changes to (non-¥Seen) flags, separate from > the true state of the flags. I would then have to make sure flag > updates don't undo any of the per-session flag changes. This is comparable to the problem that a client implementor would have to face to adopt the change. When in doubt, the burden burden properly belongs with server implementors. > The > error state Mark mentions isn't particularly new--suppose the server > says to ``turn this flag on'' when the flag hadn't been previously > mentioned in a "* FLAGS". No, because the * FLAGS specifies all valid flags. The error state can't happen; if it does then it is a server bug. The proposed change is to make this be the ``all flags that you can change on the disk on the server'' list. This creates the error state. > * old client, new server -- user does not see flag changes. User may > see errors when STORE commands elicit tagged NO responses. We consider this highly undesirable!!!!!! From owner-imap@cac.washington.edu Sun Oct 10 13:21:33 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16405; Sun, 10 Oct 93 13:21:33 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04589; Sun, 10 Oct 93 13:21:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04583; Sun, 10 Oct 93 13:21:02 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA27095; Sun, 10 Oct 93 13:20:59 -0700 Date: Sun, 10 Oct 1993 13:05:23 -0700 (PDT) From: Mark Crispin Subject: Re: ¥Seen flag possible compromise To: RL Bob Morgan Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 9 Oct 1993, RL Bob Morgan wrote: > I recall making the suggestion a while > ago that there are at least two different kinds of shared mailboxes, each > meeting a different need. In a "trouble-ticket" shared mailbox you'd want all > the state to be per-mailbox > In a "newsgroup" shared mailbox you'd want all the state to be > per-user > So was this functionality a) never considered, b) consciously dropped, c) lost > in the shuffle, or d) postponed? e) consciously planned from the very beginnings of IMAP, and being deployed in the c-client based tools For me, it's a no-brainer; this duality MUST be permitted by IMAP, and if anything in IMAP implies otherwise this needs to be fixed. The fact that you feel obligated to present it as a suggestion tells me that there is some sort of implication in the current document that suggests otherwise. I'm particularly worried that you feel that it is being ignored or shelved. It isn't. Can you suggest modifications to the draft in this area? From owner-imap@cac.washington.edu Sun Oct 10 13:54:46 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16777; Sun, 10 Oct 93 13:54:46 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04698; Sun, 10 Oct 93 13:54:03 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04692; Sun, 10 Oct 93 13:53:57 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA27125; Sun, 10 Oct 93 13:53:53 -0700 Date: Sun, 10 Oct 1993 13:44:46 -0700 (PDT) From: Mark Crispin Subject: Re: ¥Seen flag possible compromise To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: <0gi5I8600WBwRbYW97@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 10 Oct 1993, John Gardiner Myers wrote: > In standard netnews, it's the equivalent of ¥Seen that means "don't > show this to me any more". Moving this functionality to ¥Deleted is > *extremely* dangerous--it requires the user to shift gears when moving > between mailboxes with per-user ¥Deleted state and mailboxes where > they have permission to actually delete messages. On the other hand, moving this functionality to ¥Deleted is very nice if you purpose to blur the distinction between mail and netnews. I'm not asking you to agree with this design (I'm not sure I do) but rather to understand how it works and why some people want to do it. > In any case, I don't think my suggestion changes the protocol to > precludes a server from preserving additional flags on a per-user > basis. I don't think we're arguing this. We're arguing that undesirable effects happen to old clients. You consider that the current situation is a bug state, whereas we consider that the proposed situation is a bug state. > If the IMAP prococol > design requires a server to switch to per-user or per-session flag > state when the user is not allowed to change the per-mailbox flag > state, that would preclude some useful models. I don't think the protocol says anything of the sort. Actually, the protocol doesn't say anything about it at all. What you are expecting is for the protocol to assist a client in shifting between models, assuming the client cares. I think we can do this. What I don't think we can do is change the model for clients that don't care. I also don't think we can have the four possible states you outlined. With a new capability, it should be all or nothing, and I think that is what my counter-strawman provides. From owner-imap@cac.washington.edu Sun Oct 10 14:57:19 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17721; Sun, 10 Oct 93 14:57:19 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13937; Sun, 10 Oct 93 14:56:44 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13931; Sun, 10 Oct 93 14:56:36 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id RAA07302; Sun, 10 Oct 1993 17:56:33 -0400 Received: via switchmail; Sun, 10 Oct 1993 17:56:32 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 10 Oct 1993 17:55:06 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 10 Oct 1993 17:55:01 -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, 10 Oct 1993 17:54:52 -0400 (EDT) Message-Id: <4gi8GgK00WBw1bkF1w@andrew.cmu.edu> Date: Sun, 10 Oct 1993 17:54:52 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: ¥Seen flag possible compromise In-Reply-To: References: Beak: is Not Well, we've now got three entirely separate issues here. * The handling of ¥Deleted in the c-client news driver. * What a server should do if a client attempts to set a flag the user is not permitted to change the state of. (It is still my belief that the existing specs allow my server to reply NO to STORE.) * How a server should signal to the client that it is unwilling to preserve state across sessions. Mark Crispin writes: > A shared mailbox (e.g. a help action inbox) may well possess per-mailbox > ¥Seen flags. In fact, I implement this in c-client and we are deploying it. I consider per-mailbox ¥Seen flags for shared mailboxes a mistake. AMS has per-folder 'unread' flags in addition to the per-user "I've read everything before here" line. I get to see them in numerous help action style bboards. They are simply not useful. The "Answered" and "Deleted" flags are what are useful. > Our IMAP server preserves ¥Deleted per-user across sessions with > newsgroups. > > Actually, Mark opposed this design, because it represented a break with > the past of how news was handled in other newsreading tools. However, it > has shown itself to be a viable and successful model. I may still be > skeptical that it is ``better'' than the traditional model, but it's hard > to argue with something that works. I don't think I realized that c-client mapped the .newsrc to the ¥Deleted flag. I assumed that it did the obvious and mapped it to the ¥Seen flag. To say that I think this was a poor implementation choice would be an understatement. 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 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. 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 > > The > > error state Mark mentions isn't particularly new--suppose the server > > says to ``turn this flag on'' when the flag hadn't been previously > > mentioned in a "* FLAGS". > > No, because the * FLAGS specifies all valid flags. The error state can't > happen; if it does then it is a server bug. The proposed change is to > make this be the ``all flags that you can change on the disk on the > server'' list. This creates the error state. If a server didn't include ¥Seen in the * FLAGS, then it is the same server bug for it to include ¥Seen in a * n FETCH. The proposed change is to "allow the server to not support ¥Seen" for a mailbox. _.John From owner-imap@cac.washington.edu Sun Oct 10 16:29:11 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18911; Sun, 10 Oct 93 16:29:11 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05280; Sun, 10 Oct 93 16:28:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05274; Sun, 10 Oct 93 16:28:29 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA27402; Sun, 10 Oct 93 16:28:25 -0700 Date: Sun, 10 Oct 1993 15:47:55 -0700 (PDT) From: Mark Crispin Subject: Re: ¥Seen flag possible compromise To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: <4gi8GgK00WBw1bkF1w@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 10 Oct 1993, John Gardiner Myers wrote: > Well, we've now got three entirely separate issues here. > * The handling of ¥Deleted in the c-client news driver. This is not an IMAP issue. This is a c-client issue. The IMAP protocol has no right to dictate this. Whether or not you think this is a mistake, it is wrong to add something in the IMAP protocol to forbid it. Please address any questions of whether or not c-client's ¥Deleted handling in news is right or not to the c-client list. > * What a server should do if a client attempts to set a flag the user > is not permitted to change the state of. (It is still my belief that > the existing specs allow my server to reply NO to STORE.) Your belief is correct. However, the existing specs also allow a server to reply OK, and do nothing (ie, setting these flags is a no-op); or reply OK, and only change session flags. It is up to you to decide whether or not you want to deal with the consequences of replying NO. Some clients go modal in reporting an error message when a NO is returned under certain circumstanes. These clients may also assume that certain behaviors are no-op's at worse. If the users of such clients start getting modal error conditions that did not exist before, they may be inclined to blame your server. Given the behavior of the past, it seems to be awfully unhelpful to report a NO. A NO is just going to annoy the users of old clients. If you report an OK, then externally have a signal of the server behavior, then a new client will be able to avoid the situation without needing the server to say NO. > * How a server should signal to the client that it is unwilling to > preserve state across sessions. There is no argument that such a signal should be provided. You have given excellent reasons for wanting it. The only matter of contention is whether or not old clients should be impacted by this. You have not convinced me that they should, nor have I heard a clear sense from the group on it. It seems to me that there are two choices: 1) Go with some mechanism such as my wretched compromise that does not affect old software. Since it is an addition to the spec, and not a change, there is probably no opposition to it. It'll just happen. 2) Hold out for a change to the spec. In that case, you'll have to get some sort of group concensus in the entire working group. > I consider per-mailbox ¥Seen flags for shared mailboxes a mistake. This is your opinion, and by all means avoid this ``mistake'' in your implementation. However, other implementors have other opinions. I may be ambivalent about the ¥Deleted in news question, but I strongly believe in offering per-mailbox ¥Seen flags. We have customers who want it. > I don't think I realized that c-client mapped the .newsrc to the > ¥Deleted flag. I assumed that it did the obvious and mapped it to the > ¥Seen flag. To say that I think this was a poor implementation choice > would be an understatement. Again, this is your opinion. It may be my opinion; I used to map it to the ¥Seen flag. It was changed to the ¥Deleted flag. The change permits the support of an interesting model, and the proponents of that model seem happy with the results. I did not find it to be an egregiously difficult change. > 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 I don't think you have to. > If a server didn't include ¥Seen in the * FLAGS, then it is the same > server bug for it to include ¥Seen in a * n FETCH. The proposed > change is to "allow the server to not support ¥Seen" for a mailbox. I understand that. But I do not agree that it is possible to justify ``allow the server to not support ¥Seen, but it still must support the other flags.'' It should be all four system flags, or none. There is a problem with making it none; it requires a change to the grammar, and certain clients will crash. From owner-imap@cac.washington.edu Tue Oct 12 04:55:17 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06240; Tue, 12 Oct 93 04:55:17 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14303; Tue, 12 Oct 93 04:54:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14297; Tue, 12 Oct 93 04:54:39 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA09750; Tue, 12 Oct 93 12:54:35 +0100 Message-Id: <9310121154.AA09750@nada.kth.se> To: IMAP Interest List Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: Your message of "Thu, 26 Aug 1993 01:43:33 +0200." <9308252343.AA19216@nada.kth.se> Date: Tue, 12 Oct 1993 12:54:31 +0100 From: Peter Svanberg Hello again, I'm back on the IMAP-scrutinizing-track! ;-) Quoting from the latest WG minutes: ---------------------------------------------------------------------------- ISSUE 9. Preserving flags/date on COPY, setting on APPEND DISCUSSION: -Should APPEND provide a way to set flags? YES. -Should COPY preserve flags? YES (if access controls allow). ACTION: -Change COPY definition to include SHOULD preserve flags -Change APPEND definition to add *optional* argument for flags ---------------------------------------------------------------------------- This doesn't say anything about the date, and in the new draft noting is changed on the date preservation in the COPY command. The only motivation for not preserving INTERNALDATE in COPY I could get out of the earlier discussion on this issue is that the INTERNALDATEs in a mailbox must be increasing, as commands like SEARCH BEFORE assumes it. Is that correct? As I think this date field is useless (except in the Inbox), I'll have to wait for the "new SEARCH". From the minutes again: ---------------------------------------------------------------------------- ISSUE 17. New SEARCH DISCUSSION: -Understood to be needed -A starting point for a definition: Be able to search on Composed DATE Be able to search on Received DATE Be able to search on MessageID Be able to search on general header text NOT operator Deprecate "UN..." constructs OR operator operator grouping If not regular expressions, at least wild cards in strings Better international searching ACTION: -Solicit IMAP developers to flesh out a detailed proposal for new SEARCH ---------------------------------------------------------------------------- Note that the "Be able to search on Received DATE" requirement implies that this date (what I earlier called "arrival date") is stored in some way amongst other "data that is associated with a message as an entity in the mailbox". --- 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-imap@cac.washington.edu Tue Oct 12 07:42:16 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09028; Tue, 12 Oct 93 07:42:16 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14974; Tue, 12 Oct 93 07:40:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14968; Tue, 12 Oct 93 07:40:14 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id KAA03968; Tue, 12 Oct 1993 10:40:07 -0400 Received: via switchmail; Tue, 12 Oct 1993 10:40:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 10:39:08 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 10:39:04 -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 10:39:00 -0400 (EDT) Message-Id: Date: Tue, 12 Oct 1993 10:39:00 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: <9310121154.AA09750@nada.kth.se> References: <9310121154.AA09750@nada.kth.se> Beak: is Not I believe the "Received date" is the one on the topmost Received: header. _.John From owner-imap@cac.washington.edu Tue Oct 12 10:06:08 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15535; Tue, 12 Oct 93 10:06:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13573; Tue, 12 Oct 93 09:50:09 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from eco.twg.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13559; Tue, 12 Oct 93 09:49:58 -0700 Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA16770; Tue, 12 Oct 93 12:51:12 -0400 Message-Id: <9310121651.AA16770@eco.twg.com> Received: from apache.twg.com by apache.twg.com id <3023-0@apache.twg.com>; Tue, 12 Oct 1993 09:49:21 -0700 From: "David Herron" Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: John Gardiner Myers Cc: imap@cac.washington.edu Date: Tue, 12 Oct 93 9:49:20 PDT In-Reply-To: Your message of Tue, 12 Oct 1993 10:39:00 -0400 (EDT). Sensitivity: Personal Conversion: Prohibited Conversion-With-Loss: Prohibited Encoding: 15 TEXT >Date: Tue, 12 Oct 1993 10:39:00 -0400 (EDT) >From: John Gardiner Myers >To: imap@cac.washington.edu >Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) > >I believe the "Received date" is the one on the topmost Received: >header. > > _.John I believe that nothing gaurantees the ordering of header lines. So relying on the "first Received: line" to be the most recent one added, is an unsafe position. David From owner-imap@cac.washington.edu Tue Oct 12 12:07:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20594; Tue, 12 Oct 93 12:07:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16277; Tue, 12 Oct 93 12:03:46 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16269; Tue, 12 Oct 93 12:03:41 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA08437; Tue, 12 Oct 1993 15:03:36 -0400 Received: via switchmail; Tue, 12 Oct 1993 15:03:33 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 15:03:07 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 15:03:02 -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 15:02:56 -0400 (EDT) Message-Id: Date: Tue, 12 Oct 1993 15:02:56 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) In-Reply-To: <9310121651.AA16770@eco.twg.com> References: <9310121651.AA16770@eco.twg.com> Beak: is Not Both RFC 821 and RFC 1123 section 5.2.8 guarante the ordering of Received: lines with respect to each other. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Oct 12 16:16:43 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28829; Tue, 12 Oct 93 16:16:43 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17871; Tue, 12 Oct 93 16:16:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Oct 12 16:24:43 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29164; Tue, 12 Oct 93 16:24:43 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17923; Tue, 12 Oct 93 16:24:21 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17917; Tue, 12 Oct 93 16:24:19 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA02294; Tue, 12 Oct 93 16:24:12 -0700 Date: Tue, 12 Oct 1993 16:00:28 -0700 (PDT) From: Mark Crispin Subject: Re: Dates in IMAP (Re: message state preservation in COPY ...) To: Peter Svanberg Cc: IMAP Interest List In-Reply-To: <9310121154.AA09750@nada.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 12 Oct 1993 12:54:31 +0100, Peter Svanberg wrote: > This doesn't say anything about the date, and in the new draft > noting is changed on the date preservation in the COPY command. That's correct. Date preservation was discussed. But in the end, it was decided to preserve flags but not dates. The reason why flags were not preserved earlier was for consistency; I felt that both should be preserved, or neither. That argument did not win the debate. > The only motivation for not preserving INTERNALDATE in COPY I > could get out of the earlier discussion on this issue is that > the INTERNALDATEs in a mailbox must be increasing, as commands > like SEARCH BEFORE assumes it. Is that correct? Yes, this is the reason why this happened. There was a strong feeling that INTERNALDATEs in a mailbox should be strictly increasing, and that a message should be assigned a new INTERNALDATE when it is placed in a mailbox. [By the way, SEARCH BEFORE doesn't assume that INTERNALDATEs be increasing. SEARCH itemizes each message number in the results.] > As I think this date field is useless (except in the Inbox), The INTERNALDATE field is not totally useless, but you are correct; its use is definitely much more limited than people might believe. This was the case from the very beginning -- this is why it was called ``INTERNALDATE'' and not ``DATE'' -- to suggest that this is some date that is ``internal'' to the storage mechanism and not any ``message date''. > I'll have to wait for the "new SEARCH". This is probably correct. One thing that we want to do about the new SEARCH is to make sure we do not repeat the mistakes of the current SEARCH. Otherwise, a few years later we'll have to have a ``new new SEARCH''. ;-( > Note that the "Be able to search on Received DATE" requirement > implies that this date (what I earlier called "arrival date") > is stored in some way amongst other "data that is associated > with a message as an entity in the mailbox". Yes. This is understood. The BEFORE/ON/SINCE tokens use the INTERNALDATE. This is not what is proposed for the new SEARCH (although the old SEARCH capabilities will be retained as well). That list is of new capabilities that need to be considered for addition. From owner-imap@cac.washington.edu Tue Oct 12 16:53:25 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00316; Tue, 12 Oct 93 16:53:25 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18084; Tue, 12 Oct 93 16:53:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Tue Oct 12 19:41:05 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04731; Tue, 12 Oct 93 19:41:05 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23651; Tue, 12 Oct 93 19:40:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23645; Tue, 12 Oct 93 19:40:17 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id WAA15146; Tue, 12 Oct 1993 22:40:13 -0400 Received: via switchmail; Tue, 12 Oct 1993 22:40:10 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 22:40:01 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Tue, 12 Oct 1993 22:39:59 -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 22:39:56 -0400 (EDT) Message-Id: Date: Tue, 12 Oct 1993 22:39:56 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Use of ¥DELETED in c-client In-Reply-To: References: Beak: is Not Mark Crispin writes: > 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. Disagree. There is nothing in the spec that says that BBOARDs have to be read-only. BBOARD can be a synonym for SELECT, perhaps modulo INBOX. > 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. Disagree. An attempt to EXPUNGE a mailbox that you do not have appropriate access to is a permission error. To be completely consistent with calling this a no-op, you would also have to treat an attempt to COPY to a read-only mailbox as a no-op. Remember that "[READ-ONLY]" is at best a hint. "Read-only" is not a well-defined concept in the protocol and there are servers that wish to use more fine-grained access control that "you can change everything or nothing." _.John From owner-imap@cac.washington.edu Wed Oct 13 02:08:11 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11010; Wed, 13 Oct 93 02:08:11 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20059; Wed, 13 Oct 93 00:47:10 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20053; Wed, 13 Oct 93 00:45:20 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA02838; Wed, 13 Oct 93 00:44:47 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA29729; Wed, 13 Oct 93 00:44:40 -0700 Date: Tue, 12 Oct 1993 20:12:50 -0700 (PDT) From: Mark Crispin Subject: Re: Use of ¥DELETED in c-client To: John Gardiner Myers Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 12 Oct 1993 22:39:56 -0400 (EDT), John Gardiner Myers wrote: > Disagree. There is nothing in the spec that says that BBOARDs have to > be read-only. BBOARD can be a synonym for SELECT, perhaps modulo INBOX. The spec implies that bboards have a separate namespace from mailboxes. Actually, it says that they *may* have a separate namespace. However, that means that commands such as APPEND, COPY, CREATE, DELETE, RENAME, can not be used with bboards. The bboard namespace is effectively a separate namespace, whether or not an implementation chooses to make it an identical namespace to mailboxes. Consequently, you are already restricted in what you can do with bboards. You even brought this up in the August meeting. Bboards have a rather restricted use, and it turns out that what they are mostly useful for are things such as netnews and for entities very much like the old TOPS-20 bboards (that is, folders on a special directory). You should not confuse what IMAP calls bboards with what your UA calls bboards. Perhaps the thing that IMAP calls bboards should be called blurdybloops instead. What your email software does with the thing that it calls bboards, and what IMAP does with the thing that it calls bboards, are two entirely separate things. > Disagree. An attempt to EXPUNGE a mailbox that you do not have > appropriate access to is a permission error. You can do this in your server, but it would not be very popular with users of a number of existing clients. I see no reason to take this position other than a misguided notion of protocol purity. No benefit is gained by an error message (which will probably translate into a modal error report at the user's end), but there is unnecessary user annoyance. Do you also purpose to give an error message when there are messages marked as deleted and an expunge is given? > To be completely > consistent with calling this a no-op, you would also have to treat an > attempt to COPY to a read-only mailbox as a no-op. This doesn't follow. No harm is ever done by ignoring an EXPUNGE. That is not the case with COPY. > Remember that "[READ-ONLY]" is at best a hint. "Read-only" is not a > well-defined concept in the protocol and there are servers that wish > to use more fine-grained access control that "you can change > everything or nothing." This is why EXPUNGE must be a no-op instead of an error in the read-only case. Precisely because there are shades of read-only, it is non-deterministic whether or not expunge is reasonable. If the client chooses to try it, it shouldn't cough back an error message. From owner-imap@cac.washington.edu Wed Oct 13 13:22:56 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29795; Wed, 13 Oct 93 13:22:56 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05264; Wed, 13 Oct 93 13:22:08 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05256; Wed, 13 Oct 93 13:22:05 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18666-2>; Wed, 13 Oct 1993 14:22:00 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Wed, 13 Oct 93 11:54 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0onAW6-000cw8C; Wed, 13 Oct 93 12:01 MDT Date: Wed, 13 Oct 1993 12:01:26 -0600 From: Steve Hole Subject: Re: Use of ¥DELETED in c-client To: Mark Crispin Cc: John Gardiner Myers , imap@cac.washington.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 12 Oct 1993 21:12:50 -0600 Mark Crispin wrote: > From: Mark Crispin > Date: Tue, 12 Oct 1993 21:12:50 -0600 > Subject: Re: Use of ¥DELETED in c-client > To: John Gardiner Myers > Cc: imap@cac.washington.edu > > On Tue, 12 Oct 1993 22:39:56 -0400 (EDT), John Gardiner Myers wrote: > > Disagree. There is nothing in the spec that says that BBOARDs have to > > be read-only. BBOARD can be a synonym for SELECT, perhaps modulo INBOX. > > The spec implies that bboards have a separate namespace from mailboxes. > Actually, it says that they *may* have a separate namespace. However, that > means that commands such as APPEND, COPY, CREATE, DELETE, RENAME, can not be > used with bboards. The bboard namespace is effectively a separate namespace, > whether or not an implementation chooses to make it an identical namespace to > mailboxes. Whoa, whoa, whoa. This conversation has suddenly jumped right back into the IMAP realm here. This is *DEFINITELY NOT* the way that I understood the protocol spec. I am immediately going back to reread this. Let me say even before I do this that this scares the hell out of me. If this is true, then I think that we need to rethink the whole BBoard setup then. To me a BBoard is simply a shared mailbox. It has the property that it is is bound to a broadcast address as opposed to singlecast address like a private mailbox. I always thought that actions like APPEND, COPY, CREATE, DELETE and RENAME were just restricted, not invalid. > Consequently, you are already restricted in what you can do with bboards. You > even brought this up in the August meeting. Bboards have a rather restricted > use, and it turns out that what they are mostly useful for are things such as > netnews and for entities very much like the old TOPS-20 bboards (that is, > folders on a special directory). > > You should not confuse what IMAP calls bboards with what your UA calls > bboards. Perhaps the thing that IMAP calls bboards should be called > blurdybloops instead. What your email software does with the thing that it > calls bboards, and what IMAP does with the thing that it calls bboards, are > two entirely separate things. What are the differentiating factors then. Address name space? What specific rules differentiate a BBoard? What are the alternatives for a broadcast mechanism - shared mailboxes? If so, how do we differentiate them when delivering to them? > > > Disagree. An attempt to EXPUNGE a mailbox that you do not have > > appropriate access to is a permission error. > > You can do this in your server, but it would not be very popular with users of > a number of existing clients. I see no reason to take this position other > than a misguided notion of protocol purity. No benefit is gained by an error > message (which will probably translate into a modal error report at the user's > end), but there is unnecessary user annoyance. WHAT???? If you don't have access to the mailbox, then you had better come back with an error. > Do you also purpose to give an error message when there are messages marked as > deleted and an expunge is given? If the user does not have delete access on the mailbox, you bet. What would you do? > > > To be completely > > consistent with calling this a no-op, you would also have to treat an > > attempt to COPY to a read-only mailbox as a no-op. > > This doesn't follow. No harm is ever done by ignoring an EXPUNGE. That is > not the case with COPY. > > > Remember that "[READ-ONLY]" is at best a hint. "Read-only" is not a > > well-defined concept in the protocol and there are servers that wish > > to use more fine-grained access control that "you can change > > everything or nothing." > > This is why EXPUNGE must be a no-op instead of an error in the read-only case. > Precisely because there are shades of read-only, it is non-deterministic > whether or not expunge is reasonable. If the client chooses to try it, it > shouldn't cough back an error message. Oh boy! Let me give you a scenario here. Joe user hits the expunge button and nothing happens because the server blithely took the Expunge and returned OK. The messages don't disappear from the list though. The very first thing the user does is phone support and say that they can't Expunge mail. No explanation why and it takes us 2 hours to figure out they are on a Read-only mailbox. 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-imap@cac.washington.edu Wed Oct 13 13:22:58 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29808; Wed, 13 Oct 93 13:22:58 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05250; Wed, 13 Oct 93 13:21:51 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05244; Wed, 13 Oct 93 13:21:44 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18647-2>; Wed, 13 Oct 1993 14:21:26 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Wed, 13 Oct 93 11:04 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0on9k6-000cvoC; Wed, 13 Oct 93 11:12 MDT Date: Wed, 13 Oct 1993 11:11:50 -0600 From: Steve Hole Subject: Re: ¥Deleted and ¥Seen in shared mailboxes To: John Gardiner Myers Cc: imap@cac.washington.edu Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As the subject says, this response goes directly to the "handling of ¥Deleted in the c-client news driver" issue that John has identified. On Sun, 10 Oct 1993 15:54:52 -0600 John Gardiner Myers wrote: > From: John Gardiner Myers > Date: Sun, 10 Oct 1993 15:54:52 -0600 > Subject: Re: ¥Seen flag possible compromise > To: imap@cac.washington.edu > > Mark Crispin writes: > > A shared mailbox (e.g. a help action inbox) may well possess per-mailbox > > ¥Seen flags. In fact, I implement this in c-client and we are deploying it. > > I consider per-mailbox ¥Seen flags for shared mailboxes a mistake. > AMS has per-folder 'unread' flags in addition to the per-user "I've > read everything before here" line. I get to see them in numerous help > action style bboards. They are simply not useful. The "Answered" and > "Deleted" flags are what are useful. I *think* I agree with John here. Specifically, ¥Seen and ¥Deleted have entirely different connotations, both in private (Mail) and shared (News) mailboxes. Private mailboxes are easy. I think everyone understands what ¥Seen and ¥Deleted mean there. With shared mailboxes, confusion seems to have arisen as to how ¥Deleted is interpretted. Apparently, the ¥Deleted flag is used to indicate that a News message "has been seen and shouldn't show up in the list". I can see how this developed, but it is wrong. It is entirely concievable, even practical to allow delete access to a shared mailbox. The example of a trouble ticket mailbox uses this situation exactly. In this case it is desirable to maintain both the ¥Deleted and the ¥Seen flag in exactly the same way as they are maintained for a private mailbox. Some users will just want to look at messages without necessarily deleting them, while others will want to physically remove them from the mailbox. The information conveyed by ¥Seen and ¥Deleted is independent and useful. My intepretation is straightforward and (I believe) consistent. Regardless of what type of mailbox you are looking at: ¥Seen = the message has been flagged as read ¥Deleted = the message has been flagged for deletion Being flagged for deletion means *physical* removal from the mailbox. The *correct* method for presenting this information in the user (IMHO) is to provide facilities in the client to filter what is presented to the user based upon flag information. This is exactly the approach that we have taken in ECSMail and the "virtual folder" mechanism. If the user does not want to see read messages, then they can ask for them to not be displayed. Deleting a News message to make it disappear from the message list is client dependent anyway. Many clients just use a visual mark to indicate that the message is deleted, but it doesn't go anywhere. Initiating an expunge won't *really* do anything because the message is still there. 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. So, having said this, this is what we plan to do with ECSMail. (1) ECSMail will allow the user to filter, group and present messages based upon header and flag information. The virtual folder mechanism already does this for header information and is being extended in the next version to include flag information. (2) ECSMail will depend upon the per-user state information provided by the server in the form of flags to do this. If the server does not keep cross-session, per-user state information then too bad. Complain to the people who write the server. (3) We will make sure that any servers provided as part of ECSMail will provide this information. The ones that we have been working with so far do - mostly :-) (4) Reading and deleting are separate actions for *any* mailbox type. User's will be able to mark for deletion all they want in news folders, but it *will* bitch at them if they try to expunge or if they automatically expunge on exit. I don't mean to sound pushy about this but I believe it is critical to be consistent. > > Our IMAP server preserves ¥Deleted per-user across sessions with > > newsgroups. > > > > Actually, Mark opposed this design, because it represented a break with > > the past of how news was handled in other newsreading tools. However, it > > has shown itself to be a viable and successful model. I may still be > > skeptical that it is ``better'' than the traditional model, but it's hard > > to argue with something that works. > > I don't think I realized that c-client mapped the .newsrc to the > ¥Deleted flag. I assumed that it did the obvious and mapped it to the > ¥Seen flag. To say that I think this was a poor implementation choice > would be an understatement. I agree. Substituting ¥Deleted for ¥Seen is not good. > 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. I agree. The bulk of the users will not be experienced mail users. Many will certainly never see UNIX character based interface. Consistency is *very* important. > 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. > > 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 YES! Exactly. 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-imap@cac.washington.edu Wed Oct 13 14:23:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01998; Wed, 13 Oct 93 14:23:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06561; Wed, 13 Oct 93 14:22:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06555; Wed, 13 Oct 93 14:22:29 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id RAA10308; Wed, 13 Oct 1993 17:22:12 -0400 Received: via switchmail; Wed, 13 Oct 1993 17:22:08 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 13 Oct 1993 17:21:09 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 13 Oct 1993 17:20:57 -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 17:20:48 -0400 (EDT) Message-Id: <0gj74kW00WBwFm90NH@andrew.cmu.edu> Date: Wed, 13 Oct 1993 17:20:48 -0400 (EDT) From: John Gardiner Myers Subject: Re: Use of ¥DELETED in c-client To: imap@cac.washington.edu In-Reply-To: References: Beak: is Not Steve Hole writes: > Whoa, whoa, whoa. This conversation has suddenly jumped right back into the > IMAP realm here. This is *DEFINITELY NOT* the way that I understood > the protocol spec. I am immediately going back to reread this. Let me > say even before I do this that this scares the hell out of me. If this is > true, then I think that we need to rethink the whole BBoard setup then. > > To me a BBoard is simply a shared mailbox. The bboards we are talking about here are the objects that are in the namespace used by the BBOARD command. There is no mechanism for the commands CREATE, DELETE, RENAME, APPEND, COPY to name objects in the BBOARD namespace. For this reason, Cyrus IMAPD puts all objects, including news, in the SELECT namespace. We haven't decided what to do with the BBOARD namespace--make it empty, equivalent to the SELECT namespace modulo INBOX, or make it a subset of the SELECT namespace. Mark had convinced me that EXPUNGE should no-op if there isn't sufficient access. Steve does have a legitimate argument, though. I still believe STORE +FLAGS ¥DELETED should return NO--a modal error message is not inappropriate at this point. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Wed Oct 13 15:32:19 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03993; Wed, 13 Oct 93 15:32:19 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07835; Wed, 13 Oct 93 15:31:43 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07829; Wed, 13 Oct 93 15:31:40 -0700 Received: from mcs-ss1-1.Stanford.EDU by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA09068; Wed, 13 Oct 93 15:31:26 PDT Date: Wed, 13 Oct 1993 14:36:47 -0700 (PDT) From: Mike Macgirvin Reply-To: Mike_Macgirvin@CAMIS.Stanford.EDU Subject: Re: ¥Deleted and ¥Seen in shared mailboxes To: Steve Hole Cc: John Gardiner Myers , imap@cac.washington.edu In-Reply-To: Steve Hole's message of Wed, 13 Oct 1993 11:11:50 -0600: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You've seen the below message. Rather than a point-by-point affirmation, let me just say "agreed on all points". We too work on a view based mailer, and flags are a user-definable criteria for inclusion within a view. It's incredibly easy to define a view of "flags unseen", and this is, in fact, one of the default "system defined views". I consider a "mailbox" to be any collection of "messages", and would prefer not to have to have to supply conditionals for treating a read-only, shared, newsgroup, mail spool, or mail folder any differently from any other. I'm willing to disable delete buttons if access prohibits, (this isn't done currently), but would prefer to do it for -every- read-only entity, and having a delete operation for netnews seems ludicrous, unless of course it's mapped to a cancel of a message you've authored (but this isn't what's done in the current client...). This and other differences in operational modes are an important reason why we haven't yet provided bboard access in our program. the number of additional conditionals starts to get overwhelming. With the exception of some form of naming scheme to locate the different forms of "mailboxes", the interface -should- be identical. I would go so far as suggest that any IMAP command containing the string "BBOARD" is perhaps an unnecessary modality. I do understand the practical and historical reasons for their existence, but this is an idealist talking... My $0.02, mike > On Sun, 10 Oct 1993 15:54:52 -0600 John Gardiner Myers wrote: > > > From: John Gardiner Myers > > Date: Sun, 10 Oct 1993 15:54:52 -0600 > > Subject: Re: ¥Seen flag possible compromise > > To: imap@cac.washington.edu > > > > Mark Crispin writes: > > > A shared mailbox (e.g. a help action inbox) may well > possess per-mailbox > > > ¥Seen flags. In fact, I implement this in c-client and we > are deploying it. > > > > I consider per-mailbox ¥Seen flags for shared mailboxes a > mistake. > > AMS has per-folder 'unread' flags in addition to the > per-user "I've > > read everything before here" line. I get to see them in > numerous help > > action style bboards. They are simply not useful. The > "Answered" and > > "Deleted" flags are what are useful. > I *think* I agree with John here. Specifically, ¥Seen and > ¥Deleted have entirely different connotations, both in private > (Mail) and shared (News) > mailboxes. > Private mailboxes are easy. I think everyone understands > what ¥Seen and > ¥Deleted mean there. With shared mailboxes, confusion seems > to have arisen as to how ¥Deleted is interpretted. > Apparently, the ¥Deleted flag is used to indicate that a News > message "has been seen and shouldn't show up > in the list". I can see how this developed, but it is wrong. > It is entirely concievable, even practical to allow delete > access to a shared mailbox. The example of a trouble ticket > mailbox uses this situation exactly. In this case it is > desirable to maintain both the ¥Deleted and the ¥Seen flag in > exactly the same way as they are maintained for a private > mailbox. Some users will just want to look at messages > without necessarily deleting them, while others will want > to physically remove them from the mailbox. > The information conveyed by ¥Seen and ¥Deleted is independent > and useful. My intepretation is straightforward and (I > believe) consistent. Regardless > of what type of mailbox you are looking at: > > ¥Seen = the message has been flagged as read > ¥Deleted = the message has been flagged for deletion > Being flagged for deletion means *physical* removal from the > mailbox. > The *correct* method for presenting this information in the > user (IMHO) is to provide facilities in the client to filter > what is presented to the user based upon flag information. > This is exactly the approach that we have taken in ECSMail and > the "virtual folder" mechanism. If the user does not want > to see read messages, then they can ask for them to > not be displayed. > Deleting a News message to make it disappear from the message > list is client dependent anyway. Many clients just use a > visual mark to indicate that the message is deleted, but it > doesn't go anywhere. Initiating an expunge won't *really* do > anything because the message is still there. 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. > > So, having said this, this is what we plan to do with ECSMail. > > (1) ECSMail will allow the user to filter, group and present > messages > based upon header and flag information. The virtual > folder mechanism > already does this for header information and is being > extended in > the next version to include flag information. > > (2) ECSMail will depend upon the per-user state information > provided > by the server in the form of flags to do this. If the > server does > not keep cross-session, per-user state information then > too bad. > Complain to the people who write the server. > > (3) We will make sure that any servers provided as part of > ECSMail will > provide this information. The ones that we have been > working with > so far do - mostly :-) > > (4) Reading and deleting are separate actions for *any* > mailbox type. > User's will be able to mark for deletion all they want in > news > folders, but it *will* bitch at them if they try to > expunge or if > they automatically expunge on exit. > I don't mean to sound pushy about this but I believe it is > critical to > be consistent. > > > > Our IMAP server preserves ¥Deleted per-user across > sessions with > > > newsgroups. > > > > > > Actually, Mark opposed this design, because it represented > a break with > > > the past of how news was handled in other newsreading > tools. However, it > > > has shown itself to be a viable and successful model. I > may still be > > > skeptical that it is ``better'' than the traditional > model, but it's hard > > > to argue with something that works. > > > > I don't think I realized that c-client mapped the .newsrc to > the > > ¥Deleted flag. I assumed that it did the obvious and mapped > it to the > > ¥Seen flag. To say that I think this was a poor > implementation choice > > would be an understatement. > > I agree. Substituting ¥Deleted for ¥Seen is not good. > > > 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. > I agree. The bulk of the users will not be experienced mail > users. Many will certainly never see UNIX character based > interface. > Consistency is *very* important. > > > 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. > > > > 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 > > YES! Exactly. > > 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-imap@cac.washington.edu Wed Oct 13 20:27:24 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12608; Wed, 13 Oct 93 20:27:24 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25590; Wed, 13 Oct 93 20:26:49 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25584; Wed, 13 Oct 93 20:26:47 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA04144; Wed, 13 Oct 93 20:26:46 -0700 Date: Wed, 13 Oct 1993 16:05:38 -0700 (PDT) From: Mark Crispin Subject: Re: Use of ¥DELETED in c-client To: IMAP Interest List In-Reply-To: <0gj74kW00WBwFm90NH@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 13 Oct 1993 17:20:48 -0400 (EDT), John Gardiner Myers wrote: > I still believe STORE +FLAGS ¥DELETED should return NO--a modal error > message is not inappropriate at this point. But, STORE returns the new value of the flags. Why is it helpful to return a modal error when you can simply not make the objectionable change? Then too, there is the problem of the server permitting per-session flags (something that is done now). From owner-imap@cac.washington.edu Wed Oct 13 21:28:34 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13531; Wed, 13 Oct 93 21:28:34 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25810; Wed, 13 Oct 93 21:28:06 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25804; Wed, 13 Oct 93 21:28:05 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA04209; Wed, 13 Oct 93 21:27:57 -0700 Date: Wed, 13 Oct 1993 20:40:33 -0700 (PDT) From: Mark Crispin Subject: Re: Use of ¥DELETED in c-client To: Steve Hole Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Steve - Please do not confuse what you call a ``bboard'' (and, very likely, what your software calls a ``bboard'') with what IMAP calls a bboard. The IMAP name for this entity is quite unfortunate. It presupposes one very limited model of bboard. Suppose, for argument's sake, we call these things that IMAP calls ``bboards'' by a new name which doesn't carry the baggage that ``bboard'' carries. Let's call them ``blurdybloops''. The spec says that blurdybloops have the follow characteristics: . They are in a separate namespace from mailboxes. It says they *may* be in a separate namespace, but since they *may* be, they are in effect. Two namespaces may have exact overlap. . You can't APPEND, COPY, CREATE, DELETE, or RENAME them. This is corrolary to the previous statement. . Nothing is said about flags handling, but existing implementations permit you to manipulate all system flags. Some are per-session only, others are per-user. No known implementations have per-mailbox flags, but some session flags have an initial state depending upon mailbox status. . Nothing is said about the validity of EXPUNGE, but existing implementations no-op expunge attempts. In an ideal world, EXPUNGE should not exist for blurdybloops at all, as with APPEND etc. Blurdybloops may be a useful expression of netnews and of certain other entities. Some people (e.g. CMU) find blurdybloops to be useless in their environment, and many of these folks have things they call ``bboards'' that are quite different from blurdybloops. Here are some interesting questions: Given that there are blurdybloop users, is the cost of forcing them to convert all their software worth the benefit by changing the command names in IMAP to something other than BBOARD? [SELECT.BLURDYBLOOP, FIND BLURDYBLOOPS, FIND ALL.BLURDYBLOOPS, SUBSCRIBE BLURDYBLOOP, UNSUBSCRIBE BLURDYBLOOP] Alternatively, should the people who use blurdybloops be told that they can't use them any more, that blurdybloops have been abolished and they must convert their software to use the new official IMAP bboards? Is there additional capability that is needed in IMAP to support bboards, for those people who don't use blurdybloops but do want to use bboards (or who want to use blurdybloops AND something else they call ``bboards'')? Or is it the case that the existing IMAP capabilities for mailboxes (SELECT, etc.) provides sufficient capability? What can be done to make sure that people don't confuse blurdybloops with bboards, given that the IMAP command to access a blurdybloop is BBOARD? Is there any way we can say that BBOARD was just a bad name, and not an attempt to define how you do bboards? -- Mark -- From owner-imap@cac.washington.edu Thu Oct 14 06:43:52 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24309; Thu, 14 Oct 93 06:43:52 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28045; Thu, 14 Oct 93 06:43:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28039; Thu, 14 Oct 93 06:43:22 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id JAA05209; Thu, 14 Oct 1993 09:43:18 -0400 Received: via switchmail; Thu, 14 Oct 1993 09:43:17 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 14 Oct 1993 09:41:41 -0400 (EDT) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 14 Oct 1993 09:41:36 -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; Thu, 14 Oct 1993 09:41:04 -0400 (EDT) Message-Id: Date: Thu, 14 Oct 1993 09:41:04 -0400 (EDT) From: Wallace Colyer To: imap@cac.washington.edu Subject: Re: Use of ¥DELETED in c-client In-Reply-To: References: Excerpts from internet.computing.imap: 13-Oct-93 Re: Use of ¥DELETED in c-cl.. Mark Crispin@CAC.Washing (2757*) > Blurdybloops may be a useful expression of netnews and of certain other > entities. Some people (e.g. CMU) find blurdybloops to be useless in > their environment, and many of these folks have things they call > ``bboards'' that are quite different from blurdybloops. I should say why we believe find Mark's blurdybloops (IMAP bboards) useless in our environment. We see bboards are entities which come from a variety of sources. Some live in netnews, some are mappings of Internet distribution lists (we discourage the use of distribution lists to directly address users), some are local bboards, and finally some are used as a form of shared mailbox. In our current environment all these bboards live in a single namespace (actually multiple namespaces which are unified by the clients, but they are seen as one namespace). The users' mail folders live in individual namespaces. The users namespace is not easily referenceable from another user. This effectively precludes the sharing of mailboxes except in the bboard namespace. We have learned from our experiences with AFS that a single namespace brings untold advantages. It allows individuals to collaborate without administrative assistance or without learning special hoops placed in the system. We see a namespace that has only one magic name per user and that is INBOX. Then the rest of the namespace lives under: user.USER.* If I wanted to address the user jgm's work folder, I would simply look at user.jgm.work (assuming he gave me access to see it). That provides a great deal of additional simplicity. The reason we want the bboard namespace in the mailbox namespace, is that we have this mix of local bboards, shared mailboxes, and netnews. Each of them have different characteristics, but many of them need actions like APPEND, COPY, CREATE, DELETE, and RENAME. We do not want people to have to know to append some magic set of strings to do these actions in the mailbox namespace. Thus what makes the bboard namespace useless to us is that these actions do not exist. We could partition the namespace such that mailbox was personal mailboxes (still named the way I said) and bboard was all the local bboards, shared mailboxes (people's mailboxes to which I have been given lookup access), and netnews, except for the fact that it does not allow for APPEND, COPY, CREATE, DELETE, and RENAME, making it quite useless for us. -Wallace From owner-imap@cac.washington.edu Sun Oct 17 01:01:07 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20067; Sun, 17 Oct 93 01:01:07 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28962; Sun, 17 Oct 93 01:00:06 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Oct 17 08:07:51 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25561; Sun, 17 Oct 93 08:07:51 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01222; Sun, 17 Oct 93 08:07:22 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Oct 17 15:37:14 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00784; Sun, 17 Oct 93 15:37:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03526; Sun, 17 Oct 93 15:36:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Oct 17 15:45:13 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00874; Sun, 17 Oct 93 15:45:13 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03576; Sun, 17 Oct 93 15:44:42 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Sun Oct 17 17:00:09 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01628; Sun, 17 Oct 93 17:00:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03937; Sun, 17 Oct 93 16:59:48 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Mon Oct 18 07:42:09 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15421; Mon, 18 Oct 93 07:42:09 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21329; Mon, 18 Oct 93 07:41:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Wed Oct 20 02:00:18 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16854; Wed, 20 Oct 93 02:00:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13830; Wed, 20 Oct 93 01:59:33 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from survis.surfnet.nl by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13824; Wed, 20 Oct 93 01:59:30 -0700 Received: from localhost by survis.surfnet.nl with SMTP (PP) id <06217-0@survis.surfnet.nl>; Wed, 20 Oct 1993 09:59:16 +0100 To: imap@cac.washington.edu, ietf-822@dimacs.rutgers.edu, mime-mhs@SURFnet.nl, ietf-nntp@net.bio.net, ietf-osi-ds@cs.ucl.ac.uk, telnet-ietf@cray.com, tn2370e@list.nih.gov, ietf-osi-x400ops@cs.wisc.edu, ietf-smtp@dimacs.rutgers.edu Subject: Announcement of Open Applications Area Meeting Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Wed, 20 Oct 93 09:59:15 +0100 From: "Erik Huizer (SURFnet BV)" Message-Id: <"survis.sur.219:20.09.93.08.59.18"@surfnet.nl> If you're in Houston, please come! Erik Special Applications and Services Meeting Announcement John Klensin APP Joyce Reynolds USV Erik Huizer APP This is to announce a combined Application Area and User Services Area session at the upcoming IETF. The session is meant to coordinate efforts in Application related groups in these two Areas of the IETF. The session takes place on Thursday 0930-1200. The session is split into two parts: Applications Area Directorate Open Meeting (apples) (0930-1045) Integrated Information Architecture (iia) (1045-1200) First part of the session: ========================== Open Applications Area Directorate meeting (apples) --------------------------------------------------- Within the IETF there are currently a lot of application related efforts going on. In the past year there has been some reshuffling of Applications related IETF activities: - Integration of OSI related work in Applications Area - Creation of WGs that are chartered in both the User Services AND the Applications Area. - Creation of the Service Applications Area The Applications Area Directorate and the IESG are trying to keep these in line and coordinated. However, it has been our experience that often enough participants in Application related WGs are not aware of similar or related work in other IETF WGs. As a result of this it happens sometimes that valuable input from one part of the IETF community to a certain spec, is only given at a very late stage, which is of course not beneficial to the result. To make people aware of what is going on in the IETF with regard to applications, this meeting intents to give an overview of ongoing work, and issues under discussion in the various WGs. The goal of this meeting is to assure the right level of expertise in each WG to cover all aspects of the work within that WG. We strongly encourage all people who participate in any Applications related WG, to attend this session. Second part of the session: =========================== Integrated Information Architecture (IIA) meeting in Houston When IESG created the IAFA, IIIR, NIR, URI, and WNILS working groups, it did so as components of an overall effort to develop a single coordinated Internet architectures for information naming, discovery, and retrieval system. The working groups involved have made rapid progress, but occasionally at the expense of coordination with each other, with other IETF WGs, and with existing practice outside IETF. It has seemed to the responsible area directors that coordinated efforts are even more important today as these efforts overlap and intertwine. This session is an open discussion of IIA issues with the chairs of the five WGs and the three area directors to determine what level of coordination of overlapping facilities is still appropriate and how to accomplish it. The results will include a progress report to IETF on the development of the integrated information service, as required by the charter statement. A copy of the original charter and IESG position statement follows for reference. - - --------------------- Integrated Information Architecture Many new networked services to identify, access, and retrieve information resources have sprung up in the last several years -- archie, WAIS, and Netfind, to name only three. Now, much as the Internet has tied many disparate networks together into an integrated system, the pressing problem is how to integrate these many new services into a single coordinated Internet information naming, discovery, and retrieval system. There are three vital areas of this integration effort that the IESG is interested in pursuing: 1) The identification, cataloging, and documentation of networked information services, new and old. 2) The standardization of descriptions and identification schemes for networked resources, and the distribution and implementation of these identifiers. 3) The integration and interoperability of the various new information services. To this end, the IESG is creating three new working groups: 1) Networked Information Retrieval (NIR) -- NIR will work on the first issue above by identifying, cataloging, and documenting networked information services. The result will be a published catalog of network information retrieval services. In addition, NIR will liase with other organizations working on this goal, such as RARE ISUS and CNI. 2) Uniform Resource Identifiers (URI) -- URI will concentrate on the second issue above, particularly on the standardization and implementation of identification schemes for networked resources. There will be two primary components in this effort: a Uniform Resource Locator (URL) which is a string which tells how to locate a document. The second part is a Universal Resource Serial Number, which is used to uniquely identify a resource, so that one can, for example tell if two documents with different file names are, in fact, the same. The standard identification scheme developed by URI will be used by NIR to define the standard resource formats. 3) Integration of Internet Information Resources (IIIR) -- IIIR will work on the third issue by developing technical specifications and documentation for a) interoperation between the various information services and b) the integration of new information services into the existing CIM (combined information mesh). After the specifications for interoperation have been completed, IIIR will examine the need for additional protocols necessary to further integrate the CIM, including gateway protocols, query routing protocols, and other mechanisms. In addition to the above named groups, the IETF wishes to facilitate the standardization of descriptions and data formats for various specific information services by chartering single-protocol working groups which will work on this standardization. Examples of such groups are the Internet Anonymous FTP Archive group (IAFA), which is working on standardization of anonymous FTP archives, and the new Whois Network Information Lookup Service (WNILS), which is working on standardization of services using the WHOIS protocol. The IESG considers these WGs to be components of a single coordinated IETF effort to create an integrated Internet information architecture. Therefore, the chairs and membership of each group will be active participants in the other groups. The overall coordination of this effort will be under the joint management of the Applications and User Services Area. Due to the importance of an Integrated Internet Information Service Architecture, the IESG requests the working group chairs and the Applications and User Services area directors to jointly expand this brief overview into a more fully fleshed out architectural statement, and to issue periodic progress reports describing how the integrated information service is developing. ----------- From owner-imap@cac.washington.edu Wed Oct 20 15:27:14 1993 Received: by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09929; Wed, 20 Oct 93 15:27:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Relay.CV.COM by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09923; Wed, 20 Oct 93 15:27:11 -0700 Received: from 530197000002 (caller not authenticated) by Relay.CV.COM; 20 Oct 93 18:25:57 EDT Received: from huia [210.5.192.18] by PR1MEA.cv.COM ; 21 Oct 93 11:16:29 L Return-Path: Received: by huia (5.61/1.34) id AA12262; Thu, 21 Oct 93 11:14:04 +1300 Date: Thu, 21 Oct 1993 11:08:46 +1300 (NZDT) From: Michael J A Lasham Reply-To: michael_lasham@PR1MEA.CV.COM Subject: Serial Lines To: IMAP Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Could someone please explain to me what is envolved in setting up a PC that can dial-up a unix host and download mail at 9600 baud using IMAP. I have only ever setup IMAP to run over tcp/ip. Thanks Michael Lasham | Email: MICHAEL_LASHAM@Pr1mea.cv.COM Technical Consultant | Phone: (64 9) 300-3400 Eagle Technology Ltd | Fax: (64 9) 300-3430 Auckland, New Zealand | -------------------------------------------------------------------- From owner-imap@cac.washington.edu Wed Oct 20 20:53:56 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21069; Wed, 20 Oct 93 20:53:56 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09672; Wed, 20 Oct 93 20:53:27 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09666; Wed, 20 Oct 93 20:53:25 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA08365; Wed, 20 Oct 93 20:51:01 -0700 Date: Wed, 20 Oct 1993 20:40:47 -0700 (PDT) From: Mark Crispin Subject: re: Serial Lines To: michael_lasham@PR1MEA.CV.COM Cc: IMAP Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 21 Oct 1993 11:08:46 +1300 (NZDT), Michael J A Lasham wrote: > Could someone please explain to me what is envolved in setting up a PC > that can dial-up a unix host and download mail at 9600 baud using IMAP. > > I have only ever setup IMAP to run over tcp/ip. At the present time, your best bet is to set up the serial link using an serial link IP protocol such as SLIP or PPP. Basically, IMAP requires a flow controlled, error-correcting protocol. You probably also want some sort of multi-streaming mechanism. That sounds an awful lot like SLIP/PPP, but unfortunately it's still the case today that it isn't easy to set up a SLIP or PPP link. There has been some talk about a lightweight serial link protocol without all the extra overhead that setting up a SLIP/PPP line involves. It's on my list, but at the present time it's near the bottom...maybe my boss is hoping that by the time I get to doing it, PPP will be so prevalent and plug'n'play that people won't think of it as being a problem any more. ;-) In fact, I use IMAP over SLIP every day full-time. IMAP works quite well over serial links. Not surprising, because I designed it with SLIP in mind from the very beginning. I have an e-mail mailbox at the office (CAC) and one on my NeXT at home (Panda). Using IMAP I simultaneously monitor both mailboxes, no matter which machine I happen to be at the time. This is quite useful, since it's at least an hour's commute between home and office! Regards, -- Mark -- From owner-imap@cac.washington.edu Thu Oct 21 21:22:26 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25406; Thu, 21 Oct 93 21:22:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21024; Thu, 21 Oct 93 21:21:15 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from muwayb.ucs.unimelb.EDU.AU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21018; Thu, 21 Oct 93 21:21:11 -0700 Received: from werple.apana.org.au by muwayb.ucs.unimelb.edu.au (PMDF V4.2-14 #4399) id <01H4EZR036S0008ENY@muwayb.ucs.unimelb.edu.au>; Fri, 22 Oct 1993 14:20:51 +1000 Received: from bushwire.apana.org.au (root@bushwire.apana.org.au [192.188.107.58]) by werple.apana.org.au (8.6.1/8.6) with ESMTP id OAA01867; Fri, 22 Oct 1993 14:21:19 +1000 Received: from bushwire.apana.org.au (markd@bushwire.apana.org.au [192.188.107.58]) by bushwire.apana.org.au (8.6.1/bw1) with SMTP id OAA23410; Fri, 22 Oct 1993 14:20:12 +1000 Date: Fri, 22 Oct 1993 12:56:28 +1000 (EST) From: Mark Delany Subject: re: Serial Lines In-Reply-To: To: Mark Crispin Cc: michael_lasham@PR1MEA.CV.COM, IMAP Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT On Wed, 20 Oct 1993, Mark Crispin wrote: > On Thu, 21 Oct 1993 11:08:46 +1300 (NZDT), Michael J A Lasham wrote: > > Could someone please explain to me what is envolved in setting up a PC > > that can dial-up a unix host and download mail at 9600 baud using IMAP. > At the present time, your best bet is to set up the serial link > using an serial link IP protocol such as SLIP or PPP. Basically, > IMAP requires a flow controlled, error-correcting protocol. You > probably also want some sort of > There has been some talk about a lightweight serial link protocol > without all the extra overhead that setting up a SLIP/PPP line > involves. It's on my list, but at the present time it's near the > bottom...maybe my boss is hoping that by the time I get to doing it, > PPP will be so prevalent and plug'n'play that people won't think of > it as being a problem any more. ;-) Yes, there has long been a need for a generalized LW serial protocol that could be inserted below the application's socket interfaces. And not just for IMAP. The problem is that such a solution implies that the application code knows about it - in some form or another - as the socket/read/write calls have to be intercepted and sent across the serial connection. Furthermore, it realistically has to be intercepted at the application level as doing so in the OS is *very* OS dependent. On the surface, complete interception of pre-existing applications appears difficult (consider the problem of an application that opens a socket then uses stdio to do I/O), but in *many* cases on unix systems for client initiated connections the only call that needs to be intercepted is the connect() system call(*1). This works because the intercepted connect() call would actually result in a connection to a local server which manages the IP connection. Thus: [[=========LOCAL SYSTEM========]] [[====REMOTE SYSTEM======]] +-------+ +-------+ +-------+ +-------+ |client |===socket======|serial |-serial port---|serial |==socket=|remote | |appl | |server | |server | |Server | +-------+ +-------+ +-------+ +-------+ This would actually work in a reasonable subset of cases including IMAP(*2) and POP given the following caveats: 1. The Remote Server does not need to know the *true* identity of the local application's host system. IMAP is OK because there is a higher level of authentication, eg login/passwd. Something like client-side SMTP may be acceptable (even though things like Received: lines would look a bit strange). This of course is important for IMAP users. But it does mean that the client mailer has to have the interception code if SMTP is not built into the client. 2. This may not work for application servers that use multiple sockets in the way that FTP does. Well, leastwise the serial server would have to have smarts to cope with it. 3. This would not work at all for single-user single-task OSes such as DOS. Which is what the original query was all about. 4. The client code must not check/rely on the connect really going to where they think it's going. Off the top of my head I cannot think of any that do this but there are bound to be some. I haven't completely thought thru the implications of broadcast protocols - which fortunately is irrelevant to most of the useful application protocols such as IMAP/SMTP. And of course there is an absolute bucketload of work to do to implement such as scheme instead of using off-the-shelf SLIP/PPP stuff - if you have it. One advantage I see in this solution in general is that it's all done in user space and thus is not dependent on wide-spread support of SLIP/PPP in both your host and client system's OSes. The other advantage is that the client need not be IP configured in your network, nor trusted administratively, all they need to know and configure correctly is the login details to the remote server. This is especially suited to environments that want to provide IMAP style mail access to many remote users but have little real administrative control over the client systems, eg roving Unix users. Oh, and there is the minor issue of developing a portable robust LW serial protocol with multi-channels and dialers etc. Sigh. *1. gethostby*() are the biggest worry with this generalization. The simplest solution is that the client has to place the remote server in /etc/hosts or similar. A hack to be sure. *2. A quick examination of pine and it's imapd shows that almost all of it would work with an intercepted connect() excepting the authenticated opening that uses rsh. Regards, Mark D. From owner-imap@cac.washington.edu Thu Oct 21 22:12:22 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26025; Thu, 21 Oct 93 22:12:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21301; Thu, 21 Oct 93 22:11:36 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from muwayb.ucs.unimelb.EDU.AU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21295; Thu, 21 Oct 93 22:11:32 -0700 Received: from werple.apana.org.au by muwayb.ucs.unimelb.edu.au (PMDF V4.2-14 #4399) id <01H4F1I2QUOG008P8D@muwayb.ucs.unimelb.edu.au>; Fri, 22 Oct 1993 15:10:52 +1000 Received: from bushwire.apana.org.au (root@bushwire.apana.org.au [192.188.107.58]) by werple.apana.org.au (8.6.1/8.6) with ESMTP id PAA02482; Fri, 22 Oct 1993 15:11:16 +1000 Received: from bushwire.apana.org.au (markd@bushwire.apana.org.au [192.188.107.58]) by bushwire.apana.org.au (8.6.1/bw1) with SMTP id PAA23610; Fri, 22 Oct 1993 15:10:17 +1000 Date: Fri, 22 Oct 1993 15:06:34 +1000 (EST) From: Mark Delany Subject: re: Serial Lines In-Reply-To: Cc: IMAP Mailing List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT On Fri, 22 Oct 1993, Mark Delany wrote: Sorry, the pictogram didn't seem to make it thru very well, you may want to look at this instead - assuming it gets thru Ok this time. If it doesn't this time I'll give up - it's hardly very important. [[=====LOCAL SYSTEM======]] [[====REMOTE SYSTEM======]] +-------+ +-------+ +-------+ +-------+ |client |=socket==|serial |-serial port-|serial |==socket=|remote | |appl | |server | |server | |Server | +-------+ +-------+ +-------+ +-------+ M. From owner-imap@cac.washington.edu Fri Oct 22 00:32:48 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27839; Fri, 22 Oct 93 00:32:48 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17712; Fri, 22 Oct 93 00:32:12 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17706; Fri, 22 Oct 93 00:32:10 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA10648; Fri, 22 Oct 93 00:29:50 -0700 Date: Fri, 22 Oct 1993 00:24:28 -0700 (PDT) From: Mark Crispin Subject: re: Serial Lines To: Mark Delany Cc: michael_lasham@PR1MEA.CV.COM, IMAP Mailing List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Actually, it's even simpler than you say, because many network servers are written to run under inetd and thus don't know anything about the network at all! For example, the IMAP and POP servers in the c-client based IMAP toolkit do all their I/O via stdio and have no socket calls at all. So, the only thing that would need to be done at the server end is have some simple user-mode program that knows how to run the IMAP, POP, SMTP, etc. server. More work needs to be done at the client end. Basically, instead of TCP routines it would have to direct its I/O though a decoder for this protocol. But we're not talking major rocket science here. The real rocket science is in avoiding the creeping featurism that ends up TCP all over again! ;-) I did such a thing, many years ago in a previous life, on the DEC-20; and even more years ago, in another previous life, on the DEC-10. It's been on my list of things to do for UNIX, it's just that more important things to do have always come up (plus the faint hope that SLIP or PPP would take over the world and there wouldn't be a need to worry about it...). -- Mark -- From owner-imap@cac.washington.edu Sat Oct 23 09:01:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16793; Sat, 23 Oct 93 09:01:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14243; Sat, 23 Oct 93 09:00:55 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14237; Sat, 23 Oct 93 09:00:54 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id MAA03419; Sat, 23 Oct 1993 12:00:51 -0400 Received: via switchmail; Sat, 23 Oct 1993 12:00:50 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 23 Oct 1993 12:00:40 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 23 Oct 1993 12:00: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; Sat, 23 Oct 1993 12:00:34 -0400 (EDT) Message-Id: Date: Sat, 23 Oct 1993 12:00:34 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: UID searching Beak: Is I think that there's something mising from the UID suite of commands. You can FETCH them, you can use them to identify sequences of messages for FETCH, STORE, and COPY, but you can't use them to limit SEARCH hits. I think there should be UIDBEFORE and UIDAFTER search criteria. The existence of the UID command would signal their presence, so they wouldn't have to go into NSEARCH. Adding these search criteria would probably make the UID AFTER command redundant. Though UID AFTER gives you the additional information which message numbers correspond to which UID's, I can't see any client doing a UID AFTER without needing to do a subsequent FETCH or UID FETCH anyway. Also, the draft spec should probably prohibit any message from having a UID of 0. This would avoid some fencepost problems. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sat Oct 23 18:38:54 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24118; Sat, 23 Oct 93 18:38:54 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28509; Sat, 23 Oct 93 18:38:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28503; Sat, 23 Oct 93 18:38:27 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA00574; Sat, 23 Oct 93 18:38:14 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA16557; Sat, 23 Oct 93 18:38:02 -0700 Date: Sat, 23 Oct 1993 18:30:34 -0700 (PDT) From: Mark Crispin Subject: re: UID searching To: John Gardiner Myers Cc: IMAP Interest List , Rob Austein In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII John's proposal sounds alright to me. Rob, what do you think? On Sat, 23 Oct 1993 12:00:34 -0400 (EDT), John Gardiner Myers wrote: > I think that there's something mising from the UID suite of commands. > You can FETCH them, you can use them to identify sequences of messages > for FETCH, STORE, and COPY, but you can't use them to limit SEARCH > hits. > > I think there should be UIDBEFORE and UIDAFTER search criteria. The > existence of the UID command would signal their presence, so they > wouldn't have to go into NSEARCH. > > Adding these search criteria would probably make the UID AFTER command > redundant. Though UID AFTER gives you the additional information > which message numbers correspond to which UID's, I can't see any > client doing a UID AFTER without needing to do a subsequent FETCH or > UID FETCH anyway. > > Also, the draft spec should probably prohibit any message from having > a UID of 0. This would avoid some fencepost problems. From owner-imap@cac.washington.edu Sun Oct 24 01:37:31 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28941; Sun, 24 Oct 93 01:37:31 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20085; Sun, 24 Oct 93 01:36:40 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20079; Sun, 24 Oct 93 01:36:37 -0700 From: Rob Austein To: Mark Crispin , John Gardiner Myers Cc: IMAP@cac.washington.edu In-Reply-To: Mark Crispin's message of Sat, 23 Oct 1993 18:30:34 -0700 (PDT) Subject: Re: UID searching Date: Sun, 24 Oct 93 4:35:59 EDT Message-Id: <9310240435.aa05840@quern.epilogue.com> Well, I like the idea of the UIDBEFORE and UIDAFTER search criteria, but they don't exactly replace UID AFTER. UID AFTER allows you to ask the question "what UIDs are there that I've not yet seen" as an atomic operation. Using SEARCH UIDAFTER to do this would require a subsequent UID FETCH to translate the message numbers you got from the search into UIDs. There's a potential timing screw here, since another client could modify the mailbox in a way that changes the message numbers between the two commands. Granted, the timing window is small, but it's there. I was going to say that this makes UID AFTER vital, but perhaps it's not. If a client does the UID FETCH on a message number range starting one message number lower than the range returned by the SEARCH UIDAFTER command, the client should be able to detect the rare case where the timing screw has occurred and recover appropriately. So I guess I do believe that John's proposal would work. I agree that it seems unlikely that a client would want to do just a UID AFTER without also doing at least a UID FETCH FLAGS. --Rob Austein From owner-imap@cac.washington.edu Sun Oct 24 08:49:36 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03991; Sun, 24 Oct 93 08:49:36 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22223; Sun, 24 Oct 93 08:49:11 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22217; Sun, 24 Oct 93 08:49:09 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id LAA02081; Sun, 24 Oct 1993 11:48:50 -0400 Received: via switchmail; Sun, 24 Oct 1993 11:48:36 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 24 Oct 1993 11:48:04 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 24 Oct 1993 11:48:01 -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, 24 Oct 1993 11:47:58 -0400 (EDT) Message-Id: Date: Sun, 24 Oct 1993 11:47:58 -0400 (EDT) From: John Gardiner Myers Subject: Re: UID searching To: IMAP@cac.washington.edu In-Reply-To: <9310240435.aa05840@quern.epilogue.com> References: <9310240435.aa05840@quern.epilogue.com> Beak: Is An IMAP server can't insert messages in the middle, so I don't know what the "one message number lower" is supposed to protect against. An IMAP server is not allowed to send a * n EXPUNGE response to either a SEARCH or FETCH request, so if the mailbox gets modified, the server isn't allowed to change the message numbers on you. An advantage of UID AFTER/UID FETCH is that the server would be able to give you those notifications. What I really think you want to do is find the largest extant UID with a FETCH n UID (where "n" is what you got in the "* n EXISTS" response). Then use that UID to build a sequence for a UID FETCH command. This is actually how the Cyrus IMAPD implements the UID AFTER command. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sun Oct 24 12:53:55 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06561; Sun, 24 Oct 93 12:53:55 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02203; Sun, 24 Oct 93 12:53:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02197; Sun, 24 Oct 93 12:53:24 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA01078; Sun, 24 Oct 93 12:53:16 -0700 Date: Sun, 24 Oct 1993 12:44:53 -0700 (PDT) From: Mark Crispin Reply-To: Mark Crispin Subject: Re: UID searching To: John Gardiner Myers , Rob Austein Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII As I read these messages, I see the following two points coming up: There are compelling reasons for the UIDBEFORE and UIDAFTER search criteria. In the absence of objections, they should be added to the IMAP2bis draft as mandatory SEARCH criteria if the UID command is implemented. For the nonce, that there is not yet closure on the continued need for the UID AFTER command. Therefore, it should remain in the draft until there is concensus that it should be removed. Are there any problems or objections with doing this? From owner-imap@cac.washington.edu Sun Oct 24 13:04:25 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06703; Sun, 24 Oct 93 13:04:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23763; Sun, 24 Oct 93 13:03:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23757; Sun, 24 Oct 93 13:03:54 -0700 From: Rob Austein To: Mark Crispin Cc: John Gardiner Myers , IMAP@cac.washington.edu In-Reply-To: Mark Crispin's message of Sun, 24 Oct 1993 12:44:53 -0700 (PDT) Subject: Re: UID searching Date: Sun, 24 Oct 93 16:03:12 EDT Message-Id: <9310241603.aa06686@quern.epilogue.com> Agreed. Add SEARCH UIDAFTER and SEARCH UIDBEFORE, and leave UID AFTER in with the understanding that we'll probably conclude it can be flushed. --Rob From owner-imap@cac.washington.edu Sun Oct 24 17:42:35 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09579; Sun, 24 Oct 93 17:42:35 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03169; Sun, 24 Oct 93 17:41:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03163; Sun, 24 Oct 93 17:41:52 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA00321; Sun, 24 Oct 93 17:41:48 -0700 Date: Sun, 24 Oct 1993 17:30:20 -0700 (PDT) From: Mark Crispin Subject: re: UID searching To: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Should either the UIDAFTER and UIDBEFORE criteria match the UID itself? Although SINCE is documented as being ``later than the specified date'', everybody (at least until now) has always implemented it as a .GE. rather than a .GT. comparison. It ``feels right'' and seems to be more useful than the strictly .GT. comparison, but that isn't what the spec says. I propose to change the specification to specifically make SINCE be a .GE. comparison, on historical grounds and on the claim that this is the more useful comparison. But, if anyone feels that this is seriously wrong, please speak up!! I also propose that UIDAFTER should also be a .GE. comparison, but this is on much shakier consistency grounds. The current UID hackers definitely are in a better position to judge this. -- Mark -- From owner-imap@cac.washington.edu Sun Oct 24 18:42:53 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10340; Sun, 24 Oct 93 18:42:53 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25956; Sun, 24 Oct 93 18:42:16 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from cari.telecom.uqam.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25950; Sun, 24 Oct 93 18:42:14 -0700 Received: from nobel.si.uqam.ca by cari.telecom.uqam.ca (4.1/SMI-4.2.1.pop NIS) id AA04490; Sun, 24 Oct 93 21:42:13 EDT Received: by nobel.si.uqam.ca (1.37.109.4/16.2) id AA25177; Sun, 24 Oct 93 21:42:55 -0400 Date: Sun, 24 Oct 1993 21:41:46 +0500 (EST) From: "Lavallee, Marc" Subject: UnSubscribe To: IMAP@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please remove me from the IMAP mailing list Marc Lavallee r27764@er.uqam.ca From owner-imap@cac.washington.edu Sun Oct 24 20:37:47 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11594; Sun, 24 Oct 93 20:37:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26714; Sun, 24 Oct 93 20:36:51 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26708; Sun, 24 Oct 93 20:36:50 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id XAA17377; Sun, 24 Oct 1993 23:36:47 -0400 Received: via switchmail; Sun, 24 Oct 1993 23:36:46 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 24 Oct 1993 23:35:00 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sun, 24 Oct 1993 23:34:59 -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, 24 Oct 1993 23:34:57 -0400 (EDT) Message-Id: Date: Sun, 24 Oct 1993 23:34:57 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: UID searching In-Reply-To: References: Beak: is Not No objections here to changing SINCE. It'd be trivial to change the Cyrus IMAPD from .GT. to .GE. It wouldn't be the first bug in the spec I've implemented. I agree that UIDAFTER should also be .GE. for consistency. It's trivial to add one to a UID if you want .GT. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sun Oct 24 21:21:41 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12000; Sun, 24 Oct 93 21:21:41 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26950; Sun, 24 Oct 93 21:21:20 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26944; Sun, 24 Oct 93 21:21:18 -0700 From: Rob Austein To: imap@cac.washington.edu In-Reply-To: John Gardiner Myers's message of Sun, 24 Oct 1993 23:34:57 -0400 (EDT) Subject: Re: UID searching Date: Mon, 25 Oct 93 0:20:23 EDT Message-Id: <9310250020.aa08064@quern.epilogue.com> .GE. sounds right. From owner-imap@cac.washington.edu Mon Oct 25 12:05:08 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03235; Mon, 25 Oct 93 12:05:08 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07253; Mon, 25 Oct 93 12:04:13 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07247; Mon, 25 Oct 93 12:04:10 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id PAA25369; Mon, 25 Oct 1993 15:04:08 -0400 Received: via switchmail; Mon, 25 Oct 1993 15:04:07 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:03:39 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:03:29 -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, 25 Oct 1993 15:03:21 -0400 (EDT) Message-Id: Date: Mon, 25 Oct 1993 15:03:21 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: base flatlander proposal Beak: is Not Here's a draft written by Chris Newman of the base flatlander proposal. Following this message will be a draft of what a full-blown server-exported-hierarchy proposal would look like and summary of known issues and alternate flatlander proposasals. Flatlander proposal V1.1: ---------------------------------- tag FIND MAILBOXES pattern [separator_chars] [... No change to existing FIND description, except a new example:] EXAMPLE: C: A002 FIND MAILBOXES WORK.* S: * MAILBOX WORK.CORRESPONDENCE.MARK S: * MAILBOX WORK.IMAP S: * MAILBOX WORK.IMAP. S: * MAILBOX WORK.IMAP.C-CLIENT S: * MAILBOX WORK.IMAP.PINE S: * MAILBOX WORK.IMSP S: A002 OK FIND completed The optional separator_chars argument specifies a set of separator characters. If the argument is specified the pattern must end with a "*" and that "*" will not match a character following a matched separator character. In addition, if any mailbox names fail to match because of separator characters, the prefix names for those mailboxes are returned in unsolicited NONTERMINAL replies. Prefix names consist of the mailbox name up to and including the separator character. No prefix name should be sent twice for a single FIND invocation. This can be used to limit the number of returned items based on client perceived namespace hierarchy. EXAMPLE: C: A002 FIND MAILBOXES WORK.* ./ S: * NONTERMINAL WORK.CORRESPONDENCE. S: * MAILBOX WORK.IMAP S: * MAILBOX WORK.IMAP. S: * NONTERMINAL WORK.IMAP. S: * MAILBOX WORK.IMSP S: A002 OK FIND completed tag FIND ALL.MAILBOXES pattern [separator_chars] ... tag FIND BBOARDS pattern [separator_chars] [... No change to existing FIND description, except a new example:] EXAMPLE: C: A002 FIND BBOARDS WORK.* S: * BBOARD WORK.CORRESPONDENCE.MARK S: * BBOARD WORK.IMAP S: * BBOARD WORK.IMAP. S: * BBOARD WORK.IMAP.C-CLIENT S: * BBOARD WORK.IMAP.PINE S: * BBOARD WORK.IMSP S: A002 OK FIND completed The optional separator_chars argument specifies a set of separator characters. If the argument is specified the pattern must end with a "*" and that "*" will not match a character following a matched separator character. In addition, if any bboard names fail to match because of separator characters, the prefix names for those bboards are returned in unsolicited NONTERMINAL replies. Prefix names consist of the bboard name up to and including the separator character. No prefix name should be sent twice for a single FIND invocation. This can be used to limit the number of returned items based on client perceived namespace hierarchy. EXAMPLE: C: A002 FIND BBOARDS WORK.* ./ S: * NONTERMINAL WORK.CORRESPONDENCE. S: * BBOARD WORK.IMAP S: * BBOARD WORK.IMAP. S: * NONTERMINAL WORK.IMAP. S: * BBOARD WORK.IMSP S: A002 OK FIND completed tag FIND ALL.BBOARDS pattern [separator_chars] ... ... * NONTERMINAL mstring This response occurs as a result of a FIND command with the optional separator_chars argument. The string is a prefix string of a mailbox or bboard name. ... find_bboards ::= "FIND" SPACE "BBOARDS" SPACE find_pattern [SPACE separator_chars] find_bboards_all ::= "FIND" SPACE "ALL.BBOARDS" SPACE find_pattern [SPACE separator_chars] find_mailboxes ::= "FIND" SPACE "MAILBOXES" SPACE find_pattern [SPACE separator_chars] find_mailboxes_all ::= "FIND" SPACE "ALL.MAILBOXES" SPACE find_pattern [SPACE separator_chars] mailbox_data ::= "MAILBOX" SPACE mstring / "BBOARD" SPACE mstring / "NONTERMINAL" SPACE mstring / "SEARCH" SPACE 1#number / "FLAGS" SPACE flag_list separator_chars ::= astring ... The optional separator_chars argument to the FIND commands is new in IMAP2bis. A BAD response to a FIND command including the separator_chars argument indicates a server that does not support a concept of separator characters and non-terminals. The client may repeat the FIND command without the separator_chars argument, and filter the results itself. ---------------------------------- How a flat client works: Flat client does a: FIND MAILBOXES [default-prefix]* to get a list of all subscribed mailboxes and display them. How a hierarchical view client works: Hierarchical view client starts with: FIND MAILBOXES [default-prefix]* [default-separator-chars] to get a list of MAILBOXES and NONTERMINALs at the top level of "hierarchy". MAILBOXES are shown as mail folders that can be opened, NONTERMINALS are shown as "mailbox directories" (note that the separator character at the end of the NONTERMINAL must be shown to the user if there is more than one separator character). The [default-prefix] and [default-separator-chars] are client configuration issues From owner-imap@cac.washington.edu Mon Oct 25 12:07:15 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03347; Mon, 25 Oct 93 12:07:15 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07317; Mon, 25 Oct 93 12:06:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07307; Mon, 25 Oct 93 12:06:26 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id PAA25553; Mon, 25 Oct 1993 15:06:22 -0400 Received: via switchmail; Mon, 25 Oct 1993 15:06:22 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:05:44 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:05:41 -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, 25 Oct 1993 15:05:36 -0400 (EDT) Message-Id: Date: Mon, 25 Oct 1993 15:05:36 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Summary of issues on flatlander proposal Beak: is Not ---------------------------------- Issue 1 - doesn't work well with VMS There is no set of "separator characters" which always stops at the "right" place for dealing with VMS-style hierarchies. Proposals: A) Punt on the issue Pros: 1) VMS users don't have to use the mechanism--the mechanism does not preclude VMS. ---------------------------------- Issue 2 - default separator charaters It has been proposed that default separator characters shouldn't be dealt with as a client configuration issue, because some servers have a "natural" set of separator characters. Proposals: A) Leave it a client configuration issue. Pros: 1) Simplest solution, least protocol cruft. 2) IMSP would allow a consistant view between all clients. 3) Users would be free to use any hierarchy system they are comfortable with. 4) Clients already have to be configured to use the same default-prefix. Cons: 1) Without IMSP, different clients would have to have the separator characters set the same in order to get a consistant view. B) Add the following language (or similar) to the spec: If the separator_chars argument is the empty string (""), then the server's default separator characters (if any) will be used. Pros: 1) Allows clients to use "" as a hardcoded [default-separator-chars] configuration for a consistant default view. 2) Easily accommodates servers with different separator characters in different parts of the namespace. 3) Relatively simple change to proposal. Cons: 1) Might encourage client implementors to prevent user from being able to configure the separator characters. Users would then be stuck with one hierarchy system and could not use a more comfortable system. 2) Protocol cruft C) Have server send unsolicited cruft to client describing the server's "natural" separator characters. Pros: 1) Clients would have consistant default view. Cons: 1) Might encourage client implementors to prevent user from being able to configure the separator characters. Users would then be stuck with one hierarchy system and could not use a more comfortable system. 2) Protocol cruft, especially if different separator chars are allowed in different parts of the namespace. 3) Makes client startup code more complex. ---------------------------------- Issue 3 - Empty non-terminals There is a desire to be able to create "empty mailbox containers" ("empty non-terminals") which persist across sessions. The existing c-client drivers do not allow mailboxes to be created in directories which do not exist. This is not a limitation imposed by the protocol and should be considered a limitation or bug in c-client. The following proposals assume that c-client is modified to create directories as necessary. Proposals: A) Punt on the issue. Clients can present virtual "empty non-terminals" locally. If the user does not subsequently create a mailbox inside the non-terminal, the client may either discard the state at the end of the session, store it in IMSP, or store it locally. Pros: 1) Simplest solution. 2) In some namespaces, such as netnews, the concept of an empty non-terminal does not exist. Cons: 1) Client complexity required for handling empty non-terminals locally. 2) Non-terminals don't necessarily work the way most users think they should. 3) The c-client implementation must ensure that it does not inappropriately report an empty UNIX directory as a non-terminal. B) Add "CREATE.EMPTY.NONTERMINAL" and "DELETE.EMPTY.NONTERMINAL" style commands to the protocol. Depending on the exact proposal, the nonterminals may or may not persist after a mailbox is created inside of the nonterminal. Pros: 1) Hierarchical clients may create persistent "Empty mailbox containers" without handling virtual local state. Cons: 1) Adds lots of cruft to protocol. 2) In some namespaces, such as netnews, the concept of an empty non-terminal does not exist. 3) IMSP must know about the persistent "nonterminal" objects. 4) Servers must be able to create these objects even when they do not correspond to "natural" underlying directory-like objects. ---------------------------------- Issue 4 - Current FIND specification vs. c-client behavior. C-client currently does not recurse down directories when doing a FIND ALL.MAILBOXES--wildcards do not match the '/' character. There is concern over the performance and the number of mailboxes that would be returned should c-client be changed to match the specification. This problem is not specific to the flatlander propoasal. A "server exported hierarchy" proposal would have the exact same problem. A) Punt on the issue, fix c-client to match specificaton Pros: 1) Clients already have and use a mechanism to configure a default prefix (such as "‾/Mail/"), so the exposure is limited. 2) Those users who really do have hundreds of mailboxes can be reaonably expected to obtain a client which uses the new FIND facilities. Cons: 1) Old clients doing FIND on new servers could run excessively slow and/or display an excessive number of matches. B) It has been proposed to change the FIND specification to match c-client behavior. This would be something like: "Server implementations may choose to have "*" not match certain characters when used in FIND without the separator_chars argument." Pros: 1) Records the status quo. 2) Avoids problems with old clients doing FIND on new servers. Cons: 1) The c-client behavior is not internally consistent. FIND ALL.MAILBOXES does not recurse across "/", but FIND ALL.BBOARDS does recurse across ".". 2) This would essentially make FIND without the separator_chars argument a useless command. As "old FIND" is prohibited from sending "* NONTERMINAL" responses, there is no way of determining which replies correspond to nonterminals. 3) Would have to add a variant of FIND which really does recurse down directories. ---------------------------------- Top-level options: A) Flatlander Pros: 1) Relatively simple solution. 2) Offers limited transmission of FIND ALL.MAILBOXES namespace. 3) Provides simple mechanism for separator-character based hierarchy views in clients. 4) Easy to implement in IMSP server. Cons: 1) Method to add support for empty server filesystem directories is complex and confusing. 2) Does not provide mechanism for viewing complex (e.g. VMS) hierarchies. 3) May be somewhat confusing to client implementors. B) Full-blown server-exported hierarchy Pros: 1) Offers limited transmission of FIND ALL.MAILBOXES namespace. 2) Can provide mechanism for complex (e.g. VMS) hierarchies. 3) Provides simple mechanism for creation of empty server filesystem directories. Cons: 1) Major addition to protocol. 2) Adds a large number of commands useful to only a few clients. 3) Prevents users from using a hierarchy view they are comfortable with: only the server's view is available. 4) Requires IMSP server to do a complete recursive traversal of namespace and/or to be completely aware of the nature of the hierarchy on all client IMAP servers. 5) Unless support for complex hierarchies is removed, this may be somewhat confusing to client implementors. From owner-imap@cac.washington.edu Mon Oct 25 12:07:14 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03345; Mon, 25 Oct 93 12:07:14 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07311; Mon, 25 Oct 93 12:06:26 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07303; Mon, 25 Oct 93 12:06:22 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id PAA25545; Mon, 25 Oct 1993 15:06:18 -0400 Received: via switchmail; Mon, 25 Oct 1993 15:06:17 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:04:37 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:04:34 -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, 25 Oct 1993 15:04:27 -0400 (EDT) Message-Id: Date: Mon, 25 Oct 1993 15:04:27 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: full-blown server-exported-hierarchy proposal Beak: Is (Also written by Chris Newman) Hierarchy proposal V1.0: ---------------------------------- [Old FIND description unchanged for use by flat view clients] LIST commands The LIST commands return some set of unsolicited MAILBOX or BBOARD replies, depending on the type of LIST, that have as their value a single mailbox name. In addition LIST commands return some set of unsolicited DIRECTORY replies. Three wildcard characters are defined in the pattern argument. "*" specifies any number (including zero) non-hierarchical characters may match at this position. "%" and "?" specify a single non-hierarchical character may match at this position. For example, FOO*BAR will match FOOBAR, FOOD-ON-THE-BAR and FOO-BAR, whereas FOO%BAR and FOO?BAR match only FOO-BAR. "*" will match all mailboxes and directories at the top level of the hierarchy. On servers without internal hierarchy, LIST is identical to FIND. tag LIST MAILBOXES pattern The LIST MAILBOXES command accepts as an argument a pattern (including limited wildcards) that specifies some set of mailbox directories and mailbox names that the user has declared as being "active" or "subscribed". The exact meaning of this is implementation-dependent, since the concept of a set of "active" or "subscribed" mailboxes that is preserved across sessions may not be meaningful for a particular server or server implementation. If the SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX commands are implemented then this command returns the list manipulated by those commands. EXAMPLE: C: A002 LIST MAILBOXES * S: * MAILBOX FOOBAR S: * MAILBOX GENERAL S: * DIRECTORY GENERAL S: * DIRECTORY BLARTYBLOOP S: A002 OK LIST completed tag LIST ALL.MAILBOXES pattern The LIST ALL.MAILBOXES command is similar to LIST MAILBOXES; however, it should return a complete list of all mailboxes available to the user. Data are returned as in LIST MAILBOXES. The special name INBOX is included in the output from LIST ALL.MAILBOXES unless INBOX is not supported by this server or for this user. The criteria for omitting INBOX is whether SELECT INBOX will return failure; it is not relevant whether the user's real INBOX resides on this or some other server. LIST MAILBOXES and SUBSCRIBE MAILBOX provide a mechanism for the user to identify that this is his or her real INBOX. LIST ALL.MAILBOXES must, at least, return all the mailbox names that are returned by LIST MAILBOXES. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of "mailboxes available to the user" may not be meaningful for a particular server or server implementation. tag LIST BBOARDS pattern The LIST BBOARDS command accepts as an argument a pattern (including limited wildcards) that specifies some set of bboard directories and bboard names that the user has declared as being "active" or "subscribed". The exact meaning of this is implementation-dependent, since the concept of a set of "active" or "subscribed" bboards that is preserved across sessions may not be meaningful for a particular server or server implementation. If the SUBSCRIBE BBOARD and UNSUBSCRIBE BBOARD commands are implemented then this command returns the list manipulated by those commands. If wildcards are used in this command, they do not match hierarchy separator characters. EXAMPLE: C: A002 LIST BBOARDS * S: * BBOARD FOOBAR S: * BBOARD GENERAL S: * DIRECTORY GENERAL S: * DIRECTORY BLARTYBLOOP S: A002 OK LIST completed tag LIST ALL.BBOARDS pattern The LIST ALL.BBOARDS command is similar to LIST BBOARDS; however, it should return a complete list of all bboards available to the user. Data are returned as in LIST BBOARDS. The special name INBOX is included in the output from LIST ALL.BBOARDS unless INBOX is not supported by this server or for this user. The criteria for omitting INBOX is whether SELECT INBOX will return failure; it is not relevant whether the user's real INBOX resides on this or some other server. LIST BBOARDS and SUBSCRIBE BBOARD provide a mechanism for the user to identify that this is his or her real INBOX. LIST ALL.BBOARDS must, at least, return all the bboard names that are returned by LIST BBOARDS. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of "bboards available to the user" may not be meaningful for a particular server or server implementation. Other Hierarchy Commands The hierarchy commands (EXPANDPATH, JOINPATH, MKDIR, RMDIR, RENAMEDIR) convert between full pathnames and relative path components, and may be used to create, delete, and rename mailbox directories. These commands are only needed by clients which present the MAILBOX or BBOARD namespace in a hierarchial view. tag EXPANDPATH MAILBOX path This command converts the specified mailbox path into a root directory and a list of relative path components. It returns one unsolicited MAILBOX.PATH.ELEMENTS reply. EXAMPLE: C: A002 EXPANDPATH MAILBOX FOO.BAR.BAZ S: * MAILBOX.PATH.ELEMENTS (FOO BAR BAZ) S: A002 OK EXPANDPATH completed tag EXPANDPATH BBOARD path This command converts the specified bboard path into a root directory and a list of relative path components. It returns one unsolicited BBOARD.PATH.ELEMENTS reply. EXAMPLE: C: A002 EXPANDPATH BBOARD FOO.BAR.BAZ S: * BBOARD.PATH.ELEMENTS (FOO BAR BAZ) S: A002 OK EXPANDPATH completed tag JOINPATH MAILBOX path-element-list This command converts the specified mailbox path element list into a full path name and a full directory prefix usable in a LIST MAILBOXES command. It returns one unsolicited MAILBOX.PATH reply. EXAMPLE: C: A002 JOINPATH MAILBOX (FOO BAR BAZ) S: * MAILBOX.PATH (FOO.BAR.BAZ FOO.BAR.BAZ.*) S: A002 OK JOINPATH completed tag JOINPATH BBOARD path-element-list This command converts the specified bboard path element list into a full path name and a full directory prefix usable in a LIST BBOARDS command. It returns one unsolicited BBOARD.PATH reply. EXAMPLE: C: A002 JOINPATH BBOARD (FOO BAR BAZ) S: * BBOARD.PATH (FOO.BAR.BAZ FOO.BAR.BAZ.*) S: A002 OK JOINPATH completed tag MKDIR mailbox-directory-name The MKDIR command creates a mailbox directory with the given name. This command returns an OK response only if a new mailbox directory with that name has been created. It is an error to attempt to create a mailbox directory with a name that refers to an extant mailbox directory. Any error in creation will return a NO response. tag RMDIR mailbox-directory-name The RMDIR command deletes a mailbox directory with the given name. This command returns an OK response only if a mailbox directory with that name has been deleted. It is an error to attempt to delete a mailbox name that does not exist. Any error in deletion will return a NO response. The RMDIR command MUST delete a mailbox directory with no mailboxes or subdirectories. The RMDIR command SHOULD NOT permit deletion of a mailbox directory with mailboxes or subdirectories in it because this would be extremely destructive and the characteristics of the DELETE command prevent denial of service problems. tag RENAMEDIR old-mailbox-directory-name new-mailbox-directory-name The RENAMEDIR command changes the name of a mailbox directory. This command returns an OK response only if a mailbox directory with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old mailbox directory name that does not exist or a new mailbox directory name that already exists. Any error in renaming will return a NO response. ... * BBOARD.PATH bboard_path_pair This response occurs as a result of an EXPANDPATH BBOARD command. The bboard_path_pair is a list containing two elements. The first element is to full path to the object specified by the EXPANDPATH BBOARD list. The second element is that pattern that should be given to LIST BBOARDS or LIST ALL.BBOARDS in order to search the contents of a directory by the specified name. * BBOARD.PATH.ELEMENTS bboard_path_list This response occurs as a result of an EXPANDPATH BBOARD command. The bboard_path_list is a list with a bboard directory as the first element, and the names of successive subdirectories as the following elements. * DIRECTORY mstring This response occurs as a result of a LIST command. The string is a full path name to a mailbox directory or bboard directory. * MAILBOX.PATH mailbox_path_pair This response occurs as a result of an EXPANDPATH MAILBOX command. The mailbox_path_pair is a list containing two elements. The first element is to full path to the object specified by the EXPANDPATH MAILBOX list. The second element is that pattern that should be given to LIST MAILBOXES or LIST ALL.MAILBOXES in order to search the contents of a directory by the specified name. * MAILBOX.PATH.ELEMENTS mailbox_path_list This response occurs as a result of an EXPANDPATH MAILBOX command. The mailbox_path_list is a list with a mailbox directory as the first element, and the names of successive subdirectories as the following elements. ... bboard_directory ::= astring ;; should not include list_wildcards. May be ;; case-dependent as a function of server ;; implementation. May be different namespace ;; from mailbox_directory. bboard_path ::= mailbox_bboard / bboard_directory bboard_path_list ::= "(" bboard_path 0#(SPACE astring) ")" bboard_path_pair ::= "(" bboard_path SPACE bboard_pattern ")" bboard_pattern ::= astring ;; The pattern given to a LIST BBOARDS or LIST ;; ALL.BBOARDS command to show the contents of ;; a bboard directory. expandpath ::= expandpath_bboard / expandpath_mailbox expandpath_bboard ::= "EXPANDPATH" SPACE "BBOARD" SPACE bboard_path expandpath_mailbox ::= "EXPANDPATH" SPACE "MAILBOX" SPACE mailbox_path list ::= list_mailbox / list_bboard list_bboard ::= list_bboards / list_boards_all list_bboards ::= "LIST" SPACE "BBOARDS" SPACE list_pattern list_bboards_all ::= "LIST" SPACE "ALL.BBOARDS" SPACE list_pattern list_mailbox ::= list_mailboxes / list_mailboxes_all list_mailboxes ::= "LIST" SPACE "MAILBOXES" SPACE list_pattern list_mailboxes_all ::= "LIST" SPACE "ALL.MAILBOXES" SPACE list_pattern list_pattern ::= astring ;; includes list_wildcards list_wildcards ::= "%" / "?" / "*" mailbox_directory ::= astring ;; should not include list_wildcards. May be ;; case-dependent as a function of server ;; implementation. mkdir ::= "MKDIR" SPACE mailbox_directory mailbox_data ::= "MAILBOX" SPACE mstring / "BBOARD" SPACE mstring / "DIRECTORY" SPACE mstring / "SEARCH" SPACE 1#number / "FLAGS" SPACE flag_list / "MAILBOX.PATH.ELEMENTS" SPACE mailbox_path_list / "BBOARD.PATH.ELEMENTS" SPACE bboard_path_list / "MAILBOX.PATH" SPACE mailbox_path_pair / "BBOARD.PATH" SPACE bboard_path_pair mailbox_path ::= mailbox / mailbox_directory mailbox_path_list ::= "(" mailbox_path 0#(SPACE astring) ")" mailbox_path_pair ::= "(" mailbox_path SPACE mailbox_pattern ")" mailbox_pattern ::= astring ;; The pattern given to a LIST MAILBOXES or LIST ;; ALL.MAILBOXES command to show the contents of ;; a mailbox directory. renamedir ::= "RENAMEDIR" SPACE mailbox_directory request_authed ::= request_any / create / delete / rename / find / subscribe / unsubscribe / select / examine / bboard / append / list / expandpath / mkdir / rmdir / renamedir / x_command ;; valid only when in authenticated or mailbox open mode rmdir ::= "RMDIR" SPACE mailbox_directory ... The LIST MAILBOXES, LIST ALL.MAILBOXES, LIST BBOARDS, and LIST ALL.BBOARDS commands are new in imap2bis. Client implementations which receive a BAD response to these commands should use the appropriate FIND command instead. The MKDIR, RMDIR and RENAMEDIR commands are new in imap2bis. A BAD response to these commands indicates a server that does not support server based mailbox hierarchy. The EXPANDPATH MAILBOX, EXPANDPATH BBOARD, JOINPATH MAILBOX and JOINPATH BBOARD commands are new in imap2bis. A BAD response to these commands indicates a server that does not support server based mailbox or bboard hierarchies. ---------------------------------- From owner-imap@cac.washington.edu Mon Oct 25 12:44:35 1993 Received: from mx2.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04345; Mon, 25 Oct 93 12:44:35 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08392; Mon, 25 Oct 93 12:44:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08386; Mon, 25 Oct 93 12:44:00 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA05607; Mon, 25 Oct 1993 15:43:56 -0400 Received: via switchmail; Mon, 25 Oct 1993 15:43:54 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:41:54 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 15:41:52 -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, 25 Oct 1993 15:41:50 -0400 (EDT) Message-Id: Date: Mon, 25 Oct 1993 15:41:50 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Test Cyrus IMAPD available Beak: Is I have a snapshot of the current Cyrus IMAPD running on freehold.andrew.cmu.edu for interoperability testing. Log in as anonymous, any password. Commands which I haven't implemented yet are: SUBSCRIBE, UNSUBSCRIBE, EXPUNGE, COPY, UID COPY, RENAME, DELETE. All other commands are implemented to the level in the latest published IMAP2bis internet-draft. There is no mail delivery system running on the machine, to insert a message in a mailbox, you're going to have to APPEND it. Note that since EXPUNGE isn't implemented yet, there will be no way to remove any APPENDed messages. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Mon Oct 25 13:58:22 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07084; Mon, 25 Oct 93 13:58:22 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09373; Mon, 25 Oct 93 13:57:35 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09367; Mon, 25 Oct 93 13:57:33 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA19776; Mon, 25 Oct 93 13:57:27 PDT Date: Mon, 25 Oct 93 13:57:11 -0800 From: Adam Treister To: John Gardiner Myers Subject: Re: Summary of issues on flatlander proposal Cc: imap@cac.washington.edu Message-Id: In-Reply-To: Your message of Mon, 25 Oct 1993 15:05:36 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII Is there a provision in this scheme to support hierarchical representations that mix messages and folders together, like a file system does? I can't see how I can easily get that appearance from this method. OK, so I haven't really read the spec. I'll take a serious look at it tonight, but I wouldn't want that to stop me from shooting off my mouth! :) Call me an inveterate kludge, but I'd like to have references to other mail folders be supported as a special case of message. This would make it easier to support notions like intermixed folders and messages, multiple references to folders from various locations, transferring folders, etc... most of which the users have come to expect in a hierarchical space. I think Chris's proposal is the first step to what I'm asking for, and from what I've read of it, looks straightforward and sufficient, but if we're going to talk about "full-blown", lets really satisfy the users' expectations of hierarchy. Adam From owner-imap@cac.washington.edu Mon Oct 25 16:25:40 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12370; Mon, 25 Oct 93 16:25:40 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12469; Mon, 25 Oct 93 16:23:56 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12463; Mon, 25 Oct 93 16:23:53 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id TAA09823; Mon, 25 Oct 1993 19:23:49 -0400 Received: via switchmail; Mon, 25 Oct 1993 19:23:48 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 19:21:54 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 19:21:49 -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, 25 Oct 1993 19:21:47 -0400 (EDT) Message-Id: <8gn5y=C00WBw0q5t8K@andrew.cmu.edu> Date: Mon, 25 Oct 1993 19:21:47 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: "mixing" messages and folders together In-Reply-To: References: Beak: is Not Adam, I don't understand what you're saying. In IMAP and in filesystems, messages and mailboxes (files and directories) are different objects, with different sets of operations and different interactions with the authorization system. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Mon Oct 25 18:10:21 1993 Received: from mx1.cac.washington.edu by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16292; Mon, 25 Oct 93 18:10:21 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14660; Mon, 25 Oct 93 18:08:58 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14654; Mon, 25 Oct 93 18:08:53 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id VAA13850; Mon, 25 Oct 1993 21:08:50 -0400 Received: via switchmail; Mon, 25 Oct 1993 21:08:50 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 21:07:49 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 25 Oct 1993 21:07:46 -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, 25 Oct 1993 21:07:38 -0400 (EDT) Message-Id: Date: Mon, 25 Oct 1993 21:07:38 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Cyrus imapd error cases Beak: is Not At the last IMAP WG, it was decided that "an effort will be made to identify some common error cases..." Here is listing of the various error cases in the Cyrus imapd, minus errors which are specific to private protocol extensions. I haven't implemented all of the commands, so some of these are conjectures based on the current design. Errors which only occur while performing certain commands include a list of those commands. I have grouped some errors I consider to be in the same category. I have not identified or selected any set of categories for identification with a special-information token. ------------------------------ Tagged NO responses: invalid user (LOGIN) anonymous login not permitted wrong password (various Kerberos errors) permission denied over quota (APPEND, COPY) too many user flags in mailbox (STORE) mailbox does not exist (SELECT, EXAMINE, BBOARD, APPEND, COPY, DELETE, RENAME) ([TRYCREATE] is a particular instance of this condition) mailbox already exists (CREATE, RENAME) invalid mailbox name (CREATE, RENAME) message has an invalid format (APPEND) already subscribed to mailbox (SUBSCRIBE) not subscribed to mailbox (UNSUBSCRIBE) someone is reading mailbox with POP3 (EXPUNGE) I/O error mailbox has an invalid format operation not supported on mailbox (these are indicative of a hardware failure, database inconsistency, or configuration problem. The condition is similar to [PARSE] token) Unsolicited NO responses: Mailbox is over quota (SELECT, EXAMINE, BBOARD) Mailbox is at X% of quota (SELECT, EXAMINE, BBOARD) Message no longer exists (FETCH) Unable to preserve ¥Seen state (SELECT, EXAMINE, BBOARD) Unable to checkpoint ¥Seen state (CHECK, NOOP, APPEND, COPY, close mailbox) (these are indicative of a hardware failure, database inconsistency, or configuration problem.) Unsolicited BYE responses: Server terminating connection (LOGOUT) Configuration error (connection, LOGIN) I/O error Can't read mailbox list Virtual memory exhausted From owner-imap@cac.washington.edu Tue Oct 26 09:22:26 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA25514; Tue, 26 Oct 93 09:22:26 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23857; Tue, 26 Oct 93 09:21:06 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23851; Tue, 26 Oct 93 09:21:03 -0700 Received: from scapa.cs.ualberta.ca by scapa.cs.ualberta.ca with UUCP id <18640>; Tue, 26 Oct 1993 10:20:41 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Tue, 26 Oct 93 10:01 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0orqsj-000ctMC; Tue, 26 Oct 93 10:04 MDT Date: Tue, 26 Oct 1993 10:04:21 -0600 From: Steve Hole Subject: Re: name space proposals To: IMAP Discussion Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I was able to read through the two proposals last night. I was quite impressed with the thought that went into them. I would like to enter a vote (if we are voting) for the flatlander proposal. It provides the client with the consistent view that I wanted, without adding lots of "cruft" to the protocol, or imposing the namespace representation restrictions that Mark objected to. It would certainly be easy to implement inside of ECSMail and the c-client. Because ECSMail is GUI based, many of the client issues revolving around pathname representation don't really affect us anyway. As long as the returned values from the server are consistent, then we are happy. I really like this. As far as the specific issues relating to the flatlander proposal go, I am quite flexible on all of them. As long as non-terminals are handled in such a way as they can be created at will - either directly or indirectly when a mailbox is created - I am happy. 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-imap@cac.washington.edu Tue Oct 26 10:10:17 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA26890; Tue, 26 Oct 93 10:10:17 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24719; Tue, 26 Oct 93 10:09:24 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24711; Tue, 26 Oct 93 10:09:22 -0700 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA08019; Tue, 26 Oct 93 10:09:12 PDT Date: Tue, 26 Oct 93 10:08:54 -0800 From: Adam Treister To: John Gardiner Myers Subject: Re: "mixing" messages and folders together Cc: imap@cac.washington.edu Message-Id: In-Reply-To: Your message <8gn5y=C00WBw0q5t8K@andrew.cmu.edu> of Mon, 25 Oct 1993 19:21:47 -0400 (EDT) Content-Type: TEXT/plain; charset=US-ASCII > Adam, I don't understand what you're saying. In IMAP > and in filesystems, messages and mailboxes (files and > directories) are different objects, with different sets > of operations and different interactions with the > authorization system. I'll try not to belabor the point, cuz I don't want to impede the very positive progress this proposal represents, but... As a (mac) user I have folders and documents. If I'm organizing my work I create a folder right in the middle of my document space (desktop) and start dragging documents and folders into it. They are very close to the same objects, with the exception that folders support containment. Most operations (Open, Get Info, Drag, Trash, Create Alias) work consistently. In the mail arena, Apple has AOCE, which makes the Finder into the mail browser. It provides a hierarchical space with all of the abilities to include aliases to files, drag selections into folders etc. The user can drag an attachment out of the message and onto a desktop folder, and the system spans the worlds. Hard to know if it'll catch on, or if I want it to (there are drawbacks of the Finder as a mail browser), but the integration of email into the users work space with nothing more than a mailbox icon on the desktop is a most laudable design. Adam From owner-imap@cac.washington.edu Tue Oct 26 18:52:39 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10789; Tue, 26 Oct 93 18:52:39 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17757; Tue, 26 Oct 93 18:50:28 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17751; Tue, 26 Oct 93 18:50:26 -0700 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA03815; Tue, 26 Oct 93 18:50:20 -0700 Date: Tue, 26 Oct 1993 18:46:59 -0700 (PDT) From: Mark Crispin Subject: Re: name space proposals To: Steve Hole Cc: IMAP Discussion In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 26 Oct 1993, Steve Hole wrote: > I would like to enter a vote (if we are voting) for the flatlander proposal. > It provides the client with the consistent view that I wanted, without adding > lots of "cruft" to the protocol, or imposing the namespace representation > restrictions that Mark objected to. For the record, I also vote for either the CMU flatlander proposal or an even simpler alternative that I suggested in e-mail to CMU (and which I think they are preparing for a strawman). I also agree with Steve that the flatlander proposal provides the desired functionality and is MUCH simpler to implement in both clients and servers. From owner-imap@cac.washington.edu Wed Oct 27 23:34:48 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14891; Wed, 27 Oct 93 23:34:48 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28261; Wed, 27 Oct 93 23:34:05 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28255; Wed, 27 Oct 93 23:34:03 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11332; Wed, 27 Oct 93 23:34:03 -0700 Date: Wed, 27 Oct 1993 23:29:05 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: By way of building an agenda... To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII for next week's Working Group mtg: here are some of the issues I'm aware of. Please let me know if your favorite is missing. -How to support hierarchy. -Extended search. (Define in imap2bis, or defer to separate RFC?) -Definition of additional special information tokens for error conditions. -Mstring grammar. -Global vs. private flags... consistency across servers/clients -RFC-1522 search strings. Is current spec wording OK? -Namespace/driver selection, especially for non-filesystem drivers. -How useful is the BBOARD construct? -How useful are the selective header constructs (vs. fetch 822 and grep)? -Is UID AFTER now superfluous? -Should "IMAP" == "Internet Message Access Protocol" -teg From owner-imap@cac.washington.edu Thu Oct 28 08:00:25 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA21293; Thu, 28 Oct 93 08:00:25 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02467; Thu, 28 Oct 93 07:59:47 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02461; Thu, 28 Oct 93 07:59:46 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA16881; Thu, 28 Oct 93 07:59:43 -0700 Date: Thu, 28 Oct 1993 07:55:55 -0700 (PDT) From: Terry Gray Subject: Re: By way of building an agenda... To: Karl Jacob Cc: imap@cac.washington.edu In-Reply-To: < Roam 1.0.6alpha 751818700.16838.karlj.dobbs > Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I must be behind in my mailing list reading... :-(. When and > where is the meeting? Karl-- A thousand pardons. I incorrectly assumed everyone knew about the IETF meeting next week. It is in Houston (Sheraton Astrodome?) all week. We have scheduled sessions on Mon and Tues for IMAP. (Note that the IETF mtg conflicts with Email World in San Jose...) If anyone needs any of the IETF announcements, let me know and I'll forward. -teg From owner-imap@cac.washington.edu Thu Oct 28 11:03:33 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA26242; Thu, 28 Oct 93 11:03:33 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29803; Thu, 28 Oct 93 11:02:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29797; Thu, 28 Oct 93 11:02:48 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id OAA07437; Thu, 28 Oct 1993 14:02:44 -0400 Received: via switchmail; Thu, 28 Oct 1993 14:02:43 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 28 Oct 1993 14:01:10 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 28 Oct 1993 14:01:04 -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, 28 Oct 1993 14:00:49 -0400 (EDT) Message-Id: Date: Thu, 28 Oct 1993 14:00:49 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Extended search thoughts Beak: Is I intended to finish writing this up earlier, but I've been sick the last two days. Looking over the notes from the last WG meeting on extended search, I see three basic categories: 1. New things to search for: Be able to search on Composed DATE Be able to search on Received DATE Be able to search on MessageID Be able to search on general header text 2. New facilities: NOT operator Deprecate "UN..." constructs OR operator operator grouping If not regular expressions, at least wild cards in strings 3. Things we don't know how to do: Better international searching I would also add "Be able to search on msgno" to category 1. Here are strawman proposals for the first two categories. As I don't know how to do category 3, I do not include a corresponding proposal for it. Proposal 1: add to FETCH data items: RECEIVEDDATE The date and time of the message's final delivery. add to SEARCH criteria: HEADER header_line istring Messages that have a header with a field-name (as defined in RFC 822) of header_line and which contains the specified string in the field-body. MSGNOAFTER number Messages that have a message number greater than or equal to the specified number. MSGNOBEFORE number Messages that have a message number less than the specified number. RECEIVEDBEFORE date Messages whose received date is earlier than the specified date. RECEIVEDON date Messages whose received date is within the specified date. RECEIVEDSINCE date Messages whose received date is within or later than the specified date. SENTBEFORE date Messages whose Date: header is earlier than the specified date. SENTON date Messages whose Date: header is within the specified date. SENTSINCE date Messages whose Date: header is within or later than the specified date. add to search -- "HEADER" SPACE header_line SPACE istring / "MSGNOAFTER" SPACE number / "MSGNOBEFORE" SPACE number / "RECEIVEDBEFORE" SPACE date / "RECEIVEDON" SPACE date / "RECEIVEDSINCE" SPACE date / "SENTON" SPACE date / "SENTBEFORE" SPACE date / "SENTSINCE" SPACE date) add to msg_fetch -- "RECEIVEDDATE" SPACE date_time / add to fetch_att_other -- "RECEIVEDDATE" Proposal 2: (incorporate proposal 1) tag SEARCH search_program The SEARCH command searches the mailbox for messages that match the given search program. A search program is a set of criteria optionally followed by the token "OR" and another search program. The unsolicited SEARCH response from the server is a list of messages that either express the intersection (AND function) of all the messages that match the criteria or match the search program following the "OR" token. For example, A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 returns the message numbers for all deleted messages from Smith that were placed in the mail file since October 1, 1987. In all search criteria that use strings, a message matches the criteria if the string is a substring of the field. The matching is case-independent except as noted below. The server may interpret an RFC 1522 format string to express text in a character set other than US-ASCII. The criteria matches if the RFC 1522 interpreted string matches an interpreted substring (MIME or RFC 1522 as appropriate) of the field. A server implementation may omit case-independent matching on RFC 1522 strings. The currently defined search criteria are: ( search_program ) Messages which match the specified search program. NOT search_criteria Messages which do not match the specified search criteria. NOT may not be used before a parentesized search program or an obsolecent search criteria ("NEW", "OLD", starts with "UN", ends with either "AFTER" or "SINCE"). PATTERN search_criteria Same as search_criteria (which must be one of BCC, FROM, BODY, CC, HEADER, SUBJECT, TEXT, or TO) except the message matches the criteria if the field matches the string as a pattern (including wildcards). search ::= "SEARCH" SPACE search_program search_program ::= 1#search_and *( SPACE "OR" SPACE search_program ) search_and ::= "(" SPACE search_program SPACE ")" / "NOT" SPACE search_item / search_item / search_item_old search_item ::= "ALL" / "ANSWERED" / "BEFORE" SPACE date / "DELETED" / "FLAGGED" / "KEYWORD" SPACE user_flag / "ON" SPACE date / "RECENT" / "SEEN" / "UIDBEFORE" SPACE uniqueid / "MSGNOBEFORE" SPACE number / "RECEIVEDBEFORE" SPACE date / "RECEIVEDON" SPACE date / "SENTBEFORE" SPACE date / "SENTON" SPACE date / search_text / "PATTERN" SPACE search_text search_item_old ::= "MSGNOAFTER" SPACE number / "NEW" / "OLD" / "RECEIVEDSINCE" SPACE date / "SENTSINCE" SPACE date / "SINCE" SPACE date / "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / "UNKEYWORD" SPACE user_flag / "UNSEEN" / "UIDAFTER" SPACE uniqueid search_text ::= "BCC" SPACE istring / "FROM" space istring / "BODY" SPACE istring / "CC" SPACE istring / "HEADER" SPACE header_line SPACE istring / "SUBJECT" SPACE istring / "TEXT" SPACE istring / "TO" SPACE istring Alternative proposal A: Replace MSGNOAFTER, MSGNOBEFORE, UIDAFTER, and UIDBEFORE with: MSGNO sequence Messages whose message number is in the specified sequence. UID sequence Messages whose UID is in the specified sequence. Alternative proposal B: Remove RECEIVEDDATE, change the definition of INTERNALDATE to match RECEIVEDDATE. Alternative proposal C: If both proposasls 1 and 2 are done at the same time, the MSGNOAFTER, RECEIVEDSINCE, and SENTSINCE criteria can be dropped. If they are done for IMAP2bis, UIDAFTER may be dropped as well. From owner-imap@cac.washington.edu Thu Oct 28 13:12:21 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA01031; Thu, 28 Oct 93 13:12:21 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00889; Thu, 28 Oct 93 13:11:28 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00883; Thu, 28 Oct 93 13:11:26 -0700 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA06408; Thu, 28 Oct 93 13:11:18 -0700 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA05935; Thu, 28 Oct 93 13:11:08 -0700 Date: Thu, 28 Oct 1993 12:21:43 -0700 (PDT) From: Mark Crispin Subject: re: Extended search thoughts To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Some paper airplanes to toss: I don't think that MSGNO[AFTER | BEFORE | ] is needed. It should be alright just to add sequences as a search qualifier, with UID as a modifier to say that the following sequence are uids and not message numbers. The advantage of sequences is that this permits logical operations that were overlooked, since you can more easily mesh in previous and subsequent results. UIDBEFORE may be obsoleted by UID sequence, but I don't think that UIDAFTER is. The reason is that you may not know the largest UID without having to fetch it with a prior operation. PATTERN worries me. This can be seriously SLOW if it is not cautiously implemented. Done right, it shouldn't be significantly slower than a regular text search. The question is, how important is it given the risk? -- Mark -- From owner-imap@cac.washington.edu Thu Oct 28 16:00:39 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA06381; Thu, 28 Oct 93 16:00:39 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12698; Thu, 28 Oct 93 15:59:50 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from yarrina.connect.com.au by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12692; Thu, 28 Oct 93 15:59:45 -0700 Received: from bushwire.apana.org.au by yarrina.connect.com.au with SMTP id AA21310 (5.67a8/IDA-1.5 for ); Fri, 29 Oct 1993 08:58:48 +1000 Received: from localhost (markd@localhost) by bushwire.apana.org.au (8.6.3/md2) id IAA05275; Fri, 29 Oct 1993 08:58:41 +1000 Date: Fri, 29 Oct 1993 08:50:36 +1000 (EST) From: Mark Delany Subject: Sorry to bother - I'd like a clarification on UIDs Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi. Sorry if this has been worked over before, I'm seeking a clarification on the optional UIDs introduced in the draft spec. My questions are: o How unique is UID meant to be? o Who will typically generate them? o The definition implies any string, but the examples suggest numeric only, is it any string? For example, in a news posting would (or could) the Message-ID generally double as a UID? My questions revolve around the (potential) desire to synchronize my mailboxes on two separate IMAP servers - strictly through the IMAP protocol. If UIDs are supported by the servers in question is it a reasonable expectation that I can synchronize the two mailboxes by comparing UIDs on each system and exchange messages between the two imap servers by FETCHing and APPENDing? (Yes, expunging presents problems, but I'd like to keep that separate from this question if I may). For News if the Message-ID of the article was used as the basis for the UID, I would feel that to be sufficient because News S/W has to generate good unique IDs to function properly. For mail though, I feel less comfortable about using any Message-Id that may be in the rfc822 headers. I am less comfortable because I often see mail - especially from PC mail programs - that generate a fixed message-ID, or they use message ID sequences that restarts at zero when the PC is rebooted. I conclude that the preconditions needed to synchronize new messages are: o Server support for UIDS o News messages use their exiting Message-IDs as UIDs (though I'm not really considering News for my particular requirements). o Mail messages are allocated a UID by IMAP on delivery or when first noticed in the INBOX as the confidence level of the rfc822 Message-ID is too low. In conclusion, is my expectation reasonable, and if so what have I missed? Regards, Mark D. From owner-imap@cac.washington.edu Thu Oct 28 18:42:12 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10506; Thu, 28 Oct 93 18:42:12 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02777; Thu, 28 Oct 93 18:41:31 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mail.nada.kth.se by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02771; Thu, 28 Oct 93 18:41:28 -0700 Received: from cyklop.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA12887; Fri, 29 Oct 93 02:41:26 +0100 Message-Id: <9310290141.AA12887@nada.kth.se> To: imap@cac.washington.edu Subject: Re: Extended search thoughts In-Reply-To: Your message of "Thu, 28 Oct 1993 14:00:49 -0400." Date: Fri, 29 Oct 1993 02:41:22 +0100 From: Peter Svanberg Quoting John Gardiner Myers > Proposal 1: > > add to FETCH data items: > > RECEIVEDDATE The date and time of the message's final delivery. Yes! > add to SEARCH criteria: > RECEIVEDBEFORE date > Messages whose received date is earlier than the > specified date. 1) Is it never interesting to further specify the criteria with time? I think it is (looking at my own mail load ;-)). I suggest date_opt_time instead of date, with date_opt_time ::= date_new [SPACE time_optres [SPACE zone]] time_optres ::= 2DIGIT [":" 2DIGIT [":" 2DIGIT]] ;; hours minutes seconds i.e. optional time and, if time, optional time resolution and zone. 2) Time zone handling must be specified. Suggestion: When no zone (no time) is specified, date and time (time= 0-24) in the zone given in the specified data item is used, i.e. the servers time zone for RECEIVED dates and the senders time zone for SENT dates. 3) Editorial note: Couldn't the date_year_old alternative be removed from the date_year line, as there is already a choice between them on the previous level (date_new/date_old)? Other search issues 4) Would it be interesting to search on fields in the parts of a Multipart message (for exampel Multipart/Digest), to easily choose which parts to fetch? (I havn't read about the new MIME handling sufficiently to tell.) 5) How about case-sensitive searching? It is sometimes interesting (find references to paper BYTE but not all other "byte" strings), is easy to implement and users are used to be able to do it. (I'll return on the 1522 issue.) --- 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-imap@cac.washington.edu Thu Oct 28 21:42:50 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12445; Thu, 28 Oct 93 21:42:50 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03449; Thu, 28 Oct 93 21:42:21 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03443; Thu, 28 Oct 93 21:42:19 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07170; Thu, 28 Oct 93 21:42:12 -0700 Date: Thu, 28 Oct 1993 19:01:03 -0700 (PDT) From: Mark Crispin Subject: Re: Extended search thoughts To: Peter Svanberg Cc: IMAP Interest List In-Reply-To: <9310290141.AA12887@nada.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 29 Oct 1993 02:41:22 +0100, Peter Svanberg wrote: > 1) Is it never interesting to further specify the criteria with > time? > 2) Time zone handling must be specified. Suggestion: Time zones are exactly why the search dates don't include time. Time is a remarkably flaky concept because of timezone inconsistency. My own feeling is that whenever practical, an implementation should try to canonicalize times to the ``local'' timezone (hopefully the client's, but more likely the server's in most implementations). This wasn't really a problem with INTERNALDATE, since pretty much by definition it had to be the server's local timezone. Is the user benefit of including the time really worth the pain of implementing it? This sounds to me like one of these ``gee-whiz'' features that would be a lot of work for fairly little benefit. > 3) Editorial note: Couldn't the date_year_old alternative be > removed from the date_year line, as there is already a > choice between them on the previous level (date_new/date_old)? The date/time grammar has been rewritten since the last draft. I'll have a few hardcopies with me at IETF. > 4) Would it be interesting to search on fields in the parts of > a Multipart message (for exampel Multipart/Digest), to > easily choose which parts to fetch? (I havn't read about the > new MIME handling sufficiently to tell.) That's an entirely new functionality, that requires resolution at the message part level rather than the message level. By all means propose a strawman of how this would be done. > 5) How about case-sensitive searching? It is sometimes > interesting (find references to paper BYTE but not all other > "byte" strings), is easy to implement and users are used to > be able to do it. Once again, the question comes up whether it would be worth the cost of implementing it. Case-sensitive searching is easier than case-insensitive searching, but if you're using any sort of fast searching algorithm this means that you'll end up having two separate routines for searching, one which is case-dependent, one which is case-independent. I'd hate to create an implementation burden like this if it isn't going to be used frequently. Other comments? Remember, it's important that we have a specification in which it is reasonable to require that everything be fully implemented. From owner-imap@cac.washington.edu Thu Oct 28 22:51:37 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13207; Thu, 28 Oct 93 22:51:37 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03720; Thu, 28 Oct 93 22:51:13 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03714; Thu, 28 Oct 93 22:51:12 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07246; Thu, 28 Oct 93 22:51:11 -0700 Date: Thu, 28 Oct 1993 22:46:43 -0700 (PDT) From: Mark Crispin Subject: new IMAP2bis draft To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I have just submitted the latest and greatest IMAP2bis document as an Internet draft. For the most part, it consists of minor editorial corrections from the previous draft, mostly to correct grammar bugs discovered by John Myers. Hardcopies should be available at the working group meeting at IETF. I apologize for the lateness of getting this out. There will undoubtably be another draft after the working group meeting! ;-) -- Mark -- From owner-imap@cac.washington.edu Thu Oct 28 23:01:24 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13304; Thu, 28 Oct 93 23:01:24 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03755; Thu, 28 Oct 93 23:01:02 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03731; Thu, 28 Oct 93 23:00:59 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07273; Thu, 28 Oct 93 23:00:58 -0700 Date: Thu, 28 Oct 1993 23:00:23 -0700 (PDT) From: Mark Crispin Subject: new IMAP2bis draft To: IMAP Interest List Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII ..is only on ftp.cac.washington.edu as mail/imap2bis-draft-02.txt, which is presumably also its name in the Internet Drafts directory. From owner-imap@cac.washington.edu Fri Oct 29 02:45:45 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16635; Fri, 29 Oct 93 02:45:45 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04657; Fri, 29 Oct 93 02:45:14 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04648; Fri, 29 Oct 93 02:44:16 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA07703; Fri, 29 Oct 93 02:36:59 -0700 Date: Fri, 29 Oct 1993 02:24:19 -0700 (PDT) From: Mark Crispin Subject: re: Sorry to bother - I'd like a clarification on UIDs To: Mark Delany Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 29 Oct 1993 08:50:36 +1000 (EST), Mark Delany wrote: > Sorry if this has been worked over before, I'm seeking a clarification > on the optional UIDs introduced in the draft spec. UIDs are not optional; they are merely new. Any implementation which does not support UIDs is not a full implementation of the protocol and should be upgraded as soon as possible. > o How unique is UID meant to be? A UID is (permanently) unique to that message in that mailbox. UIDs do not need to be globally unique.; > o Who will typically generate them? UIDs will probably be generated by the server as a function of the server's filestore. Once assigned they are permanent; they may not be reassigned to another message in that mailbox even if the assigned message for that UID is expunged. They must be strictly ascending within the mailbox. This has the implication that when a message is copied to another mailbox it will be assigned a new UID. > o The definition implies any string, but the examples > suggest numeric only, is it any string? The current draft (available on ftp.cac.washington.edu via anonymous ftp as mail/imap2bis-draft-02.txt) defines UIDs as being numeric. > For example, in a news posting would (or could) the Message-ID > generally double as a UID? No. Message-ID's are not numeric, and are not strictly ascending within the mailbox. The Message-ID might be used to assist in the generation of a UID. > If UIDs are supported by the servers in question is it a reasonable > expectation that I can synchronize the two mailboxes by comparing UIDs on > each system and exchange messages between the two imap servers by FETCHing > and APPENDing? (Yes, expunging presents problems, but I'd like to keep > that separate from this question if I may). Everything is reasonable up to the APPEND part. Basically, there is no way to set the UID of a remote message. So, the synchronization procedure needs to be done on a client/server basis. If you think about this, you'll see that it's hard to do bidirectional (as opposed to client/server) synchronization. What keeps the two servers from independently assigning the same UID to two different messages? The UID/disconnected-use experts can probably discuss this in more detail, including perhaps assisting you with some synchronization algorithms. I think you have more or less the right idea though. From owner-imap@cac.washington.edu Fri Oct 29 08:57:20 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA22458; Fri, 29 Oct 93 08:57:20 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23656; Fri, 29 Oct 93 08:56:27 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23648; Fri, 29 Oct 93 08:56:24 -0700 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18507-2>; Fri, 29 Oct 1993 09:56:16 -0600 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Fri, 29 Oct 93 09:32 MDT Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0osvrt-000cw0C; Fri, 29 Oct 93 09:36 MDT Date: Fri, 29 Oct 1993 09:35:54 -0600 From: Steve Hole Subject: Re: new IMAP2bis draft To: Mark Crispin Cc: IMAP Interest List Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 28 Oct 1993 23:46:43 -0600 Mark Crispin wrote: > From: Mark Crispin > Date: Thu, 28 Oct 1993 23:46:43 -0600 > Subject: new IMAP2bis draft > To: IMAP Interest List > What ever happened to the IMAP Quota extensions strawman that John proposed some time ago? I found them to be rather good, and it certainly will provide a management feature that we really need. Any word on incorporating them or the flatworlder stuff into the IETF discussions? Is there any plan for incorporating them into the IMAP2bis draft? 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-imap@cac.washington.edu Fri Oct 29 09:35:49 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23766; Fri, 29 Oct 93 09:35:49 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24675; Fri, 29 Oct 93 09:35:09 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24669; Fri, 29 Oct 93 09:35:03 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12887; Fri, 29 Oct 93 09:35:00 -0700 Date: Fri, 29 Oct 1993 09:15:48 -0700 (PDT) From: Terry Gray Subject: Re: new IMAP2bis draft To: Steve Hole Cc: Mark Crispin , IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > What ever happened to the IMAP Quota extensions strawman that John proposed > some time ago? I found them to be rather good, and it certainly will > provide a management feature that we really need. Any word on incorporating > them or the flatworlder stuff into the IETF discussions? Is there any plan > for incorporating them into the IMAP2bis draft? Steve, I'll let Mark respond on the quota stuff, as I don't know the answer, but I'd like to make a comment on the hierarchy support issue. I had hoped that we could have closed on that by now, or certainly by the end of the WG meeting... but I have just learned that a counter-proposal (or maybe a compromise proposal?) is in the works, but not quite ready yet. As WG chair, my problem is to make sure that all viewpoints get a fair hearing, and to try to nudge toward mutually acceptable compromises. In this case, I find myself in the position of trying to balance the interests of those who vehemently believe that it is lunacy to do anything other than flatlander, and those who vehemently believe that it is lunacy to not have some modicum of hierarchy support in the protocol. That wouldn't be so bad, except that the latter group appears to be far more reticient to voice their position than the former group... at least most of what I hear from them is via private communication rather than messages to the list. Anyway, I'm very grateful to Chris and John for all of their efforts to move us ahead on this, and hope that their "strawpersons" will prompt additional constructive thinking. This is a very important issue, and I want to encourage *everyone* to participate in resolving it. (And I will continue to encourage everyone to express their views openly, but will also endeavor to give a voice to the shy ones.) -teg From owner-imap@cac.washington.edu Fri Oct 29 10:26:18 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA25289; Fri, 29 Oct 93 10:26:18 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25644; Fri, 29 Oct 93 10:25:30 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25638; Fri, 29 Oct 93 10:25:27 -0700 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA02314 (5.67a/IDA-1.5 for ); Fri, 29 Oct 1993 12:25:01 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA02814 (5.65c/IDA-1.4.4 for IMAP@cac.washington.edu); Fri, 29 Oct 1993 12:26:43 -0500 Message-Id: <199310291726.AA02814@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Oct 1993 12:25:58 -0500 To: From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: new IMAP2bis draft At 9:15 AM 10/29/93 -0700, Terry Gray wrote: >this case, I find myself in the position of trying to balance the >interests of those who vehemently believe that it is lunacy to do anything >other than flatlander, and those who vehemently believe that it is lunacy >to not have some modicum of hierarchy support in the protocol. I'm currently evaluating IMAP for possible support by our mail user agents (Eudora, for Mac and Windows). As a newcomer to this list, I can't argue cogently about the two alternatives, but it would really suck rocks (to use a technical term) for this issue to remain unresolved. Not being able to use a hierarchical system would be a very big minus in my book. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Fri Oct 29 11:16:44 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA26737; Fri, 29 Oct 93 11:16:44 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26613; Fri, 29 Oct 93 11:15:47 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26604; Fri, 29 Oct 93 11:15:41 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17949; Fri, 29 Oct 93 11:15:35 -0700 Date: Fri, 29 Oct 1993 11:14:51 -0700 (PDT) From: Terry Gray Reply-To: Terry Gray Subject: Re: new IMAP2bis draft To: Steve Dorner Cc: IMAP@cac.washington.edu In-Reply-To: <199310291726.AA02814@dorner.slip.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 29 Oct 1993, Steve Dorner wrote: > Not being able to > use a hierarchical system would be a very big minus in my book. Steve, There is unanimity that clients must be able to present a hierarchical namespace to users; the debate is over how to do that. In a nutshell, the two views are: 1. At the protocol level, always communicate with the server via fully qualified names, and provide a way for the client to limit the "depth" of searches when doing a FIND. This implies that the notion of hierarchy is mostly in the "eye of the client", as there would be no notion of (for example) changing directories built into the protocol. (Those holding this view do not seek to preclude hierarchy at the MUA level, but believe the issue is best left to the client to figure out what hierarchy means and how to present it to the user, since the natural hierarchy of the server may not be the one the client wants to present.) OR: 2. Make it easy for a client to take advantage of the "natural" hierarchy that may be available on a server by including primitives such as change directory, etc. (Those holding this view do not seek to preclude "flatlander" implementations, but only to make it easy to use the native server hierarchy in a consistent way across clients.) -teg From owner-imap@cac.washington.edu Fri Oct 29 13:09:55 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA00162; Fri, 29 Oct 93 13:09:55 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07864; Fri, 29 Oct 93 13:08:46 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07858; Fri, 29 Oct 93 13:08:44 -0700 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id QAA08405; Fri, 29 Oct 1993 16:08:39 -0400 Received: via switchmail; Fri, 29 Oct 1993 16:08:36 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 16:08:31 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 16:08: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; Fri, 29 Oct 1993 16:08:24 -0400 (EDT) Message-Id: Date: Fri, 29 Oct 1993 16:08:24 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: "mixing" messages and folders together In-Reply-To: References: Beak: is Not I've takin a cursory look at AOCE and it appears that there is only one mailbox-equivalent, your inbox. There are flags and restricted views of that inbox, but there's no hierarchy. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Oct 29 13:13:09 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA00258; Fri, 29 Oct 93 13:13:09 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29055; Fri, 29 Oct 93 13:12:35 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29049; Fri, 29 Oct 93 13:12:32 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id QAA29305; Fri, 29 Oct 1993 16:12:23 -0400 Received: via switchmail; Fri, 29 Oct 1993 16:12:22 -0400 (EDT) Received: from nifty.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 16:12:16 -0400 (EDT) Received: via niftymail; Fri, 29 Oct 1993 16:12:12 -0400 (EDT) Date: Fri, 29 Oct 1993 16:12:10 -0400 (EDT) From: Chris Newman Subject: Re: new IMAP2bis draft To: Steve Dorner Cc: IMAP@cac.washington.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <751925530.28804.0@nifty.andrew.cmu.edu> Terry Gray writes: > There is unanimity that clients must be able to present a hierarchical > namespace to users; the debate is over how to do that. In a nutshell, > the two views are: > > 1. At the protocol level, always communicate with the server via fully > qualified names, and provide a way for the client to limit the "depth" > of searches when doing a FIND. This implies that the notion of > hierarchy is mostly in the "eye of the client", as there would be > no notion of (for example) changing directories built into the protocol. > (Those holding this view do not seek to preclude hierarchy at the MUA > level, but believe the issue is best left to the client to figure out > what hierarchy means and how to present it to the user, since the natural > hierarchy of the server may not be the one the client wants to present.) > > OR: > > 2. Make it easy for a client to take advantage of the "natural" > hierarchy that may be available on a server by including primitives > such as change directory, etc. (Those holding this view do not > seek to preclude "flatlander" implementations, but only to make it > easy to use the native server hierarchy in a consistent way across > clients.) I think a sense of "current directory" with reference to the protocol is orthogonal to the issue. If the protocol doesn't provide a "set-prefix" or "change directory" command, it can always be kept as client state. Let me see if I can describe the two camps as I see them: Flatlander -- This is basically the netnews model. The namespace is considered "flat" for the purpose of the protocol although hierarchy-like searching restrictions are provided to limit the number of mailboxes returned by "FIND" and to provide for a simple client hierarchy view. Clients may use any separator-character based hierarchy they desire. This camp is motivated partly by a desire to keep the protocol simple and easy to implement. Hierarchy -- This is basically a filesystem model. The server has explicit directory objects which can be created, deleted and renamed. If the client presents a hierarchy, it must present the hierarchy the server exports and use the server's naming semantics for new mailboxes. This camp is motivated partly by a desire to make sure different hierarchial clients always have absolute consistancy. - Chris Newman Carnegie Mellon University Computing Services From owner-imap@cac.washington.edu Fri Oct 29 14:49:05 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03350; Fri, 29 Oct 93 14:49:05 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08475; Fri, 29 Oct 93 14:48:29 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08469; Fri, 29 Oct 93 14:48:27 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id RAA04876; Fri, 29 Oct 1993 17:48:23 -0400 Received: via switchmail; Fri, 29 Oct 1993 17:48:23 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 17:47:49 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 17:47:46 -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; Fri, 29 Oct 1993 17:47:44 -0400 (EDT) Message-Id: Date: Fri, 29 Oct 1993 17:47:44 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: QUOTA extension In-Reply-To: References: Beak: is Not I've always thought that the QUOTA command should be a private extension and not part of the standard IMAP protocol. I don't think it's something that it is reasonable to require all servers to support. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Oct 29 15:14:57 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03963; Fri, 29 Oct 93 15:14:57 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08607; Fri, 29 Oct 93 15:14:19 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08601; Fri, 29 Oct 93 15:14:17 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA08828; Fri, 29 Oct 93 15:13:27 -0700 Date: Fri, 29 Oct 1993 15:11:51 -0700 (PDT) From: Mark Crispin Subject: Re: new IMAP2bis draft To: Steve Hole Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I don't know if the quota stuff will be incorporated into IMAP2bis, or will be published as an auxillary extra to IMAP2bis (just because something is not in the IMAP2bis document doesn't mean that it isn't in the protocol). I was hoping that the namespace hierarchy issue would be settled at the WG meeting, but the latest I heard is that yet another hierarchical proposal is coming in. From owner-imap@cac.washington.edu Fri Oct 29 15:56:59 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA05213; Fri, 29 Oct 93 15:56:59 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02462; Fri, 29 Oct 93 15:56:15 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from ietf.cnri.reston.va.us by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02456; Fri, 29 Oct 93 15:56:13 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15914; 29 Oct 93 17:29 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: imap@cac.washington.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-imap-imap2bis-02.txt Date: Fri, 29 Oct 93 17:29:12 -0400 Message-Id: <9310291729.aa15914@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Mail Access Protocol Working Group of the IETF. Title : INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis Author(s) : M. Crispin Filename : draft-ietf-imap-imap2bis-02.txt Pages : 54 The Interactive Mail Access Protocol, Version 2bis (IMAP2bis) allows a client to access and manipulate electronic mail on a server. IMAP2bis is designed to permit manipulations of remote mailboxes as if they were local. IMAP2bis includes operations for creating, deleting, and renaming mailbox folders; checking for new mail; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-imap-imap2bis-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-imap-imap2bis-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931029102449.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-imap-imap2bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imap-imap2bis-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931029102449.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From owner-imap@cac.washington.edu Fri Oct 29 18:45:47 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA09859; Fri, 29 Oct 93 18:45:47 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05247; Fri, 29 Oct 93 18:44:45 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from othello.admin.kth.se by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05241; Fri, 29 Oct 93 18:44:42 -0700 Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA08712; Sat, 30 Oct 93 02:44:36 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA27073; Sat, 30 Oct 93 02:44:33 +0100 Date: Sat, 30 Oct 93 02:44:33 +0100 Message-Id: <9310300144.AA27073@mercutio.admin.kth.se> From: Peter Svanberg , Olle Jarnefors To: imap@cac.washington.edu Cc: Patrik Faltstrom , Rickard Schoultz , Peter Svanberg , Olle Jarnefors Subject: Non-ASCII in IMAP We have now - late but hopefully not _too_ late - reconsidered the non-ASCII problems in the light of current discussions on the IMAP list. Is this a correct interpretation of 8-bit usage in client <--> server transmissions? 1) High octets (octets with msb=1) are permitted only in literals 2) Literals with high octets are permitted everywhere the BNF permits it - except in RFC822.HEADER fetch results - if the character set is identified. 3) Hence, all clients and servers must be prepared to receive high octets and the connection must be 8-bit transparent in all IMAP communication. What we think is most important for non-ASCII SEARCH: 4) That the server can decide whether or not two octets, occurring in strings encoded in different character sets, represent the same character. 5) That the protocol facilities for handling extended character sets are not unnecessarily complicated but as simple as possible, so widespread implementation isn't counteracted. What we regard as _not_ important for non-ASCII SEARCH: 6) Possibility to use different character sets in differents parts of a certain search string, or even in different search strings in the same SEARCH command. Conclusions and suggestions: 7) The suggested RFC 1522-string solution is not a good tool to accomplish the above goals: It is unnecessarily complex and difficult to implement. 8) We suggest that the 1522-string soulution is removed from the draft and that the non-ASCII SEARCH extension is done as one of the features of the extended SEARCH. 9) We suggest that the normal MIME method of character set _labelling_ is used. The SEARCH command syntax is extended so that a character set label can be given, which tells the server the character set used in all strings in the search command. The easiest syntax extentions is probably to add a new keyword for this purpose: "STRINGCHARSET" SPACE mime_charset 11) Example ("#" represents octet hex BE, character in Latin 2): A003 SEARCH STRINGCHARSET ISO-8859-1 DELETED FROM {13} "Sol#enitsyn" SINCE 1-OCT-87 (Have we interpreted the usage of "literal" correct?) Note that STRINGCHARSET specifies the coded character set used in the strings of this search command, not necessarily the character set used in a found string. This command would e.g. find both From: =?ISO-8859-2?Q?Alexandr_Sol=BEenitsyn?= and From: =?ISO-8859-10?Q?Alexandr_Sol=BCenitsyn?= (This character happens to have another representation in ISO-8859-10 than in ISO-8859-2.) 12) Non-ASCII search should be case-insensitive. To have case-insensitive matching just on A-Z and case-sensitive matching on all other letters would be _very_ confusing to ordinary users. How can the poor implementer know if a character is the uppercase counterpart of another character? Just look in the new character set standard ISO 10646 (or the complete list of character names with code positions distributed freely by the Unicode consortium): This is the case only if the name of the first character is produced by replacing the word SMALL in the name of the second by CAPITAL. --- Peter Svanberg Phone: +46 8 790 71 40 Royal Inst of Tech, Sthlm, Sweden Fax: +46 8 790 09 30 -- Olle Jarnefors, Royal Institute of Technology, Stockholm From owner-imap@cac.washington.edu Fri Oct 29 19:08:28 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10062; Fri, 29 Oct 93 19:08:28 -0700 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05490; Fri, 29 Oct 93 19:08:01 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05484; Fri, 29 Oct 93 19:07:59 -0700 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA27767; Fri, 29 Oct 93 19:07:59 -0700 Date: Fri, 29 Oct 1993 19:06:32 -0700 (PDT) From: Terry Gray Subject: Agenda: Here's what I have so far... To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Agenda items for Houston IETF IMAP Working Group meeting --> in random order! 1. Is UID AFTER now superfluous? 2. Should Quotas be included? 3. How useful are selective header constructs (vs. fetch 822 and grep)? 4. Format of special information tokens which have args (UNSEEN). 5. Definition of special information tokens for error conditions. 6. Mstring grammar. 7. RFC-1522 search strings. Is current spec wording OK? 8. Additional non-ascii issues (cf. Peter Svanberg, Olle Jarnefors). 9. Extended search. (Define in imap2bis, or defer to separate RFC?) 10. How to support hierarchy. 11. Global vs. private flags... consistency across servers/clients 12. Namespace/driver selection, esp. for non-filesystem drivers. 13. How useful is the BBOARD construct? 14. Should "IMAP" == "Internet Message Access Protocol" 15. Revise the milestones in the WG's charter. From owner-imap@cac.washington.edu Fri Oct 29 19:39:02 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10307; Fri, 29 Oct 93 19:39:02 -0700 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09933; Fri, 29 Oct 93 19:38:34 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09927; Fri, 29 Oct 93 19:38:32 -0700 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id WAA12937; Fri, 29 Oct 1993 22:38:28 -0400 Received: via switchmail; Fri, 29 Oct 1993 22:38:28 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 22:37:23 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 22:37:21 -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; Fri, 29 Oct 1993 22:37:15 -0400 (EDT) Message-Id: Date: Fri, 29 Oct 1993 22:37:15 -0400 (EDT) From: John Gardiner Myers To: imap@cac.washington.edu Subject: QUOTA extension Beak: is Not Here's the write-up of the QUOTA extension, for those who may have missed it previously. *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* Cyrus Project J. G. Myers Carnegie Mellon July 1993 IMAP QUOTA extension Status of this memo This document describes an optional extension to the IMAP2bis protocol. Distribution of this memo is unlimited. The protocol extension discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol extension are STRONGLY URGED to get in touch with the author before embarking on such a project. Introduction The intent of the QUOTA extension to the Interactive Mail Access Protocol (IMAP2) is to allow administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. An IMAP server which supports the QUOTA extension may support limits on any number of resources. Each resource has an atom name and an implementation-defined interpretation which evaluates to an integer. Examples of such resources are: Name Interpretation MESSAGE Number of messages STORAGE Sum of messages' RFC822.SIZE, in Kilo-characters Each mailbox and bboard has an implementation-defined named "quota root". Each quota root has zero or more resource limits. All mailboxes that share the same named quota root share the resource limits of the quota root. Similarly, all bboards that share the same named quota root share the resource limits of the quota root. Quota root names do not necessarily have to match the names of existing mailboxes or bboards. Commands tag SETQUOTA MAILBOX quota-root setquota_list The SETQUOTA MAILBOX command takes the name of a mailbox quota root and a list of resource limits. The resource limits for the named quota root are changed to be the specified limits. Any previous resource linits for the named quota root are discarded. If the named quota root did not previously exist, an implementation may optionally create it and change the quota roots for any number existing mailboxes in an implementation-defined manner. Example: A001 SETQUOTA MAILBOX "" (STORAGE 512) * QUOTA MAILBOX INBOX "" (STORAGE 10 512) A001 OK Setquota completed tag SETQUOTA BBOARD quota-root setquota_list The SETQUOTA BBOARD command takes the name of a bboard quota root and a list of resource limits. The resource limits for the named quota root are changed to be the specified limits. Any previous resource linits for the named quota root are discarded. If the named quota root did not previously exist, an implementation may optionally create it and change the quota roots for any number existing bboards in an implementation-defined manner. Example: A002 SETQUOTA BBOARD FOO (MESSAGE 16 STORAGE 4096) * QUOTA BBOARD FOO.BAR FOO (MESSAGE 100 16 STORAGE 3154 4096) A002 OK Setquota completed tag GETQUOTA MAILBOX mailbox The GETQUOTA MAILBOX command takes the name of a mailbox and returns the quota root for the mailbox and the quota root's resource usage and limits in an unsolicited QUOTA reply. Example: A003 GETQUOTA MAILBOX INBOX * QUOTA MAILBOX INBOX "" (STORAGE 10 512) A003 OK Getquota completed tag GETQUOTA BBOARD bboard The GETQUOTA BBOARD command takes the name of a bboard and returns the quota root for the bboard and the quota root's resource usage and limits in an unsolicited QUOTA reply. Example: A003 GETQUOTA BBOARD BAR.BAZ * QUOTA BBOARD BAR.BAZ BAR () A003 OK Getquota completed Responses * QUOTA MAILBOX string string getquota_list This response occurs as a result of a GETQUOTA MAILBOX command. The first string is a mailbox name for which this quota root applies. The second string is the quota root for which this quota applies. The getquota_list is a S-expression format list of the resource usage and limits of the quota list. The list contains zero or more triplets. Each triplet conatins a resource name, the current usage of the resource, and the resource limit. Resources not named in getquota_list are not limited in the quota root. Thus, an empty list means there are no administrative resource limits in the quota root. * QUOTA BBOARD string string quota_list This response occurs as a result of a GETQUOTA BBOARD command. The first string is a bboard name for which this quota root applies. The second string is the quota root for which this quota applies. The getquota_list is a S-expression format list of the resource usage and limits of the quota list. The list contains zero or more triplets. Each triplet conatins a resource name, the current usage of the resource, and the resource limit. Resources not named in getquota_list are not limited in the quota root. Thus, an empty list means there are no administrative resource limits in the quota root. Formal syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma. getquota ::= "GETQUOTA" SP quota_opt SP string quota_list ::= "(" 0#quota_resource ")" quota_opt ::= "MAILBOX" / "BBOARD" quota_resource ::= string SP NUMBER SP NUMBER quota_reply ::= "QUOTA" SP quota_opt SP string SP string SP quota_list setquota ::= "SETQUOTA" SP quota_opt SP string SP setquota_list setquota_list ::= "(" 0#setquota_resource ")" setquota_resource ::= string SP NUMBER Author's Address John G. Myers Carnegie-Mellon University 5000 Forbes Ave. Pittsburgh PA, 15213-3890 Email: jgm+@cmu.edu From owner-imap@cac.washington.edu Tue Nov 2 07:29:52 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA07627; Tue, 2 Nov 93 07:29:52 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15262; Tue, 2 Nov 93 07:27:56 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15256; Tue, 2 Nov 93 07:27:46 -0800 Received: from sra.worf.epilogue.com with DMSP Date: 1 Nov 1993 19:25:31 -0500 From: Rob Austein To: imap@cac.washington.edu Subject: ¥Seen flag and disconnnected (batch mode) access Repository: quern Originating-Client: worf.epilogue.com Message-Id: <9311021025.aa06325@quern.epilogue.com> Dave Bridgham just reminded me of an annoyance that would come up in attempting to use the current IMAP2bis spec for disconnected access: the implicit set of the ¥Seen flag by certain FETCH operations. For a disconnected client, there's no particular correlation between when the message is fetched and when it is actually read. It's not even a safe assumption that the message will be read at all just because it was FETCHed. All you know is that the user downloaded a copy of the message (or message part) for possible later reading; this was probably done by a script-controlled program (hence the term "batch mode" for this kind of access in DMSP). In DMSP, clearing the UNSEEN flag is an explicit operation, which a batch mode client queues up as an action to be taken upon next synchronization. Ideally, we'd like to be able to do the same thing with IMAP. The fallback kluge would be for a batch-mode client to follow those FETCHes that set ¥Seen with a STORE that clears it for those messages for which ¥Seen had not been previously set. Besides being ugly, this has a potential timing screw: if the network dies after the implicit set but before the explicit clear, the message will remain marked as seen even though it's not. Perhaps we could fix this with alternate FETCH keywords that don't do the implicit set? --Rob Austein From owner-imap@cac.washington.edu Tue Nov 2 11:41:19 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15566; Tue, 2 Nov 93 11:41:19 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01258; Tue, 2 Nov 93 11:34:06 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01252; Tue, 2 Nov 93 11:33:49 -0800 Received: by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA11361; Tue, 2 Nov 93 11:33:21 -0800 Date: Tue, 2 Nov 1993 11:31:27 -0800 (PST) From: Mark Crispin Subject: Re: ¥Seen flag and disconnnected (batch mode) access To: Rob Austein Cc: IMAP Interest List In-Reply-To: <9311021025.aa06325@quern.epilogue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Rob - As a result of our discussion last night, I've defined BODY.PEEK, RFC822.PEEK, and RFC822.TEXT.PEEK in my copy of the draft. With any luck, the working group will ratify it without debate. -- Mark -- From owner-imap@cac.washington.edu Thu Nov 4 15:10:47 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14166; Thu, 4 Nov 93 15:10:47 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18921; Thu, 4 Nov 93 15:09:50 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@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-imap@cac.washington.edu Thu Nov 4 23:28:07 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA21748; Thu, 4 Nov 93 23:28:07 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08158; Thu, 4 Nov 93 23:27:04 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08152; Thu, 4 Nov 93 23:27:02 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15964; Thu, 4 Nov 93 23:26:57 -0800 Date: Thu, 4 Nov 1993 23:24:02 -0800 (PST) From: Terry Gray Subject: Houston IETF IMAP WG Mtg Notes To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SUMMARY On Monday (1 Nov 1993) 27 people convened for the first of two scheduled IMAP WG sessions (although only 21 signed the attendance sheet!) On Tues, a proper subset of around a dozen stalwarts carried on. For the continuation session after dinner, we were down to six, and there were two different ad hoc "midnight subcommittee" meetings... The 15 original agenda items and 4 new ones were all considered. Considerable progress was made on all fronts. One notable result: on Monday the group agreed that the acronym "IMAP" should be remapped to the words "Internet Message Access Protocol" to better reflect what the protocol has evolved into. There are three remaining work items: -John Myers to propose an additional set of protocol-specified special information tokens. -Chris Newman to propose a revised hierarchy support solution based on conceptual agreement reached at the meeting. -Chris Newman to propose a syntax for an IMAP "meta" namespace, to allow unambiguous identification of multiple namespaces. A new draft, incorporating at least some of the above three pending items and all of the other agreed upon items is expected around 12 November 1993. All in all, a very productive meeting! -------------------------------------------------------------------------- RESOLUTION OF SPECIFIC AGENDA ITEMS (in no particular order) 1. Is the UID AFTER construct now superfluous? -> YES; delete UID AFTER 2. Should John Myers' Quota extension be included in the draft? -> NO; requires future study. 3. How useful is selective header fetch (vs. fetch 822 and grep)? -> Useful enough to keep in the spec. 4. Format of special information tokens which have args (UNSEEN). -> Change syntax so value is inside square brackets 5. Definition of special information tokens for error conditions. -> Agreed they are useful if situation might require client to take action "behind the scenes', e.g. TRYCREATE -> No consensus on using these protocol-specified strings as an interim method to allow internationalization (client could index into local-language error message table.) -> John Myers to formulate specific proposal for additions to spec. 6. Mstring grammar. -> Objection to current definition was dropped. 7. RFC-1522 search strings. Is current spec wording OK? -> Wording revised. 8. Additional non-ascii issues (cf. Peter Svanberg, Olle Jarnefors). -> New wording resulted. 9. Extended search. (Define in imap2bis, or defer to separate RFC?) -> John Myer's proposal accepted with some modifications; especially NOT will be allowed in front of groups, and patterns (wildcards) will not be allowed at this time because of unknown interactions with international character strings. 10. How to support hierarchy. -> Conceptual agreement reached on a hybrid proposal; abandoned idea that client should define hierarchy, lest there be no hope of any consistency across clients. Rather, client should present server (mailbox driver's) view of hierarchy to allow users to use pathnames discovered via docs, voice, or msgs. -> Chris Newman to do syntax engineering and submit revised proposal. 11. Global vs. private flags... consistency across servers/clients -> New unsolicited responses will indicate which flags are stored permanently on the server, and which ones the client can update, and whether a client can add new ones. 12. Namespace/driver selection, esp. for non-filesystem drivers. -> "Rough Consensus" that there are multiple well-entrenched namespaces in the world that we need to deal with, and they don't divide cleanly into the MAILBOX and BBOARD namespaces. -> Examples: filesystem-based mail, news, ftp archives, gopher collections, other non-filesystem mailbox namespaces. -> Chris Newman to propose constructs to allow specification and/or merging of multiplicity of namespaces into one IMAP "meta" namespace. 13. How useful is the BBOARD construct? -> "Rough Consensus" that if Chris is able to come up with a satisfactory namespace syntax that BBOARD construct should be deprecated on the grounds that eliminating BBOARD simplifies the protocol, "two" namespaces is either too few or too many, and in some cases forcing "real world" namespaces into either MAILBOX or BBOARD can result in artificial and confusing distinctions for the user. 14. Should "IMAP" == "Internet Message Access Protocol" -> YES. Agreed that the new words are more descriptive of what the protocol has evolved into. 15. Revise the milestones in the WG's charter. -> No revision required (yet). December goal for Proposed Standard submission still thought plausible. Additional issues since agenda was posted before the mtg: 16. Protocol feature negotiation -> Prevailing wisdom was sustained, namely: if there had been two clear epochs of IMAP software, it might make sense to have a version mechanism, but capabilities of both clients and servers have evolved gradually, so there is a real hodgepodge of capabilities in the installed base. Accordingly, the client must probe individually each post-RFC-1176 function anyway to see if the server supports it. If individual probing is necessary, then having a single command to return capabilities doesn't offer any significant simplification of the client. -> Each new feature must have a specified way of probing for its existence without changing server state. 17. Change definition of internal date -> Agreed to change definition of internal date to be the "date of final delivery as defined in RFC-821." -> Agreed to preserve internal date on COPY and APPEND. 18. PEM vs. MIME vs. IMAP (compute checksum on server?) -> Integrity-protected PEM messages allow for the possibility of having the server compute the MD5 checksum, and let the client compare it with the sealed checksum sent in the message. The advantage is that the client can then verify integrity without fetching the entire message, as long as it is willing to trust the server to send the real message on subsequent fetches. It was agreed that, given the prospect of large body parts the client might not want, this would be a good feature to include. -> Confidentiality-protected (encrypted) PEM messages (or individual body parts), will be structurally opaque. However, it is possible to fetch the portion of the message containing the sealed key, unseal it on the client, hand it back to the server, and have the server decrypt the body part, thence allowing the server to parse the MIME structure and allow subsequent fetching of individual body parts. -> A "midnight ad hoc task force" identified wording to define extensions for both of the above cases. 19. Fetch Peek -> This was a non-controversial extension to allow fetching messages without setting the ¥SEEN flag, as one might like to do for disconnected operation. Additions, clarifications, corrections, and comments are all welcome. -teg From owner-imap@cac.washington.edu Sat Nov 6 20:44:15 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA29286; Sat, 6 Nov 93 20:44:15 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04966; Sat, 6 Nov 93 20:43:08 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA04960; Sat, 6 Nov 93 20:43:02 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25994; Sat, 6 Nov 93 20:43:02 -0800 Date: Sat, 6 Nov 1993 20:16:18 -0800 (PST) From: Terry Gray Reply-To: Terry Gray Subject: Namespace notes from IMAP WG mtg To: imap@cac.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Here are some of the "slides" used in discussing the IMAP namespace and hierarchy issues at last week's Houston IETF meeting. In a few cases I've modified the wording from the original to better reflect the consensus of those present, and the section on relative navigation will be unfamiliar to those attending the mtg because --perhaps in the euphoria of the progress we were making-- that slide was omitted... -teg ----------------------------------------------------------------------- NAMESPACE ASSUMPTIONS 1. Multiple namespaces exist and are entrenched in the world. 2. People get pathnames via multiple channels (e.g. print, voice, msgs) 3. It is unlikely that we can propose a OneTrueNamespace that will supersede existing practice. 4. Therefore: clients that allow pathname input should allow input of a context-specific path syntax. 5. Most users are well-served by relative navigation, but sometimes will want to enter full path names. 6. A single server may export multiple namespaces, e.g. comp.mail.misc and ‾ftp/mail/imap.archive 7. Namespaces are ultimately defined by IMAP mailbox drivers: some reflect their OS filesystem, some do not. --------------------------- PHILOSOPHICAL CHOICES 1. Clients present native server namespaces to users. 2. Each client defines its own namespace. 3. Everyone agrees on one (or two) namespaces. --------------------------- BIG QUESTION Should a given UA accept/present all hierarchies from all servers in the same way (i.e. accept pathnames from user only in OneTrueSyntax)... OR... Should clients reflect/present the multiplicity of server namespaces? IF clients pick their own hierarchy syntax, should all clients adopt the *same* OneTrueSyntax? --------------------------- HIERARCHY PROPOSALS 1. OneTrueSyntax: world domination (supersedes existing practice). 2. OneTrueSyntax: clients & servers map between OTS and existing practice. 3. TwoTrueSyntaxes: -MAILBOX --> foo/bar -BBOARD --> foo.bar 4. Server-exported hierarchy. 5. Flatlander. 6. Modified Flatlander. ---------------------------- MODIFIED FLATLANDER Goals/Premises: -Still uses fully-qualified names across the wire. -Should allow easy use of natural hierarchy of each server namespace. -Client should not need to know the separator character for any namespace. -Client is not allowed to specify a separator character. -Should blur distinction between terminals and non-terminals (directories) so that existing CREATE, DELETE, RENAME operations can be used for both. Detailed proposal to follow from Chris Newman. --------------------------- RELATIVE NAVIGATION o Think of Relative Navigation as "simple names" plus "change directory". o Useful abstraction for users; therefore, client builders would like to have primitives that match the relative navigation abstraction. o RN can be implemented in: -client or client's engine/library. -in protocol and therefore also in server. o RN primitives may exist in either a flatlander model or a server-exported hierarchy model. o If RN primitives are implemented on server (esp. with server-exported hierarchy), changing directory to parent can be ambiguous if the current directory has more than one parent. o In a flatland view using FQNs, the change-directory primitive may be modeled as a "set prefix" in order to avoid ambiguity when there are multiple parents. (A stack of pointers into the prefix string would define each level traversed, and allow unambiguous return to the next higher level.) o Special care must be taken in flatlander model to design things so that the client does not need to know what the natural separator character is for any given namespace, and to recognize that a server may export more than one kind of namespace. o Advantages of implementing RN primitives on server: -simplifies client. -increases consistency across clients. -avoids buggy server that might return FQNs that don't match prefix. o Advantages of implementing RN primitives on client: -simplifies protocol -simplifies server o Either way, many clients would like to avoid knowing about path separators, and to do this effectively, they must implement a prefix stack anyway to keep track of what "the next level up" really is; therefore, there seems to be little benefit to doing the same thing on the server. --------------------------- NAMESPACE SELECTION Real World IMAP ---------- ---- o Personal filesystem o MAILBOX o News o BBOARD o ‾ftp/ o "carmel" o "oracle" o "gopher" A proposal for a "prefix syntax" to allow identification of multiple namespaces, will be forthcoming from Chris Newman. --------------------------- MESSAGE COLLECTION TAXONOMY: 3 KINDS... 1. Personal/Private -User may CREATE new mailboxes. -User may modify existing mailboxes (data and flags). -User may define mailbox relationships (collections, hierarchy). 2. Shared (RW or RO) -Combination of both private and public attributes. -Actions of one user may affect others. 3. Public/Anonymous -User may not CREATE. -User may not define relationships. -User may not modify data or flags. -User typically lacks an account on server, therefore... -Personal state must be stored separately and used by client. ----------------------- From owner-imap@cac.washington.edu Mon Nov 8 13:55:19 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27265; Mon, 8 Nov 93 13:55:19 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24501; Mon, 8 Nov 93 13:52:31 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24495; Mon, 8 Nov 93 13:52:28 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id QAA03381; Mon, 8 Nov 1993 16:52:19 -0500 Received: via switchmail; Mon, 8 Nov 1993 16:52:11 -0500 (EST) Received: from nifty.andrew.cmu.edu via qmail ID ; Mon, 8 Nov 1993 16:51:34 -0500 (EST) Received: via niftymail; Mon, 8 Nov 1993 16:51:23 -0500 (EST) Date: Mon, 8 Nov 1993 16:51:22 -0500 (EST) From: Chris Newman Subject: Re: Houston IETF IMAP WG Mtg Notes To: imap@cac.washington.edu In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <752795482.4456.0@nifty.andrew.cmu.edu> Terry Gray writes: > 18. PEM vs. MIME vs. IMAP (compute checksum on server?) > ... > -> Confidentiality-protected (encrypted) PEM messages (or > individual body parts), will be structurally opaque. However, > it is possible to fetch the portion of the message containing > the sealed key, unseal it on the client, hand it back to the > server, and have the server decrypt the body part, thence > allowing the server to parse the MIME structure and allow > subsequent fetching of individual body parts. While it is possible to suck down a message, use PEM to decrypt it, ship it back up with APPEND then fetch the individual MIME parts, I believe this is *highly* undesirable. It loses both on security and efficiency, and any client which can afford the overhead for a PEM decryptor can easily fit in a MIME parser. > -> A "midnight ad hoc task force" identified wording to define > extensions for both of the above cases. I believe no mention was made of the encrypted case. > 19. Fetch Peek > -> This was a non-controversial extension to allow fetching > messages without setting the ¥SEEN flag, as one might like > to do for disconnected operation. Feel free to ignore this comment: I wonder if this change makes the EXAMINE command useless? - Chris From owner-imap@cac.washington.edu Mon Nov 8 14:57:20 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA29963; Mon, 8 Nov 93 14:57:20 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26247; Mon, 8 Nov 93 14:55:47 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26241; Mon, 8 Nov 93 14:55:31 -0800 From: Rob Austein To: Chris Newman Cc: imap@cac.washington.edu In-Reply-To: Chris Newman's message of Mon, 8 Nov 1993 16:51:22 -0500 (EST) <752795482.4456.0@nifty.andrew.cmu.edu> Subject: Re: Houston IETF IMAP WG Mtg Notes Date: Mon, 8 Nov 93 17:55:12 EST Message-Id: <9311081755.aa17324@quern.epilogue.com> While it is possible to suck down a message, use PEM to decrypt it, ship it back up with APPEND then fetch the individual MIME parts, I believe this is *highly* undesirable. It loses both on security and efficiency, and any client which can afford the overhead for a PEM decryptor can easily fit in a MIME parser. Chris, I think you misinterpreted the summary Terry posted. The idea was to fetch the signed, sealed random DES message key, unseal and unsign it on the client, and ship the unsigned unsealed key back to the server as part of a command that asked the server to please decrypt the data and parse the MIME structure. The security weaknesses here are that you've blown the message if either of the following is true: (1) you don't use an encrypted connection to the server and you don't trust the links between you and the server, or (2) you don't trust the server. You haven't blown your private key or any other messages. The (potential) big win, assuming you can live with these risks, is that you can now fetch just those parts of the message that you wanted. It's not just an issue of having a MIME parser. For example, if some clown sends you a one-page cover note on a 5GB video image, all encrypted, you can pull just the cover note down to your laptop over your 2400bps SLIP connection and leave the image alone until you get back home. So I'd claim that there's a class of applications for which this feature would be useful. I don't think anybody was proposing to use APPEND for this purpose. I could be confused about this. We didn't get very specific, but I had thought the idea was to use a brand new command. The discussion of encryption was a side conversation during the evening session just after the last formal IMAP session, when I found Ned out in the hall and brought him in to explain all this. I think you were in the room when this happened, but since there were several conversations going on at once, you may have missed this one. --Rob Austein From owner-imap@cac.washington.edu Wed Nov 10 12:15:18 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA02891; Wed, 10 Nov 93 12:15:18 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05503; Wed, 10 Nov 93 12:14:09 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from scapa.cs.ualberta.ca by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05497; Wed, 10 Nov 93 12:14:06 -0800 Received: from isagate by scapa.cs.ualberta.ca with UUCP id <18807-1>; Wed, 10 Nov 1993 13:08:32 -0700 Received: by isagate.edm.isac.ca (/¥==/¥ Smail3.1.20.1 #20.1) id ; Tue, 9 Nov 93 17:39 MST Received: from isa486-1 by isasun-1.edm.isac.ca with smtp (Smail3.1.28.1 #1) id m0ox29f-000cz2C; Tue, 9 Nov 93 16:07 MST Date: Tue, 9 Nov 1993 15:07:13 -0700 From: Steve Hole Subject: Re: Houston IETF IMAP WG Mtg Notes To: IMAP Discussion List Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Mon, 8 Nov 1993 15:55:12 -0700 Rob Austein wrote: > From: Rob Austein > Date: Mon, 8 Nov 1993 15:55:12 -0700 > Subject: Re: Houston IETF IMAP WG Mtg Notes > To: Chris Newman > Cc: imap@cac.washington.edu > > While it is possible to suck down a message, use PEM to decrypt it, > ship it back up with APPEND then fetch the individual MIME parts, I > believe this is *highly* undesirable. It loses both on security and > efficiency, and any client which can afford the overhead for a PEM > decryptor can easily fit in a MIME parser. Am I correct in assuming from this short discussion that the proposed method for producing encrypted MIME messages is to encrypt the entire message - thus hiding the MIME structure? I see that there is a new PEM/MIME merger draft out, and I have not read it yet. Was the discussion about PEM/MIME support in IMAP based on the new merger proposal or upon the earlier "entire MIME message in PEM" proposal? Is there any significant change in the new proposal that allows individual PEM encrypted MIME body parts to be accessed? I will read the new draft this evening. It seems to me, that the right way to do this is encrypt the MIME body parts separately, leaving the MIME structure visible to the server. 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-imap@cac.washington.edu Wed Nov 10 13:45:55 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA05534; Wed, 10 Nov 93 13:45:55 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07307; Wed, 10 Nov 93 13:44:51 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA07299; Wed, 10 Nov 93 13:44:47 -0800 From: Rob Austein To: imap@cac.washington.edu In-Reply-To: Steve Hole's message of Tue, 9 Nov 1993 15:07:13 -0700 Subject: Re: Houston IETF IMAP WG Mtg Notes Date: Wed, 10 Nov 93 16:43:47 EST Message-Id: <9311101643.aa09232@quern.epilogue.com> Date: Tue, 9 Nov 1993 15:07:13 -0700 From: Steve Hole Am I correct in assuming from this short discussion that the proposed method for producing encrypted MIME messages is to encrypt the entire message - thus hiding the MIME structure? I'm not up on the details of the current proposal, but just looking at the issues it seems clear to me that you need both capabilities (MIME structure visible and MIME structure hidden). I assume I don't need to make the case for MIME structure visible. MIME structure hidden is probably only of interest to real security weenies, but I'm sure that it is of interest to them, if only to cut down on what snoopers can learn via traffic analysis. --Rob Austein From owner-imap@cac.washington.edu Wed Nov 10 18:01:53 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13341; Wed, 10 Nov 93 18:01:53 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12581; Wed, 10 Nov 93 17:54:57 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SIGURD.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12575; Wed, 10 Nov 93 17:54:55 -0800 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H55GK0FGHS9D4ND3@SIGURD.INNOSOFT.COM>; Wed, 10 Nov 1993 15:27:26 PDT Date: Wed, 10 Nov 1993 15:21:56 -0700 (PDT) From: Ned Freed Subject: RE: Houston IETF IMAP WG Mtg Notes In-Reply-To: Your message dated "Tue, 09 Nov 1993 15:07:13 -0700" To: Steve Hole Cc: IMAP Discussion List Message-Id: <01H55LM93X4U9D4ND3@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > Am I correct in assuming from this short discussion that the proposed method > for producing encrypted MIME messages is to encrypt the entire message - thus > hiding the MIME structure? Sorry, this is, in general, incorrect. The current MIME-PEM proposal lets you encrypt whatever parts you like at whatever point you like. For example, you could selectively encrypt a message on a part by part basis, and then sign the resulting object to make sure that nobody messes with the structure. (Signing does not obscure structure.) Or, if you feel that the structure of the message needs to be obscured, you can sign and encrypt the whole thing in one go. The only thing that encryption obscures is the specific object that's encrypted. This can be either the entire message, specific parts, or something in between. > I see that there is a new PEM/MIME merger draft out, and I have not read it > yet. Was the discussion about PEM/MIME support in IMAP based on the new > merger proposal or upon the earlier "entire MIME message in PEM" proposal? The MIME-PEM proposal that provides all this functionality is the old one. The new proposal integrates MIME into PEM rather than the other way around, and actually reduces the options in this area quite significantly. > Is there any significant change in the new proposal that allows individual > PEM encrypted MIME body parts to be accessed? This capability has been part of the MIME-PEM proposal from the very beginning. There was nothing to add. > I will read the new draft this evening. It seems to me, that the right > way to do this is encrypt the MIME body parts separately, leaving the > MIME structure visible to the server. It may seem right to you, but in some cases the structure might provide very significant information to someone reading your mail. We view having the option of encrypting the entire message as an essential service we absolutely must provide. Ned From owner-imap@cac.washington.edu Thu Nov 11 12:20:37 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27075; Thu, 11 Nov 93 12:20:37 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21877; Thu, 11 Nov 93 12:19:34 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shivafs.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21871; Thu, 11 Nov 93 12:19:31 -0800 Received: from Relay.CV.COM by shivafs.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08141; Thu, 11 Nov 93 12:19:27 -0800 Received: from pr1mea.cv.COM by Relay.CV.COM; 11 Nov 93 15:13:46 EST Received: from huia [210.5.192.18] by PR1MEA.cv.COM ; 12 Nov 93 09:15:26 L Return-Path: Received: from eagle120 by huia (5.61/1.34) id AA14640; Fri, 12 Nov 93 09:02:11 +1300 Date: Fri, 12 Nov 1993 08:14:45 PST From: Michael Lasham Subject: Text Retrieval and Archieve To: Progress Email Group , ECS Information , IMAP Mailing List Message-Id: Reply-To: michael_lasham@PR1MEA.CV.COM Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello I am looking for some software that will: - allow me to archieve mail - have a good text retreival on the archieved mail I do not mind if they are both different sets of software. I want to run it on unix. If anyone could recommend any I'd be very grateful - prefer public domain. Thanks Michael Lasham From owner-imap@cac.washington.edu Fri Nov 12 08:41:30 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13809; Fri, 12 Nov 93 08:41:30 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05794; Fri, 12 Nov 93 08:40:50 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05788; Fri, 12 Nov 93 08:40:45 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA02876 (5.67b8/IDA-1.5 for ); Fri, 12 Nov 1993 10:40:22 -0600 Received: from [192.17.5.8] by dorner.slip.uiuc.edu with SMTP id AA05062 (5.65c/IDA-1.4.4 for imap@cac.washington.edu); Fri, 12 Nov 1993 10:40:35 -0600 Message-Id: <199311121640.AA05062@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Nov 1993 10:41:59 -0600 To: imap@cac.washington.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: IMAP newbie questions Hi, folks. I'm currently considering whether or not I want to add IMAP support to my mailer (Eudora), and if so at what level. I've just reviewed the IMAP2bis spec, and have some questions. My questions fall into several categories; clarifications (stuff I don't understand), problems (things that make me hesitate to implement IMAP), and comments (which you can safely ignore, I guess). CLARIFICATIONS - Message numbers in the presence of multiple clients. Suppose I have this sequence, with both clients lookin at the same mailbox: Client 1 Client 2 store 1 +flags (¥deleted) expunge store 1 +flags (¥deleted) expunge How many messages are deleted? - I have a feeling this is related, but what does "this implies that an expunge response can not be transmitted as part of a response to a command that uses sequence numbers" mean? - uniqeuid is called an "identifier" early in the text, but is defined as a number in the grammar. Which is it? - "If the client closes the network connection without a LOGOUT command, the server should do its normal logout procedures". What happens if the connection terminates with an error, as opposed to being cleanly closed? - What are the status of newlines in RFC822.SIZE? Counted as 1 char or 2? - I take it unique id's are NEVER EVER re-used? - Earlier versions of IMAP allowed the server to refuse to send data that it thought the client should have in its cache. This seems to now be forbidden, except for EXISTS/RECENT, right? PROBLEMS - I'm very concerned about scalability. I'd like to see some performance figures for both a single user with a very large set of mail (tens of megabytes, hundreds or thousands of mailboxes), and for a server serving large numbers of users (thousands). Has this sort of data been collected and analyzed? Does anyone have recommendations for sizing server hardware? - SEARCH command allows BODY and TEXT. HEADER seems obvious to me, but is absent. - I want my own flags, and even a little of my own data, that I can store with each message on the server. If I'm going to integrate IMAP *smoothly* into my MUA, I need a few bytes (a dozen would be plenty) that I can use for my own purposes. Having the server in charge of extension flags isn't friendly to me. Now, I can get by without this, but only at the expense of making IMAP mailboxes rather poor cousins to their local-disk counterparts. COMMENTS - Could the BNF be just a little longer? Did Tolstoy collaborate on it? :-) Seriously, this is a very large protocol. - I don't understand what purpose TRYCREATE serves. Why not just BAD and then let the client attempt a create? - The term "non-instantaneous amount of time" is used. Amusing. - Howscome I can't fetch a whole multipart body part? -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Fri Nov 12 08:53:54 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14202; Fri, 12 Nov 93 08:53:54 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03820; Fri, 12 Nov 93 08:53:18 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from is.rice.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03810; Fri, 12 Nov 93 08:53:10 -0800 Received: by is.rice.edu (AA29600); Fri, 12 Nov 93 10:53:08 CST Message-Id: <9311121653.AA29600@is.rice.edu> Date: Fri, 12 Nov 93 11:00:00 CST From: troth@rice.edu To: imap@cac.washington.edu Cc: troth@rice.edu Subject: numeric response codes In one of the IMAP sessions last week we talked for a long time about response codes. I got paged and had to step out for a while and when I returned the topic was STILL ON THE TABLE. Seems like a prob... um, a solution waiting to happen. ;-) I think I mentioned the idea of using numeric response codes. I don't know why everyone else tends to avoid numbers. I know I do because they're kinda cryptic when you're debugging. We agreed that the responses should be textual, but then ran into problems over local language considerations. I see a solution which I hope the rest of you will consider. I think it will solve the problems we've encountered thus far and not introduce more trouble. In the SIFT protocol, [see RFC 1440] I borrowed ideas from other protocols. I've seen simplistic ACK/NAK methods like +/- in MSP or NULL ACK in Berkeley LPR. I was overwhelmed by FTP's numbers, but I appreciate the programatic aspect. Consider this middle ground: 1xx = informational / more to come 2xx = ACK 3xx = NAK Here we have a three digit code where the programatic part is only the first digit. The remaining digits define a unique "reason code" that can be associated with a textual string for human consumption. A problem with FTP's numeric response codes is that they aren't always unique because more than one programatic state can map into a given code combination. In SIFT's case, the response codes are unique by definition. This may look too simplistic. It doesn't address "recoverable errors". But it seems reasonable that, should a recoverable error become evident, more sophisticated clients can be programmed for the unique response code, while simpler clients and older clients can still function happily with "something went wrong". So I like it. There's no problem with running out of response code space. Syntactically, the numeric response code must always be followed by white space, so we can add digits as needed and still have our method of analyzing that first digit for ACK/NAK/more. Here are some random examples from SIFT. The herald doesn't indicate success or failure, so it's a '1': 100 UFT 1.0 ready. You might also find 123 Wait ... which clearly tells the client "I'm not finished" but gives *something* other than silence. The client then loops, waiting for a code begining with a 2 or a 3 to indicate completion. Positive acknowledgement starts with a '2': 200 ACK 201 Command okay. 202 Command not implemented, superfluous at this site. 230 Local username okay, proceed. 250 Requested file action okay, completed. Negative acknowledgement begins with a '3': 300 NAK 301 Syntax error in parameters or arguments. 302 Command not implemented. 303 Bad sequence of commands. 332 No such local user. The beauty of this is that the server doesn't need any knowledge of the clients local language. Say the client gets a 332. It finds the text for message number 332 in its local list and displays an equivalent human message in the user's native tounge. If the client doesn't know what 332 is, then it can "punt", displaying the message text received from the server. If something fundamental is missing, you've still got 7 other digits to use, or 6 if you reserve '0' for internal use or some such. Thoughts? -- Rick TrOth , Rice University, Information Systems From owner-imap@cac.washington.edu Fri Nov 12 09:59:02 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16736; Fri, 12 Nov 93 09:59:02 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06365; Fri, 12 Nov 93 09:58:33 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06357; Fri, 12 Nov 93 09:58:31 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA06081 (5.67b8/IDA-1.5 for ); Fri, 12 Nov 1993 11:58:08 -0600 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA05143 (5.65c/IDA-1.4.4 for imap@cac.washington.edu); Fri, 12 Nov 1993 11:58:24 -0600 Message-Id: <199311121758.AA05143@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Nov 1993 11:59:12 -0600 To: imap@cac.washington.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: numeric response codes I heartily applaud the idea of numeric codes. However, I really think it would be less confusing to follow the SMTP/FTP convention of: 1xx - informational 2xx - success 3xx - more info needed 4xx - temporary failure; retry might be worthwile 5xx - permanent failure Even if the 3xx and 4xx codes go unused for now. I don't want to have to remember that 3xx means failure for IMAP, but more info for FTP. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Fri Nov 12 12:30:35 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA21603; Fri, 12 Nov 93 12:30:35 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08692; Fri, 12 Nov 93 12:29:44 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08686; Fri, 12 Nov 93 12:29:42 -0800 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id PAA06454; Fri, 12 Nov 1993 15:29:36 -0500 Received: via switchmail; Fri, 12 Nov 1993 15:29:34 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 15:28:26 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 15:28:24 -0500 (EST) 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; Fri, 12 Nov 1993 15:28:20 -0500 (EST) Message-Id: <8gsz7YG00WBw4mQ_QA@andrew.cmu.edu> Date: Fri, 12 Nov 1993 15:28:20 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: IMAP newbie questions In-Reply-To: <199311121640.AA05062@dorner.slip.uiuc.edu> References: <199311121640.AA05062@dorner.slip.uiuc.edu> Beak: is Not sdorner@qualcomm.com (Steve Dorner) writes: > - Message numbers in the presence of multiple clients. Suppose I have this > sequence, with both clients lookin at the same mailbox: > Client 1 Client 2 > store 1 +flags (¥deleted) > expunge > store 1 +flags (¥deleted) > expunge > How many messages are deleted? Each client potentially has its own different mapping of message numbers to messages. Depending on whether or not client 1 and client 2's message 1 map to the same message, there will be one or two messages deleted. > - I have a feeling this is related, but what does "this implies that an > expunge response can not be transmitted as part of a response to a command > that uses sequence numbers" mean? If a server were to send "* n EXPUNGE" responses at inopportune times, that would make the interpretation of sequence numbers than what the client intended. The server is thus explicitly restricted in when it may send such responses. > - uniqeuid is called an "identifier" early in the text, but is defined as a > number in the grammar. Which is it? It is a numeric identifier. > - "If the client closes the network connection without a LOGOUT command, > the server should do its normal logout procedures". What happens if the > connection terminates with an error, as opposed to being cleanly closed? This is basically saying "LOGOUT is optional." I don't see "terminates with an error" as being a different case--the server should presumably do something reasonable. Leaving some internal database in an inconsistent state is presumably not reasonable. > - What are the status of newlines in RFC822.SIZE? Counted as 1 char or 2? 2. Line breaks are represented as CR LF. > - I take it unique id's are NEVER EVER re-used? Not within a given mailbox. They must be strictly ascending. > - Earlier versions of IMAP allowed the server to refuse to send data that > it thought the client should have in its cache. This seems to now be > forbidden, except for EXISTS/RECENT, right? Correct. There is no command to explicitly request EXISTS/RECENT, so those aren't really exceptions. > - I'm very concerned about scalability. I'd like to see some performance > figures for both a single user with a very large set of mail (tens of > megabytes, hundreds or thousands of mailboxes), and for a server serving > large numbers of users (thousands). Has this sort of data been collected > and analyzed? Does anyone have recommendations for sizing server hardware? At CMU, we are in the process of developing an IMAP server with scalability and administerability being major design goals. We are also working on an adjunct protocol (IMSP) which among other things allows transparent distribution (and possibly replication) of mailboxes across servers. Our site has numbers at least as large as you mention. With our server work and a little client implementor prodding, we are confident we can get IMAP to work well in this scale. > - SEARCH command allows BODY and TEXT. HEADER seems obvious to me, but is > absent. This was added at the latest IETF. > - I want my own flags, and even a little of my own data, that I can store > with each message on the server. Our IMAP server allows up to 128 user flags per mailbox. > - Could the BNF be just a little longer? Did Tolstoy collaborate on it? > :-) Seriously, this is a very large protocol. It's not a small protocol, but then again it's not X.400. A lot of the grammar is consumed by descriptions of the various items of data you can fetch. > - I don't understand what purpose TRYCREATE serves. Why not just BAD and > then let the client attempt a create? You mean NO instead of BAD. The token is supposed to indicate to the client whether it is reasonable to attempt a create. This would allow a client to, say, put up a dialog box asking if the user wants to do the create only when there is a chance that creation would cause a subsequent COPY/APPEND to work. > - Howscome I can't fetch a whole multipart body part? They aren't particularly meaningful. You either want the whole message or a set of leaf parts. From owner-imap@cac.washington.edu Fri Nov 12 13:57:25 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA24062; Fri, 12 Nov 93 13:57:25 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10348; Fri, 12 Nov 93 13:56:23 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10342; Fri, 12 Nov 93 13:56:21 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA02331 (5.67b8/IDA-1.5 for ); Fri, 12 Nov 1993 15:55:51 -0600 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA05421 (5.65c/IDA-1.4.4 for imap@cac.washington.edu); Fri, 12 Nov 1993 15:56:06 -0600 Message-Id: <199311122156.AA05421@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Nov 1993 15:56:54 -0600 To: imap@cac.washington.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: IMAP newbie questions At 3:28 PM 11/12/93 -0500, John Gardiner Myers wrote: >sdorner@qualcomm.com (Steve Dorner) writes: >> - Message numbers in the presence of multiple clients. Suppose I have this >> sequence, with both clients lookin at the same mailbox: >> Client 1 Client 2 >> store 1 +flags (¥deleted) >> expunge >> store 1 +flags (¥deleted) >> expunge >> How many messages are deleted? > >Each client potentially has its own different mapping of message >numbers to messages. Depending on whether or not client 1 and client >2's message 1 map to the same message, there will be one or two >messages deleted. Assume both clients mean the same message, or used to. If client 1 deletes message 1 and expunges it, then client 2 refers to message 1, is client 2 referring to the (now vaporized) message 1, or what used to be message 2? >we are confident we can get IMAP to work well in this scale. Does anyone have numbers on current implementations? >Our IMAP server allows up to 128 user flags per mailbox. Is this going to be added to the protocol? I feel considerable unease about relying on extensions. >> - Howscome I can't fetch a whole multipart body part? > >They aren't particularly meaningful. You either want the whole >message or a set of leaf parts. With all due respect, how can you decide what I find meaningful? Is there some organic reason for this restriction, or is it simply because no one has yet imagined a use for it? I might have a utility that dealt with MIME multiparts; an appledouble decoder, perhaps. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Fri Nov 12 14:23:06 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA25184; Fri, 12 Nov 93 14:23:06 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11082; Fri, 12 Nov 93 14:22:37 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11076; Fri, 12 Nov 93 14:22:34 -0800 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id RAA07556; Fri, 12 Nov 1993 17:22:29 -0500 Received: via switchmail; Fri, 12 Nov 1993 17:22:26 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 17:21:51 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 17:21:47 -0500 (EST) 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; Fri, 12 Nov 1993 17:21:44 -0500 (EST) Message-Id: Date: Fri, 12 Nov 1993 17:21:44 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: numeric response codes In-Reply-To: <199311121758.AA05143@dorner.slip.uiuc.edu> References: <199311121758.AA05143@dorner.slip.uiuc.edu> Beak: is Not There are numerous problems with three-digit codes which have been discussed previously on this list. The most prominent problems are: * clients which cannot handle reply codes they do not know about * clients which suppress critical information in the text from the user, instead using text indexed by the reply code. * servers which shoehorn new conditions into existing but inappropriate codes. IMAP's equivalents to the first digit of three-digit codes are "OK", "NO", and "BAD", plus the reserved tags "*" and "+". For those cases where there are specific conditions for which clients may take specific actions to recover, there are special information tokens (such as [TRYCREATE]) defined to signal those conditions to knowledgeable clients. For the last IETF, I cataloged all of the error messages that my server can generate and classified most of them into one of six broad categories: PERMISSION, QUOTA, NOEXISTS, EXISTS, INTERNALPROBLEM, and INVALID. (TRYCREATE is a special case of NOEXISTS and PARSE is a special case of INTERNALPROBLEM.) It is not clear whether these six categories are enough or whether any server implementations besides mine would be able to distinguish between these categories. The only use of these categories would be for an interim internationalization measure. Until a mechanism is provided to allow a client to select a language for error messages, an internationalized client would be able to replace the text string included in the error message with a less specific message in a different language. I tend to think that this is a bad choice for an interim measure. A simpler interim measure would be for a site to modify the server to generate messages in the "correct" language, using some private convention to encode non-ASCII characters. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Fri Nov 12 15:33:32 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27391; Fri, 12 Nov 93 15:33:32 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12370; Fri, 12 Nov 93 15:32:44 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from CAMIS.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12364; Fri, 12 Nov 93 15:32:42 -0800 Received: from mac-treister.stanford.edu by CAMIS.Stanford.EDU (4.1/inc-1.0) id AA02480; Fri, 12 Nov 93 15:32:39 PST Date: Fri, 12 Nov 93 15:32:38 -0800 From: Adam Treister To: John Gardiner Myers Subject: Re: IMAP newbie questions Cc: imap@cac.washington.edu Message-Id: In-Reply-To: Your message <8gsz7YG00WBw4mQ_QA@andrew.cmu.edu> of Fri, 12 Nov 1993 15:28:20 -0500 (EST) Content-Type: TEXT/plain; charset=US-ASCII > > - I want my own flags, and even a little of my own > > data, that I can store with each message on the server. > > Our IMAP server allows up to 128 user flags per > mailbox. On the server that I use, if you use the MM mailbox format, then flags are supported via an .imaprc (or .mmrc) file. This had the awful side effect that editing this file would change the meaning of all the bit flags in the mailbox. Is your server representing the flags explicitly in the mailbox, so this kind of mismapping won't happen? I don't forsee that 128 is a limiting number of flags at any point in time, but over the life of a folder, I may add, modify and delete flags enough that, if you need to keep all flags that are used by any message in the box, the 128 could be too small. And if the 128 is a user limit, not a mailbox limit, most long term users will eventually hit the limit where they can't create new flags without killing flags in use in some old archive boxes. Also, I see there being two flavors of flags, sender- vs recipient- created, and they pbly need to be handled separately. The user may or may not want a message with Keywords: IMAP in the header to turn on the IMAP flag, but it'd be nice if the server at least has the capability to support this, should the client request it. The ability for the sender to add flags is potentially valuable, cuz it adds semi-structured semantic information that will (someday) facillitate the recipients' agents. But the level of trust in these keywords has to treated as lower than recipient initiated flags. Adam From owner-imap@cac.washington.edu Fri Nov 12 16:40:01 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA29543; Fri, 12 Nov 93 16:40:01 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08631; Fri, 12 Nov 93 16:39:31 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08625; Fri, 12 Nov 93 16:39:29 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA15037; Fri, 12 Nov 93 16:39:19 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA02229; Fri, 12 Nov 93 16:39:07 -0800 Date: Fri, 12 Nov 1993 15:41:56 -0800 (PST) From: Mark Crispin Subject: Re: IMAP newbie questions To: Steve Dorner Cc: imap@cac.washington.edu In-Reply-To: <199311122156.AA05421@dorner.slip.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Steve - John has basically given the same answers that I would have given, and perhaps in a more diplomatic way than I am capable of! ;-) So consider these comments as additions to what what John has already said. On Fri, 12 Nov 1993 15:56:54 -0600, Steve Dorner wrote: > Assume both clients mean the same message, or used to. If client 1 deletes > message 1 and expunges it, then client 2 refers to message 1, is client 2 > referring to the (now vaporized) message 1, or what used to be message 2? There is a potential timing race having to do with skews between unsolicited EXPUNGE responses. You are quite right for being concerned about it; so have we. My implementation does not (yet) permit multiple simultaneous expunge access to the same mailbox (it does permit multiple access but requires exclusivity for EXPUNGE). We believe we have resolved that timing race, by requiring that unsolicited EXPUNGEs only happen at certain points in which it is possible for the client to avoid this situation. In other words, the correct answer to your question is: 1 message will be expunged if the clients refer to the same message; 2 messages will be expunged if the clients refer to different messages. It's up to the server to handle the timing race case so that the client will never expunge the wrong message. It isn't clear what would happen if a client expunges a message that is already expunged but the server hasn't been able to tell the client yet. Personally, I think it should be a no-op, or better, the expunge shouldn't actually take place until all pointers to it are dropped (meaning all open IMAP connections have reported the expunge). This is a server implementation issue though. Anyway, we believe that we have addressed the problem satisfactorily. If implementation experience shows that we have not, we will address it. Please trust us! ;-) > Does anyone have numbers on current implementations? I don't have specific numbers (this is a frequently asked question), and it is really hard to give numbers since there are so many things you can do with my implementation to make it run better (or worse!). John's implementation works in quite a different way, since he had different constraints than I did and had options that were closed to me. In my implementation, I've observed some things: 1) Depending upon the mailbox format used, my implementation likes to have RAM or it likes to have fast access to the disk. In general, an 8MB box using NFS to access mail on an optical disk isn't going to work too well. 2) My implementation doesn't consume much CPU. Free text searches are the most expensive operation, but the CPU cost is very small compared to the access. Basically, you don't need a fast CPU for IMAP. 3) Some mailbox formats have the entire mailbox mapped into memory. This makes text searches blindingly fast even on godzilla mailboxes, but it does not scale well when the mailbox is large enough to cause the imapd to grow so that it swaps against itself. 4) Some mailbox formats read messages on demand. This slows down searches to the speed of the disk, but results in vastly diminished memory use. NFS kills these formats though. IMAP access is very much of a data base access and you don't want to NFS this for the same reason that you don't want to swap via NFS. 5) Yet other mailbox formats read messages on demand, but cache them. This can be the best, or the worst, of both worlds. The upshot is that my implementation is very general and very tunable to perform quite well (or quite poorly) when large numbers of users are present. John's implementation is specifically geared towards a black box environment where mine tries to play ball with traditional UNIX (although it has a black box mode). IMHO, an IMAP server system should have adequate RAM, but having good disk access (and good disk buffer cacheing) is much more important. RAM will hide an inadequate disk, but only for so long. IMAP servers are definitely less costly than timesharing jobs running traditional mail programs. > >Our IMAP server allows up to 128 user flags per mailbox. > Is this going to be added to the protocol? I feel considerable unease > about relying on extensions. User flags are in the protocol, however they are a server function. My implementation offers 30 user flags, but only in one format. We can talk offline about this. Don't forget the requirement on my end to play ball with extant UNIX e-mail infrastructure that isn't under my control. However, I think that we can come to an accomodation. > >> - Howscome I can't fetch a whole multipart body part? > >They aren't particularly meaningful. You either want the whole > >message or a set of leaf parts. > With all due respect, how can you decide what I find meaningful? Is there > some organic reason for this restriction, or is it simply because no one > has yet imagined a use for it? I might have a utility that dealt with MIME > multiparts; an appledouble decoder, perhaps. The reason for the restriction was that when I designed it 2 years ago, I couldn't come up with any reasonable definition of what fetching a multipart body item meant. My general feeling is that sins of omission are better than sins of commission...;-) If you consider how other body parts fetch, you would see that it really isn't as useful as you might imagine, compared to addressing the body parts individually. Or, at least the obvious definition isn't as useful. The ``obvious'' definition that you'd think of as a human is not the ``obvious'' definition given the way other stuff works. I don't think that your appledouble decoder would be impacted by this; in fact, your job is slightly easier by letting IMAP do the MIME work. Remember, you can do multiple fetches in a single request. There is no reason why you can't do: A002 FETCH 1 (BODY[2.1] BODY[2.2]) (instead of, as you propose, A002 FETCH 1 BODY[2] and then break it up yourself). It's also not clear what happens if the message store stores a message as an abstract structured object instead of a flat file in MIME. It's difficult enough to have to generate a MIMEgram for the RFC822 and RFC822.TEXT cases, but for individual bodies? We can talk about it, but I don't think you'll find it to be as valuable as you want. One possible compromise is for (given the above example) BODY[2] to mean the same as (BODY[2.1] BODY[2.2]). -- Mark -- From owner-imap@cac.washington.edu Fri Nov 12 16:54:05 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA00126; Fri, 12 Nov 93 16:54:05 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13819; Fri, 12 Nov 93 16:53:23 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13813; Fri, 12 Nov 93 16:53:20 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA06565 (5.67b8/IDA-1.5 for ); Fri, 12 Nov 1993 18:52:57 -0600 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA05569 (5.65c/IDA-1.4.4 for eudora-hotline@qualcomm.com); Fri, 12 Nov 1993 18:47:19 -0600 Message-Id: <199311130047.AA05569@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Nov 1993 18:48:08 -0600 To: Adam Treister , John Gardiner Myers From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: IMAP newbie questions Cc: imap@cac.washington.edu At 3:32 PM 11/12/93 -0800, Adam Treister wrote: >I don't forsee that 128 is a limiting number of flags at any point in time I do. I have bits and pieces of data that I would have to manufacture by combining many flags into binary numbers. 128 is squeaking by for my current needs, and needs will only grow. If IMAP mailboxes cannot support the extra data I need, they will look pretty crude in comparison to local mailboxes. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Fri Nov 12 17:05:36 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA00568; Fri, 12 Nov 93 17:05:36 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08816; Fri, 12 Nov 93 17:05:04 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08810; Fri, 12 Nov 93 17:05:03 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA15064; Fri, 12 Nov 93 17:04:52 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA02330; Fri, 12 Nov 93 17:04:43 -0800 Date: Fri, 12 Nov 1993 16:56:45 -0800 (PST) From: Mark Crispin Subject: Re: IMAP newbie questions To: Steve Dorner Cc: IMAP Interest List In-Reply-To: <199311130047.AA05569@dorner.slip.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 12 Nov 1993 18:48:08 -0600, Steve Dorner wrote: > >I don't forsee that 128 is a limiting number of flags at any point in time > I do. I have bits and pieces of data that I would have to manufacture by > combining many flags into binary numbers. 128 is squeaking by for my > current needs, and needs will only grow. > > If IMAP mailboxes cannot support the extra data I need, they will look > pretty crude in comparison to local mailboxes. I think that using binary flags for this purpose isn't what you want to do, particularly as the number of these can be implementation-dependent. Rather, we should be talking about storing some set of attributes with a message. We don't have anything like this in IMAP now, but we're open to suggestions. If you can give us a more detailed description of the sort of capability you would like, we may be able to draw up something. If I hear you correctly, you want to have some set of data items with names and values? Something like this has been bandied about. It's certainly better than gobbling down bitflags! Older servers won't give you this, but older servers are going to be lame compared to new servers no matter what. As long as you don't crash, and work as well as the server will let you, that's alright. We expect that new servers will be fully functional. From owner-imap@cac.washington.edu Fri Nov 12 20:33:49 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03413; Fri, 12 Nov 93 20:33:49 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09602; Fri, 12 Nov 93 20:33:05 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA09596; Fri, 12 Nov 93 20:33:04 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id XAA13408; Fri, 12 Nov 1993 23:33:01 -0500 Received: via switchmail; Fri, 12 Nov 1993 23:33:00 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 23:31:24 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 23:31:21 -0500 (EST) 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; Fri, 12 Nov 1993 23:31:00 -0500 (EST) Message-Id: Date: Fri, 12 Nov 1993 23:31:00 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: IMAP newbie questions In-Reply-To: References: Beak: Is If you have a (CMU) Cyrus IMAPD properly configured, users can't edit the file with the flag names. All access to mailboxes is through network protocols. From owner-imap@cac.washington.edu Fri Nov 12 20:43:57 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03506; Fri, 12 Nov 93 20:43:57 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15864; Fri, 12 Nov 93 20:43:31 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15858; Fri, 12 Nov 93 20:43:29 -0800 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id XAA10453; Fri, 12 Nov 1993 23:43:21 -0500 Received: via switchmail; Fri, 12 Nov 1993 23:43:16 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 23:43:06 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 12 Nov 1993 23:43:04 -0500 (EST) 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; Fri, 12 Nov 1993 23:43:04 -0500 (EST) Message-Id: <4gt6LM200WBwN4nd5t@andrew.cmu.edu> Date: Fri, 12 Nov 1993 23:43:04 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: IMAP newbie questions In-Reply-To: <199311122156.AA05421@dorner.slip.uiuc.edu> References: <199311122156.AA05421@dorner.slip.uiuc.edu> Beak: Is sdorner@qualcomm.com (Steve Dorner) writes: > >> Client 1 Client 2 > >> store 1 +flags (¥deleted) > >> expunge > >> store 1 +flags (¥deleted) > >> expunge > >> How many messages are deleted? > > Assume both clients mean the same message, or used to. If client 1 deletes > message 1 and expunges it, then client 2 refers to message 1, is client 2 > referring to the (now vaporized) message 1, or what used to be message 2? Client 2 is referring to the (now vaporized) message 1. As Mark mentions, his server would not allow the EXPUNGE as there are multiple sessions with the mailbox open. My server would perform the EXPUNGE command of client 1. When performing the STORE command of client 2, it would then fake setting the ¥Deleted flag on the vaporized message. When performing the EXPUNGE command of client 2, it would finally be permitted to send the * 1 EXPUNGE notification. From owner-imap@cac.washington.edu Sat Nov 13 03:27:03 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA06775; Sat, 13 Nov 93 03:27:03 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17983; Sat, 13 Nov 93 03:23:53 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17977; Sat, 13 Nov 93 03:23:48 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA18674 (5.67b8/IDA-1.5 for ); Sat, 13 Nov 1993 05:23:25 -0600 Received: from [192.17.5.8] by dorner.slip.uiuc.edu with SMTP id AA05739 (5.65c/IDA-1.4.4 for IMAP@CAC.Washington.EDU); Fri, 12 Nov 1993 20:17:58 -0600 Message-Id: <199311130217.AA05739@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Nov 1993 20:19:22 -0600 To: Mark Crispin From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: IMAP newbie questions Cc: IMAP Interest List At 4:56 PM 11/12/93 -0800, Mark Crispin wrote: >If I hear you correctly, you want to have some set of data items with names >and values? Something like this has been bandied about. It's certainly >better than gobbling down bitflags! Sure, if I can have it. :-) Currently, I have some dozen flags; I haven't looked very closely, many are no doubt the same as IMAP flags. I have a 16-bit identifier for a transliteration table, for use with non-MIME messages (so the user can manually stipulate a character set). I could squeeze that into fewer bits if I had to. I'd really like another 64 bits for remembering the window location the user last used. I have a byte or so for a user-assigned priority scheme. So I'm up to ‾112 bits now. Pretty soon I'll be letting users specify a color for each message; another byte. Then I'd really like some per-mailbox storage, too. Anyway, an area of a few dozen bytes per message and per mailbox would be a tremendous help. I'm sensitive to the difficulty of doing this on a server, especially one that maintains compatibility with other mailers. On the other hand, giving up all this stuff for IMAP mailboxes isn't so attractive, and keeping the information local to the client is not quite in the spirit of things. So I gotta ask. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Sat Nov 13 03:27:06 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA06783; Sat, 13 Nov 93 03:27:06 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17991; Sat, 13 Nov 93 03:23:59 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA17985; Sat, 13 Nov 93 03:23:57 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA18701 (5.67b8/IDA-1.5 for ); Sat, 13 Nov 1993 05:23:34 -0600 Received: from [192.17.5.8] by dorner.slip.uiuc.edu with SMTP id AA05736 (5.65c/IDA-1.4.4 for eudora-hotline@qualcomm.com); Fri, 12 Nov 1993 20:17:40 -0600 Message-Id: <199311130217.AA05736@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Nov 1993 20:19:03 -0600 To: Mark Crispin From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: IMAP newbie questions Cc: imap@cac.washington.edu At 3:41 PM 11/12/93 -0800, Mark Crispin wrote: >Anyway, we believe that we have addressed the problem satisfactorily. If >implementation experience shows that we have not, we will address it. Please >trust us! ;-) I'm willing to, I guess. But moving from a format where I have control to one where I might not be the only one with my fingers in the pie makes me jumpy. >I don't have specific numbers (this is a frequently asked question) These two facts suggest something to me; somebody should run some numbers! I think we're all aware that you can't sum up performance in a single number or anything, but it would be nice to have some rough idea of the performance envelope. Even a few data points would help. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Sat Nov 13 10:58:00 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10350; Sat, 13 Nov 93 10:58:00 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12384; Sat, 13 Nov 93 10:57:26 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12378; Sat, 13 Nov 93 10:57:25 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA15559; Sat, 13 Nov 93 10:57:18 -0800 Received: by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA05652; Sat, 13 Nov 93 10:57:12 -0800 Date: Sat, 13 Nov 1993 10:14:16 -0800 (PST) From: Mark Crispin Subject: Re: IMAP newbie questions To: Steve Dorner Cc: IMAP Interest List In-Reply-To: <199311130217.AA05736@dorner.slip.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > These two facts suggest something to me; somebody should run some numbers! > I think we're all aware that you can't sum up performance in a single > number or anything, but it would be nice to have some rough idea of the > performance envelope. Even a few data points would help. I'm not a statistician, so someone else would have to do formal gathering. I can speak only from my experience, in that a user running imapd is always better off than a user logged in via telnet and running a traditional mail program. IMAP users notice high system loads on the server much later than timesharing users do. For some reason, system administrators have the notion that they should be able to cram one or even two orders of magnitude more IMAP users than timesharing users on the same machine. This notion is misguided. At least in the case of my implementation, CPU has never been a limiting factor with the number of IMAP servers you can run; it's always been memory or disk bandwidth. It's hard to judge scaling with IMAP servers based upon my implementation, because so much depends upon how it is configured. My implementation is driver-based for different mailbox formats, and different drivers have vastly different characteristics in the demands they make upon the virtual memory subsystem and filesystem. I can say this much: my implementation won't run well in an environment where its fair share of memory is 32K and it has to use NFS to get at the disk. Another way of putting it: no, a 32MB machine isn't a reasonable platform to run 1000 simultaneous IMAP users. 100 is pretty much the maximum on such a machine, provided the disk can handle the traffic. Rather than attempt to build a 1000-user godzilla IMAP server, I would build a cluster of 20 smaller (and more than 20 times cheaper) 50-user servers, and use IMSP to distribute them. I look forward to hearing CMU's results. From owner-imap@cac.washington.edu Sat Nov 13 11:45:42 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10853; Sat, 13 Nov 93 11:45:42 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20855; Sat, 13 Nov 93 11:45:17 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20849; Sat, 13 Nov 93 11:45:15 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA18700; Sat, 13 Nov 93 11:45:14 -0800 Date: Sat, 13 Nov 1993 11:45:14 -0800 (PST) From: Terry Gray Subject: Re: IMAP newbie questions To: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 12 Nov 1993, Steve Dorner wrote: > These two facts suggest something to me; somebody should run some numbers! > I think we're all aware that you can't sum up performance in a single > number or anything, but it would be nice to have some rough idea of the > performance envelope. Even a few data points would help. One of the reasons it's difficult for us to offer useful datapoints at this time is that most of our IMAP servers are also timesharing machines. We are only now moving toward "pure" IMAP servers, but are certainly interested in answering the performance question, even while remaining optimistic that IMAP will scale quite well. As Mark has said, the performance of his server depends quite a bit on the mailbox format used, and of course usage patterns. I tend to believe that the Tenex format will scale better than the Bky format, because most people typically don't read every byte of a mailbox in a given session. To the extent that people do a lot of full-text searches on the server, the equation changes. (There is an obvious comparison to NNTP here.) On Sat, 13 Nov 1993, Mark Crispin wrote: > I can say this much: my implementation won't run well in an environment > where its fair share of memory is 32K and it has to use NFS to get at the > disk. Another way of putting it: no, a 32MB machine isn't a reasonable > platform to run 1000 simultaneous IMAP users. 100 is pretty much the > maximum on such a machine, provided the disk can handle the traffic. For the others on the list: Note that a memory-poor server will go a lot further if Tenex format mailboxes are used. Mark's Bky driver reads the entire mailbox into virtual memory, so it is great if your host has lots of RAM and a good VM system. However we have some experience with hosts that have neither :) > Rather than attempt to build a 1000-user godzilla IMAP server, I would > build a cluster of 20 smaller (and more than 20 times cheaper) 50-user > servers, and use IMSP to distribute them. Yes, we really do need IMSP to automate the user-to-server binding if there are going to be lots of servers. As Mark knows, I generally agree with the idea of using multiple small boxes rather than one big box, both in order to limit the affects of any one failure, and because the small boxes usually add up to less than the monthly maintenance fee for the large box :). But the crossover point (how many users/server) is changing, as a function of current product price/performance. Our colleagues who run the UW campus-wide systems are now purchasing the new IBM PowerPC RS/6000s for around $25K. These come with 256MB of RAM, 2GB of disk, and are 3x as fast as the DECstation 5000s we typically use. My *guess* is that such a machine could support 500 +/- 200 concurrent IMAP users, given Tenex format and not too much full text searching. (Note: no endorsement of AIX should be inferred from the preceding :) -teg From owner-imap@cac.washington.edu Sat Nov 13 12:09:23 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11107; Sat, 13 Nov 93 12:09:23 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12651; Sat, 13 Nov 93 12:08:56 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA12645; Sat, 13 Nov 93 12:08:53 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA15810; Sat, 13 Nov 93 12:08:45 -0800 Received: by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA05890; Sat, 13 Nov 93 12:08:40 -0800 Date: Sat, 13 Nov 1993 12:08:39 -0800 (PST) From: Mark Crispin Reply-To: Mark Crispin Subject: Re: IMAP newbie questions To: Terry Gray Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Sat, 13 Nov 1993, Terry Gray wrote: > Our colleagues who run the UW campus-wide systems are > now purchasing the new IBM PowerPC RS/6000s for around $25K. These come > with 256MB of RAM, 2GB of disk, and are 3x as fast as the DECstation 5000s > we typically use. My *guess* is that such a machine could support 500 +/- > 200 concurrent IMAP users, given Tenex format and not too much full text > searching. (Note: no endorsement of AIX should be inferred from the > preceding :) Terry's guess sounds plausible to me. Although I don't have numbers to back me up yet, I think the 256MB/2GB figures are more interesting than the 3x as fast. imapd does not need much CPU, and I wouldn't be at all surprised if a similarly configured DS5000 could handle an equivalent load. If this is so, the DS5000 would be a better bet because Ultrix is much more friendly to my implementation than AIX. At the present time, I don't have a way of doing the equivalent of a shared flock() on AIX, so all locking on AIX is exclusive. The SysV lockf() call doesn't give you enough capability to emulate this properly. It's pretty high on my priority list to resolve this. [If any of you AIX'ers can suggest a good way to emulate shared flock(), I'd appreciate hearing from you!] Of course, when NFS is in the picture, this is academic (gruesome horror stories about rpc.lockd available for your next Halloween party...). The concern in this case is whether or not you have *any* locking (and the ability to unlock properly), much less esoteric notions of sharing. ;-( I recommend that NFS *not* be in the picture. It is, after all, somewhat silly to have the bits first go via NFS and then via IMAP to the client; but a lot of people want to do this. From owner-imap@cac.washington.edu Sat Nov 13 12:53:41 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11450; Sat, 13 Nov 93 12:53:41 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21242; Sat, 13 Nov 93 12:45:33 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21236; Sat, 13 Nov 93 12:45:31 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id PAA07456; Sat, 13 Nov 1993 15:45:28 -0500 Received: via switchmail; Sat, 13 Nov 1993 15:45:27 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 13 Nov 1993 15:44:17 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 13 Nov 1993 15:44:16 -0500 (EST) 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; Sat, 13 Nov 1993 15:44:13 -0500 (EST) Message-Id: <0gtIQRm00WBwBXDLJg@andrew.cmu.edu> Date: Sat, 13 Nov 1993 15:44:13 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: performance statistics In-Reply-To: References: Beak: Is I should mention that Mark's numbers are for Mark's server. My server hasn't been completed yet, but preliminary results show that it should run significantly faster. For example, my server can parse the MIME torture test eight times faster than Mark's. Add to that the fact that with a few exceptions my server only parses messages upon insertion into the mailbox, whereas Mark's does it about once per session. From owner-imap@cac.washington.edu Sat Nov 13 14:30:34 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12242; Sat, 13 Nov 93 14:30:34 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21832; Sat, 13 Nov 93 14:30:07 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21826; Sat, 13 Nov 93 14:30:06 -0800 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id RAA05232; Sat, 13 Nov 1993 17:30:00 -0500 Received: via switchmail; Sat, 13 Nov 1993 17:29:55 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 13 Nov 1993 17:28:50 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Sat, 13 Nov 1993 17:28:47 -0500 (EST) 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; Sat, 13 Nov 1993 17:28:39 -0500 (EST) Message-Id: Date: Sat, 13 Nov 1993 17:28:39 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: features In-Reply-To: <199311130217.AA05739@dorner.slip.uiuc.edu> References: <199311130217.AA05739@dorner.slip.uiuc.edu> Beak: Is I'd like to throw some cautionary words in here. I'm not trying to pick on Steve in particular, but I note that he both comments that IMAP is a "very large" protocol and mentions as a potential problem the fact that it doesn't have a feature he wants. While I don't yet want to comment on the ability to store integer data with messages per se, I do want to note that IMAP is attempting to be a standard protocol for message access. In order for it to be useful and succesful, it will have to strike a careful balance between functionality and simplicity. (After coming back from the IETF, I've been thinking that MD5[section] may have been too much in the "gee-whiz" category.) My personal opinion is that it isn't a complete disaster if remote mailboxes don't have every single feature Eudora local mailboxes currently have. Some attributes Steve mentions (window location, color) don't necessarily have meaning across different client hosts, implementations, and/or platforms) If Eudora adds IMAP support, it will likely have to pick up some concepts it currently doesn't have, such as arbitrarily named flags and mailboxes which are also parents of mailboxes. If it picks up IMSP, its address book is going to have to become a bit more general. I don't think these differences are religious, but instead are artifacts of building a facility to interoperate between different systems. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Sat Nov 13 14:37:48 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12346; Sat, 13 Nov 93 14:37:48 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13185; Sat, 13 Nov 93 14:37:26 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13179; Sat, 13 Nov 93 14:37:24 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA15873; Sat, 13 Nov 93 14:37:15 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA06293; Sat, 13 Nov 93 14:37:08 -0800 Date: Sat, 13 Nov 1993 14:34:07 -0800 (PST) From: Mark Crispin Subject: re: performance statistics To: John Gardiner Myers Cc: IMAP Interest List In-Reply-To: <0gtIQRm00WBwBXDLJg@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII John - Does your code really ``parse the MIME torture test eight times faster'', or is it gaining that speed from saving the results of the parse so it doesn't actually have to dig in each time. If my MIME parser is as slow as you imply, I want to fix it. -- Mark -- From owner-imap@cac.washington.edu Sat Nov 13 17:52:04 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13714; Sat, 13 Nov 93 17:52:04 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23059; Sat, 13 Nov 93 17:51:38 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23053; Sat, 13 Nov 93 17:51:36 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA03997 (5.67b8/IDA-1.5 for ); Sat, 13 Nov 1993 19:51:15 -0600 Received: from [192.17.5.8] by dorner.slip.uiuc.edu with SMTP id AA00214 (5.65c/IDA-1.4.4 for imap@cac.washington.edu); Sat, 13 Nov 1993 19:51:54 -0600 Message-Id: <199311140151.AA00214@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Nov 1993 19:52:54 -0600 To: imap@cac.washington.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: IMAP newbie questions >As Mark has said, the performance of his server depends quite a bit on >the mailbox format used, and of course usage patterns. It would be interesting to see stats on usage patterns, too. Anyone collecting them? -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Sat Nov 13 17:52:56 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13746; Sat, 13 Nov 93 17:52:56 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23070; Sat, 13 Nov 93 17:52:30 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23064; Sat, 13 Nov 93 17:52:28 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA04010 (5.67b8/IDA-1.5 for ); Sat, 13 Nov 1993 19:52:07 -0600 Received: from [192.17.5.8] by dorner.slip.uiuc.edu with SMTP id AA00223 (5.65c/IDA-1.4.4 for imap@cac.washington.edu); Sat, 13 Nov 1993 19:52:45 -0600 Message-Id: <199311140152.AA00223@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 13 Nov 1993 19:53:47 -0600 To: John Gardiner Myers , imap@cac.washington.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: features At 5:28 PM 11/13/93 -0500, John Gardiner Myers wrote: >My personal opinion is that it isn't a complete disaster if remote >mailboxes don't have every single feature Eudora local mailboxes >currently have. Agreed. It's just a notch in the minus column, not a show-stopper. >If Eudora adds IMAP support, it will likely have to pick up some >concepts it currently doesn't have, such as arbitrarily named flags >and mailboxes which are also parents of mailboxes. If it picks up >IMSP, its address book is going to have to become a bit more general. Or I won't support those parts of IMAP, the way IMAP doesn't support some parts of Eudora. :-) -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Sun Nov 14 21:42:47 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA25334; Sun, 14 Nov 93 21:42:47 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01549; Sun, 14 Nov 93 20:51:03 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA01521; Sun, 14 Nov 93 20:50:17 -0800 Received: from sra.worf.epilogue.com with DMSP Date: 14 Nov 1993 00:39:14 -0500 From: Rob Austein To: Steve Dorner In-Reply-To: Steve Dorner's message of Fri, 12 Nov 1993 10:41:59 -0600 Subject: IMAP newbie question Cc: imap@cac.washington.edu Repository: quern Originating-Client: worf.epilogue.com Message-Id: <9311142348.aa23079@quern.epilogue.com> Steve, One of the several reasons why I lobbied to have unique IDs ("UIDs") added to the IMAP specification was to allow a client to completely avoid using message numbers, thus avoiding the timing screw you noticed. From my perspective as a regular PCMAIL user, it seems best to make message numbers strictly a local abstraction on the client. Indeed, one of the PCMAIL-based clients I use has only the most transitory binding between message numbers and UIDs. In the emacs-based PCMAIL client, message numbers depend both on the active "filter" and on any sorting order you've specified. Thus, while I may have 200 messages in my primary mailbox, if I've set my current filter to (address "sdorner") I see a sequence with two messages, numbered 1 and 2; which of these two messages gets message number 1 depends on the current sorting criteria. The other messages in my mailbox don't have any message number at all while this filter is in effect. Old-line IMAP diehards may claim that these aren't really message numbers in the IMAP sense (to which I charge would plead nolo contendre), but they're at least as meaningful to the human behind the IMAP client as the IMAP message numbers are. --Rob Austein From owner-imap@cac.washington.edu Mon Nov 15 07:12:57 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA01635; Mon, 15 Nov 93 07:12:57 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05533; Mon, 15 Nov 93 07:10:16 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from POSTOFFICE2.MAIL.CORNELL.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA05523; Mon, 15 Nov 93 07:10:06 -0800 Received: from UNCLE-MIKEY.CIT.CORNELL.EDU by postoffice2.mail.cornell.edu with SMTP id AA23723 (5.67a/IDA-1.5 for ); Mon, 15 Nov 1993 10:07:14 -0500 Message-Id: <199311151507.AA23723@postoffice2.mail.cornell.edu> X-Sender: mss1@postoffice2.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Nov 1993 10:10:05 -0500 To: imap@cac.washington.edu From: mss1@cornell.edu (Michael S. Shappe) Subject: Some numbers from another universe... Cc: Barbara Skoblick , Jim Howell I've watched with interest the discussion of IMAP performance. This issue will be particularly close to our hearts here at Cornell, based on the experience I shall now relate to you. About two years ago, we began to offer POP mail server to a limited (about 500 users) group as a pilot program. Our hope was to use it as the flagship of a whole suite of services that would free users from timesharing, and CIT from the monstrous cost of maintaining mainframes to SUPPORT timesharing. Last year, this POP service, along with a number of others, went 'production', in parallel with existing timesharing systems. Users were encouraged to move, and new students and staff were given the new Network ID instead of the old timesharing account, although the latter was still available to those who felt they needed it. Each separate service ran on its own SPARCStation 2 with 64mb of memory. In the middle of last spring, Newsstand, our NNTP server, began to feel the load. The breaking point was the UUNET crash -- UUNET had two major service failures in the space of two weeks. The resulting catchup brought our machine to its knees, and we wound up having to split off transfer service so that it wouldn't interfere with remote-reading performance. This led us to begin considering the 'next generation' -- note that, at this point, with perhaps 3000 active users of the POP service, the 'postoffice' machine was not yet having a problem, even in the middle of the day; but we felt we should plan ahead. We decided to stick with Sun (as much because we liked SunOS 4.x as because we could trade up relatively cheaply). We went to SPARCstation 10 model 31s, again with 64mb each, and to fast-SCSI disks. Our assumptions were that the user base would double by the end of Fall '93 (that is, be about 6000 active users), and that, since a SPARCStation-2 Postoffice was handling 3000 just fine, a SPARCStation-10 wouldn't break a sweat for 6000. We were right about the latter, but not the former (foreshadowing -- your key to quality literature :-) We come now to this past August, the last phase of our migration away from timesharing. No new timesharing accounts were issued on our 'old' mainframes; those who NEEDED timesharing -- either because of a class that needed access to a UNIX box or because they did not have the equipment to use the network directly or via SLIP -- were given accounts on one of three clusters of UNIX boxes. Everyone else (who used to be given accounts on our CMS-based CORNELLA and VMS-based VAX5) were given NetIDs only. On 1 November, all but a few of the remaining CMS and VMS accounts would be terminated. Even so, we predicted only 6000 active POP users by the semester's end -- no major problem for a might SPARCStation-10 :-) By October, we passed 6000. Rapidly. By the end of the second week of October, we passed 7500, in fact. At this point, the number of simultaneous users at peak time began to make real impact on the system load and the wait time. Within a week, Postoffice went into meltdown. By the end of the third week of October, we had nearly 10K active users. Pessimum load averages at peak time reached 85. Ldavs of 20 were common; the breaking point was having 40-50 active processes (pop and sendmail) simultaneously. We 'ran out' of I/O long before we ran out of CPU, although, by the height of the crisis, we were dreadfully short on both. So, we had to split things up. We created a second Postoffice, with an exactly duplicated configuration, but entirely separated spool (you couldn't pay us enough to share disks using NFS). Users were told they could use EITHER Postoffice, even BOTH, if they wanted to advertise two addresses (one each to different sets of people; most people here don't have POP clients that can do mail filtering...yet); since all NetID holders also had a 'forwarding' entry on our 'router' machine (aka 'cornell.edu'), all they had to do was change where their mail really went -- if they'd followed our instructions and advertised only their NetID@cornell.edu (and not NetID@postoffice.mail.cornell.edu), no one would ever know. We made it voluntary, figuring that the 'power users', who were most likely the bulk of our problems anyway, would move, and the others wouldn't bother and would wait out the storm. The old 80/20-rule held firm. 20% of the people were using 80% of the resource; those 20% moved (voluntarily and with remarkably little grumbling) to PO2 and are now happy, whilst the 80% remaining are also happy, because both machines are now usable again. We keep track of both the total number of active users and the total number of accesses -- the number of accesses for this month for PO2 is catching up the number on PO1, despite PO2 having far fewer users. Many of the power users check every minute! Our short-term future plans include upgrading both existing Postoffices to model 51 processors (this is already done, actually), and adding a second SCSI bus to split up the disk-I/O load on each machine. Medium-term has us purchasing a third and possibly fourth SPARCStation-10/51, but assigning new users to these 'exclusively' (that is, no more hoping around postoffices) on a round-robin per-semester basis -- the machine with the lightest load becomes the next semester's new-user-Postoffice. If a machine maxes out, we'll ask people to migrate to less loaded machines. Long-term has us going multi-processor, and making sure we have the fastest disks we can afford. We have only begun to look at IMAP to solve some of the deficiencies with POP...but these experiences have left us concerned about just how 'heavy-duty' our hardware will have to be to support what is in essence light-weight timesharing; we're also concerned about the sort of disk CAPACITY we'll need, but that's another story. I'm not honestly sure what the moral is here, but I thought I would present our experience with the 'other' protocol as a possible aid to planning for IMAP service. -- Michael Scott Shappe CIT Collaboration Systems From owner-imap@cac.washington.edu Mon Nov 15 08:19:19 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03039; Mon, 15 Nov 93 08:19:19 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21404; Mon, 15 Nov 93 08:18:44 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from log.css.itd.umich.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21398; Mon, 15 Nov 93 08:18:42 -0800 Received: from stimpy.css.itd.umich.edu by css.itd.umich.edu (5.67/2.2) id AA19068; Mon, 15 Nov 93 11:18:40 -0500 Received: by stimpy.css.itd.umich.edu (5.67/dumb-1.0) id AA24856; Mon, 15 Nov 93 11:18:39 -0500 Message-Id: <9311151618.AA24856@stimpy.css.itd.umich.edu> From: Gordon Good To: sdorner@qualcomm.com (Steve Dorner) Cc: imap@cac.washington.edu Subject: Re: IMAP newbie questions In-Reply-To: Your message of "Sat, 13 Nov 1993 19:52:54 CST." <199311140151.AA00214@dorner.slip.uiuc.edu> Date: Mon, 15 Nov 1993 11:18:36 -0500 >>As Mark has said, the performance of his server depends quite a bit on >>the mailbox format used, and of course usage patterns. > >It would be interesting to see stats on usage patterns, too. Anyone >collecting them? What sort of usage patterns are you looking for, Steve? I've added some code to imapd to write out per-process resource usage information, and am working on scripts to process it. The aim is to give us data useful for spotting trends and thresholds (e.g. when we start paging a lot under heavy load conditions) so we can plan for appropriate scaling. As of now, we have one IMAP server, a Sparc 10/30, 32MB RAM. All user mailboxes are on local disk, and we don't export any filesystems via NFS (all access is via IMAP). We have about 1050 accounts on the machine. Last friday, we had: (imapd data) Total users: 303 Total sessions: 1259 Total connect time: 155 hours, 46 min Total CPU time: 4033.94 seconds Average connect time per session: 7 min, 25 sec Average cpu time per session: 3.20 seconds Average maximum rss per session: 185 kb Average swaps per session: 0 Maximum number of concurrent sessions: 23 Average disk usage per user: 40 kb (sendmail data) Total messages we sent out: 3683 Total bytes handled: 8.09M ______ Basically, in any 24-hour period, we see about 30% of our accounts used, and our maximum concurrent user load is about 2-4% of the total number of accounts. These numbers may be a bit low, since we moved a bunch of accounts en-masse off of another system, and some may be inactive. I'd be surprised, though, if we see > 10% concurrent usage. -Gordon From owner-imap@cac.washington.edu Mon Nov 15 08:51:07 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03774; Mon, 15 Nov 93 08:51:07 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21537; Mon, 15 Nov 93 08:50:36 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21531; Mon, 15 Nov 93 08:50:30 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA13082 (5.67b8/IDA-1.5 for ); Mon, 15 Nov 1993 10:49:59 -0600 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01091 (5.65c/IDA-1.4.4 for imap@cac.washington.edu); Mon, 15 Nov 1993 10:50:44 -0600 Message-Id: <199311151650.AA01091@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Nov 1993 10:51:03 -0600 To: Gordon Good From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: IMAP newbie questions Cc: imap@cac.washington.edu At 11:18 AM 11/15/93 -0500, Gordon Good wrote: >What sort of usage patterns are you looking for, Steve? The kind you posted, only more so. :-) I think it would be really interesting to take a good look at a mature, "steady-state" IMAP system. Sometimes you don't know what statistics are interesting until you see them. >Total users: 303 >Total sessions: 1259 >Total connect time: 155 hours, 46 min >Total CPU time: 4033.94 seconds > >Average connect time per session: 7 min, 25 sec >Average cpu time per session: 3.20 seconds >Average maximum rss per session: 185 kb >Average swaps per session: 0 > >Maximum number of concurrent sessions: 23 >Average disk usage per user: 40 kb This is all interesting stuff. I'd be interested, too, in seeing things like average # of mailboxes, inter-mailbox traffic patterns, as well as medians and distributions of all this. Exactly how much such detailed numbers will help me in my decisions is debatable, but it's fascinating data to look at anyway. Perhaps some enterprising student is looking for a Master's thesis topic? The one number of yours that I find amazing is the 40Kb average storage per user. That makes me think you have a large number of users who aren't really comfortable with email yet, and aren't using it as much as they will. Either that, or you've found some magic way to make people keep their mail tidy, and delete stuff they don't need. If that's the case, let us in on it now! :-) -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Mon Nov 15 09:05:42 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04560; Mon, 15 Nov 93 09:05:42 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21654; Mon, 15 Nov 93 09:04:11 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uxc.cso.uiuc.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA21609; Mon, 15 Nov 93 09:04:02 -0800 Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA13471 (5.67b8/IDA-1.5 for ); Mon, 15 Nov 1993 11:03:41 -0600 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01113 (5.65c/IDA-1.4.4 for imap@cac.washington.edu); Mon, 15 Nov 1993 11:04:26 -0600 Message-Id: <199311151704.AA01113@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Nov 1993 11:04:44 -0600 To: imap@cac.washington.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: IMAP2bis server status I understand that the IMAP2bis spec is still being talked about. However, I wonder what the current state of server software is; has anyone been doing work in advance of the formal specification? I get the idea that this is so, but I would like to know for sure, and possibly even get an idea of when there might be something available to play with. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-imap@cac.washington.edu Mon Nov 15 11:21:31 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA09233; Mon, 15 Nov 93 11:21:31 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22523; Mon, 15 Nov 93 11:20:38 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from log.css.itd.umich.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA22517; Mon, 15 Nov 93 11:20:35 -0800 Received: from stimpy.css.itd.umich.edu by css.itd.umich.edu (5.67/2.2) id AA21384; Mon, 15 Nov 93 14:20:32 -0500 Received: by stimpy.css.itd.umich.edu (5.67/dumb-1.0) id AA29852; Mon, 15 Nov 93 14:20:30 -0500 Message-Id: <9311151920.AA29852@stimpy.css.itd.umich.edu> From: Gordon Good To: sdorner@qualcomm.com (Steve Dorner) Cc: imap@cac.washington.edu Subject: Re: IMAP newbie questions In-Reply-To: Your message of "Mon, 15 Nov 1993 10:51:03 CST." <199311151650.AA01091@dorner.slip.uiuc.edu> Date: Mon, 15 Nov 1993 14:20:29 -0500 >The one number of yours that I find amazing is the 40Kb average storage per >user. That makes me think you have a large number of users who aren't >really comfortable with email yet, and aren't using it as much as they >will. Yep. That number is bogus, since we moved a bunch of people en-masse from another system, and a number of them were (and are still) inactive. Additionally, we enforce a 3mb quota on the IMAP server, and anyone who had more than 3mb of mail on the old machine didn't get moved. If I only take into account people who have connected in the last week, the average usage is 184k. I expect that number to increase. From owner-imap@cac.washington.edu Mon Nov 15 13:49:22 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13211; Mon, 15 Nov 93 13:49:22 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23325; Mon, 15 Nov 93 13:48:43 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA23319; Mon, 15 Nov 93 13:48:41 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA17721; Mon, 15 Nov 93 13:48:33 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA16962; Mon, 15 Nov 93 13:48:24 -0800 Date: Mon, 15 Nov 1993 13:47:28 -0800 (PST) From: Mark Crispin Subject: re: IMAP2bis server status To: Steve Dorner Cc: IMAP Interest List In-Reply-To: <199311151704.AA01113@dorner.slip.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Steve - My server supports most of what is in the IMAP2bis spec, including the MIME parsing stuff and the lightweight mail management stuff. There are some newer things that have been added since August that aren't in my server yet, but will be; the most notable of these is UID support. -- Mark -- From owner-imap@cac.washington.edu Mon Nov 15 19:47:57 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23863; Mon, 15 Nov 93 19:47:57 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19907; Mon, 15 Nov 93 19:43:30 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA19901; Mon, 15 Nov 93 19:43:27 -0800 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id WAA12768; Mon, 15 Nov 1993 22:43:11 -0500 Received: via switchmail; Mon, 15 Nov 1993 22:43:04 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 15 Nov 1993 22:41:25 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 15 Nov 1993 22:41:22 -0500 (EST) 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, 15 Nov 1993 22:41:19 -0500 (EST) Message-Id: Date: Mon, 15 Nov 1993 22:41:19 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: IMAP2bis server status In-Reply-To: <199311151704.AA01113@dorner.slip.uiuc.edu> References: <199311151704.AA01113@dorner.slip.uiuc.edu> Beak: is Not My IMAP server (running on freehold.andrew.cmu.edu, login as anonymous) implements everything that was in the pre-IETF draft except SUBSCRIBE, UNSUBSCRIBE, DELETE, RENAME, EXPUNGE, COPY, and UID COPY. I've started doing some of the IETF changes, but lately I've been sidetracked. I hope to have a full post-IETF alpha code release by Februrary at the latest. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Tue Nov 16 12:11:03 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10014; Tue, 16 Nov 93 12:11:03 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29500; Tue, 16 Nov 93 12:10:18 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SIGURD.INNOSOFT.COM by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29494; Tue, 16 Nov 93 12:10:15 -0800 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H5CBD1CYHC8Y518Z@SIGURD.INNOSOFT.COM>; Mon, 15 Nov 1993 16:47:42 PDT Date: Mon, 15 Nov 1993 16:37:22 -0700 (PDT) From: Ned Freed Subject: Re: IMAP2bis server status In-Reply-To: Your message dated "Mon, 15 Nov 1993 11:04:44 -0600" <199311151704.AA01113@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: imap@cac.washington.edu Message-Id: <01H5CNVHP86W8Y518Z@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > I understand that the IMAP2bis spec is still being talked about. However, > I wonder what the current state of server software is; has anyone been > doing work in advance of the formal specification? I get the idea that > this is so, but I would like to know for sure, and possibly even get an > idea of when there might be something available to play with. This is actually something of a problem at present. The current state of server technology seems to lie somewhere between the original IMAP2bis document the IMAP Working Group started with and the current specification. This is all fine and dandy, but the fact of the matter is that current client expectations also seem to lie somewhere along this road. Servers that only implement IMAP2 or the original IMAP2bis don't work very well with some clients that expect more, or less, or different, feature-sets. To the extent that this is just part of protocol evolution, I have no problem with it. However, I have customers who are constantly asking, "When will you support IMAP2bis?" (They also ask when we'll upgrade our server from IMAP2 to IMAP3, but those I know how to handle ;-) They don't seem to be able to grasp that IMAP2bis is not complete yet and as such talking about having a server that "fully supports the standard" is a meaningless exercise in wordplay. I would also suggest that once the protocol is finalized that we label it as IMAP4. Such a label cuts through the murk surrounding IMAP quite nicely, I think. I also think we all need to do a better job of educating people as to the status of various protocols. In particular, there seem to be people out there with clients written to expect some intermediate IMAP2bis feature-set, and this behavior clearly needs to be labelled with a "wait until the dust settles before you go production with this software" stamp. Ned From owner-imap@cac.washington.edu Tue Nov 16 14:26:01 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13197; Tue, 16 Nov 93 14:26:01 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03397; Tue, 16 Nov 93 14:22:39 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA03391; Tue, 16 Nov 93 14:22:37 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA20601; Tue, 16 Nov 93 14:22:36 -0800 Date: Tue, 16 Nov 1993 14:22:36 -0800 (PST) From: Terry Gray Subject: Re: IMAP2bis server status To: imap@cac.washington.edu In-Reply-To: <01H5CNVHP86W8Y518Z@SIGURD.INNOSOFT.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Re Ned's msg on version confusion... Like Ned, I have begun thinking that the final product should be called IMAP4 in order to eliminate confusion regarding IMAP3. Contrary views? -teg From owner-imap@cac.washington.edu Tue Nov 16 15:05:04 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14745; Tue, 16 Nov 93 15:05:04 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00481; Tue, 16 Nov 93 15:02:13 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA00475; Tue, 16 Nov 93 15:02:11 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA19461; Tue, 16 Nov 93 15:02:09 -0800 Date: Tue, 16 Nov 1993 14:48:50 -0800 (PST) From: Mark Crispin Subject: Re: IMAP2bis server status To: Terry Gray Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Tue, 16 Nov 1993 14:22:36 -0800 (PST), Terry Gray wrote: > Like Ned, I have begun thinking that the final product should be > called IMAP4 in order to eliminate confusion regarding IMAP3. > > Contrary views? This seems to be a good idea. It has one neat feature. My server has called itself IMAP2bis for quite a while, but the IMAP2bis specification has now overtaken it and I have to play catch up. An IMAP4 server clearly identifies itself as being up to the latest spec, whereas an IMAP2bis server is some intermediate version. This would suggest that perhaps both names (IMAP2bis and IMAP4) should be used, but no server should call itself IMAP4 until it implements the function of the Draft Standard (when that happens...). I am on record as having opposed the IMAP4 name, but events have overtaken the reason for this opposition. There is one possible reason for keeping the IMAP2bis name: With a few exceptions, IMAP2bis is interoperable with IMAP2. The original (now extinct) IMAP was non-interoperable with IMAP2, and IMAP2 was non- interoperable with ``IMAP3'' (RFC-1203 had a VERSION command to shift gears). IMAP4 will be the first instance of an interoperable IMAP version, although the interoperability is with IMAP2, not IMAP3. [Since IMAP3 was stillborn, it doesn't really matter, but...] From owner-imap@cac.washington.edu Thu Nov 18 06:16:56 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04684; Thu, 18 Nov 93 06:16:56 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11647; Thu, 18 Nov 93 06:15:02 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uafhp.uark.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA11641; Thu, 18 Nov 93 06:15:01 -0800 Message-Id: <9311181415.AA11641@mx2.cac.washington.edu> Received: from loki.uark.edu by uafhp.uark.edu with SMTP (1.37.109.4/15.6) id AA03225; Thu, 18 Nov 93 08:13:16 -0600 Date: Thu, 18 Nov 93 08:13:16 -0600 X-Sender: cbrown@comp.uark.edu (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: imap@cac.washington.edu From: cbrown@comp.uark.edu (Craig Brown) Subject: Re: features At 17:28 1993/11/13 -0500, John Gardiner Myers wrote: >My personal opinion is that it isn't a complete disaster if remote >mailboxes don't have every single feature Eudora local mailboxes >currently have. Some attributes Steve mentions (window location, >color) don't necessarily have meaning across different client hosts, >implementations, and/or platforms) > >If Eudora adds IMAP support, it will likely have to pick up some >concepts it currently doesn't have, such as arbitrarily named flags >and mailboxes which are also parents of mailboxes. If it picks up >IMSP, its address book is going to have to become a bit more general. My hope is that if Steve decides to adopt IMAP that he's still able to keep Eudora small enough to run in under 500K. With the battle between feature sets and program size, it's rare to find an easy to use, yet feature rich, package like Eudora that is a reasonable size. From owner-imap@cac.washington.edu Thu Nov 18 11:06:10 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11470; Thu, 18 Nov 93 11:06:10 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14766; Thu, 18 Nov 93 11:05:09 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA14760; Thu, 18 Nov 93 11:05:06 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA29035; Thu, 18 Nov 93 11:05:01 -0800 Date: Thu, 18 Nov 1993 11:05:01 -0800 (PST) From: Mark Crispin Subject: Re: features To: Craig Brown Cc: imap@cac.washington.edu In-Reply-To: <9311181415.AA11641@mx2.cac.washington.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 18 Nov 1993, Craig Brown wrote: > My hope is that if Steve decides to adopt IMAP that he's still able to keep > Eudora small enough to run in under 500K. With the battle between feature > sets and program size, it's rare to find an easy to use, yet feature rich, > package like Eudora that is a reasonable size. Technically, it is possible; it does not require that much code to implement IMAP. The tradeoff is between performance, disk space, and memory use. Many IMAP tools like to use memory to cache IMAP data results so that they don't have to get them over the network. This is for the ``network traffic is expensive'' religion; IMAP clients run really nicely over SLIP links! But it isn't necessarily appropriate in other circumstances. IMHO, well-designed clients have the ability to be configured for various strategies of resource use. For example, the c-client library (used by Pine and other tools) has a master switch which disables all in-memory caching as well as various cache garbage collection routines. It is smart enough to know when it can use the cache or must generate IMAP traffic. So, if Eudora is clever, it could have a Preferences option to control its caching strategy. Someone with a 12MB Mac may want to throw memory at Eudora to give it faster performance... From owner-imap@cac.washington.edu Thu Nov 18 12:34:41 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14639; Thu, 18 Nov 93 12:34:41 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13578; Thu, 18 Nov 93 12:34:09 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Qajaq.Stanford.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA13572; Thu, 18 Nov 93 12:34:07 -0800 Received: by Qajaq.Stanford.EDU (5.65/inc-1.0) id AA19477; Thu, 18 Nov 93 12:34:05 -0800 Message-Id: <9311182034.AA19477@Qajaq.Stanford.EDU> To: imap@cac.washington.edu Reply-To: morgan@networking.stanford.edu Subject: S/Key (challenge/response) login and IMAP Date: Thu, 18 Nov 1993 12:34:05 -0800 From: RL "Bob" Morgan I've spent some time recently looking at the "S/Key" one-time password login scheme. I've appended the S/Key README at the end of this message. I've been using it for a few weeks now to telnet into my workstation from remote places (eg home); it seems to work well. I think that S/Key, or similar challenge/response authentication methods, is a useful tool in our increasingly cracker-crazed environment. I'd like to see support for it in IMAP clients and servers. This may require a protocol enhancement; then again, maybe not. Very briefly, S/Key resists wiretapping attacks by using a computed one-time password for login rather than a standard fixed password. It's OK for this password to be sent in the clear because it's useless to any (passive) attacker who might grab it. Generically, the login process might be described as: C -> S: S -> C: login: C -> S: S looks up username in local database, retrieves S -> C: C performs crypto-hash on and a user secret, resulting in C -> S: S performs further crypto-hash on , compares result to stored value. If valid, user is authenticated, database is updated so that and are obsolete. This doesn't seem to fit in with IMAP's normal login sequence, which is: C -> S: S -> C: OK C -> S: LOGIN S -> C: OK It's possible to short-circuit this with PREAUTH, but I don't think that's the right way to make S/Key work. Note that a different sort of challenge/response scheme (eg PPP's CHAP protocol) works generically like this: C -> S: S generates random S -> C: C performs crypto-hash on , username, secret, resulting in C -> S: S does same computation to verify , authenticate user I think this sort of scheme is less useful than the first one, but it would be nice for the IMAP protocol to support this sort of thing too. One approach to supporting S/Key might be: C: tag LOGIN @SKEY S: tag OK @SKEY: C: tag LOGIN @SKEY: S: tag OK There's the usual concern about how a non-S/Key-savvy server would respond to this request. I think in the case presented above it would interpret "@SKEY" in the first LOGIN as a password and so would see it as a bad login. A clever S/Key-ized client could give the user a message: "No S/Key support; use regular login?" or similar. I can't see any clean way to take advantage of S/Key without an S/Key-savvy client. If you could predict what the S/Key challenge would be, say by trying a telnet login and remembering the challenge, then you could just deliver the S/Key response in the password slot in the initial LOGIN and an S/Key-savvy server could accept it. This seems pretty funky, though. Note that an S/Key-savvy client doesn't have to expose the user to the S/Key innards, it can just prompt for a password like normal. This is a big win. Comments? - RL "Bob" Morgan Networking Systems Stanford --- S/KEY One-Time Password System (Version 1.1 11-01-93) Authors ------- Neil M. Haller nmh@thumper.bellcore.com Philip R. Karn karn@chicago.qualcomm.com John S. Walden jsw@thumper.bellcore.com Scott Chasin chasin@crimelab.com Archive Contents Listing ------------------------ src - Sources for the S/Key system (key, keyinit, keysh, libskey.a) man - Man pages for the S/Key tools tools - S/Key tools misc - Miscellaneous S/Key support programs (login, su, ftpd) S/Key anonymous FTP archive sites --------------------------------- thumper.bellcore.com [128.96.41.1] Directory: /pub/nmh crimelab.com [198.64.127.1] Directory: /pub/skey Both archive sites contain "key" binaries for DOS, MSWINDOWS, MAC, and various UNIX flavors. S/Key mailing list ------------------ We have established a mailing list to be used for S/Key announcements, Bug reporting, and for any general discussion of S/Key system. To get added or deleted from this list, send mail to: skey-users-request@thumper.bellcore.com To send to the list, send mail to: skey-users@thumper.bellcore.com Please do not send add/delete requests to the entire list. Description of The S/KEY One-Time Password System ------------------------------------------------- The S/KEY one-time password system provides authentication over networks that are subject to eavesdropping/reply attacks. This system has several advantages compared with other one-time or multi-use authentication systems. The user's secret password never crosses the network during login, or when executing other commands requiring authentication such as the UNIX passwd or su commands. No secret information is stored anywhere, including the host being protected, and the underlying algorithm may be (and it fact, is) public knowledge. The remote end of this system can run on any locally available computer. The host end could be integrated into any application requiring authentication. Attributes of the S/KEY One-Time Password System ------------------------------------------------ The S/KEY authentication system is a simple scheme that protects user passwords against passive attacks. It is not as powerful or general in scope as Kerberos or SDASS; nor does it protect against active attacks. It can, however, be easily and quickly added to almost any UNIX system without requiring any additional hardware and without requiring the system to store information (such as plain text passwords) that would be more sensitive than the encrypted passwords already stored. The S/KEY system can be used with non programmable terminals or personal computers (e.g., systems running DOS or Apple Macintoshes) with conventional communications programs. Some of the properties of the S/KEY system are: o Eavesdropping protection o Conceptually simple and easy to use o Based on a memorized secret password; does not require a special device although it can easily be adapted to do so. o Can be automated for authentication from a trusted system. (Can also be partially automated for fast operation.) o No secret algorithms. o No secrets stored on host. Description of the S/KEY One-Time Password System ------------------------------------------------- There are two sides to the operation of our one-time password system. On the user (or client) side, the appropriate one-time password must be generated. On the system (server) side, the one-time password must be verified. One time passwords are generated and verified using a one-way function based on MD4 [Rivest]. (Conversion to MD5 would be trivial) We have defined our one-way function to take 8 bytes of input and to produce 8 bytes of output. This is done by running the 8 bytes of input through MD4 and then "folding" pairs of bytes in the 16-byte MD4 output down to 8 bytes with exclusive-OR operations. This allows us to apply the one-way function an arbitrary number of times. Generation of One-Time Passwords The sequence of one-time passwords is produced by applying the one-way function multiple times. That is, the first one-way password is produced by running the user's secret password (s) through the one-way function some specified number of times, (n). Assuming n=4, p(1) = f(f(f(f(s)))) The next one-way password is generated by running the user's password through the one-way function only n-1 times. p(2) = f(f(f(s))) An eavesdropper who has monitored the use of the one-time password p(i) will not be able to generate the next one in the sequence p(i+1) because doing so would require inverting the one-way function. Without knowing the secret key that was the starting point of the function iterations, this can not be done. Seeding the Password A user might want to use the same secret password on several machines, or might allow the iteration count to go to zero. An initial step concatenates a seed with the arbitrary length secret password, crunches the result with MD4, and folds the result to 64 bits. The result of this process is then iterated n times. System Verification of Passwords The host computer first saves a copy of the one-time password it receives, then it applies the one-way function to it. If the result does not match the copy stored in the system's password file, then the request fails. If they match, then the user's entry in the system password file is updated with the copy of the one-time password that was saved before the final execution (by the server) of the one-way function. This updating advances the password sequence. Because the number of one-way function iterations executed by the user decreases by one each time, at some point the user must reinitialize the system or be unable to log in again. This is done by executing a special version of the passwd command to start a new sequence of one-time passwords. This operation is essentially identical to a normal authentication, except that the one-time password receive over the network is not checked against the entry already in the password file before it replaces it. In this way, the selection of a new password can be done safely even in the presence of an eavesdropper. Operation of S/KEY One-Time Password System ------------------------------------------- Overview The S/KEY one-time password authentication system uses computation to generate a finite sequence of single-use passwords from a single secret. The security is entirely based on a single secret that is known only to the user. Alternatively, part of or the entire secret can be stored in a non-retrievable way, in the computing device. Generation of S/KEY One-Time Passwords As mentioned above, the one-time password sequence is derived from the secret password using a computer. The required computation has been executed on a variety of PC and UNIX class machines including notebook and palm-tops. A vendor has estimated that credit card size devices could be built for less than $30 in large quantities. The program can also be stored on and executed from a standard floppy disk. This would allow operation on a remote computer that could not be entirely trusted not to contain a Trojan Horse that would attempt to capture the secret password. It is sometimes useful to pre-compute and print several one-time passwords. These could be carried on a trip where public terminals or workstations were available, but no trusted local computation was available. Description of Operation The following narrative describes the procedure for logging into a UNIX system using the S/KEY one-time password system. To illustrate the most complex case, we assume a hand-held PC compatible computer is used. o The user, call her Sue, identifies herself to the system by login name. o The system issues a challenge including the sequence number of the one-time password expected and a "seed" that is unique to the system. This "seed" allows Sue to securely use a single secret for several machines. Here the seed is "unix3" and the sequence number is 54. o Sue enters 54 and unix3 into her palm-top computer. She is prompted for her secret password. o Sue enters her secret password that may be of any length. The palm-top computes the 54th one-time password and displays it. o Sue enters the one-time password and is authenticated. o Next time Sue wants access, she will be prompted for one-time password sequence number 53. Semi-Automated Operation The complexity illustrated above is necessary only when using a terminal that is not programmable by the user, or when using a non-trusted terminal. We have built semi-automatic interfaces for clients using communications software on popular personal computers. The following example illustrates logging in using a trusted personal computer and a popular terminal emulation program. o Before starting the communication program, Sue runs the CTKEY program that ties a TSR to a "hot-key" such as F10. o Sue identifies herself by login name as above. o The system issues the same challenge including the seed "unix3" and the sequence number 54. The host system now expects an s/key one-time password. o Sue presses the hot-key and is then prompted for a secret password by the TSR program on the local system. o In response to Sue's secret password, the 54th one-time password is displayed at the position of the cursor. o Sue presses "Insert" and the terminal emulator transmits the one-time password completing the authentication. If the personal computer were in a trusted location, an option of the CTKEY program allows the secret password to be stored in a local file. Form of Password Internally the one-time password is a 64 bit number. Entering a 64 bit number is not a pleasant task. The one-time password is therefore converted to a sequence of six short words (1 to 4 letters). Each word is chosen from a dictionary of 2048 words. The contents of this dictionary is not a secret. Acknowledgments --------------- The idea behind our system was originally described by Leslie Lamport. Some details of the design were contributed by John S. Walden who wrote the initial version of the client software. Trademarks ---------- Athena and Kerberos of trademarks of MIT. S/KEY is a trademark of Bellcore. SPX and DEC are trademarks of Digital Equipment Company. UNIX is a registered trademark of UNIX System Laboratories, Inc. References ---------- Eugene H. Spafford, "The internet worm program: An analysis." Computer Communications Review 19(1):17-57, January 1989. D. C. Feldmeier and P. R. Karn, "UNIX Password Security - Ten Years Later", Crypto '89 Conference , Santa Barbara, CA August 20-24, 1989. J. G. Steiner, C. Neuman, and J. I. Schiller. "Kerberos: An authentication service for open network systems." USENIX Conference Proceedings, pp. 191-202, Dallas, Texas, February 1988. Catherine R. Avril and Ronald L. Orcutt. Athena: MIT's Once and Future Distributed Computing Project. Information Technology Quarterly , Fall 1990, pp. 4-11. R. L. Rivest, The MD4 Message Digest Algorithm, Crypto '90 Abstracts (August 1990), 281-291. Leslie Lamport, "Password Authentication with Insecure Communication", Communications of the ACM 24.11 (November 1981), 770-772. From owner-imap@cac.washington.edu Wed Nov 24 19:43:50 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08105; Wed, 24 Nov 93 19:43:50 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02419; Wed, 24 Nov 93 19:42:10 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from husc1.harvard.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02413; Wed, 24 Nov 93 19:42:08 -0800 Received: from HUSC15.HARVARD.EDU by HUSC15.HARVARD.EDU (PMDF V4.2-13 #4724) id <01H5PK0LFRA89FMD3U@HUSC15.HARVARD.EDU>; Wed, 24 Nov 1993 22:41:45 EST Date: Wed, 24 Nov 1993 22:20:47 -0500 (EST) From: "Bill Ouchark, Networks Group, (617) 495-1271" Subject: A few questions... To: imap@cac.washington.edu Cc: ouchark@HUSC15.HARVARD.EDU Message-Id: <01H5PKVJ29DW9FMD3U@HUSC15.HARVARD.EDU> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT I've encountered a few problems in the setup PC-Pine {Packet Driver} (I actually had these problems a couple months ago, but I'm just getting around to re-visiting them), namely: 1) If appears that BootP works somewhat, but PC-Pine is not using default gateway information returned from the BootP server (looks like address and name servers work fine). I verified using WATTCP's TCPINFO that the BootP server is indeed send the correct gateway address, but I can only get things to work if I hardcode the default gateway address in the WATTCP.CFG file. The following works fine: my_ip=bootp gateway=128.103.21.1 The following doesn't (although 128.103.21.1 is being returned in the BootP response): my_ip=bootp I re-verified that this behavior is true on the latest release as well. I also tested a number of the WATTCP apps and didn't find any problems with gateway address at all, so it looks specific to PC-Pine. 2) I cannot get PC-Pine to include a Unix system here as a collection folder. I use: inbox-path={husc.harvard.edu}inbox incoming-folders=VMS-INBOX {husc15.harvard.edu}inbox folder-collections=Unix-Email {husc.harvard.edu}mail/[], VMS-Email {husc15.harvard.edu}[], Local-PC c:¥network¥mail¥[] default-fcc={husc.harvard.edu}sent-mail read-message-folder={husc.harvard.edu}saved-messages Whenever I try and select the Unix-Email collection I do not see any of the folders I have on the Unix side (and I know they are there). Is this an IMAP server issue (the IMAP server in this case identifies itself as running IMAP2+ Service 6.7(46)). As I'm also receiving APPEND and CREATE errors, I'm under the strong assumption IMAP server version are the issue here--what release (on Ultrix) should we be running? 3) In the above configuration I also receive the error "[Bad LOGIN user name and/or password]" when I point to the VMS-Email collection. But it works anyway (i.e. I do get in and can see and access the folders correctly, but that error pops up for no apparent reason). We're running PMDF on the VMS machine (latest version of the IMAP2+ server from Innosoft). 4) Following the information contained in the PINERC file I attempted to suppress the saving of outgoing mail by setting default-fcc="". This did not work. Any help you can offer to remedy these issues is greatly appreciated. -Bill Ouchark- ------------------------------------------------------------------------------ Bill Ouchark Voice : (617) 495-1271 Manager of Networking Fax : (617) 495-9285 Harvard University/FAS Computer Services Internet: ouchark@husc3.harvard.edu 1 Oxford Street BITnet : OUCHARK@HUSC3 Cambridge, MA 02138 ------------------------------------------------------------------------------ From owner-imap@cac.washington.edu Thu Nov 25 07:55:22 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14544; Thu, 25 Nov 93 07:55:22 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06758; Thu, 25 Nov 93 07:54:43 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA06752; Thu, 25 Nov 93 07:54:42 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24609; Thu, 25 Nov 93 07:54:32 -0800 Date: Thu, 25 Nov 1993 07:54:31 -0800 (PST) From: Terry Gray Subject: Re: A few questions... To: "Bill Ouchark, Networks Group, (617) 495-1271" Cc: imap@cac.washington.edu, ouchark@HUSC15.HARVARD.EDU In-Reply-To: <01H5PKVJ29DW9FMD3U@HUSC15.HARVARD.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bill, I believe your msg is best directed to "pine-bugs@cac.washington.edu" rather than the imap discussion list. I'll forward it for you. -teg From owner-imap@cac.washington.edu Thu Nov 25 21:51:18 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19660; Thu, 25 Nov 93 21:51:18 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10532; Thu, 25 Nov 93 21:50:16 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO5.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA10526; Thu, 25 Nov 93 21:50:13 -0800 Received: from localhost (postman@localhost) by po5.andrew.cmu.edu (8.6.4/8.6.4) id AAA24338 for imap@cac.washington.edu; Fri, 26 Nov 1993 00:50:09 -0500 Received: via switchmail; Fri, 26 Nov 1993 00:50:06 -0500 (EST) Received: from data.cc.cmu.edu via qmail ID ; Fri, 26 Nov 1993 00:48:58 -0500 (EST) Received: from data.cc.cmu.edu via qmail ID ; Fri, 26 Nov 1993 00:48:54 -0500 (EST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.data.cc.cmu.edu.pmax.ul4 via MS.5.6.data.cc.cmu.edu.pmax_ul4; Fri, 26 Nov 1993 00:48:53 -0500 (EST) Message-Id: <0gxNX5m00WBc03IEgq@andrew.cmu.edu> Date: Fri, 26 Nov 1993 00:48:53 -0500 (EST) From: Michael Meyer To: imap@cac.washington.edu Subject: MH support in imap-3.2?/ HP imapd bugs Am I correct in assuming that there is no (working) support for MH folders in imap-3.2? I've 1) noticed that mh is commented out of the makefile 2) built imapd with mh support (on an hp 9000/7??, HPUX 9.01) and still not been able to read MH folders. //Digression: There are some small bugs in the hp support code in imap 3.2. In c-client/flock.c there are several "typos", including a struct mis-spelt as struck. Here are differences. ‾/Imap/imap-3.2/c-client> diff flock.c flock.c‾ 47,48c47 < /* struck flock fl; MMM */ < struct flock fl; --- > struck flock fl; 56,57c55 < /* fl.l_type = F.WRLCK; MMM */ < fl.l_type = F_WRLCK; --- > fl.l_type = F.WRLCK; 60,61c58 < /* fl.l_type = F.RDLCK; MMM */ < fl.l_type = F_RDLCK; --- > fl.l_type = F.RDLCK; 64c61 < fl.l_type = F_UNLCK; --- > fl.l_type = F.UNLCK; temper:‾/Imap/imap-3.2/c-client> diff flock.c flock.c‾ 47,48c47 < /* struck flock fl; MMM */ < struct flock fl; --- > struck flock fl; 56,57c55 < /* fl.l_type = F.WRLCK; MMM */ < fl.l_type = F_WRLCK; --- > fl.l_type = F.WRLCK; 60,61c58 < /* fl.l_type = F.RDLCK; MMM */ < fl.l_type = F_RDLCK; --- > fl.l_type = F.RDLCK; 64c61 < fl.l_type = F_UNLCK; --- > fl.l_type = F.UNLCK; Mike Meyer, Computing Services and Department of Statistics, Carnegie Mellon University From owner-imap@cac.washington.edu Thu Nov 25 22:14:26 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19805; Thu, 25 Nov 93 22:14:26 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26506; Thu, 25 Nov 93 22:13:42 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26500; Thu, 25 Nov 93 22:13:40 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA12162; Thu, 25 Nov 93 22:13:34 -0800 Received: by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA15791; Thu, 25 Nov 93 22:13:28 -0800 Date: Thu, 25 Nov 1993 22:13:27 -0800 (PST) From: Mark Crispin Subject: Re: MH support in imap-3.2?/ HP imapd bugs To: Michael Meyer Cc: imap@cac.washington.edu In-Reply-To: <0gxNX5m00WBc03IEgq@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The mh support in imap-3.2 is contributed code, and is read-only. You will to have to look at the code (e.g. at the mh_name() routine) to see how mh names work. There has been some discussion about finishing the mh support or rewriting it to a supported version, but since we don't have/use mh here it is difficult to test. It has been alleged by some people that they have gotten it to work for them. For future reference, c-client implementation issues such as this should go to the c-client list instead of the imap list, particularly now that there are other implementations of the IMAP protocol. We realize that the present situation is confusing (particularly with c-client being buried in the imap toolkit instead of the other way around), and we are slowly reorganizing things to be a bit less obtuse... Please bear with us. There are two versions of the IMAP toolkit on the ftp.cac.washington.edu server; the 3.1 version which has been frozen, and the current development 3.2 version which changes on a regular basis. The development version reflects the state of my current sources; the idea is to have the latest sources available for IMAPware developers. If you need a stable release, it's better to use the previous, frozen version, or use the c-client/imapd that is bundled with Pine. The typos which you reported in flock.c are fixed. flock.c is a new module which did not exist in earlier versions. From owner-imap@cac.washington.edu Mon Nov 29 22:01:30 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA22408; Mon, 29 Nov 93 22:01:30 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA25006; Mon, 29 Nov 93 21:59:57 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from bart.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24998; Mon, 29 Nov 93 21:59:53 -0800 Received: from shiva1.cac.washington.edu by bart.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA08877; Mon, 29 Nov 93 22:00:48 -0800 Date: Mon, 29 Nov 1993 21:59:50 -0800 (PST) From: Terry Gray Subject: Re: S/Key (challenge/response) login and IMAP To: morgan@networking.stanford.edu Cc: imap@cac.washington.edu In-Reply-To: <9311182034.AA19477@Qajaq.Stanford.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bob, I haven't seen a response to your proposal as yet, so consider this an attempt to stimulate some discussion. The idea of having a "lightweight" authentication mechanism has come up in past working group meetings (though not the most recent one.) Given that Kerberos support is a done deal, is the rationale for an S/Key type of scheme that Kerberos, because of its complexity, is not likely to be pervasively available in the near term? Any other reasons? -teg From owner-imap@cac.washington.edu Tue Nov 30 20:32:41 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA20578; Tue, 30 Nov 93 20:32:41 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15532; Tue, 30 Nov 93 20:31:51 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uvaarpa.Virginia.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA15526; Tue, 30 Nov 93 20:31:48 -0800 Received: from elvis.med.virginia.edu by uvaarpa.virginia.edu id aa09807; 30 Nov 93 23:31 EST Received: by elvis.med.Virginia.EDU (5.65c/1.34) id AA17311; Tue, 30 Nov 1993 23:31:44 -0500 Date: Tue, 30 Nov 1993 23:31:44 -0500 From: "Steven D. Majewski" Message-Id: <199312010431.AA17311@elvis.med.Virginia.EDU> X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: imap@cac.washington.edu Subject: why does CHECK | SELECT only sometimes return EXISTS - why? My imapd server ( IMAP2 Service 6.0(30) - I haven't tested this on another server. ) sometimes returns a number for EXISTS on a SELECT maibox or a CHECK command, and sometimes it doesn't. ( It DOES however, always return a value for RECENT. ) I did not notice any discussion of this in RFC1176, and I haven't yet figured out a pattern as to when or why is does or doesn't. [ I thad hought it might perhaps only return EXISTS on the initial SELECT or when the number had changed, but that does not appear to be the case. ] If this is proper behaviour for the server, can someone explain it to me ? ( Also: I've been a subscriber to this list for some time, but I haven't kept quite up to date on it lately. If anyone has a blurb on hand that describes the current status of drafts and imap software, please send me a copy - it will save me trying to sort thru 6 months of mail archives! ) Thanks, - Steve Majewski (804-982-0831) - UVA Department of Molecular Physiology and Biological Physics From owner-imap@cac.washington.edu Tue Nov 30 23:49:02 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA22321; Tue, 30 Nov 93 23:49:02 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24454; Tue, 30 Nov 93 23:48:13 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA24448; Tue, 30 Nov 93 23:48:09 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA19257; Tue, 30 Nov 93 23:48:00 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA08548; Tue, 30 Nov 93 23:47:51 -0800 Date: Tue, 30 Nov 1993 23:43:07 -0800 (PST) From: Mark Crispin Subject: re: why does CHECK | SELECT only sometimes return EXISTS - why? To: "Steven D. Majewski" Cc: IMAP Interest List In-Reply-To: <199312010431.AA17311@elvis.med.Virginia.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi - SELECT should *always* return a value for EXISTS. If it doesn't, it is a bug in the server. The version you are running, 6.0(30), is very old. Please get a current version of the IMAP toolkit from ftp.cac.washington.edu, file mail/imap.tar.Z The CHECK command does not necessarily return an EXISTS or RECENT value; if it does not, you should use the current value (if nothing else, what you got from SELECT). The current draft is draft-ietf-imap-imap2bis-02.txt, available from the ftp.cac.washington.edu archive or from your favorate Internet drafts server. It is going to be updated very soon (a matter of days). Regards, -- Mark -- From owner-imap@cac.washington.edu Wed Dec 1 13:14:03 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10482; Wed, 1 Dec 93 13:14:03 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28826; Wed, 1 Dec 93 13:12:30 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from uvaarpa.Virginia.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA28820; Wed, 1 Dec 93 13:12:27 -0800 Received: from elvis.med.virginia.edu by uvaarpa.virginia.edu id aa22971; 1 Dec 93 16:12 EST Received: by elvis.med.Virginia.EDU (5.65c/1.34) id AA26773; Wed, 1 Dec 1993 16:12:14 -0500 Date: Wed, 1 Dec 1993 16:12:14 -0500 From: "Steven D. Majewski" Message-Id: <199312012112.AA26773@elvis.med.Virginia.EDU> X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: Mark Crispin Subject: question about results of FIND MAILBOXES Cc: IMAP Interest List On Nov 30, 23:43, Mark Crispin wrote: > [ ... ] > The version you are running, 6.0(30), is very old. Please get a current > version of the IMAP toolkit from ftp.cac.washington.edu, file mail/imap.tar.Z > [ ... ] > The current draft is draft-ietf-imap-imap2bis-02.txt, available from the > ftp.cac.washington.edu archive or from your favorate Internet drafts server. > It is going to be updated very soon (a matter of days). > Thanks Mark, I've updated my server ( imapd-3.2) and now SELECT and a few other things seem to work more consistently for me now, including 'FIND MAILBOXES' - however, now that it works, I see that the output list is not ONLY mailboxes, but the equivalent of doing a unix 'ls' with the same pattern. All files and directories are listed, including '.' and '..' if they match. Trying to SELECT a directory returns BAD, but selecting a non mailbox text file DOES return "1 EXISTS" and the text of the file is retrievable with "FETCH 1 RFC822" Is this the intentional behaviour ? It appears (to me) to be counter to implications in RFC1176. IMAPbis then says: "The FIND MAILBOXES command as described in RFC-1176 is hereby more thoroughly defined. " but then goes on to say that the meaning of the results are implementation dependent. I would like a little more guidance/discussion of what are reasonable expected bounds to this implementation dependent behaviour. I'm not necessarily saying that what imapd is doing is unreasonable - I can come up with arguments either way. I can live with not distinguishing between mailboxes and ordinary files, although it seems a bit odd to me that it's is NOT explicitly the server's duty. I would probably prefer if directories where somehow tagged as directories (and since posix-like name conventions are already documented in Naming.TXT, I would suggest that a trailing '/' be appended to the names of directories), but again, I could live with the current behaviour as long as it is specified somehow that that IS in fact what a server ought to do. [ Forgive me if I'm missing something obvious in IMAP2bis - it usually takes me a couple of reads to digest these documents sufficiently. ] - Steve Majewski (804-982-0831) - UVA Department of Molecular Physiology and Biological Physics From owner-imap@cac.washington.edu Thu Dec 2 23:30:16 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA20402; Thu, 2 Dec 93 23:30:16 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08649; Thu, 2 Dec 93 23:26:09 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA08643; Thu, 2 Dec 93 23:26:03 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA22606; Thu, 2 Dec 93 23:25:56 -0800 Date: Thu, 2 Dec 1993 23:19:09 -0800 (PST) From: Mark Crispin Subject: re: question about results of FIND MAILBOXES To: "Steven D. Majewski" Cc: IMAP Interest List In-Reply-To: <199312012112.AA26773@elvis.med.Virginia.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Steven - The IMAP2bis protocol is still evolving. A new draft will be coming out this month based upon decisions which were made at the Houston IETF meeting; the only thing holding it up is a namespace syntax question that should be solved in a few days. Among the many changes in it will be a deprecation of the FIND command in favor of a new LIST command. The important thing is not to draw any conclusions from the older IMAP2bis documents and especially not the Naming.TXT document. If you are writing IMAP client software, please touch bases with me and with John Myers (jgm+@cmu.edu) to help coordinate your efforts and to avoid confusion and duplication of effort. PS: Yes, the ability to select a non-mailbox text file and the listing of such files in FIND (soon to be LIST) is an intentional feature of the c-client based IMAP server. Soon, directories will be selectable as well. Regards, -- Mark -- From owner-imap@cac.washington.edu Wed Dec 8 12:08:41 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA21986; Wed, 8 Dec 93 12:08:41 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12932; Wed, 8 Dec 93 12:06:42 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Mordor.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12926; Wed, 8 Dec 93 12:06:38 -0800 Received: from macii-morgan.Stanford.EDU by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA25732; Wed, 8 Dec 1993 12:06:36 -0800 Date: Wed, 8 Dec 93 12:06:37 -0800 From: RL "Bob" Morgan To: imap@cac.washington.edu Subject: Re: S/Key (challenge/response) login and IMAP Cc: morgan@networking.stanford.edu, Terry Gray Message-Id: In-Reply-To: Your message of Mon, 29 Nov 1993 21:59:50 -0800 (PST) Content-Type: TEXT/plain; charset=US-ASCII Terry: > Given that Kerberos support is a done deal, Done? I know it's in the protocol, but are there clients and servers that support it that are in production use today? Could we have a roll-call here? I don't see any Kerberos references anywhere in c-client. Am I missing something? > is the rationale for an S/Key type of scheme that Kerberos, > because of its complexity, is not likely to be > pervasively available in the near term? Essentially. And that Kerberos-impoverished environments will continue to be something we have to deal with for a long time, even after our primary desktops are warm and kerberized (or DCE-ized). And that there may be life beyond Kerberos, too. As for complexity, here's my anecdote. We've had lots of attacks here recently that included crackers running packet-sniffing programs on hosts that they had compromised. One of these attacks involved the regional net that is based here at Stanford. *I* dial in from home, using a Mac, via that regional net. It's really just luck that my packets didn't travel over the compromised path; if they had, my accounts on our critical service-providing hosts would have been up for grabs. But what about when I dial in this evening? Kerberos technology has been available to us for years, but there still seem to be obstacles to putting it into daily production use to solve this kind of problem. Kerberized telnet doesn't seem to be available out of the box, Kerberos support on the Mac is a swamp of differing local implementations (including a new one of ours), key distribution to hosts depends on infrastructure (eg Moira) that we aren't using, etc. Are *you* using Kerberos for this kind of thing (anybody)? Sure, we use it for AFS ... On the other hand, I got the S/Key code, hacked it, and installed it within a few hours and it's solving the above problem for me today. I'm as much a believer in Kerberos as anybody, but I gotta solve this problem *now*, and S/Key helps me do that. As I described before, the nice thing about S/Key is that it drops right in to apps like telnet and FTP that (usually) use the traditional username/password dialog. IMAP doesn't have this nice feature, unfortunately, so S/Key looks like less of a win. But do you really think that Kerberos is the last authentication we'll ever need? That a challenge/response method like S/Key, maybe involving smart cards and public keys, won't be The Way To Do It sometime soon? I'm suggesting that the protocol take this into account and offer some login sequence beyond LOGIN/OK. And that clients be flexible about their login methods, so they don't have to be rewritten every time some new scheme comes along. - RL "Bob" From owner-imap@cac.washington.edu Wed Dec 8 12:37:52 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23018; Wed, 8 Dec 93 12:37:52 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13571; Wed, 8 Dec 93 12:37:10 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA13565; Wed, 8 Dec 93 12:37:01 -0800 To: morgan@networking.stanford.edu Cc: imap@cac.washington.edu In-Reply-To: RL Bob Morgan's message of Wed, 8 Dec 93 12:06:37 -0800 Subject: S/Key (challenge/response) login and IMAP Reply-To: dab=replies@epilogue.com Date: Wed, 8 Dec 93 15:36:12 EST From: dab@epilogue.com Message-Id: <9312081536.aa00962@quern.epilogue.com> Regarding RL Bob Morgan's message about Kerberos and challenge/response authentication. He seems to imply that Kerberos is the right thing and challenge/response is a quick to implement, temporary solution. My attitude is almost the reverse of that in that I consider challenge/response to be the right solution in many cases though Kerberos is certainly an acceptable alternative for those sites that wish it. Kerberos was great for Project Athena at MIT because they wanted centralized control of authentication over hundreds of unix workstations. I prefer not to have a trusted third party, such as the Kerberos server, get involved. I also prefer not to have my authentication time out. Is the kerberos support in imap such that it automatically gets a new key when the old one times out? That would be nice but it would be the first time I've heard of a kerberized protocol getting that right. So I'll probably resist running kerberos for a long time, but I'd run a well integrated challenge/response system today if it were available. S/Key isn't exactly what I'd call well integrated, but it does follow the challenge response model and it probably could be integrated into a client. Dave Bridgham From owner-imap@cac.washington.edu Wed Dec 8 13:28:28 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA24569; Wed, 8 Dec 93 13:28:28 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14652; Wed, 8 Dec 93 13:25:40 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from Slapshot.Stanford.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14646; Wed, 8 Dec 93 13:25:38 -0800 Received: from localhost (schemers@localhost) by Slapshot.Stanford.EDU (8.6.4/8.6.4) id NAA18826; Wed, 8 Dec 1993 13:25:34 -0800 From: schemers@Slapshot.Stanford.EDU (Roland J. Schemers III) Message-Id: <9312081325.ZM18824@Slapshot.Stanford.EDU> Date: Wed, 8 Dec 1993 13:25:33 -0800 In-Reply-To: dab@epilogue.com "S/Key (challenge/response) login and IMAP" (Dec 8, 3:36pm) References: <9312081536.aa00962@quern.epilogue.com> X-Mailer: Z-Mail (2.1.5 09aug93) To: dab=replies@epilogue.com, morgan@networking.stanford.edu Subject: Re: S/Key (challenge/response) login and IMAP Cc: imap@cac.washington.edu On Dec 8, 3:36pm, dab@epilogue.com wrote: > the Kerberos server, get involved. I also prefer not to have my > authentication time out. Is the kerberos support in imap such that it > automatically gets a new key when the old one times out? That would > be nice but it would be the first time I've heard of a kerberized > protocol getting that right. I don't really understand this comment. In the normal use you would present a kerberos ticket when you initially connect. After you connect and have a TCP/IP session the Kerberos ticket is never used again. If the files you are accessing through IMAP are in AFS then you have to worry about your AFS token timing out after 25 hours, but that doesn't sound like what you are talking about. Now if you are talking about a kerberized IMAP client that connects and disconnects over and over then of course the IMAP client needs to prompt the user for a password when the ticket expires. Roland -- Roland J. Schemers III | Networking Systems Systems Programmer | 414 Sweet Hall +1 (415) 723-6740 Distributed Systems Operations | Stanford, CA 94305-3090 Stanford University | schemers@Slapshot.Stanford.EDU From owner-imap@cac.washington.edu Wed Dec 8 14:20:42 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA25933; Wed, 8 Dec 93 14:20:42 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15797; Wed, 8 Dec 93 14:18:28 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailhost2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15789; Wed, 8 Dec 93 14:18:26 -0800 Received: from shiva2.cac.washington.edu by mailhost2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA17680; Wed, 8 Dec 93 14:18:17 -0800 Date: Wed, 8 Dec 1993 14:18:16 -0800 (PST) From: Terry Gray Subject: Re: S/Key (challenge/response) login and IMAP To: RL Bob Morgan Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 Dec 1993, RL Bob Morgan wrote: > > Given that Kerberos support is a done deal, > > Done? I know it's in the protocol, but are there clients and servers that > support it that are in production use today? Could we have a roll-call here? I > don't see any Kerberos references anywhere in c-client. Am I missing > something? I just meant that it was a done deal in the protocol spec. However, the hooks will show up in c-client pretty soon. Both CMU and ISA are anxiously awaiting that. -teg From owner-imap@cac.washington.edu Wed Dec 8 14:39:06 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA26770; Wed, 8 Dec 93 14:39:06 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11462; Wed, 8 Dec 93 14:37:45 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11456; Wed, 8 Dec 93 14:37:42 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA26368; Wed, 8 Dec 93 14:37:35 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA11423; Wed, 8 Dec 93 14:37:29 -0800 Date: Wed, 8 Dec 1993 14:13:33 -0800 (PST) From: Mark Crispin Subject: Re: S/Key (challenge/response) login and IMAP To: IMAP Interest List In-Reply-To: <9312081325.ZM18824@Slapshot.Stanford.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I have been following these messages with great interest. I haven't spoken up about the technical merits of S/Key, or S/Key vs. Kerberos, because I am not an expert on authentication systems. Nor do I play one on TV ;-) I'm abstaining in this vote... There definitely *are* plans to integrate Kerberos into c-client, and also there are plans to upgrade c-client to the latest IMAP2bis/IMAP4 document once the dust settles on that. The current state of c-client is thus very much ``work in progress.'' It reflects IMAP2bis thinking as of last July, and is not authoritative about the current state of IMAP. I do have some concerns about the S/Key vs. Kerberos question. I really don't know the answers to any of these questions; I hope that we can get some clarifications. 1) What is the proposal? Proposed and real methods of authentication are: a) plaintext LOGIN command b) external authentication (e.g. the rimapd kludge) c) Kerberos d) S/Key c-client presently supports (a) and (b), and (c) is being added now. There are different interpretations of (d): d1) add S/Key as Yet Another Authentication mechanism d2) replace (c) with (d) d3) use S/Key as an alternative mechanism in (b) 2) Is S/Key as good as its proponents claim? Are there any security problems introduced by S/Key? 3) What is the likelihood that S/Key support will enhance (or reduce) the attractiveness of IMAP? a) How widespread is S/Key? I had never heard of it before Bob's first message. b) Does it make IMAP too complex? c) Is S/Key entangled with any licensing or export restrictions? d) What vendor support is there for S/Key? 4) A couple of messages suggest that Kerberos support may reduce the attractiveness of IMAP. Is this really true, and should Kerberizing work on IMAP stop? 5) Are there any other political consequences of considering S/Key? a) Would we be inadvertantly taking a side in an external protocol war (e.g. ``The IMAP group has adopted S/Key, so you must adopt it too.'')? This wouldn't be the first time such has happened, with disasterous consequences. b) Would we be inadvertantly taking a side in a external architecture war? 6) Is there any kind of group concensus on this issue? I look forward to seeing more comments, as well as a concrete proposal of how S/Key authentication might work in IMAP. One specific question that I have is could S/Key authentication use the existing external authentication mechanism as suggested by (1d3) above. Thanks! -- Mark -- From owner-imap@cac.washington.edu Wed Dec 8 15:06:53 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27717; Wed, 8 Dec 93 15:06:53 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA17191; Wed, 8 Dec 93 15:04:35 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from yarrina.connect.com.au by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA17181; Wed, 8 Dec 93 15:04:30 -0800 Received: from bushwire.apana.org.au by yarrina.connect.com.au with SMTP id AA09880 (5.67a8/IDA-1.5 for ); Thu, 9 Dec 1993 10:04:14 +1100 Received: from localhost (markd@localhost) by bushwire.apana.org.au (8.6.4/8.6.4-D) id KAA00544; Thu, 9 Dec 1993 10:04:09 +1100 Date: Thu, 9 Dec 1993 09:54:17 +1100 (EST) From: Mark Delany Subject: Re: S/Key (challenge/response) login and IMAP To: Mark Crispin Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 8 Dec 1993, Mark Crispin wrote: > I do have some concerns about the S/Key vs. Kerberos question. I > really don't know the answers to any of these questions; I hope that > we can get some clarifications. > 1) What is the proposal? Could I add a 7) ? Is *all* of the associated technology exportable from the US to foreign (and potential hostile I presume) countries such as Australia? Importantly, will such an authentication scheme interoperate between the two countries? Ie, no algorithm substitution strategies *please*. M. From owner-imap@cac.washington.edu Wed Dec 8 15:54:03 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA29403; Wed, 8 Dec 93 15:54:03 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11799; Wed, 8 Dec 93 15:51:38 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SIGURD.INNOSOFT.COM by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11793; Wed, 8 Dec 93 15:51:31 -0800 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-1 #1234) id <01H68JBNRABK9GV9DW@SIGURD.INNOSOFT.COM>; Wed, 8 Dec 1993 15:50:52 PDT Date: Wed, 08 Dec 1993 15:01:01 -0700 (PDT) From: Ned Freed Subject: RE: S/Key (challenge/response) login and IMAP In-Reply-To: Your message dated "Wed, 08 Dec 1993 14:13:33 -0800 (PST)" To: Mark Crispin Cc: IMAP Interest List Message-Id: <01H68QLYIJEC9GV9DW@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > 2) Is S/Key as good as its proponents claim? Are there any security problems > introduced by S/Key? If we're actually going to consider alternatives of this sort, I think we should also look at the APOP facility of POP3 (RFC1460). This scheme has two crucial advantages over S/Key: - All the stuff about a finite number of uses before a reset is needed goes away. - Arbitrary passwords can be used, as opposed to some machine generated stuff that users are certain to write down. There's one corresponding disadvantage: - The server has to have a copy of the cleartext password. The advantages far outweighs the disadvantage, in my opinion. I also think that S/Key needs to shift to using MD5, as some analysis has shown the potential for weakness in MD4, but this is just a minor nit. Let me now continue and answer Mark's questions in regards to APOP: > 3) What is the likelihood that S/Key support will enhance (or reduce) the > attractiveness of IMAP? > a) How widespread is S/Key? I had never heard of it before Bob's first > message. There are several implementations of APOP currently in use on the Internet. I don't have actual usage stats, but there is a nontrivial user base. > b) Does it make IMAP too complex? It didn't make POP3 too complex, and POP3 is far simpler than IMAP. > c) Is S/Key entangled with any licensing or export restrictions? The only algorithm involved in APOP is MD5, which is unrestricted. > d) What vendor support is there for S/Key? We've received requests for APOP. > 4) A couple of messages suggest that Kerberos support may reduce the > attractiveness of IMAP. Is this really true, and should Kerberizing work > on IMAP stop? No. People who don't want Kerberos don't have to use it. > 5) Are there any other political consequences of considering S/Key? > a) Would we be inadvertantly taking a side in an external protocol war > (e.g. ``The IMAP group has adopted S/Key, so you must adopt it too.'')? > This wouldn't be the first time such has happened, with disasterous > consequences. APOP was uncontroversial. > b) Would we be inadvertantly taking a side in a external architecture war? I don't think so. > 6) Is there any kind of group concensus on this issue? Enough for APOP to be a Draft Standard. Ned From owner-imap@cac.washington.edu Wed Dec 8 16:27:57 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA00805; Wed, 8 Dec 93 16:27:57 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19302; Wed, 8 Dec 93 16:26:49 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from yarrina.connect.com.au by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19296; Wed, 8 Dec 93 16:26:41 -0800 Received: from bushwire.apana.org.au by yarrina.connect.com.au with SMTP id AA15778 (5.67a8/IDA-1.5 for ); Thu, 9 Dec 1993 11:18:46 +1100 Received: from localhost (markd@localhost) by bushwire.apana.org.au (8.6.4/8.6.4-D) id LAA01276; Thu, 9 Dec 1993 11:18:38 +1100 Date: Thu, 9 Dec 1993 11:17:29 +1100 (EST) From: Mark Delany Reply-To: Mark Delany Subject: Re: S/Key (challenge/response) login and IMAP To: Mark Crispin , IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Thu, 9 Dec 1993, Mark Delany wrote: > Is *all* of the associated technology exportable from the US to Oops. MRC has indeed asked this as a part of 3) sorry. M. From owner-imap@cac.washington.edu Wed Dec 8 17:58:51 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03265; Wed, 8 Dec 93 17:58:51 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12440; Wed, 8 Dec 93 17:57:05 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from wizard-gw.qualcomm.com by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12434; Wed, 8 Dec 93 17:57:02 -0800 Received: from [129.46.162.36] by qualcomm.com; id RAA08602 sendmail 8.6.4/QC-main-2.2 via SMTP Wed, 8 Dec 1993 17:49:08 -0800 Message-Id: <199312090149.RAA08602@qualcomm.com> X-Sender: sdorner@wizard.qualcomm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Dec 1993 19:51:16 -0600 To: Ned Freed , Mark Crispin From: sdorner@qualcomm.com (Steve Dorner) Subject: RE: S/Key (challenge/response) login and IMAP Cc: IMAP Interest List At 3:01 PM 12/8/93 -0700, Ned Freed wrote: >should also look at the APOP facility of POP3 (RFC1460). >... >There's one corresponding disadvantage: > > - The server has to have a copy of the cleartext password. > >The advantages far outweighs the disadvantage, in my opinion. Cleartext passwords on user machines (as opposed to the hypothetical highly-secure Kerberos server) are totally unacceptable to a lot of people. I'm not expressing an opinion one way or another, just noting that mileage varies dramatically. >There are several implementations of APOP currently in use on the Internet. >I don't have actual usage stats, but there is a nontrivial user base. For what it's worth, Eudora supports APOP. I know of only one user who has used it. -- Steve Dorner, Qualcomm Inc. "Don't give up hope. Everyone is cured sooner or later. In the end we shall shoot you." - George Orwell From owner-imap@cac.washington.edu Wed Dec 8 18:09:11 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03440; Wed, 8 Dec 93 18:09:11 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12514; Wed, 8 Dec 93 18:07:59 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO4.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12508; Wed, 8 Dec 93 18:07:57 -0800 Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.6.4/8.6.4) id VAA15008 for imap@cac.washington.edu; Wed, 8 Dec 1993 21:06:40 -0500 Received: via switchmail; Wed, 8 Dec 1993 21:06:38 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 8 Dec 1993 21:04:50 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 8 Dec 1993 21:04:43 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 8 Dec 1993 21:04:37 -0500 (EST) Message-Id: Date: Wed, 8 Dec 1993 21:04:37 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: S/Key (challenge/response) login and IMAP In-Reply-To: <01H68QLYIJEC9GV9DW@SIGURD.INNOSOFT.COM> References: <01H68QLYIJEC9GV9DW@SIGURD.INNOSOFT.COM> Beak: Is Ned Freed writes: > - The server has to have a copy of the cleartext password. That's a pretty major disadvantage. It either requires each service to have a different password database, which is a management nightmare for both users and administrators, or it requires the users' cleartext passwords to be distributed to every server, which is an unacceptable security risk. From owner-imap@cac.washington.edu Wed Dec 8 18:16:20 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03662; Wed, 8 Dec 93 18:16:20 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA21321; Wed, 8 Dec 93 18:14:52 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from SIGURD.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA21315; Wed, 8 Dec 93 18:14:47 -0800 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-1 #1234) id <01H68VKB3PDS9GV9L1@SIGURD.INNOSOFT.COM>; Wed, 8 Dec 1993 18:14:19 PDT Date: Wed, 08 Dec 1993 18:13:44 -0700 (PDT) From: Ned Freed Subject: RE: S/Key (challenge/response) login and IMAP In-Reply-To: Your message dated "Wed, 08 Dec 1993 19:51:16 -0600" <199312090149.RAA08602@qualcomm.com> To: sdorner@qualcomm.com Cc: Ned Freed , Mark Crispin , IMAP Interest List Message-Id: <01H68VLTM1O49GV9L1@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > For what it's worth, Eudora supports APOP. I know of only one user who has > used it. I know of several sites that use it or are planning to use it very heavily. We're talking thousands of users here. Ned From owner-imap@cac.washington.edu Wed Dec 8 19:26:30 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04489; Wed, 8 Dec 93 19:26:30 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12829; Wed, 8 Dec 93 19:25:40 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12823; Wed, 8 Dec 93 19:25:39 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.6.4/8.6.4) id WAA17983 for imap@cac.washington.edu; Wed, 8 Dec 1993 22:25:37 -0500 Received: via switchmail; Wed, 8 Dec 1993 22:25:36 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 8 Dec 1993 22:24:34 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Wed, 8 Dec 1993 22:24:29 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Wed, 8 Dec 1993 22:24:25 -0500 (EST) Message-Id: <4h1ddd_00WBwQJz14Q@andrew.cmu.edu> Date: Wed, 8 Dec 1993 22:24:25 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: S/Key (challenge/response) login and IMAP In-Reply-To: References: Beak: is Not Mark Crispin writes: > 2) Is S/Key as good as its proponents claim? Are there any security problems > introduced by S/Key? I grabbed a copy of the S/Key implementation on crimelab.com and found a few serious problems. If a black hat server convinces a user to log into it, it can issue a challenge consisting of an iteration count of 1 and a seed corresponding to some other server. The black hat server now has sufficient information to log into the other server as the user. The implementation chooses seeds in such a way that it is relatively likely for a user to have the same seed for multiple machines. The implementation does not lock its database file. Instead it "mediates" concurrent access either using setpriority() or not at all. I am concerned that S/Key appears to not have been adequately reviewed by security experts. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Thu Dec 9 06:53:20 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12666; Thu, 9 Dec 93 06:53:20 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27223; Thu, 9 Dec 93 06:47:23 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from [128.224.1.136] by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27217; Thu, 9 Dec 93 06:47:20 -0800 To: schemers@slapshot.stanford.edu Cc: morgan@networking.stanford.edu, imap@cac.washington.edu In-Reply-To: "Roland J. Schemers III"'s message of Wed, 8 Dec 1993 13:25:33 -0800 <9312081325.ZM18824@Slapshot.Stanford.EDU> Subject: S/Key (challenge/response) login and IMAP Reply-To: dab=replies@epilogue.com Date: Thu, 9 Dec 93 9:45:56 EST From: dab@epilogue.com Message-Id: <9312090945.aa05095@quern.epilogue.com> From: "Roland J. Schemers III" Date: Wed, 8 Dec 1993 13:25:33 -0800 On Dec 8, 3:36pm, dab@epilogue.com wrote: > the Kerberos server, get involved. I also prefer not to have my > authentication time out. Is the kerberos support in imap such that it > automatically gets a new key when the old one times out? I don't really understand this comment. In the normal use you would present a kerberos ticket when you initially connect. After you connect and have a TCP/IP session the Kerberos ticket is never used again. It's entirely possible that I misunderstood Kerberos on this point. That would be good as it would make Kerberos eminently more usable. I understood that when your Kerberos ticket timed out, the server was supposed to boot you off even though you're already past the authentication step in the protocol. Perhaps I've been confused by thinking of MFS based protocols where you include the ticket in each packet so you're continually using the ticket. Dave From owner-imap@cac.washington.edu Thu Dec 9 06:58:50 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12769; Thu, 9 Dec 93 06:58:50 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27279; Thu, 9 Dec 93 06:53:31 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from [128.224.1.136] by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27273; Thu, 9 Dec 93 06:53:27 -0800 To: IMAP@cac.washington.edu In-Reply-To: Ned Freed's message of Wed, 08 Dec 1993 15:01:01 -0700 (PDT) <01H68QLYIJEC9GV9DW@SIGURD.INNOSOFT.COM> Subject: S/Key (challenge/response) login and IMAP Reply-To: dab=replies@epilogue.com Date: Thu, 9 Dec 93 9:51:50 EST From: dab@epilogue.com Message-Id: <9312090951.aa05117@quern.epilogue.com> Date: Wed, 08 Dec 1993 15:01:01 -0700 (PDT) From: Ned Freed > c) Is S/Key entangled with any licensing or export restrictions? The only algorithm involved in APOP is MD5, which is unrestricted. Not true. We've been through all this is a big way with SNMP. The situation is complex and confused (mostly confused) but the bottom line is you need an export license to export cryptographic technology from the US, other countries may and do vary. The point about MD5 is that it's believed that you will be able to get such a license. Some lawyers even claim that you can ship MD5 under general license whichs means you don't have to get an explicit license. But ANY cryptographic technology needs a license. No, I don't know how they define "cryptographic technology". That's part of the confused bit. Dave From owner-imap@cac.washington.edu Thu Dec 9 07:56:22 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14177; Thu, 9 Dec 93 07:56:22 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15834; Thu, 9 Dec 93 07:52:49 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15826; Thu, 9 Dec 93 07:51:05 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.6.4/8.6.4) id KAA08385; Thu, 9 Dec 1993 10:51:00 -0500 Received: via switchmail; Thu, 9 Dec 1993 10:50:59 -0500 (EST) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 9 Dec 1993 10:49:39 -0500 (EST) Received: from cortland.andrew.cmu.edu via qmail ID ; Thu, 9 Dec 1993 10:49:32 -0500 (EST) 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; Thu, 9 Dec 1993 10:49:03 -0500 (EST) Message-Id: Date: Thu, 9 Dec 1993 10:49:03 -0500 (EST) From: Wallace Colyer To: imap@cac.washington.edu, RL "Bob" Morgan Subject: Re: S/Key (challenge/response) login and IMAP Cc: morgan@networking.stanford.edu, Terry Gray In-Reply-To: References: Excerpts from internet.computing.imap: 8-Dec-93 Re: S/Key (challenge/respon.. RL "Bob" Morgan@networki (2714*) > > Given that Kerberos support is a done deal, > Done? I know it's in the protocol, but are there clients and servers that > support it that are in production use today? Could we have a roll-call > here? I don't see any Kerberos references anywhere in c-client. Am I > missing something? Depends on your definition of production. I use Unix pine to connect to a IMAPD which supports kerberos logins to read my mail every day. The c-client work we are waiting on is a better integration. Excerpts from internet.computing.imap: 8-Dec-93 S/Key (challenge/response) .. dab@epilogue.com (1220) > Kerberos was great for Project Athena at MIT because they wanted > centralized control of authentication over hundreds of unix > workstations. I prefer not to have a trusted third party, such as the Kerberos server, get involved. We have over 6 kerberos realms at CMU and share keys with all of them to that functions can interopertate between them. Kerberos does not have to be monolithic, but there is overhead to setting up a new realm. -Wallace From owner-imap@cac.washington.edu Thu Dec 9 08:44:28 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA15432; Thu, 9 Dec 93 08:44:28 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA28938; Thu, 9 Dec 93 08:43:38 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva1.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA28932; Thu, 9 Dec 93 08:43:37 -0800 Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04763; Thu, 9 Dec 93 08:43:23 -0800 Date: Thu, 9 Dec 1993 08:43:22 -0800 (PST) From: David L Miller Subject: Re: S/Key (challenge/response) login and IMAP To: dab=replies@epilogue.com Cc: schemers@slapshot.stanford.edu, morgan@networking.stanford.edu, imap@cac.washington.edu In-Reply-To: <9312090945.aa05095@quern.epilogue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Kerberos can be used for anything from one time authentication on login to full encryption. Per-packet and encryption are where you run into timeout problems. The mode used in IMAP is to simply replace the clear text password on login with the Kerberos key. Anything else would require severe changes to the protocol. |¥ | |¥/| 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, 9 Dec 1993 dab@epilogue.com wrote: > From: "Roland J. Schemers III" > Date: Wed, 8 Dec 1993 13:25:33 -0800 > > On Dec 8, 3:36pm, dab@epilogue.com wrote: > > the Kerberos server, get involved. I also prefer not to have my > > authentication time out. Is the kerberos support in imap such that it > > automatically gets a new key when the old one times out? > > I don't really understand this comment. In the normal use you > would present a kerberos ticket when you initially connect. After > you connect and have a TCP/IP session the Kerberos ticket is never > used again. > > It's entirely possible that I misunderstood Kerberos on this point. > That would be good as it would make Kerberos eminently more usable. I > understood that when your Kerberos ticket timed out, the server was > supposed to boot you off even though you're already past the > authentication step in the protocol. > > Perhaps I've been confused by thinking of MFS based protocols where > you include the ticket in each packet so you're continually using the > ticket. > > Dave > From owner-imap@cac.washington.edu Thu Dec 9 21:29:43 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04535; Thu, 9 Dec 93 21:29:43 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12469; Thu, 9 Dec 93 21:26:54 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from wizard-gw.qualcomm.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12463; Thu, 9 Dec 93 21:26:49 -0800 Received: from DialupEudora by qualcomm.com; id VAA06623 sendmail 8.6.4/QC-main-2.2 via SMTP Thu, 9 Dec 1993 21:26:44 -0800 for Message-Id: <199312100526.VAA06623@qualcomm.com> X-Sender: sdorner@wizard.qualcomm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Dec 1993 23:28:48 -0600 To: imap@cac.washington.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Configuration & IMAP I hear people with rampant fantasies that IMAP will allow students to just wander into a lab and get to their mail, without needing any local storage, eg: >"Saved-message folders may be stored on server (as well as INBOX)" allows >"dataless" clients and/or nomadic users (e.g. student labs). I can't quite see this in light of: > IMAP2bis does not address problems with ... mobility of client > configuration and address book information. These and other issues > are being considered for a companion protocol. Where can I find information on this companion protocol? -- Steve Dorner, Qualcomm Inc. "Don't give up hope. Everyone is cured sooner or later. In the end we shall shoot you." - George Orwell From owner-imap@cac.washington.edu Thu Dec 9 21:47:06 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04699; Thu, 9 Dec 93 21:47:06 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19753; Thu, 9 Dec 93 21:45:58 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA19747; Thu, 9 Dec 93 21:45:56 -0800 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA29839; Thu, 9 Dec 93 21:45:51 -0800 Date: Thu, 9 Dec 1993 21:43:33 -0800 (PST) From: Mark Crispin Subject: re: Configuration & IMAP To: Steve Dorner Cc: imap@cac.washington.edu In-Reply-To: <199312100526.VAA06623@qualcomm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Steve - John Myers and Chris Newman at CMU are working on IMSP, the support protocol for IMAP. A copy of a draft of the IMAP specification is on ftp.cac.washington.edu as mail/imsp-9307.txt I'm sure that John and Chris have a newer version. By the way, if you can overlook the address book issue and assume a constant configuration, it is already possible to do the no-local-storage model. We do it. -- Mark -- From owner-imap@cac.washington.edu Thu Dec 9 21:58:11 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA04782; Thu, 9 Dec 93 21:58:11 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12685; Thu, 9 Dec 93 21:57:13 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from THOR.INNOSOFT.COM by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12679; Thu, 9 Dec 93 21:57:11 -0800 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H69O6D7R8G9I43KO@INNOSOFT.COM>; Thu, 9 Dec 1993 21:56:55 PST Date: Thu, 09 Dec 1993 21:34:37 -0800 (PST) From: Ned Freed Subject: Re: S/Key (challenge/response) login and IMAP In-Reply-To: Your message dated "Thu, 09 Dec 1993 09:51:50 -0500 (EST)" <9312090951.aa05117@quern.epilogue.com> To: dab@epilogue.com Cc: IMAP@cac.washington.edu Message-Id: <01H6AHO5SX849I43KO@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > > The only algorithm involved in APOP is MD5, which is unrestricted. > Not true. We've been through all this is a big way with SNMP. The > situation is complex and confused (mostly confused) but the bottom > line is you need an export license to export cryptographic technology > from the US, other countries may and do vary. > The point about MD5 is that it's believed that you will be able to get > such a license. Some lawyers even claim that you can ship MD5 under > general license whichs means you don't have to get an explicit > license. I thought this had in fact been confirmed. In fact, I believe that it has now possible to export authentication-only Kerberos systems -- I know of at least one company that had lawyers dig into this and I think that they are now licensed to ship Kerberized software overseas. Let's face it, MD5 is just a hash function. If it isn't legal to export MD5, the folks maintaining the RFC archives better remove a bunch of documents from their servers... Ned From owner-imap@cac.washington.edu Thu Dec 9 22:14:55 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA05007; Thu, 9 Dec 93 22:14:55 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12836; Thu, 9 Dec 93 22:13:53 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from shiva2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA12830; Thu, 9 Dec 93 22:13:52 -0800 Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03950; Thu, 9 Dec 93 22:13:51 -0800 Date: Thu, 9 Dec 1993 22:13:49 -0800 (PST) From: David L Miller Subject: re: Configuration & IMAP To: Mark Crispin Cc: Steve Dorner , imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII And as soon as Mark gets the phile driver finished (read/write) we will be able to have remote addressbooks as well... |¥ | |¥/| 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, 9 Dec 1993, Mark Crispin wrote: > Steve - > > John Myers and Chris Newman at CMU are working on IMSP, the support > protocol for IMAP. A copy of a draft of the IMAP specification is on > ftp.cac.washington.edu as mail/imsp-9307.txt > > I'm sure that John and Chris have a newer version. > > By the way, if you can overlook the address book issue and assume a > constant configuration, it is already possible to do the no-local-storage > model. We do it. > > -- Mark -- > > From owner-imap@cac.washington.edu Fri Dec 10 07:15:21 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA10646; Fri, 10 Dec 93 07:15:21 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16584; Fri, 10 Dec 93 07:14:26 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from quern.epilogue.com by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16578; Fri, 10 Dec 93 07:14:23 -0800 To: NED@innosoft.com Cc: IMAP@cac.washington.edu In-Reply-To: Ned Freed's message of Thu, 09 Dec 1993 21:34:37 -0800 (PST) <01H6AHO5SX849I43KO@INNOSOFT.COM> Subject: S/Key (challenge/response) login and IMAP Reply-To: dab=replies@epilogue.com Date: Fri, 10 Dec 93 10:14:03 EST From: dab@epilogue.com Message-Id: <9312101014.aa18574@quern.epilogue.com> Date: Thu, 09 Dec 1993 21:34:37 -0800 (PST) From: Ned Freed I thought this had in fact been confirmed. In fact, I believe that it has now possible to export authentication-only Kerberos systems -- I know of at least one company that had lawyers dig into this and I think that they are now licensed to ship Kerberized software overseas. That's my point. They spent the lawyer time and now they're LICENSED to ship Kerberos. I didn't say it was not legal to export crypto software, I said you needed a license. I also passed on that one set of lawyers that I know decided that MD5 authentication is exportable under a thing called the general license, which means you don't have to actually get yourself a license. However, someone reported on an SNMP mailing list that their company was denied an export license for MD5 authentication. Each case is different. That's why I called the situation confused. Cynics might suggest intentionally so. Let's face it, MD5 is just a hash function. If it isn't legal to export MD5, the folks maintaining the RFC archives better remove a bunch of documents from their servers... Possibly a problem. Also arguable that they havn't exported any software but the person who does the actual FTP transfer does the exporting. Also arguable that they aren't exporting software but have just published algorithms. Publishing appears to not have such restrictions (after all, all the algorithms have been put to paper in journals and books and sent all over the world). We won't know the answer until someone goes to court and then we still won't really know the answer because it might change next time. I'm not a lawyer and I don't play one on the net. I'm passing on what I've learned so that everyone else out there who also isn't a lawyer understands that they should get competent legal advise before getting into more hot water than they can stand. Or at least has an inkling of what hot water might lay ahead and can judge for themselves whether or not to leap in. Dave Bridgham From owner-imap@cac.washington.edu Fri Dec 10 08:08:42 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA11502; Fri, 10 Dec 93 08:08:42 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA17158; Fri, 10 Dec 93 08:08:18 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from PO3.ANDREW.CMU.EDU by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA17152; Fri, 10 Dec 93 08:08:16 -0800 Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.6.4/8.6.4) id LAA09967 for imap@cac.washington.edu; Fri, 10 Dec 1993 11:08:10 -0500 Received: via switchmail; Fri, 10 Dec 1993 11:08:09 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 10 Dec 1993 11:07:24 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 10 Dec 1993 11:07:22 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 10 Dec 1993 11:07:19 -0500 (EST) Message-Id: Date: Fri, 10 Dec 1993 11:07:19 -0500 (EST) From: John Gardiner Myers To: imap@cac.washington.edu Subject: Re: Configuration & IMAP In-Reply-To: References: Beak: Is The canonical location for the IMSP draft specification and alpha-test server is on export.acs.cmu.edu in pub/cyrus-mail/ -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-imap@cac.washington.edu Wed Dec 15 06:04:04 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23586; Wed, 15 Dec 93 06:04:04 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03663; Wed, 15 Dec 93 07:31:10 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from snow.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA03657; Wed, 15 Dec 93 07:31:03 -0800 Received: from quinag.csi.cam.ac.uk by ppsw2.cam.ac.uk with SMTP-CAM (PP-6.0) as ppsw.cam.ac.uk id <29662-0@ppsw2.cam.ac.uk>; Wed, 15 Dec 1993 15:30:28 +0000 Date: Wed, 15 Dec 1993 15:29:09 GMT From: Barry Landy Subject: IMAP-ware To: imap@cac.washington.edu X-Sender: bl10@cus.cam.ac.uk Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone have latest news on the state of IMAP-ware, especially for MACs, please? ------------------------------------------------------------------------------- Barry Landy Computer Laboratory:+44 223 334600 Head of Systems and Development Direct line: +44 223 334713 University of Cambridge Computing Service New Museums Site Email:Barry.Landy@ucs.cam.ac.uk Pembroke Street, Cambridge CB2 3QG From owner-imap@cac.washington.edu Thu Dec 16 05:20:24 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA22957; Thu, 16 Dec 93 05:20:24 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23272; Thu, 16 Dec 93 08:49:47 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from mailhost2.cac.washington.edu by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA23266; Thu, 16 Dec 93 08:49:45 -0800 Received: from shiva1.cac.washington.edu by mailhost2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA27149; Thu, 16 Dec 93 08:48:50 -0800 Date: Thu, 16 Dec 1993 08:48:49 -0800 (PST) From: Terry Gray Subject: Re: IMAP-ware To: Barry Landy Cc: imap@cac.washington.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Barry, The file ftp.cac.washington.edu: /mail/imap.software contains the latest info I have been given. The only additions I've heard about recently are that the CMU folks are considering adapting their existing Mac mail client to IMAP, and I'm now aware of one other person working on IMAPifying Elm. If anyone has any other additions, please post to the list as I expect there is general interest in such info, and I'll try to keep the file mentioned above updated. -teg On Wed, 15 Dec 1993, Barry Landy wrote: > Does anyone have latest news on the state of IMAP-ware, especially for > MACs, please? > > ------------------------------------------------------------------------------- > Barry Landy Computer Laboratory:+44 223 334600 > Head of Systems and Development Direct line: +44 223 334713 > University of Cambridge Computing Service > New Museums Site Email:Barry.Landy@ucs.cam.ac.uk > Pembroke Street, Cambridge CB2 3QG > > From owner-imap@cac.washington.edu Wed Dec 29 12:56:26 1993 Received: from mx1.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16938; Wed, 29 Dec 93 12:56:26 -0800 Received: by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16360; Wed, 29 Dec 93 13:01:51 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from gray.csi.cam.ac.uk by mx1.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA16354; Wed, 29 Dec 93 13:01:50 -0800 Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk with GB-CAM (PP-6.0) as ppsw.cam.ac.uk id <17161-0@ppsw1.cam.ac.uk>; Wed, 29 Dec 1993 21:01:45 +0000 Date: Wed, 29 Dec 93 21:01:40 GMT From: A.Grant@ucs.cam.ac.uk To: imap@cac.washington.edu Subject: SELECT and possible race condition? Message-Id: Suppose I get unsolicited data * 3 EXISTS Which mailbox does this refer to, if I have just sent off a SELECT? How do I know if it relates to the new mailbox or is an asynchronous update about the old one? Is there a race condition here? (Incidentally, it would be helpful if the RFC had section or even paragraph numbers like others do.) From owner-imap@cac.washington.edu Wed Dec 29 13:34:13 1993 Received: from mx2.cac.washington.edu by shivams.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA17784; Wed, 29 Dec 93 13:34:13 -0800 Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14199; Wed, 29 Dec 93 13:35:59 -0800 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.29 ) id AA14193; Wed, 29 Dec 93 13:35:57 -0800 Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA08096; Wed, 29 Dec 93 13:35:48 -0800 Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA21367; Wed, 29 Dec 93 13:35:40 -0800 Date: Wed, 29 Dec 1993 13:28:54 -0800 (PST) From: Mark Crispin Subject: re: SELECT and possible race condition? To: A.Grant@ucs.cam.ac.uk Cc: IMAP Interest List In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Wed, 29 Dec 93 21:01:40 GMT, A.Grant@ucs.cam.ac.uk wrote: > Suppose I get unsolicited data > > * 3 EXISTS > > Which mailbox does this refer to, if I have just sent off a SELECT? It refers to the new mailbox. If a server implementation sends an EXISTS for the previous mailbox, it's a server bug. The c-client based server might have this bug (failing to go silent on update events during closing); if it does, I'll fix it. > How do I know if it relates to the new mailbox or is an asynchronous > update about the old one? Is there a race condition here? This is one of two problem with the whole notion of asynchronous responses in IMAP; the other being the flow control problem. IMAP is not asynchronous; there is a definite command/response interaction. What IMAP does have is the ability for other things to happen in a response besides what is strictly necessary to answer the command. > (Incidentally, it would be helpful if the RFC had section or even > paragraph numbers like others do.) Suggestion noted.