[NEW KEP] KEP #17: Kolab XML Format 3.0
mollekopf at kolabsys.com
Thu Mar 8 18:11:47 CET 2012
On 2012-03-08 18:00, Thomas Brüderli wrote:
> Christian Mollekopf wrote:
>> On 2012-03-07 17:13, Christian Mollekopf wrote:
>>> On 2012-03-06 9:48, Thomas Brüderli wrote:
>>>> 2) The old format also stored the contact UID within the members
>>>> list of
>>>> a distribution list. This made it easier to connect a member to a
>>>> contact object and to propagate changes from the contact record to
>>>> distributions list. Would it be possible to add an (optional) uid
>>>> element to the member element?
>>> This seems to be a shortcoming of the vcard spec. The only option I
>>> see is adding a x-uid parameter to the property.
>>> I'm going to update that too.
>> For the record:
>> The idea in vcard would be that the member property can point to
>> another vcard using a urn: uri instead of a simple mailto: uri,
>> which is
>> sufficient for email distribution lists.
>> The problem is that a client needs to be pretty smart already to be
>> able to do the actual matching of the urn to a contact, and the
>> distribution-list is completely disfunctional if it can't.
> Actually, a MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af is
> exactly what we'd nned to reference other contacts and it would make
> sense in the context of a Kolab address book. But I agree to your
> second argument that a distribution list becomes dysfunctional once
> such an URI cannot be resolved.
> Furthermore it increases the effort of a simple mail distribution
> script to collect all the recipients of a list.
Yes, it's one of those not-so-interoperable features in the xcard spec
that you can specify *any* uri and expect the client to do something
sensible with it.
With x-uid we have a middleway which can actually work.
>> By using mailto: uris, we're serving the primary purpose of this
>> (email distribution-lists), and make it easy for clients to
>> support for it.
>> By adding an x-uid parameter we introduce data duplication (you have
>> the email address in the contact vcard and the mailto: uri), but
>> clients to implement advanced functionality (by using x-uid), while
>> keeping it simple for simple clients (using the mailto: uri). The
>> additional mailto: uri is also useful in case the contact has
>> email addresses.
>> Obviously the mailto: uri remains authoritative (and not one of the
>> referenced contacts email addresses).
> I guess that's the price we pay for keeping the lists functional. But
> still we should add the x-uid parameter.
Already in master =)
> Acutally, the same problem already exists with the current Kolab 2
> format. Have any specific requirements therefore been documented for
> clients? A client should ensure consistency when touching either a
> contact or a distribution list.
I put it this way:
* "x-uid": This parameter '''MAY''' be used to refer to the
[[#Contact]] object of the member. This parameter '''MUST''' contain the
[[#UID]] of a [[#Contact]] if specified. In case this parameter is used,
the mailto: email address remains authorative for distribution-list
usage. Clients '''MUST NOT''' use an email address from a referenced
contact directly in this case.
It's IMO pretty clear how it must be used, and there is no need to keep
anything consistent, respectively there is no inconsistent state. There
is not even the need that the referenced contact has the same
email-address available as you have stored as mailto in the member
More information about the Kolab-format