InfoMagic Internet Tools 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0141.txt < prev next >

Wrap

Text File | 1993-07-02 | 46.6 KB | 1,242 lines

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