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

Christian Mollekopf mollekopf at kolabsys.com
Mon Mar 12 18:15:27 CET 2012


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.

> 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.
If you have only the urn or imap link to the contact object, you require every 
client to be able to retrieve it and find the right email address (for the 
distribution list usecase). Finding the right email address is not even 
trivial, we'd need some selection mechanism which email address should be 
used, probably ending up in x-email (That's the only feasible solution that 
comes to my mind right now).

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

Yes, that is not ideal. Maybe we should use the imap uri then within the x-uid 
element. Or an additional x-imap element as optimization. We chose the urn 
because Roundcube can work with that and it seem conceptually the nicest (it's 
the globally unique identifier). We'd also have to see how to make the imap uri 
work within Kontact.
I think that is definitely something we should consider though.

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

Yes, that is indeed an advantage.

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

Not sure about that one. It could make sense to do that if you actually link 
the contact there. If you have distribution lists as stupid lists (as it is 
currently implemented in Kontact), I don't think you'd even want that (it 
would seem quite unexpected behavior to me).
If we have the imap uri in the x-uid attribute that's pretty easy for a client 
to update though.

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

Don't see why, because with the imap uri in the uri element, there is no email 
address within the distribution list which would need to be updated. Am I 
misunderstanding?

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

Yep, that's a bit nasty. That would speak for urn instead of imap (maybe x-
imap as a possible optimization). If possible we should try to work as much as 
possible with globally unique identifiers, because that just makes it easier if 
you have several instances of the same entity on different devices and want to 
sync them afterwards again. Using an imap uri is certainly better from a 
performance/efficiency POV, but I'd rather have that as an additional mechanism 
allowing performant retrievals where possible. If the imap retrievel fails you 
could just issue a search and update the new imap uri afterwards.

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

Yes. Note that we extended the format for compatibility reasons for all 
clients. Ideally we would be using the urn instead of mailto and all clients 
could deal with that, what we're doing now just seems much more feasible.

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

Yeah, but they also need to be able to do something sensible with it. And I 
don't know of any client that can make use of an imap uri in the member 
attribute. Kontact can't for sure out of the box

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

Ok, I have nothing against that, as long as we keep all the authoritative data 
within the xCard/xCal file.

To sum up, I still think the current approach with mailto as member property 
and and x-uid with the urn of the contact is a good one, because it covers all 
our current needs, provides a low entry barrier for client implementors, 
doesn't require any changes in Kontact and allows for adding more 
functionality incrementally without breaking clients not supporting this.

Using imap in the x-uid property would be a possible solution, but I'd rather 
have that in an x-imap property as pure optimization with x-uid being the 
authoritative link to the contact (imap as the primary link doesn't seem very 
sustainable to me).

What ever makes sense to extract to the mime headers for performance, we can 
put there, as long as we have the authoritative version in the XML object IMO. 
So just tell me what you want/need on that side.

Cheers,
Christian

> 
> Kind regards,
> 
> Jeroen van Meeuwen
> 
> [1] http://tools.ietf.org/html/rfc6351
> [2] http://tools.ietf.org/html/rfc5092
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20120312/7404f26f/attachment.sig>


More information about the format mailing list