[NEW KEP] KEP #17: Kolab XML Format 3.0

Christian Mollekopf mollekopf at kolabsys.com
Thu Mar 8 07:25:40 CET 2012


On 2012-03-07 17:13, Christian Mollekopf wrote:
> On 2012-03-06 9:48, Thomas Brüderli wrote:
>> Christian Mollekopf wrote:
>>> Dear all,
>>>
>>> A first draft of a KEP which rebases the whole Kolab XML Format on
>>> the xCal&
>>> xCard RFCs resulting in the Kolab XML Format 3.0 specification, has
>>> been
>>> released.
>>>
>>>          KEP 17: Kolab XML Format 3.0
>>>          http://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17
>>>
>>> The KEP still has some rough edges, but should define everything in
>>> the scope
>>> of the KEP or declare that a topic still needs clarification. This
>>> KEP follows
>>> the discussions in [1],[2],[3].
>>
>> Hello
>>
>> I have a few comments concerning the Distribution Lists:
>>
>> 1) In the old Kolab format, the following value for X-Kolab-Type was
>> used: "application/x-vnd.kolab.distribution-list"
>>
>> You now propose to use "application/x-vnd.kolab.contact.distlist"
>> instead. Is this on purpose? Maybe it's irrelevant once an account 
>> is
>> entirely migrated but I see other object types on your draft still
>> having the same X-Kolab-Type assigned as before. And in order to
>> implement a storage layer which can cope with both the old and the
>> new
>> format it would be much appreciated if these headers would remain 
>> the
>> same.
>>
>
> Not sure why I changed that... We can continue to use
> "application/x-vnd.kolab.distribution-list" though, so I'll change 
> that
> back.
>
>> 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
>> the
>> 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.

By using mailto: uris, we're serving the primary purpose of this object 
(email distribution-lists), and make it easy for clients to implement 
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 allow 
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 several 
email addresses.

Obviously the mailto: uri remains authoritative (and not one of the 
referenced contacts email addresses).

Cheers,
Christian

> Cheers,
> Christian
>
>> Thanks,
>> Thomas
>>
>>
>>
>>
>> _______________________________________________
>> Kolab-format mailing list
>> Kolab-format at kolab.org
>> https://www.intevation.de/mailman/listinfo/kolab-format
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-format




More information about the format mailing list