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

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-03-13 15:51, Christian Mollekopf wrote:
> On 2012-03-13 14:48, Jeroen van Meeuwen (Kolab Systems) wrote:
>> - A client not aware of the x-uid attribute, nor what it's value
>> means, has *no* chance in either of the aforementioned cases to 
>> refer back
>> to the contact object.
>>
>
> Yes, obviously. It also has not if it can't make use of an imap url.
> With the imap url you're completely lost and have a disfunctional
> distlist, while with mailto you have at least the distlist covered.
>

"If it can't make use of an IMAP URI" is quite the moot argument. It 
has the same face-value as saying "if it can't do $x it's not a Kolab 
client".

An IMAP URI is a perfectly valid, standard URI, rather well described 
in an RFC, and provides the linking capability, in a more consistent 
fashion than would deriving from a standard format.

Clients incapable of using IMAP URIs can be made to become compatible 
with an IMAP URI value for the member element.

Clients incapable of using a Kolab specific x-uid however, can not as 
easily be made to become compatible with the x-uid attribute to a member 
element - because it is Kolab specific.

Try and provide functionality within the standards available as defined 
and implemented by the community, which is perfectly possible, as I've 
illustrated.

Even without any completely xCard RFC compliant RFC-defined IMAP URI or 
x-uid attribute run-in-circles-format-fork, resolving the element value 
back and forth is perfectly possible.

Inefficient, perhaps, when, as a client, you are operating directly 
against IMAP, without caching or IMAP abstraction layer.

Caching, as I've mentioned, can greatly enhance a client's capabilities 
to handle changes needed in multiple locations, as long as the routines 
inserting objects into a relational database are sufficiently aware of 
the fact the format allows for references. One can imagine an IMAP 
abstraction layer can perform a similar task

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