Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA04358; Sat, 26 Aug 1995 21:28:22 -0400 X-Resent-To: drums@CS.UTK.EDU ; Sat, 26 Aug 1995 21:28:21 EDT Errors-to: owner-drums@CS.UTK.EDU Received: from SEARN.SUNET.SE by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA04351; Sat, 26 Aug 1995 21:28:18 -0400 Message-Id: <199508270128.VAA04351@CS.UTK.EDU> Received: from SEARN.SUNET.SE by SEARN.SUNET.SE (IBM VM SMTP V2R2) with BSMTP id 0110; Sun, 27 Aug 95 03:23:33 +0200 Received: from SEARN.SUNET.SE (NJE origin ERIC@SEARN) by SEARN.SUNET.SE (LMail V1.2b/1.8b) with RFC822 id 9114; Sun, 27 Aug 1995 03:23:33 +0200 Date: Sun, 27 Aug 1995 02:59:31 +0200 From: Eric Thomas Subject: Re: From the Chair: the Reply-To issue To: drums@CS.UTK.EDU I think we're missing an important point in this discussion about whether "Reply-To:" is for public or private replies. While I appreciate that the current Reply-To: specs in RFC822 may be frustrating and not provide a clear answer to a number of questions that developers and users are asking themselves, the fact is that, in 1982, mailing lists were still in their infancy (I won't go so far as to say that they didn't exist, because they did, but they weren't used to the same extent as they are nowadays - they were more like glorified address book aliases that probably got added to the MTA because, uh, it was easier than adding a global address book feature to the UA and, uh, having to convince all users to use the same UA :-) ). If RFC822 had meant to give clear, unambiguous answers on the behaviour of mailing lists, there would have been a section about mailing lists stating how they should behave, and we wouldn't be having this discussion. So it doesn't make much sense to argue whether RFC822 originally intended for "Reply-To:" to apply to a *private* reply to the author, or to a public reply through a potential mailing list. RFC822 simply failed to consider the possibility, hence the lack of "Followup-To:" (or equivalent). If you absolutely have to know what RFC822 originally intended, ask the authors! My guess is that they'll confirm that they hadn't thought of that problem. And even if we decided that RFC822 did after all intend to give the field a particular meaning, to the exclusion of the other, we're stuck with the fact that it's currently used for both things and we don't have any other field we could use for the deprecated meaning. Eric