Re: Kolab 3.0: Mime Message Storage

On Friday 18 May 2012 23.38:02 Jeroen van Meeuwen wrote:
> 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.
> 

From my understanding RFC 2045 intially specifies "7bit" / "8bit" / "binary" 
/"quoted-printable" / "base64", but basically allows for arbitrary extensions 
of that list using an x-token or by specification of further RFC's.

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

As I said, I see reasons to restrict (implementation effort and 
interoperability in case of incomplete implementations).

So, should we not make any additional restrictions (everything that is valid 
MIME is valid for a Kolab Object? Of course that will mean that our 
implementation is incomplete, so I would just add a recomendation that quoted-
printable SHOULD be used. Would that be ok?

Cheers,
Christian

> 
> Kind regards,
> 
> Jeroen van Meeuwen

_______________________________________________
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+3fC8ACgkQF4TVOOpldAABGwCghxcJj+VxElSp7jESPZl0RiHd
FWkAoOWxYeDD5DdJtJQmV6f7aY4OXKN8
=/j7C
-----END PGP SIGNATURE-----