[Kroupware] Re: Kolab RFC (IMAP Groupware Folders)

Marc Groot Koerkamp marc at its-projects.nl
Wed Apr 23 11:51:41 CEST 2003


   Please feel free to make contributions and send in comments to the
   kroupware at mail.kde.org mailing list.

I have some comments :-)

Chapter 1:
I miss the rfc for imap-acl support (RFC 2086). Sharing calendars,
contacts requires inside imap requires the imap-acl extension.

Chapter 2:
In my opinion this RFC should only describe how to store vCards, vCalendar
entries en Notes inside an imap mailbox. (remove Chapter 2)

Chapter 4:
The Rfc's for vCards, vCalendar should cover what can be stored inside
those mime types.
What's left for this RFC is the description of the rfc822 header and the
mimestructure of the body. (Chapter 4)

The rest of the comments are in the text below.


Copyright Notice

   Copyright (c) 2003 Stephan Buys.
   Permission is granted to copy, distribute and/or modify this document
   under the terms of the GNU Free Documentation License, Version 1.1
   or any later version published by the Free Software Foundation;
   with no Invariant Sections, with no Front-Cover Texts, and with no
   Back-Cover Texts. A copy of the license is included in the section
   entitled "GNU Free Documentation License" at the end of the document.

Abstract

   IMAP Groupware Folders is a draft proposal for the Internet Standards
   track that defines a standard for storing [Groupware] items in an
   [IMAP] mailbox.

   This draft is based on the methods used by the Kolab KDE Client[1]
   and the Bynari Insight Connector[2]. FIXME - Is this correct?

Table of Contents

1. Introduction

   This document specifies how a Mail User Agent [MUA] uses an [IMAP]
   server to store [Groupware] information. [Groupware] information can
   be seen as the user's [Contacts], [Calendar Entries],
   [Notes] and [Task Lists]. Currently there is an abundance of
   applications that can handle these types of information on the client
   hosting the [MUA], however, there is no standard way of storing these
   items in a standard format on a central server.

   IGF addresses this need and specifies the specific
   standards and formats to be used by a [MUA] to access and store
   Groupware information in an interoperable fashion.

   This document does not cover the process of sending [Groupware]
   related items between different User Agents. These processes are
covered by
   [iTIP] and [iMIP].

1.1 Formatting Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFCWORDS].

1.2 Related Documents

   Other pertinent documents needed for implementation are:

   [IMAP] -  (RFC2060) Specifies the server protocol that a [MUA] uses
      to access [Groupware] information.

   [iTIP] -  (RFC2446) Specifies the standard protocol for scheduling
      between different applications.

   [iMIP] -  (RFC2447) Specifies the transport of [iTIP] items through
      email.

   [iCAL] - FIXME - is this the same as vCal?

   [vCard] - FIXME

   [vToDo] - (RFC2446)


1.3 Definitions

   Groupware -  FIXME

2. Groupware Items

2.1 Contacts

   Analogous to Business Cards. Users are able to maintain a private
   repository of contacts. A contact could be an organization or
   an individual. Typical information associated with a contact is:

   - name
   - email address
   - role
   - organization

2.2 Calendar Entries

   The user's private calendar entries. Information stored could
   include important dates, appointments and events. A calendar entry
   will typically include:

   - description
   - start time
   - end time
   - location

2.3 Notes

   This addresses the need for a user to centrally store information
   items or notes. A note is typically just composed of text.

2.4 Task Lists

   Allows a user to keep track of private action items. A task typically
   contains the following information:

   - description
   - priority
   - due date
   - status


3. IGF Access Method

   FIXME - In the KMail client the folders are all stored under a specific
   folder. Would it be possible to have all the folders under the root
   folder? Ie. INBOX, Contacts, Tasks, etc. on the same depth?

