usefor-article-03 February 2000

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 [MESSFOR].

   In plain-text messages (those with no Mime headers, or those with a
   Mime Content-Type of text/plain) posting agents SHOULD 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 SHOULD
   NOT 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.

--- ../s-o-1036/Size_Limits.out          June 1994
+++ ../usefor-article-03/Size_Limits.out          February 2000
@@ -1,120 +1,51 @@
-4.6. Size Limits
+4.5.  Size Limits
 
-Implementations SHOULD avoid fixed constraints on the  sizes
-of  lines  within  an  article and on the size of the entire
-article.
-
-Relayers SHOULD treat the body of an article as an  uninter-
-preted  sequence of octets (except as mandated by changes of
-EOL representation and processing of control messages),  not
-to be altered or constrained in any way.
-
-If  it  is  absolutely  necessary  for  an implementation to
-impose a limit on the length of header lines, body lines, or
-header  logical  lines,  that  limit  shall be at least 1000
-octets, including EOL representations.  Relayers and  trans-
-mission  paths  confronted  with lines beyond their internal
-limits (if any)  MUST  not  simply  inject  EOLs  at  random
-places;  they MAY break headers (as described in 4.2.3) as a
-last resort, and otherwise they MUST either  pass  the  long
-lines  through  unaltered,  or refuse to pass the article at
-all (see section 9.1 for further discussion).
-
-     NOTE: The limit here is essentially the same mini-
-     mum  as  that  specified  for SMTP mail in RFC 821
-     [rrr].  Implementors are  warned  that  Path  (see
-     section  5.6)  and  References  (see  section 6.5)
-     headers, in particular, often become several  hun-
-     dred  characters  long,  so  1000 is not an overly
-     generous limit.
-
-All implementations  MUST  be  able  to  handle  an  article
-totalling  at least 65,000 octets, including headers and EOL
-representations, gracefully and efficiently.  All  implemen-
-tations  SHOULD  be  able  to handle an article totalling at
-least 1,000,000 (one million) octets, including headers  and
-EOL  representations,  gracefully  and efficiently.  "Grace-
-fully and efficiently" is  intended  to  preclude  not  only
-failures,  but also major loss of performance, serious prob-
-lems in error recovery, or resource consumption beyond  what
-is reasonably necessary.
-
-INTERNET DRAFT to be        NEWS                    sec. 4.6
-
-
-     NOTE:  The intent here is to prohibit lowering the
-     existing  de-facto  limit   any   further,   while
-     strongly  encouraging  movement  towards  a higher
-     one.  Actually, although improvements  are  desir-
-     able  in some cases, much news software copes rea-
-     sonably well with very large articles.   The  same
-     cannot  be said of the communications software and
-     protocols used to transmit news from one  host  to
-     another, especially when slow communications links
-     are  involved.   Occasional  huge  articles   that
-     appear now (by accident or through ignorance) typ-
-     ically leave trails of  failing  software,  system
-     problems,  and irate administrators in their wake.
-
-     NOTE: It is intended that the  successor  to  this
-     Draft will raise the "MUST" limit to 1,000,000 and
-     the "SHOULD" limit still further.
-
-Posters SHOULD limit  posted  articles  to  at  most  60,000
-octets,  including  headers  and EOL representations, unless
-the articles are being posted only within a cooperating sub-
-net which is known to be capable of handling larger articles
-gracefully.  Posting agents presented with a  large  article
-SHOULD warn the poster and request confirmation.
-
-     NOTE:  The difference between this and the earlier
-     "MUST" limit is margin for header growth,  differ-
-     ing  EOL  representations,  and transmission over-
-     heads.
-
-     NOTE: Disagreeable though these limits are, it  is
-     a fact that in current networks, an article larger
-     than 64K (after header growth etc.) simply is  not
-     transmitted  reliably.   Note  also  the  comments
-     above on the trauma caused  by  single  extremely-
-     large articles now; the problems are real and cur-
-     rent.  These problems arguably  should  be  fixed,
-     but this will not happen network-wide in the imme-
-     diate future.  Hence  the  restriction  of  larger
-     articles to cooperating subnets, for now.
-
-Posters  using  non-ASCII characters in their text MUST take
-into account the overhead involved in MIME encoding,  unless
-the  article's  propagation  will  be  entirely limited to a
-cooperating subnet which does not  use  MIME  encodings  for
-non-ASCII  characters.   For  example,  MIME base64 encoding
-involves growth by a factor  of  approximately  4/3,  so  an
-article  which would likely have to use this encoding should
-be at most about 45,000 octets before encoding.
-
-Posters SHOULD use  MIME  "message/partial"  conventions  to
-facilitate  automatic  reassembly  of a large document split
-into smaller pieces for posting.  It is recommended that the
-content identifier used should be a message ID, generated by
-
-INTERNET DRAFT to be        NEWS                    sec. 4.6
-
-
-the same means as article message IDs (see section 5.3), and
-that  all  parts  should have a See-Also header (see section
-6.16) giving the message IDs of at least the previous  parts
-and preferably all the parts.
-
-     NOTE:  See-Also  is  more correct for this purpose
-     than References, although References is in  common
-     use  today  (with  less-formal reassembly arrange-
-     ments).  MIME reassemblers should probably examine
-     articles  suggested  by References headers if See-
-     Also headers  are  not  present  to  indicate  the
-     whereabouts   of   the   other   parts   of  "mes-
-     sage/partial" articles.
-
-To repeat: implementations SHOULD avoid fixed constraints on
-the  sizes of lines within an article and on the size of the
-entire article.
+   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 [MESSFOR].
+
+   In plain-text messages (those with no Mime headers, or those with a
+   Mime Content-Type of text/plain) posting agents SHOULD 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 SHOULD
+   NOT 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.