Network Working Group L. Greenfield Internet Draft Carnegie Mellon Document: draft-greenfield-acap-mbox-01.txt November 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 ftp.ietf.org, 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 May 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 18 November 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 clients to determine mailboxes that have been created recently * 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 18 November 1998 3. 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 The hierarchy defines the user visible mailboxes in a realm---clients using the mailbox dataset display mailboxes using the names exported though the ACAP server, even though these may be different from the names available on each IMAP server. Most of the attributes are inherited system wide, though some may be overridden on a per-user basis, as defined in [ACAP]. Specifically, attributes such as mailbox.Subscribed and any annotations are meant to be overridden on a per-user basis. Most other attributes are only modifiable in the original message store. 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.URL" 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. A mailbox dataset MAY correspond to newsgroups accessed via NNTP. In such a case, any IMAP specific attributes will be undefined. Clients SHOULD ignore any NNTP mailboxes if they do not support NNTP. L. Greenfield [Page 3]
Internet DRAFT ACAP Mailbox Dataset 18 November 1998 - Mailbox Attributes mailbox.URL This is a multivalued attribute containing the URL (as defined in [IMAP-URL]) used to access this mailbox. If there are multiple URLs (corresponding to multiple servers) the mailbox MUST have identical content. The list SHOULD be sorted in preferential order of access to allow for load balancing. ("imap://mail2.andrew.cmu.edu/comp.mail.imap" "imap://mail4.andrew.cmu.edu/#news.comp.mail.imap") mailbox-URL = 1*URL ;; as defined in [IMAP-URL] 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 choose 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 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.Flags.Noinferiors mailbox.Flags.Marked mailbox.Flags.Unmarked These attributes correspond to the IMAP mailbox flags. The attribute equals 1 if the flag is set; 0 otherwise. mailbox-flags = number L. Greenfield [Page 4]
Internet DRAFT ACAP Mailbox Dataset 18 November 1998 remailbox.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.Size mailbox.Quota.Size.Deleted mailbox.Quota.Messages mailbox.Quota.Messages.Deleted These attributes are equal to the ones defined in [IMAP-QUOTA]. The .deleted attributes are the resources contained in just the messages marked \Deleted. These attributes are useful even on servers that do not enforce quotas. mailbox-quota = 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 5]
Internet DRAFT ACAP Mailbox Dataset 18 November 1998 6. Open Issues The author is unsure the best way to encode IMAP ACLs and IMAP QUOTAs into the mailbox data set. Specifically, there is currently no way to find out the quotaroots or the maximum quota in the mailbox. IMAP4 namespaces [NAMESPACE] can lead to many many issues. Should multiple hierarchy seperators be allowed? How should this be exported? 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. There has been some requests for folder annotations---is this desired? How much structure should be enforced on it? Should a more formal definition for server coherency be made? L. Greenfield [Page 6]
Internet DRAFT ACAP Mailbox Dataset 18 November 1998 4. 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. 5. Security Considerations The mailbox dataset should not export information that would be otherwise unavailable to the user. ACAP permissions should be tied with the corresponding IMAP permissions. 6. Author's Address Lawrence Greenfield Cyert Hall 100c Computing Services Carnegie Mellon University Pittsburgh PA, 15213-3890 L. Greenfield [Page 7]
Internet DRAFT ACAP Mailbox Dataset 18 November 1998 Email: leg+asg@andrew.cmu.edu L. Greenfield [Page 8]
Internet DRAFT ACAP Mailbox Dataset 18 November 1998 TTaabbllee ooff CCoonntteennttss Status of this Memo ............................................... i Abstract .......................................................... i 1. Conventions Used in this Document ............................ 2 2. Design Issues ................................................ 2 3. ACAP Mailbox Dataset Class ................................... 3 6. Open Issues .................................................. 6 4. References ................................................... 7 5. Security Considerations ...................................... 7 6. Author's Address ............................................. 7 L. Greenfield [Page ii]