[Kolab-devel] mailto URIs in KEP#17 and libkolabxml

[Christian Mollekopf]

Hey,

In the new format specifications we have mailto: uris in a couple of 
places, and I'm not quite sure how to handle them.

One example is the 1.4.3.1.21 Member property, which lacks an element 
or parameter for the name, but requires a mailto: uri. It is possible to 
embed the name inside the mailto uri in the style of "mailto:John 
Doe<email_1 at email.com>",
but according to the mailto: RFC(http://tools.ietf.org/html/rfc6068) 
one also needs to do encoding afterwards, which results in 
"mailto:John%20Doe%3Cemail%5F1%40email%2Ecom%3E".

Now I can of course do that (it's already implemented), but the 
exercise seems a bit futile. First, I don't think we need the encoding 
since the mailto: uri is inside the kolab xml, where those characters 
aren't reserved.
Second, it might make sense to add a (potentially non-interoperable) 
x-name parameter, because embedding it into the mailto: uri seems a bit 
like a hack.

Another question is how to expose this in libkolabxml. I opted for 
handling the mailto encoding transparently, so you set and get email and 
name, not even knowing that there is a mailto uri under the hood. 
Letting the client do the mailto: encoding seems to fragile if we rely 
on mailto: embedded names.

So what do you think? Should we remove the encoding, but still use the 
name embedding? Or add an x-name parameter?
If noone objects I'll probably drop the encoding but leave the name 
embedding, which simplifies the code, but leaves us with a non-RFC 
compliant mailto: uri (AFAIU).

In other places where mailto: uris are required, libkolabxml doesn't do 
anything at all atm. (the string is just passed on) and expects the 
client to pass in a valid mailto: uri. The situation is less complex, 
because we don't rely on uri embedded names (because xcal has a cn 
parameter). I suppose I can also add automatic mailto: handling there, 
so the clients only have to specify the email address.

In case you wonder why we're using mailto: in the first place, that's 
because the xcard/xcal specifications would also allow for other uris, 
such as urn: pointing to a xcard contact. We're not using this 
possibility right now, though.

Any comments welcome =)

Cheers,
Christian

-- 
Christian Mollekopf
Software Engineer

Kolab Systems AG
Zürich, Switzerland

e: mollekopf at kolabsys.com
w: http://kolabsys.com

pgp: EA657400 Christian Mollekopf