Internet DRAFT - draft-greenfield-acap-mbox
draft-greenfield-acap-mbox
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]
