s-o-1036 June 1994

4.6. 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.