Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA05425; Sun, 6 Feb 2000 15:45:49 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Sun, 6 Feb 2000 15:43:01 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA05064; Sun, 6 Feb 2000 15:43:00 -0500 (EST) Received: from muncher.math.uic.edu (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA05051; Sun, 6 Feb 2000 15:42:59 -0500 (EST) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by CS.UTK.EDU (smtpshim v1.0); Sun, 6 Feb 2000 15:42:59 -0500 Received: (qmail 11242 invoked by uid 1001); 6 Feb 2000 20:43:15 -0000 Date: 6 Feb 2000 20:43:15 -0000 Message-ID: <20000206204315.19320.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: RFC822's Appendix D, and X- fields Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Sam Roberts writes: > And what about Appendix B, Simple Field Parsing, or is it deemed > redundant? Not at all. Any sensibly structured parser will start that way. See http://cr.yp.to/immhf/header.html and http://cr.yp.to/immhf/field.html; beware that there are several interoperability problems to watch out for even in this ``simple'' format. > I also was looking for a description of the X- for extension fields > that will never conflict with the names of standard fields. If you're trying to avoid conflicts, contribute to my list of names at http://cr.yp.to/immhf/index.html. The X- prefix really doesn't help. ---Dan