Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA10549; Tue, 26 Mar 1996 18:13:57 -0500 Received: by CS.UTK.EDU (bulk_mailer v1.4); Tue, 26 Mar 1996 18:13:38 -0500 Received: from munnari.oz.au (munnari.OZ.AU [128.250.1.21]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA10490; Tue, 26 Mar 1996 18:13:32 -0500 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id XA18256; Wed, 27 Mar 1996 10:13:16 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: djb@koobera.math.uic.edu (D. J. Bernstein) Cc: drums@cs.utk.edu Subject: Re: Domain literals In-Reply-To: Your message of "26 Mar 1996 22:37:21 GMT." <19960326223721.18061.qmail@koobera.math.uic.edu> Date: Wed, 27 Mar 1996 10:13:07 +1100 Message-Id: <6547.827881987@munnari.OZ.AU> Sender: kre@munnari.oz.au Date: 26 Mar 1996 22:37:21 GMT From: djb@koobera.math.uic.edu (D. J. Bernstein) Message-ID: <19960326223721.18061.qmail@koobera.math.uic.edu> Question: Should 822bis addresses be limited to Internet mail addresses? Gawd, that would be a radical change. I actually think I like it, I'd prefer not to have any addressing restrictions in 822, just allow 822 to deal with headers, and have the addressing details someplace else. I do assume here that you know that you are doing away with the (822) requirement that addresses have an '@' character in them, or that any particular characters are restricted in addresses. That is To: a!b!c!user would become a perfectly valid 822bis header (that of course is a uucp address, not Internet), as would To: host::otherhost::user which is a decnet type address. Yes, I think I'd approve that. On the other hand, if we're to remain internet centric, and retain the '@' requirement, restrict the character set choice, etc, then I think I'd make it rational, and certainly get rid of the absurd user@thing.[literal].otherthing meaningless syntax which has no Internet meaning at all, and other than treating "[literal]" as a sub-domain of "otherthing", which certainly could be done (the DNS would not object) never will. kre