Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA21587; Tue, 2 Apr 1996 16:21:44 -0500 Received: by CS.UTK.EDU (bulk_mailer v1.4); Tue, 2 Apr 1996 16:20:33 -0500 Received: from koobera.math.uic.edu (qmailr@KOOBERA.MATH.UIC.EDU [128.248.178.247]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA21437; Tue, 2 Apr 1996 16:20:29 -0500 Received: (qmail-queue invoked by uid 666); 2 Apr 1996 21:22:46 -0000 Date: 2 Apr 1996 21:22:46 -0000 Message-ID: <19960402212246.12608.qmail@koobera.math.uic.edu> From: djb@koobera.math.uic.edu (D. J. Bernstein) To: drums@cs.utk.edu Subject: Re: legal 822, illegal 822bis > 1) The legal 822 structure will often break in the installed base. MUST NOT generate. Do you want message creators to get into trouble? MUST parse correctly. Do you want parsers to get into trouble? Is the objective here to minimize trouble, or to design a new standard? > 2) The legal 822 structure is mostly unused. As I've mentioned before, I think 99.98% reliability is abysmal. Note also that the use of a structure can change over time; for example, empty groups are much more popular now than they were a year ago. > 3) There is no legitimate reason to use the legal 822 structure. This says that there is no disadvantage to MUST-NOT-generate. > 4) Removal of the legal 822 structure would simplify parsers, In every case the simplification has been _insignificant_. Mark's claims of substantial simplification, no matter how often repeated, are false. This is something we can measure---there are code metrics, you know. > the > document, or have other technical benefits. Simplification of the document is a bad idea when it comes at the cost of clarity. If there are other technical benefits, let's hear them. > If all of these conditions are met, then the identified 822 structure > should not only be forbidden in generation, but should be removed from > the basic accept grammar No. Do you want parsers to get into trouble? DRUMS can do something valuable here by telling implementors everything they need to know. I don't understand why you want to throw this away. > This requires us to remove some crud from 822, > since current practice shows it is not sufficiently implementable for > the real world. I disagree. The problem with 822 is a paucity of examples. Look at all the text in 3.4.4, for example, with no examples to make it clear. > The best incentive would be to cause their products to > break _more_ often -- not less often. I find this philosophy absolutely disgusting. You are exalting your own desire to change 822 over the integrity of the Internet mail system. This is exactly what we saw in the despicable case of an MTA bouncing messages without Message-ID. ---Dan