ietf-822
[Top] [All Lists]

Re: 2822upd-04 line length limits

2008-01-27 14:32:00

On Sunday 27 January 2008 15:28:08 Tony Hansen wrote:

Bruce Lilly wrote:
...
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.

Bruce,

you are both correct and incorrect. The MIME specifications cover a 
number of transfer encodings. Two of those (quoted-printable and base64) 
limit the lines to 76 characters plus a CRLF, as you describe.

2045 overloads the terms used in a Content-Transfer-Encoding field to
indicate either an actual encoding transformation or the domain of
unencoded ("identity transformation" in 2045-speak) content:

    (3)   A Content-Transfer-Encoding header field, which can be
          used to specify both the encoding transformation that
          was applied to the body and the domain of the result.
          Encoding transformations other than the identity
          transformation are usually applied to data in order to

I was referring specifically to the *actual* encoding transformations.
Thanks for the clarification.

Two of the MIME encodings (7bit and 8bit) retain the 998 line limit. 
(RFC 2045 sections 2.7 & 2.8)

However, one of the MIME encodings (binary) REMOVES all line length 
limitations. (RFC 2045 section 2.9) It does indeed *extend* the 
specification.

These "identity transformations" describe the domain of unencoded
body content.  See also section 6.2 of RFC 2045.
 
And there is room left within the specification for other encodings to 
be defined that have other limitations, although none are currently 
defined within the MIME specs, nor is it likely that there ever will be any.

[off-topic]
The 2045-defined (actual, not "identity") encoding transformations both
result in an implicit 7bit domain (of the encoded text). I recall that
Ned was at one time working on a binary to 8bit transformation, but
there seemed little interest in it from precisely the community that
would have benefitted from it.

[back on-topic]
In addition to 2045's discussion of body content, RFC 2047 (as amended by
2231 and errata (http://www.rfc-editor.org/cgi-bin/errata.pl)) also
restricts the length of header field lines containing an encoded-word
to 76 characters.  As can be seen from the quoted draft text above,
RFC 2047, RFC 2231, and the RFC errata are not mentioned in the draft.
Many of the RFCs referenced by the draft ARE amended by errata (q.v.)
and/or other RFCs (the rfc-index provides some hints, but is not
exhaustive).
 
I suggest changing the wording "extend this specification" to be 
"shorten or extend this line length limitation".

That works for part of the problem, although it only applies to the
generation (not parsing) part of the 2822 grammars, contrary to the
description of section 2 provided in section 1.2.3 (the 2822upd-04
parse grammar contains neither of the restrictions specified in
draft section 2.3).  And as noted above, there are relevant RFCs
and errata not mentioned in the draft.

<Prev in Thread] Current Thread [Next in Thread>