Hi Jörg, Well, I misunderstood it, too. I agree that checking Content-Transfer- Encoding is usefull, and simple. Perhaps you can add it ?
Aarno Jörg Pommnitz wrote: > I think I misrepresented my point: I just encountered > an example in RFC2387 where application/octet-stream > is represented in BASE64. The same could theoretically > happen with any other content (XML encoded in UCS-16 or > UTF-8 being a good candidate). > I think Kannel should check the Content-Transfer-Encoding > header and do its best to correctly handel encoded content. > It will most likely encounter BASE64 (quoted printable > is just ugly). Supporting BASE64 should be easy: we already > have the octstr_base64_to_binary(Octstr *ostr) function, > so just a few more lines of code would be required to glue > this in. > > Regards > Jörg > > > -----Ursprüngliche Nachricht----- > > Von: Aarno Syvänen [mailto:[EMAIL PROTECTED]] > > Gesendet am: Dienstag, 23. Oktober 2001 11:50 > > An: Jörg Pommnitz > > Cc: [EMAIL PROTECTED] > > Betreff: Re: AW: Kannel PPG, PI and character encoding > > > > Hi Jörg, > > > > Jörg Pommnitz wrote: > > > > > I just read RFC2387: it uses base64 as transfer > > > encoding for application/octet-stream data. While > > > there is a void octstr_base64_to_binary(Octstr *ostr) > > > function in the Kannel source tree it seems not to > > > be used in the PPG code. Aarno, what's your opinion? > > > > This is a good question. Will Kannel do any transform- > > ations to multipart application/octet-stream data ? If it > > does not (and I think it should not) it should only pass > > (and tokenize, of course) content headers to the client. > > It the client that decodes transfer-encoding. > > > > aarno > >
