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

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Mon Mar 12 16:40:53 CET 2012


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].

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.

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.

Caching aside, which is where you get to do way more funky stuff then 
searching to retrieve (being, linking on update/insert);

- With an x-uid attribute to the member element, all contacts folders 
need to be searched with "SUBJECT <uid>".
- With the IMAP URI, the contacts folder in which the contact is 
supposed to be can be searched first (still with "SUBJECT <uid>" 
though).

The latter is more efficient in most cases.

- With an x-uid attribute to the member element, when a contact's email 
address or display name is updated, all distribution lists need to be 
searched for a matching x-uid attribute to the member element,
- With the IMAP URI, when a contact's email address or display name is 
updated, all distribution lists need to be searched for a matching IMAP 
URI (search parameter).

Both are supposed to be equally efficient.

There's a downside to IMAP URIs as well:

- When a contact is moved from one folder to another, all distribution 
lists could need searching for the old URI (euh, the current uid) to be 
updated to the new URI.

That said, there's a balance to strike between;

- Extending the format for the (perceived) efficiency of Kolab clients, 
and Kolab clients only, and
- Not extending the format and provide (potential) efficiency for all 
clients.

Rests me to say that;

- clients that conform to the specification of xCard are supposed to be 
able to parse any valid URI - thus also RFC 5092[2] IMAP URIs,
- the uid being stored in the Subject header for an RFC822 message with 
a Kolab XML attachment is only one sort of limitation we currently have; 
we should seriously consider using From, To and CC headers as well (to 
possibly store the mailto: URI's DisplayName and <EmailAddress> values 
so that they are indexed by the IMAP server).

Kind regards,

Jeroen van Meeuwen

[1] http://tools.ietf.org/html/rfc6351
[2] http://tools.ietf.org/html/rfc5092

-- 
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