Network Working Group L. Greenfield Internet Draft Carnegie Mellon Document: draft-greenfield-acap-mbox-00.txt August 1998 ACAP Mailbox Dataset Class Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress''. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire before January 1999. Distribution of this draft is unlimited. Abstract IMAP [IMAP4] allows users to access the mail store in an efficient way, but has insufficient support to export detailed meta-level information about mailboxes, subscriptions, and multiple servers. The mailbox dataset provides a fast, flexible way of exporting this data. L. Greenfield [Page i]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 1. Conventions Used in this Document The key words "MUST", "MUST NOT", "SHOULD" , "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. The attribute syntax specifications use the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. When UTF-8 [UTF8] is referred to in this document, it refers to Unicode version 2.0, and not Unicode version 1.1. 2. Design Issues IMAP [IMAP4] provides a robust protocol for fetching messages and partial data from a remote server, both for active and detached clients. However, it provides only rudimentary support for determining what mailboxes reside on a server, subscription support, and fast updates. Current proposals for handling mailboxes spread over multiple IMAP servers force clients to make complicated and slow searches. The mailbox dataset is designed to aid IMAP clients in dealing with a large number of mailboxes, possibly spread and replicated over multiple servers. It exports information that cannot be expressed via IMAP. Clients will be able to use the mailbox dataset to * quickly tell what mailboxes have new messages in them * receive overview information about the mailbox (statistics and mailbox flags) * quickly tell what mailboxes have had state changes since they were last examined * enable "new mailbox" creation messages * determine how to "post" messages to this mailbox, if possible * present a simple, unified view of a large number of servers L. Greenfield [Page 2]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 3. ACAP/IMAP mail realms Large mail sites (both in number of users and amount of mail/news processed) require more complex setups than a single IMAP server. A "mail realm" is a collection of ACAP, IMAP, LDAP, and SMTP servers. The ACAP server serves to unify the multiple IMAP server into a single, coherent form. Users need not know any details of the underlying IMAP servers but are instead presented with simple hierarchical names. The ACAP mailbox dataset supercedes the IMAP subscription support. A client that uses the ACAP mailbox dataset never sends LIST or LSUB-- -a superset of that information is available from the ACAP server. How a server keeps multiple replicas of a mailbox in sync is not addressed by this document. Any changes to one server MUST be reflected in the other servers as soon as possible. L. Greenfield [Page 3]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 4. ACAP Mailrealm Dataset Class Datasets whose names begin with "/mailrealm" contain general information about this mail realm, as defined in this specification. ACAP Attributes entry The name of this mail realm. "andrew.cmu.edu" mailrealm-name = 1*TEXT-UTF8-CHAR mailrealm.IMAPservers The IMAP servers associated with this mailrealm. mailream-imapservers = 1*CHAR *(NUL 1*CHAR) ;; multi-valued mailrealm.SMTPservers The SMTP server used for posting outgoing mail. It MAY be sorted in order of preferential use. mailrealm-smtpservers = 1*CHAR *(NUL 1*CHAR) ;; multi-valued mailrealm.LDAPservers The LDAP server used for directory information. mailrealm-ldapservers = 1*CHAR *(NUL 1*CHAR) ;; multi-valued L. Greenfield [Page 4]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 5. ACAP Mailbox Dataset Class Datasets whose names begin with "/mailbox" contain mailbox entries as defined in this specification. The hierarchy corresponds to the hierarchy defined by the mail realm by the following transformation: * change all hierarchy delimiters to "/" * change all "\"'s in names to "\\" (if "\" isn't the hierarchy delimiter) * change all "/"'s in names to "\S" (if "/" isn't the hierarchy delimiter) * change the modified UTF-7 encoding to UTF-8 Any server that provides this dataset should advertise the MAILBOX attribute. Most of the attributes are inherited system wide, though some may be overridden on a per-user basis, as defined in [ACAP]. Required ACAP Attributes - Basic Attributes entry The "entry" attribute is the last component in the mailbox. subdataset The "subdataset" attribute is used to indicate that there are submailboxes in the hierarchy from this mailbox. It's possible the mailbox has no real existance on an IMAP server (or exists with the \Noselect flag). In such a case, the "mailbox.Servers" attribute is NIL. A user MAY still be subscribed to a mailbox with no IMAP server. Such a subscription SHOULD be persistant should this mailbox later be created, and MAY have meaning to certain clients. For example, a graphical hierarchical client may choose to show a subscribed \Noselect mailbox to allow the user quick access to the mailboxes underneath. - Mailbox Attributes mailbox.Name This is the name of this mailbox in UTF-8 form, suitable to display to a user. "comp.mail.imap" or "#news.comp.mail.imap" mailbox-name = 1*TEXT-UTF8-CHAR mailbox.Name.UTF7 L. Greenfield [Page 5]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 This is the name of this mailbox in modified-UTF7 form, suitable for sending to a server as an argument to SELECT. "comp.mail.imap" or "#news.comp.mail.imap" mailbox-imapname = 1*CHAR mailbox.Expand.URL This is the suggested URL to try to access this mailbox. see mailbox.Expand.Server. "imap://mail2.andrew.cmu.edu/comp.mail.imap" mailbox-expand-url = URL ;; as defined in [IMAP-URL] mailbox.Expand.Server This is the suggested server to try to access this mailbox. It MUST be listed in "mailbox.Servers". The server returned SHOULD be currently available. "mail2.andrew.cmu.edu" mailbox-expand-server = 1*CHAR mailbox.Servers This is a list of servers that this mailbox is available on. If there is more than one server, the mailbox MUST be named the same on every server and MUST have identical content. It MAY be sorted in preferential order of access. ("mail2.andrew.cmu.edu" "mail4.andrew.cmu.edu") mailbox-servers = *(NUL 1*CHAR) mailbox.Subscribed Non-0 if the user is subscribed to this mailbox. Clients MAY support multiple methods of subscription by the following values: * 0 unsubscribed * 1 normal subscription (show changed messages) * 2 show-all subscription (always show all messages) * 3 ask subscription (the user needs to take some action to show the captions in this mailbox) Clients may write to this attribute to change the subscription state; mail realms may chose to force this attribute to be non-zero, so that users are forced to subscribe to a mailbox containing system announcements. mailbox-subscribed = number mailbox.State.Unseen L. Greenfield [Page 6]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 mailbox.State.Recent mailbox.State.Exists mailbox.State.Deleted mailbox.State.Uidnext mailbox.State.Uidvalidity This is the current state of the mailbox, obtained via some unspecified method from an appropriate IMAP server. The IMAP server MAY act as an ACAP client and store the appropriate information when it changes. mailbox-state = number mailbox.Post This is a URL describing how to post messages to this mailbox. "mailto:post+comp.mail.imap@andrew.cmu.edu" mailbox-post = url mailbox.Archive If non-zero, this is considered a repository for a mailing list or newsgroup since the time indicated. mailbox-archive = time mailbox.CreateTime This contains an ACAP-format time when this mailbox was created. mailbox-createtime = time mailbox.Quota This is a writable attribute containing the IMAP quota of this mailbox. (The exact layout is still under consideration.) mailbox-quota = *(quota_resource) ;; multi-valued quota_resource = atom SP number SP number mailbox.ACL This is a writable format containing the ACL for this mailbox. (The exact layout is still under consideration.) mailbox-acl = *(acl_data) acl_data = identifier SP acl_rights acl_rights = string L. Greenfield [Page 7]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 6. Open Issues The author is unsure the best way to encode IMAP ACLs and IMAP QUOTAs into the mailbox data set. IMAP4 namespaces [NAMESPACE] can lead to many many issues. It may be possible to integrate NNTP servers into this proposal; this adds even more complexity and could create even more complicated clients. The naming scheme for each mailbox (for an N hierarchical name, the first N-1 components form the dataset and the last component forms the name) feels needlessly complicated. Should a more formal definition for server coherency be made? Is the mailrealm dataset necessary? L. Greenfield [Page 8]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 7. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, Innosoft, Netscape, November 1997. [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1994. [IMAP-ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie- Mellon University, January 1997. [IMAP-QUOTA] Myers, J. "IMAP4 QUOTA extension", RFC 2087, Carnegie- Mellon University, January 1997. [IMAP-URL] Newman, C. "IMAP URL Scheme", RFC 2192, Innosoft, September 1997. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [NAMESPACE] Gahrns, Newman, "IMAP4 Namespace", RFC 2342, Microsoft, Innosoft, May 1998. [UTF8] Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, Alis Technologies, January 1998. 8. Security Considerations The mailbox dataset should not export information that would be otherwise unavailable to the user. 9. Author's Address Lawrence Greenfield Cyert Hall 100c Computing Services Carnegie Mellon University Pittsburgh PA, 15213-3890 L. Greenfield [Page 9]
Internet DRAFT ACAP Mailbox Dataset August 7, 1998 Email: leg+asg@andrew.cmu.edu L. Greenfield [Page 10]