usefor-article-04 April 2001
[< Prev]
[TOC] [ Next >]
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].
[RFC8222? now expresses it as 1000 incl. CRLF]
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.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-03/Size_Limits.out February 2000
+++ ../usefor-article-04/Size_Limits.out April 2001
@@ -8,6 +8,7 @@
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
@@ -23,14 +24,15 @@
NOTE: The limit of 998 octets is consistent with the
corresponding limit in [MESSFOR].
+[RFC8222? now expresses it as 1000 incl. CRLF]
In plain-text messages (those with no Mime headers, or those with a
- Mime Content-Type of text/plain) posting agents SHOULD endeavour to
+ 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 SHOULD
- NOT adjust the length of quoted lines in followups unless they are
+ 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.