Re: Kolab 3.0: Mime Message Storage

Thomas Brüderli <[email protected]>
Newsgroups gmane.comp.kde.devel.kolab
Message-ID <4FB60B22.4080002__35612.1162571528$1337330489$gmane$org@kolabsys.com>
Christian Mollekopf wrote:
>> First the encoding of the attachment is restricted to quoted-printable,
>> then the encoding of the XML attachment itself is set to utf-8.
>>
>> Honestly, mail clients require some level of compatibility already,
>> including a variety of encodings, such as iso-8859-1 or what is it
>> again, and it doesn't really seem impossible to just allow "whatever is
>> most convenient for the client writing it out".
>>
>> That is to say, libkolabmime / libkolab could of course just only ever
>> writing out quoted-printable. That's not the problem. I just think it's
>> best to not restrict what anything else might write out and have
>> libkolabmime / libkolab act accordingly upon reading the MIME attachment
>> - even though part of the exercise is to have "our clients" use
>> libkolab*.
>>
> 
> 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.

I'd also vote to allow 8bit (raw) encodings for the xml part. The charset
is specified to by UTF-8 by the format spec and all email servers, proxies
and clients nowadays should be able to handle and transfer such parts
without messing up their contents. I don't see the need for encoding the
xml part in quoted-printable either.

~Thomas
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.