Section 2.1.1 states in part:
Again, even though this limitation is
put on messages, it is incumbant upon implementations which display
messages to handle an arbitrarily large number of characters in a
line (certainly at least up to the 998 character limit) for the sake
of robustness.
[off-topic] "incumbant" should be "incumbent". A spell-checker can find
this and many other similar errors in the text...
No! The MIME RFCs specifically state that lines (in header or body)
which use MIME encoding are limited to 76 (N.B. not 78 or 998) characters.
Please do not suggest, imply, or leave to the reader's imagination that
MIME-encoded text can be placed in long lines. Do not under any
circumstances imply that MIME-conforming implementations must handle
encoded text in lines "at least up to the 998 character limit".
Section 2.3 states in part (I'll address the other part in a separate message):
o Lines of characters in the body MUST be limited to 998 characters,
and SHOULD be limited to 78 characters, excluding the CRLF.
Note: As was stated earlier, there are other documents,
specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049],
[RFC4288], [RFC4289]), that extend this specification to allow for
different sorts of message bodies. Again, these mechanisms are
beyond the scope of this document.
Note (as stated above) that the MIME RFCs *limit* line lengths to 76
characters when MIME encoding is used. The text "extend this specification"
might be misinterpreted (76 characters is a *limitation*, not an
*extension*) w.r.t. line length limits. At a minimum, some clarification
of this point is needed in the draft text.
Section 3.5 begins with:
A message consists of header fields, optionally followed by a message
body. Lines in a message MUST be a maximum of 998 characters
excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
characters excluding the CRLF. (See the note in section 2.1.1 for
explanation.)
Here again, some note of the lower length limit imposed on MIME-encoded
text is needed.