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

Marc Groot Koerkamp marc at its-projects.nl
Wed Apr 23 17:39:01 CEST 2003


Stephan Buys zei:
> Hi Marc,
>
> This is the detailed reply that I promised... Comments are inline.
>
> On Wednesday 23 April 2003 10:51, Marc Groot Koerkamp wrote:
>>    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.
>>
>
> Done I have added it.
>
>> 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)
>>
>
> I wanted to add some filler and can understand that this might be a bit
> off-topic.
> I am going to indicate that the chapter is to be removed in the text and ask
> for
> some comments on it.
>
>> 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)
>>
>
> I agree. Could you give me an example of  you would indicate it? I never
> liked the fact that I copy/pasted the message contents but I am not very
> experienced in all the details of these things.
>
For the record, I do not have experience with Exchange, Kolab and Bynary
insight connector yet. I looked at it and read the Rfc's regarding vCalendar
and vCard.

In the kolab architecture doc there are descriptions for KDE client format and
the Microsoft format. They both differ. Probably the used format is a server
descission. Outlook uses a content type text/calendar and KDE uses
multipart/mixed with a mime-part text/calendar inside it.

If you want shared calendars you are dependent of the server (in this case
kolab). Calender events are processed by the server and the server distributes
the events to the other users.
I do not know how Kolab takes care of that. If you want to add calendar data
directly in the correct Folder then it's important that you use a format that
can be understood by the server. Again I'm not sure how kolab deals with that.

Reconstructing a calendar at clientside is as far as I know simply a matter of
collecting the text/calendar parts from the Calendar folder and process the
received vCalendar entries. For performance it could be usefull if the client
is aware of the location of those entries. If you do not know the location you
have to process the bodystructure of each message in order to detect the right
mime-parts containing the calendar data.
I do not understand why the KDE client uses a different approach then outlook.

The RFC822 Header from each message can be used to limit the required messages
to fetch if there is information like startdate / enddate inside the rfc822
header (See IMAP SEARCH).

>
>> 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)
>>
>
> Added.
>
>> 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.
>>
>
> Could you please explain? (I know the concept of namespaces) What I
> meant here was that does it have to be:
> INBOX
> 	-Contacts
> 	-Calendar
> 	-Notes
> 	-Tasks

Probably in the personal namespace like above.

>
> or:
>
> INBOX
> Calendar
> Notes
> Tasks
> Contacts

this implies that all users share the same folders for Calendar, Notes, Tasks
and Contacts.

NB: Representing a folder-tree at client site is something else then the
folder tree structure inside imap. If the client is aware of the special
nature of the the just mentioned folders the client is free the display it as
a sibling folder underneath INBOX instead of listing it as child.

When I look at the Kolab architecture doc Kolab make use of folders in the
personal namespace (children of INBOX) and shared events are distributed
server side to the personal calendar folders.

>
> ie. Doesn't it make sense to have the groupware folders as children of the
> root
> folder?

I think that doesn't make sense because you cannot have private appointments
with groupware folders as children of root.

>
>>    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.
>>
>
> Would this also be set up using ACLs? ie. is there a flag which can indicate
> "do not list?" I will add this as a FIXME for comments. Or does imply a IMAP
> extension? (Maybe that is a good idea?)

The IMAP-ACL extension describes several standard rights that can be placed on
a folder. (lrswipcda) The l right is for list. Without the l flag it indicates
"do not list".
Because of the fact that there are a lot of imap-clients around that aren't
aware of the special nature of contact, calendar ... folders it's better to
hide them.

>
>>    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)
>>
>
> I am going to delete this FIXME. Would it be correct to say that this is
> actually
> handled by the Disconnected IMAP RFC?

Yes, see:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-disc-02.txt


>
>>    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.
>>
>
> I agree to this, but I dont think this is the way it was implemented in either
> the Kolab or Bynari clients.

Ok, then it should be possible to setup special folders at the client, just
like Sent and Drafts.

>
>> 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.
>>
>
> Agreed. FIXME removed.
>
>>    FIXME - Is this compatible with Bynari Insight Connector?
>>
>>
>>    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).
>>
>
> Added. Thanks.
>
>>
>>       BEGIN:VCALENDAR
>>       PRODID
>>        :REQUEST
>>
>>       BEGIN:VTODO
>
>>
>>       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 *
>>
>
> Wont they already be distinguished by the fact that TODO's are in the Tasks
> folder
> and that EVENTS are in the Calendar folder?

After reading the docs again I see that VTODO events cannot be nested inside
other calendar components so forget the flag story store them in a seprate
folder Tasks.

Marc Groot Koerkamp.


More information about the Kroupware mailing list