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

[Christian Mollekopf]

That should have gone to kolab-format. Please discuss it there.

Sorry for the mess.

On 2012-03-08 7:04, 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.
>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-devel

-- 
Christian Mollekopf
Software Engineer

Kolab Systems AG
Zürich, Switzerland

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

pgp: EA657400 Christian Mollekopf