I know that it is an RFC, but it does say that it is standards track and
there doesn't seem to be a full standard already that covers the same
info. However, STD11 is not helpful in this argument. It is not covering
the presentation of the message, only its transport. I don't believe
that unruh is saying that his mailer cannot handle the long lines, he is
saying that his mailer displays long lines on the screen as long lines.
The RFC I referred to also is basically talking about the transport
format of the message, but does address how they should be presented on
screen as well.
Now, if you don't like RFC2646, you might say it's not a standard and
that you won't follow it, but I don't think you should get a lot of
sympathy, just as if you decided that you were going to ignore RFC 1305
because it isn't a standard.
On 2/21/2013 1:08 PM, Mike S wrote:
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
[email protected]
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
