On 2/21/2013 8:52 AM, Brian Utterback wrote:
Having said that, I note that Ed Mischanko's mailer is not sending
text/plain flowed. So unruh has a point in that case.
On 2/21/2013 8:38 AM, Brian Utterback wrote:
Hate to get into a religious war here, but there is a hard, factual
standard here. RFC2646 which defines the MIME type text/plain format
parameter.
RFC2646 isn't a standard. It's an RFC, just like RFC1149. The standard
is STD11 (from RFC822). It places no restriction on the length of lines
in the body. The planned replacement (draft standard) is RFC5322, which
is quite clear that an MUA which can't handle long lines is
"non-conformant."
"2.1.1. Line Length Limits
There are two limits that this specification places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.
The 998 character limit is due to limitations in many implementations
that send, receive, or store IMF messages which simply cannot handle
more than 998 characters on a line. Receiving implementations would
do well to handle an arbitrarily large number of characters in a line
for robustness sake. However, there are so many implementations that
(in compliance with the transport requirements of [RFC5321]) do not
accept messages containing more than 1000 characters including the CR
and LF per line, it is important for implementations not to create
such messages.
The more conservative 78 character recommendation is to accommodate
the many implementations of user interfaces that display these
messages which may truncate, or disastrously wrap, the display of
more than 78 characters per line, in spite of the fact that such
implementations are non-conformant to the intent of this
specification (and that of [RFC5321] if they actually cause
information to be lost)."
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
