INTERNET-DRAFT                               Charles H. Lindsey
Usenet Format Working Group                  University of Manchester
                                             July 2001

4.5. Size Limits

4.5.  Size Limits
   Posting agents SHOULD endeavour to keep all header lines, so far as
   is possible, within 79 characters by folding them at suitable places
   (see 4.2.3).  However, posting agents MUST permit the poster to
   include longer headers if he so insists, and compliant software MUST
   support headers of at least 998 octets. Likewise, injecting agents
   SHOULD fold any headers generated automatically by themselves.
   Relaying agents MUST NOT fold headers (i.e. they must pass on the
   folding as received).

        NOTE: There is NO restriction on the number of lines into which
        a header may be split, and hence there is NO restriction on the
        total length of a header (in particular it may, by suitable
        folding, be made to exceed the 998 octets restriction pertaining
        to a single header line).

   The syntax provides for the lines of a body to be up to 998 octets in
   length, not including the CRLF. All software compliant with this
   standard MUST support lines of at least that length, both in headers
   and in bodies, and all such software SHOULD support lines of
   arbitrary length. In particular, relaying agents MUST transmit lines
   of arbitrary length without truncation or any other modification.

        NOTE: The limit of 998 octets is consistent with the
        corresponding limit in [RFC 2822].

   In plain-text messages (those with no MIME headers, or those with a
   MIME Content-Type of text/plain) posting agents Ought to endeavour to
   keep the length of body lines within some reasonable limit. The size
   of this limit is a matter of policy, the default being to keep within
   79 characters at most, and preferably within 72 characters (to allow
   room for quoting in followups).  Exceptionally, posting agents Ought
   Not to adjust the length of quoted lines in followups unless they are
   able to reformat them in a consistent manner.  Moreover, posting
   agents MUST permit the poster to include longer lines if he so
   insists.

        NOTE: Plain-text messages are intended to be displayed "as-is"
        without any special action (such as automatic line splitting) on
        the part of the recipient. The policy limit (e.g. 72 or 79)
        should be expressed as a number of characters (as they will be
        displayed by a reading agent) rather than as the number of
        octets used to encode them.

        NOTE: This standard provides no upper bound on the overall size
        of a single article, but neither does it forbid relaying agents
        from dropping articles of excessive length. It is, however,
        suggested that any limits thought appropriate by particular
        agents would be more appropriately expressed in megabytes than
        in kilobytes.

Diffs to previous draft

--- {draft-04}	Wed Jul 11 21:55:16 2001
+++ {draft-05}	Wed Jul 11 21:55:17 2001
@@ -22,11 +22,10 @@
    of arbitrary length without truncation or any other modification.
 
         NOTE: The limit of 998 octets is consistent with the
-        corresponding limit in [MESSFOR].
-[RFC8222? now expresses it as 1000 incl. CRLF]
+        corresponding limit in [RFC 2822].
 
-   In plain-text messages (those with no Mime headers, or those with a
-   Mime Content-Type of text/plain) posting agents Ought to endeavour to
+   In plain-text messages (those with no MIME headers, or those with a
+   MIME Content-Type of text/plain) posting agents Ought to endeavour to
    keep the length of body lines within some reasonable limit. The size
    of this limit is a matter of policy, the default being to keep within
    79 characters at most, and preferably within 72 characters (to allow