Son-of-RFC1036:[Previous][Up to Table of Contents] [Next]
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.
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
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.