[Kroupware] Re: Kolab RFC (IMAP Groupware Folders)
Stephan Buys
s.buys at codefusion.co.za
Tue Apr 29 11:07:10 CEST 2003
Hi Marc,
Comments inline:
> > 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.
>
This is actually a client decision - thus the RFC. The idea is to have it really
unambigious on how the mail should be stored.
> 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.
>
Again a client decision.
> 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.
>
Haven't scrutinized the code of the KDE client yet but I am pretty sure that the
folder determines how the client will interpret (or attempt to interpret) the
messages.
> 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).
>
Agreed. This could be client-side recommendation.
> >> 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.
>
Understood. As you mentioned this is not much of an issue.
> > 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.
>
Agreed.
> >> 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.
>
This is also a good idea that can go in as a recommendation.
> >> 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
>
Thanks.
> >> 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.
> _______________________________________________
> Kroupware mailing list
> Kroupware at mail.kde.org
> http://mail.kde.org/mailman/listinfo/kroupware
Thanks again for the feedback.
Regards,
Stephan
More information about the Kroupware
mailing list