mailto URIs in KEP#17 and libkolabxml

[Thomas Brüderli]

Christian Mollekopf wrote:
> 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.

Well, if the RFCs suggest it that way, we should follow for the sake of 
interoperability.
>
> 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.

It would be nice if libkolabxml would make it transparent by introducing 
a mailto struct with the according getters and setters for name and email.
>
> 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).

I vote for using mailto: URLs including proper URL encoding but all 
encoding/decoding done transparently by libkolabxml.
>
> 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.

Using a dedicated mailto struct would simplify things for users of the lib.

~Thomas