No x-uid please. (was: Re: [NEW KEP] KEP #17: Kolab XML Format 3.0)

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Tue Mar 13 01:18:20 CET 2012


On 2012-03-12 17:15, Christian Mollekopf wrote:
> On Monday 12 March 2012 15.40:53 Jeroen van Meeuwen wrote:
>> On 2012-03-08 17:11, Christian Mollekopf wrote:
>> > On 2012-03-08 18:00, Thomas Brüderli wrote:
>> >> (...snip...)
>> >
>> > (...snip...)
>>
>> If I understand correctly, according to the xCard specification, the
>> member element to a distribution list is to contain a valid URI[1].
>>
>
> Yes, the member can contain any valid uri including mailto, a urn
> with the UID of another contact or an imap: uri pointing to a contact 
> resource.
>
>> What we seem to have done is we've gone outside of the boundaries of
>> the xCal specification and added an 'x-uid' attribute to the member
>> element so that Kolab clients can use the values of the attribute to 
>> get
>> to the <uid> of the contact being referred to.
>>
>
> Yes, we have extended it within the bounds of the xCards own 
> extension
> mechanism, so the document remains valid xCard. It is however a 
> non-standard
> property, but I don't think it's less interoperable than having imap 
> as the
> default uri.
>

Arguing an extension to a standard is within the standard is 
misinterpreting the definition of the term "extension".

The standard permits (arbitrary) extensions, but simply by permitting 
extensions, the standard does not make such extensions part of the 
standard.

We're probably going to need a few, but morphing a standard into our 
own version of said standard "just because" is not going to fly.

>> This is supposed to resolve a problem people perceive to exist with
>> referencing external contact entries, but goes about it the wrong 
>> way.
>>
>> The spec says the member attribute can contain a valid URI, 
>> including:
>>
>>    imap://imap.example.org/Contacts/SUBJECT%20<uid>
>>
>> For a client to retrieve the contact objects associated with a
>> distribution list, nothing is gained by adding an x-uid attribute to 
>> the
>> member element over the use of an IMAP URI.
>>
>
> The simplest usecase of a group is IMO an email distribution list.
> This is the primary usecase we're serving using the mailto uri scheme 
> (hence also the
> name).
>
> I went this route because it's very easy to implement for clients,
> and is what the goup has been used for so far (Kontact and kolabV2).
>
> Because we acknowledge there are more advanced usecases where you 
> actually
> want to get hold of the complete contact object, we introduced the 
> x-uid
> attribute, serving that additional/optional usecase. Client's don't 
> need to
> support that attribute to make all possible which has been so far,
> but may, to retrieve the full contact object.

This is exactly the type of circular reasoning we're trying to avoid 
applying to the format by ourselves.

If a Kolab client aware of the meaning of an x-uid attribute value 
reads a distribution list object edited by a client that has no 
understanding of the x-uid attribute value, the behaviour between the 
two clients is going to be different.

Remember we've been there before and it wasn't pretty.

Different clients showing different behaviour, precedence rules, 
conflict detection between asynchronous edits and conflict resolving all 
kick in here, and for no good reason.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08




More information about the format mailing list