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