Path: utzoo!mnetor!uunet!mcvax!unido!iraun1!iravcl!joachim From: joachim@iravcl.ira.uka.de Newsgroups: comp.protocols.appletalk Subject: Re: Macintosh mail systems. Message-ID: <96@iravcl.ira.uka.de> Date: 18 Apr 88 21:15:33 GMT Lines: 189 Organisation: Universitaet Karlsruhe, IRA, F.R. Germany There has been an ongoing discussion about Macintosh mail systems in the past days, and as David suggested, anyone should state his/her requirements. The following text will outline the requirements/interface that I see. This is not intended to be a full spec, although we are thinking about implementing it. I am a student of computer science at University of Karlsruhe, Federal Republic of Germany, and I am involved in Macintosh projects at that university. I am a computer consultant, too. There is no big difference between the requirements at our university and large companies in Germany. 1. Macintoshes are turned on and off frequently, and may be off for long periods of time (e.g. during holidays). Mail must not be returned UNDELIVERABLE because of that. This implies that there must be a mail server. Because most universities and companies already use a UNIX/VMS/other host for mail, using this host to serve Macintosh mail is the most likely solution. This does not imply however, that s/he is allowed to login to that host. There are a number of possibilities, how the Macintosh front-end might communicate to the host, two of them are MacWorkstation and an AppleTalk service (based on CAP, AlisaTalk, ..), others might be SMTP, NNTP which I am not familar with. The protocol may be proprietary, because it is only used to communicate to the mail server, not to the world. Of course if Apple released their specification of the AppleTalk Messaging Protocol (Larry Taylor of Apple talked about it at EUC Heidelberg, April 8th, 1988), I'd go with that, if it suits all needs. 2. There must be a unified interface to mail and news, like the integration present on unix hosts. I don't want to use a mac application to read/send mail and another one to read/post news - or even worse, login on to (different) host to do that. The application should also support digests (whether received by mail or news), and interpret reply or followup sensibly, i.e., reply to the originator of the message, not to the sender of the digest, mail followups to the origin of the digest. 3. Unlike the present mail applications, INBOX and INTERMAIL one cannot assume that all possible recipients are known to the mail server. This could be reasonable for one university or company, but not with the internet behind. Of course, if your site already has a nameserver, the mail application should be able to lookup local mail addresses by name. 4. One cannot assume that anybody is going to use a Macintosh to read her/his mail. This has two consequences: First, if files are to be transferred - and there is definitely a need to include support for that - they must be included in a way that allows them to be extracted manually and processed by some other tool. A simple but sufficient solution is to include them binhexed, each preceeded by a line standard mail will read this just as he always did and fire up binhex or stuffit. A user using the mac mail will read a message that this mail contains files, and choose extract from the file menu... Even if I am using a mac to read mail, I may want to process/archive files on the host. Someone might have mailed me a shar archive for use on the (unix)host, or I may use unxbin on a unix computer and store the files directly to AUFS volumes (that's how I install new stuff). Second, there must be a character set conversion included. If you are only going to mail in English, this is not required. If however, you receive mail from any country, this is important. Imagine German umlauted characters. Of course these characters are included in the Macintosh character set. But they aren't ASCII. If I know that the recipient of the mail is using a mac too, and that the mailers in between don't discard characters with the eigth bit on, I may send the character unchanged, otherwise it has to be mapped to the closest ASCII equivalent, possibly combined by several characters. Alternatively, some other German user is using the German version of the ISO character set. This is ASCII with the special characters [\]{\}~ replaced by German characters. I want to tell my Macintosh that any mail received from this user is to be interpreted using that character set. Another example: VAX/VMS supports multinational characters using an ASCII extension, proprietary to DEC. The point is, that there must be a possibility to convert both incoming and outgoing characters, depending upon the sender/receiver and/or system defaults. I emphasized this point, because this is crucial to our environment - you won't sell your mail program in Germany, if the user gets beeps or garbage typing umlauted characters. Of course this is a marketing decision. Most of the points above are technically, not related to the user interface. The following highlite some of the user related aspects. 5. It should include an editor. It does however not need to be a full blown word processor. If you want to pass your new novel to another mac user, include the document as an attached file. Anything within the range of TeachText and MPW Shell is possible. No styles or justification is required (imagine an IBM PC user, reading your letter on his monochrome card), but font and size should be user selectable. Word wrap should be automatic, based on charcter count, not on the window size. The program should be able to manage arbitrarily large files. This may however be limited to viewing/archiving them, not editing. The largest mail I received was 2 MB and consisted of a uuencoded tar archive. Of course this mail was to be decoded by unix tools, but you don't want your mac to crash because of a large mail. 6. It has become a habit to comment on text by preceeding it with some special character like > and inserting new text. While this is not the only way to point out what you are going to reply to, and especially the mac could provide a more graphic feedback (at least different fonts), this technique is common sense. If the user chooses a function like reply, the macintosh mail program should copy selected text (discontinous selections should be supported) to a new window and mark it as comment. 7. The program must provide for a list of name aliases. This should be entirely transparent to the rest of the program. I.e. there should be no special dedicated menus, but editing the list should be allowed whenever a mail address is required and selected from the list. Selection should be possible by both scrolling/clicking or typing as in standard file. New aliases should be created automatically if you reply to mail. There must be an option to delete no longer used names. 8. While incoming mail should be presented in separate windows automatically, this may not be appropriate for news. A scrolling list of items that can individually or collectively be opened or discarded comes to my mind. There should be either no (prefered) or a very large limit to the number of open windows - aren't you bothered by the finder's limit of 12 windows? 9. There must be an automatic archive feature. I want any incoming mail to be saved automatically, say in a folder named after the sender and with the filename taken from the subject. There should be a flag associated with each newsgroup, whether it should be archived (local or remotely) or not, and this flag should be independent from whether I want to read it or not - I don't read binaries. There should be an option that asks me where to put the file and when it should be resubmitted. I consider this to be an important feature if mail is going to be used in your administration. This will also provide a simple reminders utility, although a real appointment calendar is more superior. 10. There should be an INIT that checks for mail on startup (this could be a RDEV that selects among several mail hosts). There should also be a possibility for the mail host to tell you about new mail arriving during your macintosh work. This could be done using the broadcast mechanism I published in the past (you can get it free, send mail to ry77@dkauni11.bitnet, I'll mail it to you). Joachim Lindenberg, University of Karlsruhe Federal Republic of Germany - West Germany.