On Mon, 21 Jul 2003, Tony Finch wrote:
> The most common one is Mac OS. I don't know if it's still the case for
> Mac OS X, though. Acorn also used bare CRs, but that's not practically
> useful information these days.
IIRC, Acorn changed to LF for Risc OS.
> My suggestion of transforming bare CR to CRLF space (or CRLF tab) was
> intended for headers only. I'm not to happy with following the Cyrus
> interpretation since it means different people along the relay chain
> see different header information on the same message. I'm also not happy
> about quietly throwing nasty octets away.
I entirely agree, and, having studied the code, I think this won't be
too hard to do. So the proposal now is:
All three of CR, LF, and CRLF are treated as line terminators. However,
if a bare CR occurs in a header line, it is turned into a line
terminator followed by a space - in other words, it does not terminate
the logical header line.
> >4. Should there be any options to change these interpretations? If the
> > answer is "no", the drop_cr and -dropcr options can be made into
> > no-ops and obsoleted. If the answer is "yes", what is needed?
>
> I note that RFC 3030 (BINARYMIME) doesn't have anything helpful to say --
> it still insists on CRLF newlines :-(
On the wire that is certainly true.
Oh well, I'll take all the options away, and wait to see if anybody
wants anything different.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
