Re: Kolab 3.0: Mime Message Storage

On Friday 18 May 2012 08.11:33 Aleksander Machniak wrote:
> On 05/17/2012 11:25 PM, 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.
> 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. 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.

Cheers,
Christian

_______________________________________________
Kolab-devel mailing list
[email protected]
https://www.intevation.de/mailman/listinfo/kolab-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEABECAAYFAk+2uIkACgkQF4TVOOpldAAyqQCg0zyZCgrXPN5UJY5AvX0H4e2J
jgsAn0XA794DBZNW/p0WSYejZwKB11Ea
=IVvh
-----END PGP SIGNATURE-----