Ingo Klöcker <kloecker 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 <bradhfrogmouth.net>
> Subject: [Kde-pim] new IETF activity on vCard
> To: kde-pimkde.org
> Date: Sat, 09 Feb 2008 13:49:00 +1100
> Reply-to: KDE PIM <kde-pimkde.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-secretaryietf.org>
> To: ietf-announceietf.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.blanchetviagenie.ca>
> Kurt Zeilenga <Kurt.ZeilengaIsode.com>
>
> Applications Area Director(s):
> Chris Newman <chris.newmansun.com>
> Lisa Dusseault <lisaosafoundation.org>
>
> Applications Area Advisor:
> Chris Newman <chris.newmansun.com>
>
> Mailing Lists:
> General Discussion: vcarddavietf.org
> To Subscribe: https
://www1.ietf.org/mailman/listinfo/vcarddav
> Archive: http://www1.i
etf.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-Announceietf.org
>
https://www1.ietf.org/mailman/listinfo/ietf-announce
>
> -------------------------------------------------------
> _______________________________________________
> KDE PIM mailing list kde-pimkde.org
> https:/
/mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
> ----------
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-formatkolab.org
> https
://kolab.org/mailman/listinfo/kolab-format
--
______ http://kdab.com
_______________ http://kolab-konsortium.c
om _
prdus Kolab work is funded in part by KDAB and the
Kolab Konsortium
____ http://www.pardus.de
_________________ http://gunnarwrobel.de _
E-mail : prdus.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
prdus <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~
_______________________________________________
Kolab-format mailing list
Kolab-formatkolab.org
https
://kolab.org/mailman/listinfo/kolab-format
|
