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