Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA06505; Tue, 17 Mar 1998 04:55:39 -0500 (EST) Received: by cs.cs.utk.edu (bulk_mailer v1.9); Tue, 17 Mar 1998 04:53:42 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id EAA06385; Tue, 17 Mar 1998 04:53:40 -0500 (EST) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id EAA06356; Tue, 17 Mar 1998 04:53:32 -0500 (EST) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id KAA11622 for ; Tue, 17 Mar 1998 10:53:28 +0100 (MET) X-Sender: jpalme@mail.dsv.su.se Message-Id: In-Reply-To: <199803162344.SAA29074@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Mar 1998 10:20:19 +0100 To: IETF working group on revision of mail standards From: Jacob Palme Subject: Re: At 00.44 +0100 98-03-17, "Eric S. Raymond" wrote: > Chris, it's clear we need to we need to avoid having the debate bog down > until everyone limps away exhausted. Perhaps another solicitation to > proposal champions, followed up quickly by another straw poll, would > be in order. The last straw poll suggested that we've been suffering > less from genuine deadlock than from very loud, very small minorities. A good idea. But before this is done, it would be useful if the participants of the group are allowed to contribute to short, concise specifications of which are the meaning of the actual proposals. This would ensure that (a) all significant proposals are included in the straw vote, (b) that we know what we mean with the items we vote on. I would also suggest that the straw vote is not a vote with yes or no, or where you have to vote on one single alternative, but rather a vote where voters can, for each alternative, indicate that it is "very good", "good", "acceptable", "bad" or "very bad". In this way, we may find that several alternatives are regarded as good by most of us, then we may actually have rough consensus for any of them. Here is a first attempt to define the alternatives: (1) Keep RFC822 definition of Reply-To as it is (2) Define two headers, "Personal-Reply-To" and "Mail-Followup-To" (as defined by separate documents) and phase out "Reply-To" over a number of years. (3) Define one new header, "Mail-Followup-To", plus change the definition of "Reply-To" to have the maning of "Personal-Reply-To". (4) Define one new header, "Reply-Kinds" with a syntax where several reply addresses can be given for different uses. Example: Reply-Kinds: Personal: John Smith , Mary Smith , Group: Tropical flowers (5) Define one new header "Reply-To-Meaning" which explains the meaning of a separate header "Reply-To". ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme