From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/18316 Path: main.gmane.org!not-for-mail From: Karl Kleinpaste Newsgroups: gmane.emacs.gnus.general Subject: Re: OT Length of Header-Lines? Date: 29 Oct 1998 16:06:39 -500 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035156860 5488 80.91.224.250 (20 Oct 2002 23:34:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:34:20 +0000 (UTC) Keywords: sizes,length,text,robustness,today,software Cc: juerg.heim@sunweb.ch Return-Path: Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id QAA17969 for ; Thu, 29 Oct 1998 16:07:55 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id PAB08778; Thu, 29 Oct 1998 15:07:35 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 29 Oct 1998 15:07:27 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id PAA00161 for ; Thu, 29 Oct 1998 15:07:16 -0600 (CST) Original-Received: from pocari-sweat.jprc.com (POCARI-SWEAT.JPRC.COM [207.86.147.217]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id QAA17947 for ; Thu, 29 Oct 1998 16:07:12 -0500 (EST) Original-Received: (from karl@localhost) by pocari-sweat.jprc.com (8.8.7/8.8.7) id QAA01892; Thu, 29 Oct 1998 16:06:39 -0500 Original-To: ding@gnus.org X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu In-Reply-To: Robert Epprecht's message of "29 Oct 1998 21:13:58 +0100" Original-Lines: 79 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:18316 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:18316 On the one hand, this is an utterly stupid question to have to answer. Any "new" mail-serving program which imposes such severe line length limits of that sort has, in the very first analysis, violated the Robustness Principle. RFC 1122, "Requirements for Hosts -- Communications Layers", p. 12: ________________ 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability [IP:1]: "Be liberal in what you accept, and conservative in what you send" ________________ This bug (and that's what it is) appears to be the flip side of the R.P., being so conservative as to be inoperable, and non- interoperable. This conservatism is horribly misplaced -- messages with line sizes > 255 bytes are routine. Did the authors of IMail not do any robustness testing of their own, before inflicting this on the world at large? This is pretty much a first order, low-grade testing criteria, after all: "Does our software handle `big things,' generally?" Did no one think to ask, "How much sense does a measly little 255-byte length limitation make in this day of gigabit trunk lines and gigabyte discs?" That said, the only reference to these sorts of things in the RFCs appears to be RFC 821, "SMTP", p. 42: ________________ 4.5.3. SIZES There are several objects that have required minimum maximum sizes. That is, every implementation must be able to receive objects of at least these sizes, but must not send objects larger than these sizes. **************************************************** * * * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * * OF THESE OBJECTS SHOULD BE USED. * * * **************************************************** [...] text line The maximum total length of a text line including the is 1000 characters (but not counting the leading dot duplicated for transparency). ________________ Text emphasis and offset in original. And that block of text is repeated on the next page, for additional emphasis. Observe that RFC 821 dates from 1982 -- fully 16 years ago -- when 1000 bytes could be considered in some contexts to be a lot of space. Is that true any longer today? Of course not. Note that 821 demands acceptance of "at least these sizes." Not "at most," and not "if the software is feeling especially condescendingly service-oriented today." Just "at least these sizes." RFCs 1122 & 1123 have no comment, as do the POP RFCs, from my brief perusal. No such document discusses the acceptability of truncation, which is to say, it's not. Length limits are Bad, nearly everywhere they are encountered. They may be needed in certain circumstances, but they should be avoided whenever possible. Anyone who is writing such software *today* ought to be expected to be sufficiently aware of general habits on the net in the first place, so as not to write ridiculously length-limited code like that. --karl