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