The question is if the special folders should be located in the shared
namespace, the personal namespace or a custom defined namespace. Private
contacts should be located in the personal namespace.

   FIXME - Describe the process whereby a UA logs into the IMAP server
   and the transport is used. Security comes into this as well. Do we do
   any special actions or do we just open the hardcoded folders?

Security is arranged at admin level by setting ACL info on the folders. I
can imagine that the folders for contacts, calendar events should not be
listed if a client does a LSUB or a LIST request (acl -l). This requires
that the client is aware of the folder names used for storing such date
which implies that the foldernames are hardcoded.

   FIXME - What consideration is given to offline storage or is it
   defined by the UA? Disconnected IMAP?

By using UID and UIDVALIDITY a client can cache data. The client should
validate the cache on init (check if the uid's are still available on the
server and retrieve the new uid's (adapted events / contacts get a new UID
if I'm correct)

   FIXME - Should the UA have hardcoded folder names? Ideally there will
   be fixed names for the folders with a translation done by the client.
   This way different clients using different languages can use the same
   store. Is this feasible?

Yes, there should be hardcoded folder names.

4. IMAP Groupware Folders

4.1 Contacts Folder

   Each contact is represented as a multi-part MIME email with a [vCard]
   attached in the user's IMAP contact folder.

   vCard MIME Message:

      Content-Type: Text/X-VCard;
      charset="utf-8"
      From: Stephan Buys <s.buys at codefusion.co.za>
      Reply-To:
      Bcc:
      Organization: Code Fusion
      X-KMail-Fcc:
      To: Stephan Buys
      Subject: Contact: Stephan Buys
      Date: Sat, 5 Apr 2003 11:19:56 +0200
      User-Agent: KMail/kroupware-RC1
      Status: RO
      X-Status: O
      X-KMail-EncryptionState:
      X-KMail-SignatureState:
      X-KMail-MDN-Sent:
      X-UID: 1

      BEGIN:VCARD
      VERSION:3.0
      NAME:Stephan Buys
      UID:rwxg4FeaU
      FN:Stephan Buys
      EMAIL:stephanb at codefusion.co.za
      N:Buys;Stephan;;;
      CLASS:PRIVATE
      END:VCARD

   FIXME - are there guidelines (should there be?) for retrieving the
   contacts? Are they all retrieved at once?

This is a client issue. With a large contact list a client can retrieve
contacts with a search query.

   FIXME - Is this compatible with Bynari Insight Connector?

4.2 Calendar Folder

   Each calendar entry, appointment or conference, is represented as a
   multi-part MIME email.

   vCAL MIME Message:

      Content-Type: text/calendar;
        method=REQUEST;
        charset="utf-8"
      From: Stephan Buys <s.buys at codefusion.co.za>
      Reply-To:
      Bcc:
      Organization: Code Fusion
      X-KMail-Fcc: sent-mail
      To: Stephan Buys <s.buys at codefusion.co.za>
      Subject: libkcal-2014235416.404
      Date: Mon, 7 Apr 2003 18:47:51 +0200
      User-Agent: KMail/kroupware-RC1
      Status: RO
      X-Status: O
      X-KMail-EncryptionState:
      X-KMail-SignatureState:
      X-KMail-MDN-Sent:
      X-UID: 4

      BEGIN:VCALENDAR
      PRODID
       :-//K Desktop Environment//NONSGML libkcal 3.1//EN
      VERSION
       :2.0
      METHOD
       :REQUEST
      BEGIN:VEVENT
      DTSTAMP
       :20030407T164751Z
      ORGANIZER
       :MAILTO:s.buys at codefusion.co.za
      ATTENDEE
       ;CN=Stephan Buys
       ;RSVP=FALSE
       ;PARTSTAT=ACCEPTED
       ;ROLE=REQ-PARTICIPANT
       :mailto:s.buys at codefusion.co.za
      CREATED
       :20030407T164751Z
      UID
       :libkcal-2014235416.404
      SEQUENCE
       :0
      LAST-MODIFIED
       :20030407T164751Z
      SUMMARY
       :A meeting
      LOCATION
       :The meeting place
      CLASS
       :PUBLIC
      PRIORITY
       :3
      DTSTART
       :20030407T074500Z
      DTEND
       :20030407T094500Z
      TRANSP
       :OPAQUE
      END:VEVENT
      END:VCALENDAR

   Each message is stored in the user's IMAP calendar folder.

   FIXME - could the KMail guys explain the special format of the
   Subject? (When accessing the IMAP store with "Groupware Disabled".

   FIXME - Again. Any retrieval guidelines here? Should the UA only
   retrieve messages according to a specific date? How will this scale?
   See: Slow startup with many calendar entries - Andreas Gungl -
   (4 April 2003) - [Kroupware] mailing list.

I should add an extra rfc822 header, namely X-EndDate. If a client want to
retrieve all the calendar entries in a bounded period the startdate isn't
enough. By doing that the performance will increase because the client can
retrieve all the calendar data for a bounded period (day, week month,
whatever).


4.3 Notes Folder

   Each note is reprented by a multi-part MIME email. The note itself is
   derived from the body of the email.

   MIME Part:

      Content-Type: text/plain;
        charset="utf-8"
      From: Stephan Buys <s.buys at codefusion.co.za>
      To: Stephan Buys <s.buys at codefusion.co.za>
      X-KOrg-Note-Id: libkcal-1953363517.276
      X-KOrg-Note-Color: #ffff00
      Status: RO
      X-Status: O
      X-KMail-EncryptionState:
      X-KMail-SignatureState:
      X-KMail-MDN-Sent:
      X-KOrg-Note-Geometry: 200x150+640+543

      A note with some info on it.

   FIXME - The notes in the Kolab client aren't even close to what is
   described in Appendix A2 of the Architecture document?

4.4 Tasks Folder

   Each task entry is represented as a multi-part MIME email with [iCAL]
   [VTODO] information in a MIME part of the email. Each email is
   representing a task is stored in the designated tasks folder.

   MIME iCal Part:

      Content-Type: text/calendar;
        method=REQUEST;
        charset="utf-8"
      From: Stephan Buys <s.buys at codefusion.co.za>
      Reply-To:
      Bcc:
      Organization: Code Fusion
      X-KMail-Fcc: sent-mail
      To: Stephan Buys <s.buys at codefusion.co.za>
      Subject: libkcal-727785235.893
      Date: Mon, 7 Apr 2003 18:49:22 +0200
      User-Agent: KMail/kroupware-RC1
      Status: RO
      X-Status: O
      X-KMail-EncryptionState:
      X-KMail-SignatureState:
      X-KMail-MDN-Sent:
      X-UID: 2

      BEGIN:VCALENDAR
      PRODID
       :-//K Desktop Environment//NONSGML libkcal 3.1//EN
      VERSION
       :2.0
      METHOD
       :REQUEST
      BEGIN:VTODO
      DTSTAMP
       :20030407T164922Z
      ORGANIZER
       :MAILTO:s.buys at codefusion.co.za
      CREATED
       :20030407T164922Z
      UID
       :libkcal-727785235.893
      SEQUENCE
       :0
      LAST-MODIFIED
       :20030407T164922Z
      SUMMARY
       :A todo
      LOCATION
       :The place
      CLASS
       :PUBLIC
      PRIORITY
       :3
      PERCENT-COMPLETE
       :0
      END:VTODO
      END:VCALENDAR

   FIXME - Again. What is up with the special subject?

Like already said on the list, VTODO === vCalendar. Maybe TODO entries and
EVENT entries can be distincted by an message flag if the imap-server
support PERSISTANT FLAGS *


Appendix A. Acknowledgements

   FIXME

Appendix B. Bibliography

   FIXME
   [IMAP]      RFC....


Regards,

Marc Groot Koerkamp
(
  AKNA stekkel
  http://sourceforge.net/projects/squirrelmail/
).



More information about the Kroupware mailing list