evolution-kolab is a project to provide connectivity to Kolab groupware servers for Evolution.
Contents
1. evolution-kolab - RFC Reference
1.1. RFC 2060
- Obsoleted by
RFC 3501
- Date
- December 1996
- Obsoletes
- RFC 1730
- Description
- Describes the IMAPv4r1 protocol. Access to remote mailboxes not fundamentally different from local access. Specifies a method to synchronise a client with a server after some time for the client being offline. Compatible to IMAP2/IMAP2bis
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 34-41: AP7-7
1.2. RFC 2177
- Date
- June 1997
- Description
- IMAPv4r1 does not specify a method to check a mailbox for new messages, other than actively polling. IMAP IDLE specifies an enhancement to IMAPv4r1, the IDLE command. With the IDLE command, the server can tell the client that a mailbox status has changed.
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 42-43: AP7-8
1.3. RFC 2180
- Date
- July 1997
- Description
- Specifies how an IMAP server should handle gracefully concurrent access of multiple clients to the same IMAP mailbox. Has some best-practices how well-behaving IMAP servers should behave. In doubt, RFC 2060 is authorative.
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 42-43: AP7-8
1.4. RFC 2595
- Date
- June 1999
- Description
Using TLS (formerly SSL) for encryption of a connection to either of the services mentioned within the document.
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 42-43: AP7-8
1.5. RFC 2683
- Date
- September 1999
- Description
- Recommendations on the implementation of IMAPv4 clients and servers regarding implementation tradeoffs.
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 42-43: AP7-8
1.6. RFC 3501
- Date
- March 2003
- Obsoletes
- RFC 2060
- Description
- Describes the IMAPv4r1 protocol. Access to remote mailboxes not fundamentally different from local access. Specifies a method to synchronise a client with a server after some time for the client being offline. Compatible to IMAP2/IMAP2bis
1.7. RFC 4549
RFC 4549 - Synchronization Operations for Disconnected IMAP4 Clients
- Date
- June 2006
- Description
- Recommendations for implementing offline-capabilities and synchronization procedures between IMAPv4r1 clients and servers. Non-authorative addendum to RFC 3501.
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 34-41: AP7-7
1.8. RFC 5257
RFC 5257 - Internet Message Access Protocol - ANNOTATE Extension / imapext-annotate
- Date
- June 2008
- Description
- Enhances the IMAP Specification with the capability to add annotations to a mailbox or a server as a whole. Moreover, single parts of emails may be annotated, e.g. some explanation to an attachment. The specification has an example:
It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 28-33: AP7-6
1.9. RFC 5464
- Date
- February 2009
- Description
- Enhances the IMAP Specification with the capability to add metadata to a mailbox or a server as a whole. Moreover, single parts of emails may be annotated, e.g. some explanation to an attachment. The specification has an example:
It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.
- Project references
- Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf page 28: AP7-6
1.10. Other relevant RFCs
1.10.1. RFC 2255
- Date
- December 1997
- Abstract
- LDAP is the Lightweight Directory Access Protocol, defined in [1], [2] and [3]. This document describes a format for an LDAP Uniform Resource Locator. The format describes an LDAP search operation to perform to retrieve information from an LDAP directory. This document replaces RFC 1959. It updates the LDAP URL format for version 3 of LDAP and clarifies how LDAP URLs are resolved. This document also defines an extension mechanism for LDAP URLs, so that future documents can extend their functionality, for example, to provide access to new LDAPv3 extensions as they are defined.
1.10.2. RFC 2445
RFC 2445 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)
- Date
- November 1998
- Abstract
- There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [...]
1.10.3. RFC 3986
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
- Date
- January 2005
- Abstract
- A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.
1.10.4. RFC 4314
- Date
- December 2005
- Obsoletes
- RFC 2086
- Description
- Unterstützung von Zugriffskontroll-Listen (ACL) in IMAP4.
- Abstract
- The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands.
1.10.5. RFC 4551
RFC 4551 - IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
- Date
- June 2006
- Abstract
- Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
1.10.6. RFC 5161
- Date
- March 2008
- Abstract
- Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports.
1.11. Draft documents
1.11.1. ANNOTATEMORE
ANNOTATEMORE - IMAP ANNOTATEMORE Extension / draft-daboo-imap-annotatemore-05
- Date
- April 2004
- Abstract
- The ANNOTATEMORE extension to the Internet Message Access Protocol permits clients and servers to maintain "metadata" on IMAP4 servers. It is possible to store data on a per-mailbox basis or on the server as a whole.
- Description
- Predecessor of RFC 5464; relevant in kolab; implemented/patched in cyrus (as of cyrus-2.3, it is version 05(!) of the draft)