From wrobel at pardus.de Thu Mar 13 08:36:12 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 13 Mar 2008 08:36:12 +0100 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <877ime800w.fsf_-_@home.pardus.de> (Gunnar Wrobel's message of "Wed, 26 Sep 2007 07:32:15 +0200") References: <87fy1kqa9n.fsf@home.pardus.de> <200709141013.55119.bernhard@intevation.de> <87lkb3fylt.fsf@home.pardus.de> <20070919070730.GB22343.thomas@intevation.de> <87fy1bf5x1.fsf@home.pardus.de> <20070919100516.GA1732.thomas@intevation.de> <877ime800w.fsf_-_@home.pardus.de> Message-ID: <87abl3849f.fsf_-_@home.pardus.de> Additional folder type ---------------------- In addition to the s defined in http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html Horde now allows the type "prefs". Format Of Preferences --------------------- The mimetype for preferences is "application/x-vnd.kolab.prefs". This is the specification of the body contents: (string, no default) (string, default empty) (string, default empty)

(datetime, no default)

(string, default public) {(string, no default)} {(string, no default)} (string, default empty) (string, default empty) See http://kolab.org/doc/kolabformat-2.0rc5-html/c183.html for the description of the common fields. There can be any number of "prefs" elements. Each client is free to choose the desired format within these fields as appropriate. Example ------- This is an example object from Horde: 7bba75ca0aa90a23f9e099c4b1a4407d mnemo

2008-03-04T13:23:14Z

public

Horde::Kolab

show_notepad:MA=3D=3D show_panel:MQ=3D=3D sortby:MA=3D=3D sortdir:MA=3D=3D memo_categories: memo_colors: display_notepads:YToxOntpOjA7czoyMDoid3JvYmVsQGRldi5wYXJkdXMuZGUiO3= 0=3D delete_opt:MQ=3D=3D -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From thomas.jarosch at intra2net.com Thu Mar 13 09:31:39 2008 From: thomas.jarosch at intra2net.com (Thomas Jarosch) Date: Thu, 13 Mar 2008 09:31:39 +0100 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <87abl3849f.fsf_-_@home.pardus.de> References: <87fy1kqa9n.fsf@home.pardus.de> <877ime800w.fsf_-_@home.pardus.de> <87abl3849f.fsf_-_@home.pardus.de> Message-ID: <200803130931.39803.thomas.jarosch@intra2net.com> Hello Gunnar, On Thursday, 13. March 2008 08:36:12 Gunnar Wrobel wrote: > > > 7bba75ca0aa90a23f9e099c4b1a4407d > > mnemo > 2008-03-04T13:23:14Z > 2008-03-04T13:23:14Z > public > Horde::Kolab > show_notepad:MA=3D=3D > show_panel:MQ=3D=3D > sortby:MA=3D=3D > sortdir:MA=3D=3D > memo_categories: > memo_colors: > > display_notepads:YToxOntpOjA7czoyMDoid3JvYmVsQGRldi5wYXJkdXMuZGUiO3= > 0=3D > delete_opt:MQ=3D=3D > The IMAP prefs driver is great news! Will try it next week once I've finished my -secret project- for Kolab ;-) Might I suggest a little change in the format: The root node is called and the childs are called , too. We might run into trouble if we want to specify f.e. attributes in a DTD. IMHO it would be better if the child nodes are called like this: memo_categories: memo_colors: What do you think? Cheers, Thomas From wrobel at pardus.de Thu Mar 13 09:51:32 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 13 Mar 2008 09:51:32 +0100 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <200803130931.39803.thomas.jarosch@intra2net.com> (Thomas Jarosch's message of "Thu, 13 Mar 2008 09:31:39 +0100") References: <87fy1kqa9n.fsf@home.pardus.de> <877ime800w.fsf_-_@home.pardus.de> <87abl3849f.fsf_-_@home.pardus.de> <200803130931.39803.thomas.jarosch@intra2net.com> Message-ID: <87ejaf6m7f.fsf@home.pardus.de> Thomas Jarosch writes: > Hello Gunnar, > > On Thursday, 13. March 2008 08:36:12 Gunnar Wrobel wrote: >> >> >> 7bba75ca0aa90a23f9e099c4b1a4407d >> >> mnemo >> 2008-03-04T13:23:14Z >> 2008-03-04T13:23:14Z >> public >> Horde::Kolab >> show_notepad:MA=3D=3D >> show_panel:MQ=3D=3D >> sortby:MA=3D=3D >> sortdir:MA=3D=3D >> memo_categories: >> memo_colors: >> >> display_notepads:YToxOntpOjA7czoyMDoid3JvYmVsQGRldi5wYXJkdXMuZGUiO3= >> 0=3D >> delete_opt:MQ=3D=3D >> > > The IMAP prefs driver is great news! Will try it next week once > I've finished my -secret project- for Kolab ;-) > > Might I suggest a little change in the format: The root node is called > and the childs are called , too. We might run into trouble > if we want to specify f.e. attributes in a DTD. IMHO it would be better if the > child nodes are called like this: > > > memo_categories: > memo_colors: > > > What do you think? Stupid me ;-) Thanks for the suggestion! In CVS. Cheers, Gunnar > > Cheers, > Thomas > > _______________________________________________ > Kolab-format mailing list > Kolab-format at kolab.org > https://kolab.org/mailman/listinfo/kolab-format -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bernhard at intevation.de Thu Mar 13 11:53:04 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 13 Mar 2008 11:53:04 +0100 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <87abl3849f.fsf_-_@home.pardus.de> References: <87fy1kqa9n.fsf@home.pardus.de> <877ime800w.fsf_-_@home.pardus.de> <87abl3849f.fsf_-_@home.pardus.de> Message-ID: <200803131153.05406.bernhard@intevation.de> On Thursday 13 March 2008 08:36, Gunnar Wrobel wrote: > In addition to the s defined in > > http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html > > Horde now allows the type "prefs". Doing an experiment like this is good in giving us more experience we can later decide what we should officially declare as Kolab Format. Ideally I would like to see a good writeup of all the considerations we have discussed over the list regarding how client should save their configuration. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20080313/e18feb82/attachment.bin From joon at radleys.co.za Fri Mar 14 06:30:14 2008 From: joon at radleys.co.za (Joon Radley) Date: Fri, 14 Mar 2008 07:30:14 +0200 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <200803131153.05406.bernhard@intevation.de> References: <87fy1kqa9n.fsf@home.pardus.de> <877ime800w.fsf_-_@home.pardus.de> <87abl3849f.fsf_-_@home.pardus.de> <200803131153.05406.bernhard@intevation.de> Message-ID: <002001c88594$7d70af10$78520d30$@co.za> Hi Bernhard and Gunnar, Making custom types was part of the design so this is well within the scope of Kolab-XML. As Kolab-XML uses the IMAP4 server for storage there is no problem with saving the data to the server. The problem is that the format is Horde specific. So this will not form part of the main specification. Also I think the name should be "name spaced" to show that it is bound to a specific client e.g. "h-prefs" or "horde-prefs" Best Regards Joon Radley Radley Network Technologies CC Cell: +27 (0)83 368 8557 Fax: +27 (0)12 998 4346 E-mail: joon at radleys.co.za Web: www.toltec.co.za > -----Original Message----- > From: kolab-format-bounces at kolab.org [mailto:kolab-format- > bounces at kolab.org] On Behalf Of Bernhard Reiter > Sent: Thursday, March 13, 2008 12:53 PM > To: kolab-format at kolab.org > Subject: Re: Declaring a new folder type and format for Horde > preferences > > On Thursday 13 March 2008 08:36, Gunnar Wrobel wrote: > > In addition to the s defined in > > > > http://kolab.org/doc/kolabformat-2.0rc5-html/c154.html > > > > Horde now allows the type "prefs". > > Doing an experiment like this is good in giving us more experience we > can later decide what we should officially declare as Kolab Format. > > Ideally I would like to see a good writeup of all the considerations we > have discussed over the list regarding how client should save their > configuration. > > Bernhard > > -- > Managing Director - Owner: www.intevation.net (Free Software > Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab- > Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From wrobel at pardus.de Fri Mar 14 16:57:10 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 14 Mar 2008 16:57:10 +0100 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <002001c88594$7d70af10$78520d30$@co.za> (Joon Radley's message of "Fri, 14 Mar 2008 07:30:14 +0200") References: <87fy1kqa9n.fsf@home.pardus.de> <877ime800w.fsf_-_@home.pardus.de> <87abl3849f.fsf_-_@home.pardus.de> <200803131153.05406.bernhard@intevation.de> <002001c88594$7d70af10$78520d30$@co.za> Message-ID: <8763vp1ep5.fsf@home.pardus.de> Hi Joon, "Joon Radley" writes: > Hi Bernhard and Gunnar, > > Making custom types was part of the design so this is well within the scope > of Kolab-XML. As Kolab-XML uses the IMAP4 server for storage there is no > problem with saving the data to the server. > > The problem is that the format is Horde specific. So this will not form part > of the main specification. Also I think the name should be "name spaced" to > show that it is bound to a specific client e.g. "h-prefs" or "horde-prefs" that should be no problem and will definitely namespace two other folder types that I'll introduce soon. Concerning the "Preferences" I'm hesitating though: Why shouldn't Kontact for example be able to store configuration options in there too? The format is really not that restrictet. After all it just defines that you have a "prefs" container that can hold a multiple number of "pref" nodes, each having string content. This should provide all necessary means for a client to save its configuration on the server. And I wouldn't mind if I could do that with contact so that I don't have to configure each installation on its own. So I feel this does not have to be Horde specific. If the other client devs are certain that they won't ever use this format I can of course make it Horde specific. Cheers, Gunnar -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bernhard at intevation.de Mon Mar 17 11:51:47 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 17 Mar 2008 11:51:47 +0100 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <8763vp1ep5.fsf@home.pardus.de> References: <87fy1kqa9n.fsf@home.pardus.de> <002001c88594$7d70af10$78520d30$@co.za> <8763vp1ep5.fsf@home.pardus.de> Message-ID: <200803171151.52125.bernhard@intevation.de> On Friday 14 March 2008 16:57, Gunnar Wrobel wrote: > Concerning the "Preferences" I'm hesitating though: Why shouldn't > Kontact for example be able to store configuration options in there > too? I think we had a couple of drawbacks mentioned already, this is why a consistant writeup of the consideration would be quite useful. > And I wouldn't mind if I could do that with contact so that I don't > have to configure each installation on its own. The situation with Kontact is different than with Horde I guess, with Kontact you often _want_ to have different configurations depending on where your Kontact is running. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-format/attachments/20080317/0d522512/attachment.bin From wrobel at pardus.de Thu Mar 20 16:01:35 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 20 Mar 2008 16:01:35 +0100 Subject: Declaring a new folder type and format for Horde preferences In-Reply-To: <200803171151.52125.bernhard@intevation.de> (Bernhard Reiter's message of "Mon, 17 Mar 2008 11:51:47 +0100") References: <87fy1kqa9n.fsf@home.pardus.de> <002001c88594$7d70af10$78520d30$@co.za> <8763vp1ep5.fsf@home.pardus.de> <200803171151.52125.bernhard@intevation.de> Message-ID: <87fxul5tio.fsf@home.pardus.de> Bernhard Reiter writes: > On Friday 14 March 2008 16:57, Gunnar Wrobel wrote: >> Concerning the "Preferences" I'm hesitating though: Why shouldn't >> Kontact for example be able to store configuration options in there >> too? > > I think we had a couple of drawbacks mentioned already, > this is why a consistant writeup of the consideration would be quite useful. I made this Horde-only now. So I'm not certain if any elaborate documentation makes much sense here. Or do you mean a writeup of the presence of custom folder in general? > >> And I wouldn't mind if I could do that with contact so that I don't >> have to configure each installation on its own. > > The situation with Kontact is different than with Horde I guess, > with Kontact you often _want_ to have different configurations depending on > where your Kontact is running. Okay, I made the preferences thing Horde-only in Horde CVS and the folder type is h-prefs now (and the root node too). Cheers, Gunnar > > > -- > Managing Director - Owner: www.intevation.net (Free Software Company) > Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Kolab-format mailing list > Kolab-format at kolab.org > https://kolab.org/mailman/listinfo/kolab-format -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From wrobel at pardus.de Thu Mar 20 16:09:47 2008 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 20 Mar 2008 16:09:47 +0100 Subject: why did you develop kolab xml format? In-Reply-To: <200802091233.16581@erwin.ingo-kloecker.de> (Ingo =?utf-8?Q?K?= =?utf-8?Q?l=C3=B6cker's?= message of "Sat, 09 Feb 2008 12:33:16 +0100") References: <200801232248.13511.thomas@koch.ro> <873as7wvie.fsf@home.pardus.de> <200802060220.46716.martin.konold@erfrakon.de> <200802091233.16581@erwin.ingo-kloecker.de> Message-ID: <87bq595t50.fsf@home.pardus.de> Ingo Kl?cker writes: > [Please note, that I'm not subscribed to this mailing list.] > > On Wednesday 06 February 2008, you wrote: >> Am Dienstag, 5. Februar 2008 schrieb Gunnar Wrobel: >> >> Hi, >> >> > > I'm interested in groupware developing and just subscribed to ask >> > > you a question. I couldn't find an explanation about your >> > > motivation not to use vCard and vCal anymore, but to develop an >> > > XML format. >> > >> > I think the original reasons were that vCal did not provide all the >> > functionaltiy to match the requirements to cope for the different >> > clients. >> >> No, it was not about lack of functionality but for other reasons >> including but not limited to: >> >> iCal and vCard standards are very complex, featureful, and offer a >> superset of overlapping functionality. (A typical multi-vendor >> standard). >> >> They are difficult to parse and hard to extend. The later is >> especially importand if you intend to match the OL/Ex functionality >> 1:1. > > FWIW: The IETF is forming a new working group to look at updates to the > vCard format (RFC2426). (See attached message.) > > I think you should join the working group for making sure that at least > some of the short-comings of the vCard format you've observed are > fixed. Thanks! I subscribed... Cheers, Gunnar > > > Regards, > Ingo > > From: Brad Hards > Subject: [Kde-pim] new IETF activity on vCard > To: kde-pim at kde.org > Date: Sat, 09 Feb 2008 13:49:00 +1100 > Reply-to: KDE PIM > > If you have a strong interest in vCard changes, keep reading; else return(). > > The IETF is forming a new working group to look at updates to the vCard format > (RFC2426) - see below for the full charter / scope. > > For anyone who hasn't been involved in IETF stuff before, it is really easy > (and very similar to most open source projects, except for the code bit of > course). Basically, you just subscribe to the mailing list, and read/post as > appropriate. There is no (official) concept of organisational membership - > we're all just contributing as individuals. > > You can just lurk on the mailing list too - no-one will be worried. > > Brad > ---------- Forwarded Message ---------- > > Subject: WG Action: vCard and vCardDAV (vcarddav) > Date: Friday 01 February 2008 > From: IESG Secretary > To: ietf-announce at ietf.org > > A new IETF working group has been formed in the Applications Area. For > additional information, please contact the Area Directors or the WG > Chairs. > > +++ > > vCard and vCardDAV (vcarddav) > ============================== > > Last Modified: 2007-12-26 > > Current Status: Active Working Group > > Chair(s): > Marc Blanchet > Kurt Zeilenga > > Applications Area Director(s): > Chris Newman > Lisa Dusseault > > Applications Area Advisor: > Chris Newman > > Mailing Lists: > General Discussion: vcarddav at ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/vcarddav > Archive: http://www1.ietf.org/pipermail/vcarddav > > Description of Working Group: > > A personal address book (PAB) contains a read/write copy of attributes > describing a user's interpersonal contacts. This is distinct from a > directory which contains a primarily read-only copy of users within an > organization. While these two data objects share a large number of common > attributes, their use and access patterns are fundamentally different. The > IETF has a standards-track data format (vCard) which has been successfully > used to interchange both personal-address-book and user directory entry > data objects. However, due to the lack of a standard access control model > for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB > objects, and the different access patterns for PAB data (as opposed to > directory data), the use > of LDAP as an access protocol for PABs has had mixed results in practice. > Moreover, the vCard format has been extended by many parties and the > current specification is ambiguous for some objects. > > If the deployed protocols related to interpersonal communication are > viewed as a component-based system, there are a number of points in the > system that would benefit from a standards track access protocol for > personal address book data. > This includes: > > * Mail User Agents use PAB data to assist outgoing email addressing and > may use vCard attachments to transport PAB data between users. > * Calendar User Agents use PAB data to invite attendees to events > * Instant Messaging User Agents can provide additional information about a > user's buddies if they can be associated with a user's PAB entry. > * A server-side Sieve engine with the spamtest/virustest extension would > benefit from access to a user's PAB to provide per-user white list > capabilities. > * Various deployed challenge-response mechanisms for email present in Mail > Transfer Agents, such as TMDA, would be improved by a PAB-based white > list. > * Mobile device synchronization software might be simplified by a single > cross-platform PAB access protocol. > * A voice conference or IP telephony system could access a user's PAB to > provide name-based or nickname-based dialing. > > > This WG will produce the following outputs: > > (1) A revision of the vCard specification (RFC2426) at proposed standard > status. This revision shall include other vCard standardized extensions > (RFC 2739, 4770) and extensions assisting synchronization technologies > (for example, a per-entry UUID or per-attribute sequence number). Other > extensions shall be considered either in the base specification or in > additional documents. > > (2) An address book access protocol leveraging the vCard data format. The > Internet-draft draft-daboo-carddav will be the starting point. > The WG is explicitly cautioned to keep the base specification feature set > small with an adequate extension mechanism, as failure to do so was a > problem for previous PAB efforts (ACAP). The WG will consider arguments of > the form "feature X must be in the base feature set because ..." with > great skepticism. > > These documents will consider security implications carefully. The WG > will consider developing a mechanism that provides the ability to check if > an email address (or im address, etc) is in the user's PAB without > providing unrestricted access to all of the user's PAB data. The WG should > also consider developing a mechanism that allows the user to grant this > limited permission to a third-party service (such as a server-based Sieve > engine) for white-list purposes. > > Once the primary outputs are complete, the WG will consider the following > secondary outputs: > > (3) An XML schema which is semantically identical to vCard in all ways > and can be mechanically translated to and from vCard format without loss > of data. While vCard has deployed successfully and will remain the > preferred interchange format, a standard XML schema which preserves vCard > semantics might make vCard data more accessible to XML-centric > technologies such as AJAX and XSLT. Such a standard format would be > preferable to multiple proprietary XML schemas, particularly if vCard > semantics were lost by some of them and a lossy gateway problem resulted. > (4) Identifying useful deployed vCard vendor extensions and creating > standards track versions of those extensions. > (5) Cooperate with the Sieve WG to produce a Sieve extension for address > book Sieve tests. > (6) LDAP mapping to the new vCard format without loss of data. > > Goals and milestones: > Q1 2008 Address book access protocol draft > Q1 2008 vCard new revision draft > Q2 2008 submit to IESG both drafts > Q2 2008 XML schema > Q2 2008 LDAP schema > Q3 2008 vcard extensions > Q4 2008 submit to IESG remaining drafts > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > ------------------------------------------------------- > _______________________________________________ > KDE PIM mailing list kde-pim at kde.org > https://mail.kde.org/mailman/listinfo/kde-pim > KDE PIM home page at http://pim.kde.org/ > ---------- > > _______________________________________________ > Kolab-format mailing list > Kolab-format at kolab.org > https://kolab.org/mailman/listinfo/kolab-format -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Mail at ease - Rent a kolab groupware server at p at rdus << ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~