http://git.gnome.org/browse/evolution-kolab/plain/art/logo/evo-kolab-small.pnghttp://git.gnome.org/browse/evolution-kolab/plain/art/logo/evo-kolab-lettering.png

evolution-kolab is a project to provide connectivity to Kolab groupware servers for Evolution.

evolution-kolab main page

Contents

  1. evolution-kolab - RFC Reference
    1. RFC 2060
    2. RFC 2177
    3. RFC 2180
    4. RFC 2595
    5. RFC 2683
    6. RFC 3501
    7. RFC 4549
    8. RFC 5257
    9. RFC 5464
    10. Other relevant RFCs
      1. RFC 2255
      2. RFC 2445
      3. RFC 3986
      4. RFC 4314
      5. RFC 4551
      6. RFC 5161
    11. Draft documents
      1. ANNOTATEMORE

evolution-kolab - RFC Reference

RFC 2060

  • RFC 2060 - Internet Message Access Protocol - Version 4rev1

    • 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

RFC 2177

  • RFC 2177 - IMAP4 IDLE command

    • 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

RFC 2180

  • RFC 2180 - IMAP4 Multi-Accessed Mailbox Practice

    • 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

RFC 2595

Project references
Feinkonzept_Anteil_KC_SecurMobI_v1_smf_2010-07-08.pdf pages 42-43: AP7-8

RFC 2683

  • RFC 2683 - IMAP4 Implementation Recommendations

    • 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

RFC 3501

  • RFC 3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

    • 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

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

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

RFC 5464

  • RFC 5464 - The IMAP METADATA Extension / IMAP-Metadata

    • 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

Other relevant RFCs

RFC 2255

  • RFC 2255 - The LDAP URL Format

    • 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.

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. [...]

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.

RFC 4314

  • RFC 4314 - IMAP4 Access Control List (ACL) Extension

    • 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.

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.

RFC 5161

  • RFC 5161 - The IMAP ENABLE Extension

    • 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.

Draft documents

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)

Attic/Evolution/Kolab/RFCReference (last edited 2018-08-18 15:14:07 by AndreKlapper)