From: Kragen S. <kra...@ai...> - 2004-03-23 19:47:47
|
On Tue, Mar 23, 2004 at 09:08:20AM +1100, Robert Leftwich wrote: > We might run into problems with Rule 4 of RFC 1521 which says "A line > break in a text body, independent of what its representation is following > the canonical representation of the data being encoded, must be represented > by a (RFC 822) line break, which is a CRLF sequence...", but given the > python server encodes \n it may not be an issue. Hmm, it's only in the Perl server's on-disk format that we leave newlines in kn_payload unencoded, right? Nobody uses an on-the-wire format with a special case for kn_payload? > The fact that the mps spec only uses the QP 'style', not the QP spec itself > is a possible source of problems, so using a qp decode function is probably > not ideal. Although, the likelihood of it causing any problems appears to > be pretty low, as evidenced by the fact that no-one is reporting any actual > problems! > > Do we keep the status quo and 'don't fix it if it ain't broke'? Maybe nobody's been testing most of the clients with, say, JPEG files as event attributes. Maybe we should. > All things going well I should have a useable release later today, but > writing unit tests that cover all the edge cases is no small undertaking! That's excellent! |