[Kolab-devel] Kolab 3.0: Mime Message Storage

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-05-18 22:00, Christian Mollekopf wrote:
> On Friday 18 May 2012 08.11:33 Aleksander Machniak wrote:
>> On 05/17/2012 11:25 PM, Christian Mollekopf wrote:
>> > My point is, that if we allow *any* encoding, we have to support 
>> *any*
>> > encoding in libkolab, and so does every other kolab client, which 
>> is in
>> > fact impossible, unless there are some restrictions on the allowed
>> > encodings in the MIME RFC. Given that a kolab client needs to make 
>> that
>> > decision anyways (in which encoding to write out the xml), I don't 
>> see
>> > why it couldn't just use quoted-printable, unless the given 
>> platform
>> > would indeed lack an
>> > implementation of quoted-printable and implementing it would be 
>> too
>> > cumbersome, which is unlikely given its simplicity. So overall I 
>> just see
>> > allowing multiple encodings complicating matters without any 
>> benefits in
>> > return.
>> >
>> > I do see your argument about using utf-8 for the xml and then 
>> using quoted
>> > printable to encode it again. We can allow utf-8 and quoted 
>> printable, if
>> > you think it's worth the extra effort, but I'm really not in favor 
>> of
>> > allowing just everything, because that just means we have to 
>> implement
>> > every encoding some client implements because we don't comply to 
>> our own
>> > spec otherwise.
>>
>> There are three possibilities for mail messages: base64,
>> quoted-printable and 8bit. I think all recent mail clients support 
>> them.
>> I don't see a need to require any specific encoding type for kolab 
>> objects.
>
> While that may be a de-facto standard, I couldn't find any
> specificaiton stating this.

If I recall correctly, it is RFC 2045 and/or 2049 that state only 7bit, 
8bit or binary can be used, and transmission of non-7bit ascii 
characters over 8bit nor binary compatible transport layers (such as 
legacy SMTP RFC 821) must (thus) be quoted-printable or base64.

> I am ok with defining those three encodings as the available 
> encodings
> for our MIME message format, but I still think we should define them.
> Also IMO every additional encoding raises the implementation efforts
> for a new client, so we shouldn't be unecessarily loose.
>

And, we shouldn't be unnecessarily restrictive either.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08