Re: Dealing with growing FAQs

Steve Summit (scs@eskimo.com)
Tue, 28 Jun 1994 06:29:46 -0700

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Bob Allison: "FAQ Size"
Previous message: Russell Nelson: "Re: Dealing with growing FAQs"
In reply to: ig25@rz.uni-karlsruhe.de: "Dealing with growing FAQs"
Next in thread: Kent Landfield: "Re: Dealing with growing FAQs"
Reply: Kent Landfield: "Re: Dealing with growing FAQs"

In <9406271247.AA6391@fg70.rz.uni-karlsruhe.de>, Tom Koenig wrote:
> Another datapoint to the 60k limit... here's part of the son of 1036,
> which is likely to become the next News standard.
>...
> # Posters SHOULD limit posted articles to at most 60,000 octets,
> # including headers and EOL representations...
> #
> # NOTE: The difference between this and the earlier "MUST"
> # limit is margin for header growth, differing EOL
> # representations, and transmission overheads.
> #
> # 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 extremelylarge
> # articles now; the problems are real and current...

However, for reference, the text just before that (referred to by
the "difference between this and the earlier `MUST' limit" note)
is:

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.

Now, Henry's being conservative here (because he has to), and I'm
admittedly being belligerent, but I have to say that I have never
heard of any trauma, trails of failing software, irate
administrators, etc. as a result of *any* of the overlarge
comp.lang.c FAQ lists I've been posting every month for several
years now.

Steve Summit
scs@eskimo.com

Next message: Bob Allison: "FAQ Size"
Previous message: Russell Nelson: "Re: Dealing with growing FAQs"
In reply to: ig25@rz.uni-karlsruhe.de: "Dealing with growing FAQs"
Next in thread: Kent Landfield: "Re: Dealing with growing FAQs"
Reply: Kent Landfield: "Re: Dealing with growing FAQs"

[ Usenet Hypertext FAQ Archive | Search Mail Archive | Authors | Usenet ]
[ 1993 | 1994 | 1995 | 1996 | 1997 ]