GJOF=ֱB,('-44=kʾQGBA?@EMT?TZ0('*46:W;ɺ^JCD>=FNTF>ɮ?*'(/77CƻXG?@>AJRQ?_U/('+36:\Ǽ̾mNFC>>CKQDG:*')/45Dؿž`LJE=?HMIAڳL.)(,25CFD>`|6+)+/15JнĿhQJBABED>O@0--/12:8848=GlhQHC??CFIQj~WI?:8678;?H\ǼiSLGB@BGLQ^{pYNG?:88;>CQ;wUKDA?@ADNXlnSG>:778BFLR_|n]ME><;:=BK_ɿyULHBA@CDIOTzoxlWRI>>=@ADIVʾxZNHC@?@CGKOX_glga[QLGCABFKTksZNEFC>>CGKNRZbjmmc]TNJHHIMTeȿjWMHFBA@CFIMSZajqulf\VOMMMRXhÿ|]PKIGDDEHJLOU^en{x{qaZTPQSZi}¿hYPNMLKJKMOSVZblv{xofj]RTOX\bf]UQOMMLNPUY\air|z|me]XVTUX^ip^VTVTQORSTTUX]bikideb_^]_hozh_\YWTSSTTWXZ_konqf]kNLPJWa\^RQRF?H]ec\bpYWTPIAELPS\Ľ}ZV\cW[RCj?1/.,))/?TįH>@@?G^{ElYXX71/..++7L߿A559?J[׿UFXD.-,+*'+?ʸD5430=\ĻKAP{H.+*++'*>۾B658;Fv¼G:ti3,*)+()9dA647=MüI5L>/,*+*)1TǶG=89?Uj<8]9669:?Wl^YY]]SHNxQC?>?@@GWw¼k_czgcYMR^nYlhZOIEGIIKWdowfei[NL\o\XceVMJGJNLMS_yrneSPN\tk`XPV[SONLLORT]_joqa[SNVcc`TMOSVSSOOW]Z[]yyp~_ZQMSY^VRRORY][RSZa]Wcqw{_WQKW`WXSPRW\[VXZWZ]\fpqf[WOLYc]YRQV`[SSWZ[^_hm|o^ZOL\fl^VVTgYOSSRMZYXexw_WKM]qm[RY]TMHHIJJJOaſ]GOоbNNG:1027ݷPNF1($%+3:CxVPMT¾_6MQC?.#!-:LƯ9.1>]\2C`IG/!!-CIGMhʸO/'EE7#*n?7>HWͼ?/-룝c;. 3ǯs3,>ûL7/ۢN7.!!:W/+>õrl[?3O^4/&!4Z3):ǰh^nO<8;/+!)}@--SK]`ZjQ8>2.(!"3dR:/5ͩW@Vy^cO3@T.,&"!$=eKJ90CEBdi^S3>O+*&$#&?J?D<8<ĦC2GmRQ:6,''''&4T:>A><ᬧV4@XH]J1w2%%'+(,l:8;D?@9.N¾F?~D3Ƣ+$%+/*/㯥;59GBQ94XƽAAdI5ȧ-$#,1+0[E45B=U43M̸DAQؽ_3a?(!(/-0?ϫ:1;Oo[NC:>趨C,&#&+/9Kնm=8>[_N@8=?*$"%+0;Qεj:4:UcPB9;`K,$!$*/9Lܹ=56ErſbOC99Np/% "(.8G񽭧D65?YwXH:8G˭4&!"&-5CbƱ~>8;B^ÿ_M>7=>*"!%+1=OٹN;;@I[S=4:n<*$#',4>L⽭H?Ij_C67W=)#"&,3=P׸l?5;lZJD;=嵧8&""&-5@?8Cÿ^NLH?A6&""'.4AiůD=GoPID>Bⷩ9(##'-3>bƳZILWxypVND=E丫;+'%(,1,''+.08OϽÿlRMH@=BJJ=P~9*&(-14=eƽĵ\@@B@;?>>;=J\SMδN5,,/459LƹbC?>?=P¾¾`QPOLGFKLJKPlbOFA?=>AFPiýkVLHFA>BKR[r^MC=:9:=AI[_MD>=<;;@ITk[KA<:9;>CMbʿtUIB?==<>FNZpoQF>;99;?EOĻ`LD>=<;<>EMXi[LB=;:BIWfnUMDA>>?CJToǾiND><;::<=CKTa}jZOHFFFINXrýeOE?>===?BILOWhno^TNLLNS\ooVKDA????ADINU]ow_]TVRR_n¿gPOHGDEJDGKOZYfmsee]Ybd{n]YQMMJKNNOTT\gdlub^TNcwf[SHIKTO\OOuPIICABALiĽgPNhUJI62/0249L̾hQTZUXcdED{_?/,+,/18MӼ]NSL@FgE5YWkM.%%(.45DįNDINEItSXZ\g^nsn}v]kna{mg`\]XikhYSNILOV_`b`f~vohkmiqmknnr}jcklnlhxn}{zxk`eifclwj`\YXZXZadh{os}jmtpuqkeddefn{o}yup~}}kys~yliflyqsmsnronu]foz[[dR_]mWwjuyoa^bhf_cbjnhq{m~nngx|iwh~n_ccmoxzwxx~xqvp{t}~vr}pywt~}inwkpg_fugj}wtng~sog}mp~nprzzuoglqxio}khxzmnymo||szwnz]}wmzvkze_mj{yuspeox`erk`_{tsgej~}wmuslpox|s{|nmtomxto|xhon}rrtn|wkp~{totno}l~kwlrqg}|jkaywcy{ouy~~vtttjdnrlyffx{lzuwzyxv}qvxvmv{j{kv{hrsnbn}}xv{vnv{wsr{rlgntonz~ur{x{u}xtozbkx}}z}{~t{{yhw}uzz|zw||x{y~{~|}zyy}{||~|~}~qzhql|xzx{xitn|uxzlspw}~jo}fpvnvwmzpo~mll{4D8CC CCCCCCCCCCCCCCCCCCCCCCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFCFD1 D3CFCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCD6E4F0FF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEEEEDDCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCE4FCFFFFFFFFFFFFFFFFFFFFFFFFFFFCE4CC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFepository). The Pcmail design therefore allows two modes of communication between repository and client. "Interactive mode" is used when the client is always connected to the network. Any changes to the client's local mail state are immediately also made to the repository's global mail state, and any incoming mail is immediately transmitted from repository to client. "Batch mode" is used by clients that have infrequent access to the repository. Users manipulate the client's local mail state, queueing the changes locally. When the client is next connected to the repository, the changes are executed, and the client's local mail state is synchronized with the repository's global mail state. Finally, the Pcmail design minimizes the effect of using a resource- poor workstation as a client. Mail messages are split into two Lambert [Page 3] RFC 1056 PCMAIL June 1988 parts: a "descriptor" and a "body". The descriptor is a capsule message summary whose length (typically about 100 bytes) is independent of the actual message length. The body is the actual message text, including an RFC-822 standard message header. While the client may not have enough storage to hold a complete set of messages, it can usually hold a complete set of descriptors, thus providing the user with at least a summary of his mail state. For clients with extremely limited resources, Pcmail allows the storage of partial sets of descriptors. Although this means the user does not have a complete local mail state, he can at least look at summaries of some messages. In the cases where the client cannot immediately store message bodies, it can always pull them over from the repository as storage becomes available. The remainder of this document is broken up into sections discussing the following: - The repository architecture - DMSP, its operations, and motivation for its design - The client architecture - A typical DMSP session between the repository and a client - The current Pcmail implementation - Appendices describing the DMSP protocol in detail 3. Repository architecture A typical machine running repository code has a relatively powerful processor and a large amount of disk storage. It must also be a permanent network site, for two reasons. First, clients communicate with the repository over a network, and rely on the repository's being available at any time. Second, people sending mail to repository users rely on the repository's being available to receive mail at any time. The repository must perform several tasks. First, and most importantly, the repository must efficiently manage a potentially large number of users and their mail states. Mail must be reliably stored in a manner that makes it easy for multiple clients to access the global mail state and synchronize their local mail states with the global state. Since a large category of electronic mail is represented by bulletin boards (bboards), the repository should efficiently manage bboard mail, using a minimum of storage to store Lambert [Page 4] RFC 1056 PCMAIL June 1988 bboard messages in a manner that still allows any user subscribing to the bboard to read the mail. Second, the repository must be able to communicate efficiently with its clients. The protocol used to communicate between repository and client must be reliable and must provide operations that (1) allow typical mail manipulation, and (2) support Pcmail's distributed nature by allowing efficient synchronization between local and global mail states. Third, the repository must be able to process mail from sources outside the repository's own user community (a primary outside source is the Internet). Internet mail will arrive with a NIC RFC-822 standard message header; the recipient names in the message must be properly translated from the RFC-822 namespace into the repository's namespace. 3.1. Management of user mail state Pcmail divides the world into a community of users. Each user is associated with a user object. A user object consists of a unique name, a password (which the user's clients use to authenticate themselves to the repository before manipulating a global mail state), a list of "client objects" describing those clients belonging to the user, a list of "subscription objects", and a list of "mailbox objects". A client object consists of a unique name and a status. A user has one client object for every client he owns; a client cannot communicate with the repository unless it has a corresponding client object in a user's client list. Client objects therefore serve as a means of identifying valid clients to the repository. Client objects also allow the repository to manage local and global mail state synchronization; the repository associates with every client an "update list" of message state changes which have occurred since the client's last synchronization. A client's status is either "active" or "inactive". The repository defines inactive clients as those clients which have not connected to the repository within a set time period (one week in the current repository implementation). When a previously-inactive client does connect to the repository, the repository notifies the client that it has been inactive for some time and should "reset" itself. Resetting a client has the effect of placing every message in every mailbox onto the client's update list. This allows the client to get a fresh global mail state from the repository when it next synchronizes (see synchronization discussion following). The reset is performed on the assumption that enough global state changes occur in a week tFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFE4E4D8CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFCE4CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC E4FCFFFFFFFFFFFFFFFFF6FCE5D0D3CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFCFCFCFCDCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCDAE8E8E8E8FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE6CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCD CCCCCCCCCCCCCCCCCCCCCCCCCCD2D0CEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFCECECECECCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCD2D8EEFCFFFF FFFFFFFFFFFFE9E9E9E9DACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCE4FCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFE\ɾ[NLKKMOXpZUND>:889Ibz`NJHHJLS_hVK@<8668;?Kdļ]OIGHHKOYl}jZNG?;989;?GXaQKIHHILS\did\SLE?=;;=?FOiɿqXMHFFGHLPX_^^[UOJFB@?AEIS~_SKIGGHJMRZadhc]XNJFDCFJN^ſbRLHGHIKNQ]emrjf_XPKIHIKOXjƿjZNJIIJKLP[\deKA<<@CJ]žu|eQA?}I:57813=VʿgJ>>)#!)33@϶NB:?ַUGIE<.2/*?5૤lP>-((4ͳ>/2@վH8GN]slMEOH6^iK4+*7׹Yÿ}E;>NSB?EVM@R_Wb]<5kLB?6-->SIG<59Xg`OGNּVOOMKW[GEGGK\cOISucWb94ΩD@=5--FFBD=7:rQKWZJS׻|KJS[[lHCXSJYaOWS11ʦ:992+-UFBG? RFC 1056 PCMAIL June 1988 following information: the message UID, the message size in bytes and lines, four "useful" message header fields (the "date:", "to:", "from:", and "subject:" fields), and sixteen flags. These flags are given identifying numbers 0 through 15. Eight of these flags have well-known definitions and are reserved for the repository's use. The eight repository-defined flags mark: - (#0) whether the message has been deleted - (#1) whether it has been seen - (#2) whether it has been forwarded to the user - (#3) whether it has been forwarded by the user - (#4) whether it has been filed (written to a text file outside the repository) - (#5) whether it has been printed (locally or remotely) - (#6) whether it has been replied to - (#7) whether it has been copied to another mailbox The remaining eight flags are availble for user use. Descriptors serve as an efficient means for clients to get message information without having to waste time retrieving the entire message from the repository. 3.2. Repository-to-RFC-822 name translation "Address objects" provide the repository with a means for translating the RFC-822-style mail addresses in Internet messages into repository names. The repository provides its own namespace for message identification. Any message is uniquely identified by the triple (user-name, mailbox-name, message-UID). Any mailbox is uniquely identified by the pair (user-name, mailbox-name). In order to translate between RFC-822-style mail addresses and repository names, the repository maintains a list of address objects. Each address object is an association between an RFC-822-style address and a (user-name, mailbox-name) pair. When mail arrives from the Internet, the repository can use the address object list to translate the recipients into (user-name, mailbox-name) pairs and route the message correctly. Lambert [Page 7] RFC 1056 PCMAIL June 1988 4. Communication between repository and client: DMSP The Distributed Mail System Protocol (DMSP) defines and manipulates the objects mentioned in the previous section. It has been designed to work with Pcmail's singlerepository/multiple-client model of the world. In addition to providing typical mail manipulation functions, DMSP provides functions that allow easy synchronization of global and local mail states. DMSP has been completely re-specified in this version of Pcmail. Formerly, DMSP was implemented on top of the USP remote-procedure- call protocol. Since this protocol is not fully unofficially specified (let alone officially specified) anywhere, implementation of USP is difficult for sites wishing to implement Pcmail on different systems. We therefore have decided to completely redesign DMSP. It is now a very simple request/response protocol similar to SMTP or NNTP, running directly on a reliable bidirectional byte- stream such as TCP. The TCP contact port for DMSP has been designated 158. Requests and responses consist of ASCII characters; on octet-based transmission streams, each character is transmitted rightjustified in an octet with the high-order bit cleared to zero. 4.1. DMSP commands DMSP operations consist of an operation name, followed by zero or more tab or space characters, followed by zero or more arguments, each of which is separated from the operation name and other arguments by one or more space or tab characters. All operation requests, as well as all responses, must be terminated with a carriage-return plus line-feed (CR-LF) pair. All operation names and arguments must be taken from the set of alphanumeric characters plus the characters dash ("-"), underscore ("_"), and period ("."). DMSP operation names are case-insensitive; they may be transmitted in any combination of upper and lower case. DMSP arguments are case- insensitive but case-preserving; in other words a mailbox named "MarkL" may be referred to by an operation argument "markl", but will always be stored, and transmitted in a repository response, as "MarkL"; furthermore, any attempt to create a new mailbox "MaRkL" will not be permitted. Each operation argument may contain no more than 64 characters. No single request or response line may contain more than 512 characters, including all white space and the terminating CR-LF. 4.2. DMSP responses A DMSP operation always results in a response, which may be followed Lambert [Page 8] RFC 1056 PCMAIL June 1988 in turn by a list, consisting of zero or more lines of CR-LF- terminated text terminated by a single period (".") plus a CR-LF. A response is always prefaced by a three-digit reply code; possible text following the response code can be in any format. The response code is sufficient to determine whether the operation succeeded or failed, or whether more text is forthcoming following the response line. Any text following the response code is for information only, and need not follow any particular format. The first digit indicates whether the operation succeeded or failed, and if it succeeded whether or not more text should be presented to the repository. Definitions of the first digit are similar to those of NNTP: 1XX Informative message 2XX Operation completed successfully 3XX Operation completed successfully, present remainder of text and terminate with a single period plus CR-LF pair. 4XX Operation was performed and failed for some reason. 5XX Operation could not be performed because of a protocol syntax error of some sort. The second digit indicates the type of object referred to by the response. X0X Miscellaneous X1X User operation X2X Client operation X3X Mailbox operation Lambert [Page 9] RFC 1056 PCMAIL June 1988 X4X Subscription operation X5X Message operation X6X Address operation In an error response, the final digit can describe the type of error that occurred. Otherwise, it simply gives a response a unique number. Numbers 0 through 3 are significant in 4XX-class (error) responses only. Numbers 0-9 in all other responses serve only to differentiate responses dealing with the same type of object under different circumstances. 4X0 Operation failed because object exists 4X1 Operation failed becausWONNMHGns8,*+-/39An}NHHHLMNXgOIKQZTFA\[3**,/138=rpSKFDITldSMNQWUMBBnO2,,././4@ߵ[M@;>PoTPWYQLIIJK`A2--.--0=nM>:cĺ\LKNNJEFMdƯ:+(*-.1:MշfOF=BUԻH==BIJJOYʶ8+)*-3:=KԺVIIKIUؿN?;FOWS]øT6*(*.4?NŷkD??CN~οZB<:BMZdwͺa6*()-6=GeμG;:?KkYF><>EM[sugµ?.))+2:CVǶuA;N.L#:]ԏjt:Ɲ@ܡ'$9&$zhlSR%!\`(d?ul1ipUkKDR]\cIK{RUTBqJJPlw[ Ə/4d;Mo+WYR\D<+(c%bMT- f~*y )aJF_c%]MfjLI*=;'o޿r8ǏYx:K.[=%e&}"*Ij\ "UG/+wi$VZAܭϰ,Li4J`uFtH?ZKhOq)ب%d2qZ2!&O"e@fMR8tFWªeܿӒ&[ qΦIV,UdKR  yF_E<42ƃA(E]ɥqV%G( W=f+#6,#ZqT4PQ:69.sJ搁X _X&Ħ^iDgYs*#!!R:hEWn~C'uO*_+n~2tJnW].!!F@FUg{UERPBN_lМ;ڻ9Xgt(]RIDʯyZqH[7}ݛ.PHŋ**3UrJOUm!!$N}4Y w~g ۖC9"##3"#IeLȘJ܇Bjm+ Au1'oY|Llf4xBG9Weϓ1D*apvH'.;XmBگG$a\5qՕtaOUo H+hoi~/_DMԨݽ#QrUos~zWYKw[4*"a[.X%W`TY_1QutG;OIZ-̑OڨKé?眤luv["^?!_:O[Ys\k1ۻ{awAgq'3;hY|csP3l]t&AXk@sXgNƷ㿛zc[7ꧽ;4!.扬O3_g3 ={ݷ`U]_#0Ū%嫢=t#ϣf~쳠O]so~Do~ln䟋^x.>M2`цQWX5_kD)UQQQꥑ^;^mL1;R4&+.G>jvM4vϲٞi q'd$AC%sxq\)syԼ:Q\ρ,y>2X I|5~~2!s8_cK.2W2@3@_Y( ծ%.Xz{]P[\%)pBNq2W  qh6N˱}*}!0;\#86KcS2g.N-sV`p-8N/sUE B/ \nc^2 \>Yȫd!.eGS0Rwi2wn9EF̧HM 8]HT?}_.&eX)s6l8e Veɜ LX+_a_Ό \\ݶ2W±e9_8z B6y\)p~THv(WÀ-q s*]*g` pitm՚f~ce(zOF5+X%OZx->ԛmdqdM%Nϖ%+$m˾DV7$"<eaIޣ$ZjAY: &Xabd;Cȡ,汘 ~b$x\!K@k[ebu JˬW@8D Y"G\$n:r7PBӥ,zYi6@[q#UjgjӲK#ZUn8䰀HmH$kX;mdDfSצMcȑn!Ý n`=^I'@9,+KG)%S+^^In3+&O6jU+c6rqܡ8m,X뱷Huʠ8r8ՙYں`7lr%@H8T4m%HvIeihHqڠ*E9X`G,դ@\"y 6VK+nKddFWU9\(מSrHS8v9Rl9mD~HۉȀ9UvG,a.m\DN6*Tliln=^YM3d*6He *[)d`9j6ꨠ(Yڠ$&66c)Җn9GUcn#&ꉲ]Z`-~J-]&qܠ`deQ~(ඌgؠ٧[dY3CeٝQޡ57AF۽ض=X0Z0JV'd^lGT85!I) 7()fYup!u&AݾFv h⩛BMI`$뢸J\#^|٧z0lqFLX`Ht%Y(N ga S;TPGu#XHE|@ԪcZr]m2gءG4ԜuJO\eT)\69C5n;5*8p-L󡛤YQ$]aDrӰW)(%ላѷ*BGlqIe7Uջحe_`E)T๛*U֡ېfJܰ(تҙ[ں噩$K#ȣ*aVeIpe%  X۬&_:\reҜ]q"pnۤۉN 9uͫ)%Z IZ39eTN)$9S[:*m!7$Qv|䀠WKޠfG!դJIY@nf_n[w8nJgi5gj[1c$j_ È$(Za%mchY`G"ãcHXh"Qd.V;&Ŧd:cgVQ9"c(8E\al؟lvR"ޥ%WD7kfe쭰0Axw֠eAX߆0#ʡ(H̡%eXeȠyi M[meca2ږ;#r\_H<_Cdag_ƕտ_Cy] nT[ѫId/[YI([y0K1[J.c[KA*Z9S_H&XK8DmSgώmԦ'˅!|u&/DH6eVfz%n ș9@̭Z qE[SCe΀DێGoX2SaԸ[ڠ%[k/Z]rƦ CplԞ-oᴧѶc"+dOc8ʹZ#RXfd^!$a=(W$i%+WC\M?( hqcDyVTDVDe5#8|cuQ^m2U"yաSwbQ؁JM[{xbeKY\UTDעR2rMN[nr]M'5_ÖTJ%JoqaT>I䍽ʼn,rX#e(i\I0g )$GgI*&|'ٿ(QBj[ؤ9ϤziH%$ GURR%_;6i99EcD%︜\v#, Ҥd*HrYEm8_}#kԑ4kActZݒKDfc$k>%[m:g]AԲF؁}eҡdmaHjmYXAVm =H!Ԣdm!+ QKd`v3m!#RK'o RﶝdAW1%%qA&AeoɭoA!ҥ!c o:Eok"GF4ڕ7m4pꨬԝ}k7%E#m¬vŒÉZU~mVhCӠmBG0mAH rG2VՓl:6Vb&!թ젉؉d,Sa20B7!h߾YtR]&;~BcʁŠ9vUaـV0gcŹ'բ[&cƷ$sA c"_$3TخaC܍!dq0aJi)afac9r])4bSV}c Z&M#IeM%mcԄb_]h=cX6ӟ]eB޲eqȂ S7&gaԩ,uyb j$ή(jj W%$aU&%tl)I46r8de*.bB]E!Tqϙkd(ecNr܉z"QجbBē+Eq cqz,تqFS[X Px͎uUum]aŌd.[#b9#Ӥ{]<[:F[dHۖX*Iĉ!LռgfPDgq$?gU]miC:FaMgY8,})ܪ܈ljnIզE(萳#+-ܘY1 ƟI_;il[y*ƃv^ƣĠEzdF%/z2QdPƅܢ7&¹cKFݲ bUɨ28Q7i)IIcmH9kd [ulE{CҜgEI3knb]"sm#'r"&$b;Tc)[aXLUb+iXOW$ma;b؂'P!lmaJ!%ĪA5gI#~bk)Bc:ۀ@[fƂj\Aiv-ؒ;@ Ӛ̣W]8Hbڀ,jlPcdTE[jfyؚVN(8ۭǤdG+Fۍ&z\ټ&r6VI,W# Dܑ#h'd%ܚv8v;ΠIn'P WI)-ש٦[#-V5\U(mtf'Z&%鲀.1u6ZR"I1nRvة^-Xn†b`dt¦Vl!Ԣpjb b%^mȡwaĤ*3^RCf! 2]j䯧pAÅ i]jkoc; )l企(m4Z@]fizg(c=2bTXj˔-r8aG`kdM ic3՘\X$S%j g4Vc;e{hˡ"DJKl@VۚZe - 7@JP" QlTXvp9Fk!S$HmCk83h)#q뙡AAgyR3p«bK]&aXe;\@֤ L# 7nGvҙր'l JۑbGp6A[-ڸu$ R/nM]ˆr9dYAcrFg+#c"A$eNTpl72nG˚0e,mg#N7$@dJۮ}i_kȵW8$%XMhe repository returns the descriptors in a list with the following format: If a descriptor has been expunged, the repository transmits two consecutive lines of information: the word "expunged" on one line, followed by the message UID on the next line. "Expunged" notifications are only transmitted in response to a "fetch-changed- descriptors" command; they are an indication to the client that someone else has expunged the mailbox and that the client should remove the local copy of the expunged message. If a descriptor has not been expunged, it is presented as six consecutive lines of information: the word "descriptor" on the first line, followed by a second line containing the message UID, flag states (see examples following), message length in bytes, and message length in lines, followed by four lines containing in order the message "from:" field, "to:" field, "date:" field, and "subject:" field. The entire list of descriptors is terminated by a period plus CR-LF; individual descriptors are not specially terminated since the first line ("expunged" or "descriptor") of a list entry determines Lambert [Page 16] RFC 1056 PCMAIL June 1988 the exact length of the entry (two lines or six lines). The "fetch-changed-descriptors" operation is intended for use during state synchronization. Whenever a descriptor changes state (one of its flags is cleared, for example), the repository notes those clients which have not yet recorded the change locally. Fetch- changed-descriptors has the repository send to the client a maximum of the first N descriptors which have changed since the client's last synchronization, where N is a number sent by the client. The list sent begins with the descriptor with lowest UID. Note that the list of descriptors is only guaranteed to be monotonically increasing for a given call to "fetch-changed-descriptors"; messages with lower UIDs may be changed by other clients in between calls to "fetch- changeddescriptors". "Fetch-changed-descriptors" takes two arguments: the name of the mailbox to search, and the maximum number of descriptors for the repository to return. Once the changed descriptors have been looked at, a user will want to inform the repository that the current client has recorded the change locally. The "reset-descriptors" command causes the repository to mark as "recorded by current client" a given series of descriptors. The series is identified by a low UID and a high UID. UIDs within the series that no longer exist are ignored. Arguments are: mailbox name, low UID in range, and high UID in range. Whole messages are transmitted from repository to user with the "fetch-message" operation. The separation of "fetchdescriptors" and "fetch-message" operations allows clients with small amounts of disk storage to obtain a small message summary (via "fetch-descriptors" or "fetch-changed-descriptors") without having to pull over the entire message. Arguments are mailbox name, followed by message UID. Frequently, a message may be too large for some clients to store locally. Users can still look at the message contents via the "print-message" operation. This operation has the repository send a copy of the message to a named printer. The printer name need only have meaning to the particular repository implementation; DMSP transmits the name only as a means of identification. Arguments are: mailbox name, followed by message UID, followed by printer identification. Copying of one message into another mailbox is accomplished via the "copy-message" operation. A descriptor list of length one, containing a descriptor for the copied message, is returned if the copy operation is successful. This descriptor is required because the copied message acquires a UID different from the original message. The client cannot be expected to know which UID has been assigned the copy, hence the repository's sending a descriptor Lambert [Page 17] RFC 1056 PCMAIL June 1988 containing the UID. Arguments to copy-message are: source mailbox name, target mailbox name, and source message UID. Each message has associated with it sixteen flags, as described earlier. These flags can be set and cleared using the "set-message- flag" operation. The first eight flags have special meaning to the repository as described above; the remaining eight are for user use. Set-message-flag takes four arguments: mailbox name, message UID, flag number (0 through 15), and desired flag state (0 or 1). 5. Client Architecture Clients can be any of a number of different workstations; Pcmail's architecture must therefore take into account the range of characteristics of these workstations. First, most workstations are much more affordable than the large computers currently used for mail service. It is therefore possible that a user may well have more than one. Second, some workstations are portable and they are not expected to be constantly tied into a network. Finally, many of the smaller workstations resource-poor, so they are not expected to be able to store a significant amount of state information locally. The following subsections describe the particular parts of Pcmail's client architecture that address these different characteristics. 5.1. Multiple clients The fact that Pcmail users may own more than one workstation forms the rationale for the multiple client model that Pcmail uses. A Pcmail user may have one client at home, another at an office, and maybe even a third portable client. Each client maintains a separate copy of the user's mail state, hence Pcmail's distributed nature. The notion of separate clients allows Pcmail users to access mail state from several different locations. Pcmail places no restrictions on a user's ability to communicate with the repository from several clients at the same time. Instead, the decision to allow several clients concurrent access to a user's mail state is made by the repository implementation. 5.2. Synchronization Some workstations tend to be small and fairly portable; the likelihood of their always being connected to a network is relatively small. This is another reason for each client's maintaining a local copy of a user's mail state. The user can then manipulate the local mail state while not connected to the network (and the repository). This immediately brings up the problem of synchronization between local and global mail states. The repository is continually in a position to receive global mail state updates, either in the form of Lambert [Page 18] RFC 1056 PCMAIL June 1988 incoming mail, or in the form of changes from other clients. A client that is not always connected to the net cannot immediately receive the global changes. In addition, the client's user can make his own changes on the local mail state. Pcmail's architecture allows fast synchronization between client local mail states and the repository's global mail state. Each client is identified in the repository by a client object attached to the user. This object forms the basis for synchronization between local and global mail states. Some of the less common state changes include the adding and deleting of user mailboxes and the adding and deleting of address objects. Synchronization of these changes is performed via DMSP list operations, which allow clients to compare their local versions of mailbox and address object lists with the repository's global version and make any appropriate changes. The majority of possible changes to a user's mail state are in the form of changed descriptors. Since most users will have a large number of messages, and message states will change relatively often, special attention needs to be paid to message synchronization. An existing descriptor can be changed in one of three ways: first, one of its sixteen flag values can be changed (this encompasses the user's reading an unseen message, deleting a message, printing a message, etc). Second, a descriptor can be created, either by the delivery of a new message or by the copying of a message from one mailbox to another. Finally, a descriptor can be destroyed, via an "expunge-mailbox" operation. In the above cases, synchronization is required between the repository and every client that has not previously noted the change. To keep track of which clients have noticed a global mail state change and changed their local states accordingly, each mailbox has associated with it a list of active clients. Each client has a (potentially empty) "update list" of messages which have changed since that client last synchronized. When a client connects to the repository, it executes a DMSP "fetch- changed-descriptors" operation. This causes the repository to return a list of all descriptors on that client's update list. When the client receives the changed descriptors, it may do one of two things: if the descriptor is marked "expunged", it can remove the corresponding message from the local mailbox. If the descriptor is not expunged, the client can store the descriptor, thus updating the local mail state. After a changed descriptor has been recorded, the client uses the DMSP "reset-descriptors" operation to remove descriptors from its update list. Those descriptors will now not be sent to the client unless (1) it is explicitly requested via a "fetch-descriptors" operation, or (2) it changes again. Lambert [Page 19] RFC 1056 PCMAIL June 1988 In this manner, a client can run through its user's mailboxes, getting all changes, incorporating them into the local mail state, and marking the changes as recorded. 5.3. Batch operation versus interactive operation Because of the portable nature of some workstations, they may not always be connected to a network (and able to communicate with the repository). Since each client maintains a local mail state, Pcmail users can manipulate the local state while not connected to the repository. This is known as "batch" operation, since all changes are recorded by the client and made to the repository's global state in a batch, when the client next connects to the repository. Interactive operation occurs when a client is always connected to the repository. In interactive mode, changes made to the local mail state are also immediately made to the global state via DMSP operations. In batch mode, interaction between client and repository takes the following form: the client connects to the repository and sends over all the changes made by the user to the local mail state. The repository changes its global mail state accordingly. When all changes have been processed, the client begins synchronization; this incorporates newly-arrived mail, as well as mail state changes by other clients, into the local state. In interactive mode, since local changes are immediately propagated to the repository, the first part of batch-type operation is eliminated. The synchronization process also changes; although one synchronization is required when the client first opens a connection to the repository, subsequent synchronizations can be performed either at the user's request or automatically every so often by the client. 5.4. Message summaries Smaller workstations may have little in the way of disk storage. Clients running on these workstations may never have enough room for a complete local copy of a user's global mail state. This means that Pcmail's client architecture must allow user's to obtain a clear picture of their mail state without having all their messages present. Descriptors provide message information without taking up large amounts of storage. Each descriptor contains a summary of information on a message. This information includes the message UID, its length in bytes and lines, its status (contained in the eight system-defined and eight user-defined flags), and portions of its Lambert [Page 20] RFC 1056 PCMAIL June 1988 RFC-822 header (the "from:", "to:", "date:" and "subject:" fields). All of this information can be encoded in a small (around 100 bytes) data structure whose length is independent of the size of the message it describes. Most clients should be able to store a complete list of message descriptors with little problem. This allows a user to get a complete picture of his mail state without having all his messages present locally. If a client has extremely limited amounts of disk storage, it is also possible to get a subset of the descriptors from the repository. Short messages can reside on the client, along with the descriptors, and long messages can either be printed via the DMSP print-message operation, or specially pulled over via the fetch- message operation. 6. Typical interactive-style client-repository interaction The following example describes a typical communication session between the repository and a client mail reader. The client is one of three belonging to user "Fred". Its name is "office-client", and since Fred has used the client within the last week, it is marked as "active". Fred has two mailboxes: "fred" is where all of his current mail is stored; "archive" is where messages of lasting importance are kept. The example will run through a simple *A2]W}筄[-}\'۠mp.K$Gj(.Ԋ'[lq__{7J7h&>ug;N2`cgQdT Zr?Iׄ>/M@I4; I<`TohdIbܺy|2ݢmϞ2W\&2"a!66Ƭ} 7L^g%@4I5 bOm_1zEJ`1Z+PH9i^WKmeTa 7 vY"N=9v"Tjd=ΔF*w3ME tB9)6켕1׭-[3ͯj3yad& LHJ_' c0͹Yr6N\KJ>R~)G| ] Fp*9N~ټ>5g?_̊q+<&[(f0 f au-[_Id׆&uKnI}k?[y(_fJY˄ҒZښ;oRRs)Cx:~0uDSV/8uZ{A4yJQz8/ײMP\i-D8j 3SbzLA1i$~P>혋^}Nт5*bvZ?NNoZxWx&O`|cs>]=#QtGL6o@~Wp`Z#_ȣyL?Ŭv{}Zf#b[VV[҇f}mv߼8l͉h t|`\a= UxٴLsaי8,#Zحa@[m=?A }m^1B("es*:N=]P>?w~7m NM{fBm}Z~8YS逸\#>H˗a S\u襵Ͱ>6|K'rjX1Tr }{߰2'oVQ"#DS_+QDiܗz5W׹Mp04E%c_L]eݨqBpT.g=mOZֹյ-~\,{:waAJ+WyItʾ~?! t,%X=.Aס@<;@Vװ~C՚A$ͫGbW~"Ix)ĸF=iKH;ol>w[AvܴӲO78>[DY.'߃ my1dJK\0XLO( 6pAu97Om\ Pp^#q7϶2mY=֕_kc`z>|mg(<¾) Ifu%pE߼}~"Š?6w<#3y#vǫ`nٕ-#8g#.!u+:dZ=$3Zb "@@ {?p?޷w u_S8.$6?"m$iB:PÖn] mailboxes in the list (if there were, the mail reader would create them. On the other hand, if some mailboxes in the mail reader's local list were not in the repository's list, the program would assume them deleted by another client and delete them locally as well). To synchronize, the mail reader need only look at each mailbox's contents to see if (1) any new mail has arrived, or (2) if Fred changed any messages on one of his other two clients subsequent to "office-client"'s last connection to the repository. The mail reader asks for any changed descriptors via the "fetch- changed-descriptors" operation. It requests at most ten changed descriptors since storage is very limited on Fred's workstation. fetch-changed-descriptors fred 10 The repository responds with: 250 descriptor list follows: expunged Lambert [Page 22] RFC 1056 PCMAIL June 1988 2101 expunged 2104 descriptor 2107 1100011100000010 1400 30 foo@bar.edu (Foo Jones) fred@PTT.LCS.MIT.EDU Wed, 9 Dec 87 10:43:52 EST A typical subject line descriptor 2312 0000000000000000 12232 320 joe@athena.mit.edu fred@PTT.LCS.MIT.EDU Thu, 17 Dec 87 18:24:09 PST Another typical subject line . If a descriptor changed because it was expunged, it is transmitted as two lines: the word "expunged" on one line, followed by the message UID on the next line. If one of its flags changed state, or it is a new message, it is transmitted as six lines: the word "descriptor" on one line, followed by a line containing the message UID, flags, and length in bytes and lines, followed by the to, from, date, and subject fields, each on one line. The flags are transmitted as a single string of ones and zeroes, a one if the flag is on and a zero if the flag is off. All 16 flags are always transmitted. Flag zero's state is the first character in the flag string; flag fifteen's is the last character in the flag string. The first two descriptors in the list have been expunged, presumably by Fred's expunging his mailbox on another client. The mail reader removes messages 2101 and 2104 from its local copy of mailbox "fred". The next descriptor in the list is one which Fred marked for deletion on another client yesterday. The mail reader marks the local version of the message as deleted. The last descriptor in the list is a new one. The mail reader adds the descriptor to its local list. Since all changes to mailbox "fred" have now been recorded locally, the update list can be reset: reset-descriptors fred 1 2312 The repository responds with: 200 command OK indicating that it has removed from "office-client"'s update list all Lambert [Page 23] RFC 1056 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFFF2FCFAFFFCFCF6 FDE4CCD8CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F1F1F2DFCCCCCCCCCCCCCCCC CCCCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCED0E6FCE4CCD7CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCE4FCFFFFFFFFFFFFFFFFF8F8F8FFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFFFFFFFFFFFFFFFFFD FDFDFCFCE4CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F2F2F2DFCCCCCCCCCCCCCC CCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCFD4E8FCEFF8E3CCCCCCCCCCCCCCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCE7FCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF a number of BABYL-format mailboxes. The interface is very similar to the RMAIL mail reader already present in GNU-EMACS. The mail reader communicates with the repository through network code implemented in EMACS-LISP. Changes to the local mail state are immediately made on the repository; although the repository is fast, there is a small noticeable delay in performing operations over the network. There is no provision for automatic synchronization whenever new mail arrives or old mail is changed by another client. Instead, users must get any new mail explicitly. A simple "notification" program runs in the background and wakes up every minute to check for new mail; when mail arrives, the user executes a command to get the new mail, synchronizing the mailbox at the same time. 7.3. Repository code The repository is implemented in C on 4.2/4.3BSD UNIX. Currently it runs on DEC VAX-750s and Microvaxes, although other repositories will soon be running on IBM RT machines and Sun workstations. The repository code is designed to allow several clients belonging to a particular user to "concurrently" modify the user's state. A locking scheme prevents one client from modifying mail state while another client is modifying the same state. 8. Conclusions Pcmail is now used by a small community of people at the MIT Laboratory for Computer Science. The repository design works well, providing an efficient means of storing and maintaining mail state for several users. Its performance is quite good when up to ten users are connected; it remains to be seen whether or not the repository will be efficient at managing the state of ten or a Lambert [Page 26] RFC 1056 PCMAIL June 1988 hundred times that many users. Given sufficient disk storage, it should be able to, since communication between different users' clients and the repository is likely to be very asynchronous and likely to occur in short bursts with long "quiet intervals" in between as users are busy doing other things. Members of another research group at LCS are currently working on a replicated, scalable version of the repository designed to support a very large community of users with high availability. This repository also uses DMSP and has successfully communicated with clients that use the current repository implementation. DMSP therefore seems to be usable over several flavors of repository design. The IBM PC clients are very limited in the way of resources. The mail reader/editor combination is quite powerful, making local mail state manipulation fairly easy. Obviously a big performance enhancement would be to provide a fully interactive client. As it is, batch-style synchronization is relatively time consuming due to the low performance of the PCs. The "batch-mode" that the PCs use tends to be good for those PCs that spend a large percentage of their time unplugged and away from a network. It is somewhat inconvenient for those PCs that are always connected to a network and could make good use of an "interactive-mode" state manipulation. The UNIX-based clients are more powerful and easier to use than their PC counterparts. Synchronization is much faster, and there is far more functionality in the mail reader (having an interface that runs within GNU-EMACS helps a lot in this respect). Most of those people using the Pcmail system use the UNIX-based client code. Lambert [Page 27] RFC 1056 PCMAIL June 1988 I. DMSP Protocol Specification Following are a list of DMSP operations by object type, together with syntax, and possible responses. Some responses may be followed by zero or more lines of text, terminated by a single period plus CR-LF pair. Only success responses and common error responses are listed; a complete list of possible responses follows this appendix. Expressions in angle brackets (i.e. ) are metalinguistic variables indicating a general request or response form. Operations with arguments have a sample invocation following the operation syntax and response. General operations: HELP 100 Repository version xxx. Following are supported: HELP SEND-VERSION SEND-MESSAGE LOGIN LOGOUT ... FETCH-MESSAGE COPY-MESSAGE . SEND-VERSION 200 Command OK 500 version skew! i.e. SEND-VERSION 230 SEND-MESSAGE 350 enter message; end with "." To: markl From: markl Subject: a test message this is a test message . Lambert [Page 28] RFC 1056 PCMAIL June 1988 Repository responds: 200 Command OK 403 message syntax error User operations: LOGIN 200 Command OK 221 Client out of date by > 1 week 404 Bad password 405 Client is locked 411 No user named 421 Client not found i.e. LOGIN markl foo random-client-name 1 0 LOGOUT 200 Command OK SET-PASSWORD 200 Command OK 404 Incorrect old password i.e. SET-PASSWORD foo bar Client operations: LIST-CLIENTS 220 Client list follows: client-1 active client-2 inactive client-3 active ... client-foobar active . Each line of the list contains a client name, followed by whitespace, followed by the word "active" or the word "inactive", indicating whether or not the client has connected to the repository within the last week. Lambert [Page 29] RFC 1056 PCMAIL June 1988 CREATE-CLIENT 200 Command OK 403 is an illegal name 420 Client exists i.e. CREATE-CLIENT new-client DELETE-CLIENT 200 Command OK 421 Client not found 405 Client is locked i.e. DELETE-CLIENT old-client RESET-CLIENT 200 Command OK 421 Client not found 405 Client is locked i.e. RESET-CLIENT any-old-client Mailbox operations: LIST-MAILBOXES 230 Mbox list <#msgs> <#new> follows: mailbox-1 2338 8 1 mailbox-2 59 44 0 ... mailbox-foobar 19 9 0 . Each line of the list contains a mailbox name, followed by the mailbox's next available unique identifier, followed by the number of messages in the mailbox, followed finally by the number of unseen messages in the mailbox. Unseen messages are those whose descriptors have flag #1 ("message has been seen") set to zero. CREATE-MAILBOX 200 Command OK 403 is an illegal name 430 already exists 440 exists as a bboard subscription Lambert [Page 30] RFC 1056 PCMAIL June 1988 i.e. CREATE-MAILBOX current-events DELETE-MAILBOX 200 Command OK 431 mailbox not found 440 is a bboard; use delete-bboard-mailbox i.e. DELETE-MAILBOX income-tax-information CREATE-BBOARD-MAILBOX 200 Command OK 430 a mailbox named already exists. 430 a bboard mailbox named already exists. 403 is an illegal name i.e. CREATE-BBOARD-MAILBOX sf-lovers DELETE-BBOARD-MAILBOX 200 Command OK 404 not owner of 431 no bboard mailbox named i.e. DELETE-BBOARD-MAILBOX rec.autos RESET-MAILBOX 200 Command OK 431 mailbox not found i.e. RESET-MAILBOX british-cars EXPUNGE-MAILBOX 200 Command OK 431 mailbox not found EXPUNGE-MAILBOX british-cars Address operations: LIST-ADDRESSES 260 Address list for follows: address-1 Lambert [Page 31] RFC 1056 PCMAIL June 1988 address-2 ... address-6 . or 431 mailbox not found i.e. LIST-ADDRESSES archive Each line of the list consists solely of one address. CREATE-ADDRESS 200 Command OK 403 is an illegal name 431 mailbox not found 460 already exists i.e. CREATE-ADDRESS markl markl-bug-pcmail DELETE-ADDRESS 200 Command OK 431 mailbox not found 461 address not found i.e. DELETE-ADDRESS markl markl-info-cobol Subscription operations: LIST-SUBSCRIPTIONS 240 subscription list follows: bboard-1 2573 33 2606 bboard-2 541 4 545 ... bboard-6 1530 43 1573 . Each line of the list consists of a bulletin-board name, followed by the UID of the first message which the user has not yet looked at, followed by the number of messages in the bulletin-board that the user has not yet looked at, followed by the bulletin-board's next available unique message identifier. Lambert [Page 32] RFC 1056 PCMAIL June 1988 CREATE-SUBSCRIPTION 200 Command OK 403 is an illegal name 430 A mailbox named already exists 431 Bboard mailbox not found 440 Already subscribing to i.e. CREATE-SUBSCRIPTION sf-lovers DELETE-SUBSCRIPTION 200 Command OK 441 Subscription not found i.e. DELETE-SUBSCRIPTION rec.music RESET-SUBSCRIPTION 200 Command OK 441 Subscription not found i.e. RESET-SUBSCRIPTION rec.music.gdead 1210 LIST-AVAILABLE-SUBSCRIPTIONS 241 All available bboards follow: mod.politics sfl tcp-ip forum ... comp.emacs . Each line of the list consists solely of one bulletin-board name. Message operations: FETCH-CHANGED-DESCRIPTORS 250 Descriptor list follows: expunged 2333 expunged 2334 Lambert [Page 33] RFC 1056 PCMAIL June 1988 descriptor 2337 0001000001110000 481 14 croaker@ptt.lcs.mit.edu fred@anymachine.mit.edu Tue, 19 Jan 88 11:10:03 EST a typical subject line descriptor 2339 0000000000000000 1457 40 bob@lcs.mit.edu csr-people@ptt.lcs.mit.edu Mon, 18 Jan 88 13:08:17 +0000 another typical subject line expunged 2340 . or 431 mailbox not found i.e. FETCH-CHANGED-DESCRIPTORS markl 100 Each element of the descriptor list is either two or six lines long. Descriptors which have been expunged are transmitted as two lines: the word "expunged" on one line, followed by the message unique identifier on the next line. Descriptors which still exist are transmitted as six lines: the word "descriptor" on one line, followed by a line containing the message unique identifier, flag states (sixteen characters either one or zero depending on the associated flag value), followed by the message length in characters, followed by the message length in lines. The next four lines contain the message's "from:", "to:", "date:", and "subject:" fields, respectively. Flag zero's state is the first character in the flag string; flag fifteen's is the last character in the flag string. FETCH-DESCRIPTORS 250 Descriptor list follows: descriptor 2337 0001000001110000 481 14 croaker@ptt.lcs.mit.edu fred@anymachine.mit.edu Tue, 19 Jan 88 11:10:03 EST a typical subject line descriptor 2339 0000000000000000 1457 40 bob@lcs.mit.edu csr-people@ptt.lcs.mit.edu Lambert [Page 34] RFC 1056 PCMAIL June 1988 Mon, 18 Jan 88 13:08:17 +0000 another typical subject line . or 431 mailbox not found i.e. FETCH-DESCRIPTORS british-cars 12 31 COPY-MESSAGE 250 Descriptor list follows: descriptor 2339 0000000000000000 1457 40 bob@lcs.mit.edu csr-people@ptt.lcs.mit.edu Mon, 18 Jan 88 13:08:17 +0000 another typical subject line . or 400 cannot copy message onto itself 431 target mailbox not found 431 source mailbox not found 451 message not found i.e. COPY-MESSAGE markl british-cars 2338 RESET-DESCRIPTORS 200 Command OK 431 mailbox not found i.e. RESET-DESCRIPTORS markl 1 10000 PRINT-MESSAGE 200 Command OK 401 printer not found 431 mailbox not found 451 message not found i.e. PRINT-MESSAGE markl 2433 pravda Lambert [Page 35] RFC 1056 PCMAIL June 1988 SET-MESSAGE-FLAG 200 Command OK 431 mailbox not found 451 message not found 500 flag number out of range i.e. SET-MESSAGE-FLAG british-cars 23 0 1 FETCH-MESSAGE 251 message follows: From: markl@ptt.lcs.mit.edu To: markl@ptt.lcs.mit.edu Date: Sun, 17 Jan 88 11:11:11 EST Subject: anything this is a sample of some message text . or 431 Mailbox not found 451 message not found i.e. FETCH-MESSAGE current-events 495 Lambert [Page 36] RFC 1056 PCMAIL June 1988 II. Operations by name copy-message create-address create-bboard-mailbox create-client create-mailbox create-subscription delete-address delete-bboard-mailbox delete-client delete-mailbox delete-subscription expunge-mailbox fetch-changed-descriptors fetch-descriptors fetch-message help list-addresses list-available-subscriptions list-clients list-mailboxes list-subscriptions login logout print-message reset-client reset-descriptors reset-mailbox reset-subscription send-message send-version set-message-flag set-password Lambert [Page 37] RFC 1056 PCMAIL June 1988 III. Responses by number 100 Pcmail repository version XXX; following are supported 200 Command OK 220 Client list follows: 221 Client out of date by > 1 week 230 Mailbox list <#msgs> <#new> follows: 240 Subscription list follows: 250 Descriptor list follows: 251 Message follows: 260 Address list follows: 350 enter message; end with "." 400 cannot copy message onto itself 410 already logged in 420 client already exists 430 mailbox already exists 430 bboard mailbox already exists 440 subscription already exists 460 address already exists 411 no user named 421 client not found 431 mailbox not found 441 subscription not found 451 message not found 461 address not found 402 internal error message 403 syntax error in outbound message 404 bad password or permission denied 405 mail state is temporarily in use by another client 406 please log in 500 operation syntax error or illegal argument Lambert [Page 38]