why did you develop kolab xml format?
Gunnar Wrobel
wrobel at pardus.de
Thu Mar 20 16:09:47 CET 2008
Ingo Klöcker <kloecker at kde.org> 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 <bradh at frogmouth.net>
> 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 <kde-pim at kde.org>
>
> 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 <iesg-secretary at ietf.org>
> 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 <marc.blanchet at viagenie.ca>
> Kurt Zeilenga <Kurt.Zeilenga at Isode.com>
>
> Applications Area Director(s):
> Chris Newman <chris.newman at sun.com>
> Lisa Dusseault <lisa at osafoundation.org>
>
> Applications Area Advisor:
> Chris Newman <chris.newman at sun.com>
>
> 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 <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the format
mailing list