Re: Event element encoding

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!


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click