mailto URIs in KEP#17 and libkolabxml

Christian Mollekopf mollekopf at kolabsys.com
Thu Mar 8 18:25:51 CET 2012


On 2012-03-08 17:39, Thomas Brüderli wrote:
> 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.

God! we're soooo RFC compliant ;-)
I'll add the encoding.

>>
>> 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.


Done (without the url encoding yet, but that's on the todo list).

>>
>> 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.

There is only the XCard:member property where you can actually make use 
of the name embedding, and there you have a setter/getter for both 
email/name. In all other cases you have only the email address, which is 
now transparently mailto encoded. So there's actually no need for the 
mailto struct (respectively it's not even necessary to expose that 
mailto is involved at all).

Cheers,
Christian

>
> ~Thomas
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://www.intevation.de/mailman/listinfo/kolab-format




More information about the format mailing list