Re: [Nmh-workers] base64 ... just looking for advice

[Wolfgang Denk]

Dear David,

In message <address@hidden> you wrote:
> Ken wrote:
> 
> > [Wolfgang:}
> > >> However I notice that not only the "text/plain" part has been
> > >> modified;  the "text/html" part has _also_ been modified:
> > >> originally, it was a base64 encoded HTML file with UNIX line endings
> > >> (plain LF); now it is a base64 encoded file with DOS line endings (CR
> > >> + LF).
> >
> > Just as a point of note ... text parts that are based-64 encoded are
> > supposed to have CR+LF line endings.  Before we got that wrong, but the
> > latest release of nmh should get that right (we'll write out those with
> > Unix line endings when storing them, and add a CR during encoding).
> > Technically a base64-encoded text part with Unix line endings is wrong
> > according to the standard.
> 
> Oh yeah, thanks.  I could see an option for mhfixmsg to not try to do the 
> right thing.  I find the current behavior of adding the CRs when it's 
> supposedly not modifying a part to be a bit annoying.

I'm not sure what Ken means here; I understand him such that the
base64 encoded part should have CR+LF line endings.  This is ok with
me.

What I was compaining about was that the data payload (i. e. the
text/html which was encoded) would be converted to CR/LF, i. e.

        Zm9vCmJhcgo=<CR><LF>

should NOT be converted to

        Zm9vDQpiYXINCg==<CR><LF>

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: address@hidden
"I find this a nice feature but it is not according to  the  documen-
tation. Or is it a BUG?"   "Let's call it an accidental feature. :-)"
                       - Larry Wall in <address@hidden>