From owner-ietf-822 Sun Jan 12 17:23:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA02594 for ietf-822-bks; Sun, 12 Jan 1997 17:23:33 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-822@imc.imc.org using -f Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id RAA02582 for ; Sun, 12 Jan 1997 17:23:26 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Jan 1997 17:22:57 -0800 To: ietf-822@imc.org From: "Paul E. Hoffman" Subject: The new "ietf-822" mailing list Sender: owner-ietf-822@imc.org Precedence: bulk Greetings. This is the first message on the ietf-822 mailing list, which has moved from CREN to IMC. The participants of the list are the same. There is a Web site for the list at which has an archive of both the old list and the new one. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-822 Tue Feb 18 16:07:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA15536 for ietf-822-bks; Tue, 18 Feb 1997 16:07:31 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA15531 for ; Tue, 18 Feb 1997 16:07:28 -0800 (PST) Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16639(1)>; Tue, 18 Feb 1997 16:08:58 PST Received: from palimpsest ([127.0.0.1]) by palimpsest.parc.xerox.com with SMTP id <242>; Tue, 18 Feb 1997 16:08:46 PDT Message-ID: <330A448D.7EA8@parc.xerox.com> Date: Tue, 18 Feb 1997 15:08:45 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ietf-822@imc.org Subject: content-disposition Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk After a lot of wrangling about how to present form data within multipart, RFC 1867 ("Form-based File Upload in HTML") recommended that data returned from filling out a form be returned as multipart/form-data where each part is identified with content-disposition: form-data. One of the things holding back RFC 1867 from standards track is that content-disposition was itself "experimental". There is ample experience now with RFC 1867, at least in HTTP, although there are some mail implementations as well. draft-moore-mime-cdisp-00 makes no mention of this use of content-disposition. There's a desire to move RFC 1867 onto standards track, or at least those parts that are outside the realm of HTML markup, even if the HTML extensions become part of W3C's next revision of HTML. What are your thoughts? Would you consider mentioning the possibility of content-disposition: form-data; name="fieldname" as a legitimate use of content-disposition within multipart/form-data in draft-moore-mime-cdisp? Thanks, Larry From owner-ietf-822 Tue Feb 18 23:32:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA21234 for ietf-822-bks; Tue, 18 Feb 1997 23:32:41 -0800 (PST) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA21223 for ; Tue, 18 Feb 1997 23:32:38 -0800 (PST) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id CAA01230; Wed, 19 Feb 1997 02:34:39 -0500 (EST) Message-Id: <199702190734.CAA01230@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Larry Masinter cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: content-disposition In-reply-to: Your message of "Tue, 18 Feb 1997 15:08:45 PST." <330A448D.7EA8@parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 1997 02:34:39 -0500 Sender: owner-ietf-822@imc.org Precedence: bulk > After a lot of wrangling about how to present form data > within multipart, RFC 1867 ("Form-based File Upload in HTML") > recommended that data returned from filling out a form > be returned as multipart/form-data where each part is > identified with > content-disposition: form-data. > > One of the things holding back RFC 1867 from standards track > is that content-disposition was itself "experimental". There is > ample experience now with RFC 1867, at least in HTTP, although > there are some mail implementations as well. > > draft-moore-mime-cdisp-00 > > makes no mention of this use of content-disposition. This was an accidental omission on my part; I had intended to include form-data and simply forgot to do so. Barring strong objections, I'll put it in the next draft. Keith From owner-ietf-822 Fri Feb 21 19:25:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA04666 for ietf-822-bks; Fri, 21 Feb 1997 19:25:16 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA04662; Fri, 21 Feb 1997 19:25:12 -0800 (PST) Received: from [205.214.160.130] (d20.netgate.net [205.214.160.52]) by ng.netgate.net (8.8.5/8.6.9) with ESMTP id TAA26971; Fri, 21 Feb 1997 19:30:56 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 2 (High) Date: Fri, 21 Feb 1997 19:26:15 -0800 To: imc-mailconnect@imc.org From: Dave Crocker Subject: MailConnect 2 interoperability event Cc: (drums, ietf-smtp@imc.org, ietf-822@imc.org, imap@cac.washington.edu) Sender: owner-ietf-822@imc.org Precedence: bulk =46olks, The Internet Mail Consortium is now trying to finalize details for MailConnect 2, an engineering interoperability event for Internet mail software developers. This past summer's MailConnect 1 tested IMAP4 and MIME. MailConnect 2 is intended for ESMTP and more IMAP4 testing. In previous queries, the end of March appeared to be the best choice for bringing developers together. I would like to get some quick feedback about preferred dates, from folks who are likely to attend. LOGISTICS The event will be in the same venue as before, the San Jose, CA Hilton. They now have a T1 connection to the net. We'll be providing snacks and drinks and, will provide lunch this time. We are investigating reduced room rates at the Hilton. Let me know if you would be likely to stay there: Yes ____ No ____ DATE Please indicate ALL of the following that are feasible for you: March 18/19 - T/W ____ 19/20 - W/Th ____ 21/22 - Th/F ____ March 25/26 - T/W ____ 27/28 - W/Th ____ 28/29 - Th/F ____ April 1/2 - T/W ____ 2/3 - W/Th ____ (no 3/4, to avoid the Friday before IETF) If a later date is very strongly preferred, please let me know. If a later date is very strongly NOT preferred, also let me know. COSTS Early Registration: $1500 for IMC members; $2000 for non-members Late Registration: $2000 for IMC members; $2500 for non-members d/ -------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segre Place dcrocker@imc.org Santa Cruz, CA 95060 USA info@imc.org , http://www.imc.org From owner-ietf-822 Wed Mar 5 11:08:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25824 for ietf-822-bks; Wed, 5 Mar 1997 11:08:29 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA25813; Wed, 5 Mar 1997 11:08:11 -0800 (PST) Received: from [205.214.160.83] (d45.netgate.net [205.214.160.79]) by ng.netgate.net (8.8.5/8.6.9) with ESMTP id LAA08457; Wed, 5 Mar 1997 11:15:38 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 2 (High) Date: Wed, 5 Mar 1997 11:08:33 -0800 To: imc-mailconnect@imc.org From: Dave Crocker Subject: MailConnect 2 / 26-27 March 97: Email Interoperability testing Cc: (drums, ietf-smtp@imc.org, ietf-822@imc.org, imap@cac.washington.edu) Sender: owner-ietf-822@imc.org Precedence: bulk The Internet Mail Consortium is sponsoring a second interoperability testing event for Internet Mail. MailConnect 2 will be held: Wednesday - Thursday, 26-27 March 1997 with setup: available the day before at: San Jose, California Hilton testing: IMAP4 and ESMTP The details of the testing will be determined by the attendees, based on discussion on the imc-mailconnect mailing list, beforehand. This is the second time we will be testing IMAP4 and the first for SMTP extensions. The event is for engineering testing, rather than for press and marketing demonstrations. These events improve actual interoperability among independent implementations, typically producing enormous imrpovements within the very short time of the meeting. =46or further details, please see: To subscribe to the event discusssion list, send a message to imc-mailconnect-request@imc.org with the single word subscribe in the body of the message. d/ -------------------- Dave Crocker, Director +1 408 246 8253 Internet Mail Consortium (f) +1 408 249 6205 127 Segre Place dcrocker@imc.org Santa Cruz, CA 95060 USA info@imc.org , http://www.imc.org From owner-ietf-822 Tue Apr 29 10:45:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA02426 for ietf-822-bks; Tue, 29 Apr 1997 10:45:04 -0700 (PDT) Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA02422 for ; Tue, 29 Apr 1997 10:45:00 -0700 (PDT) Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20533 for ; Tue, 29 Apr 1997 10:45:59 -0700 Received: from shorter.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA26577; Tue, 29 Apr 1997 10:45:57 -0700 Received: from cochin.eng.sun.com by shorter.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15530; Tue, 29 Apr 1997 10:45:59 -0700 Received: from cochin by cochin.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA03526; Tue, 29 Apr 1997 10:45:56 -0700 Date: Tue, 29 Apr 1997 10:45:56 -0700 (PDT) From: John Mani Reply-To: John Mani Subject: URL type To: ietf-822@imc.org cc: jmk@cochin.Eng.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ie0k4RNezTf5GBmxqR6XfA== X-Mailer: dtmail 1.1.0 CDE Version 1.1_40 SunOS 5.5.1 sun4u sparc Sender: owner-ietf-822@imc.org Precedence: bulk Hi all We want to use the MIME typing system as a generic datatyping/naming mechanism (outside of mail) in our system. I know that RFC 2017 states that 'message/external-body; access-type=URL; URL=' is the recommended way of typing URLs in MIME email. However this is probably too cumbersome and too mail-specific in our generic system. What we want is a way to specify URLs as real "standalone" types. Our choices are "text/x-url" and "application/x-url". What would be the appropriate 'type' in this case ? (What's the guiding factor in deciding which type - application or text ?) And finally, is there any interest in making this a standard type ? Comments ? thanx -john From owner-ietf-822 Tue Apr 29 11:41:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA03455 for ietf-822-bks; Tue, 29 Apr 1997 11:41:20 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [128.248.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA03450 for ; Tue, 29 Apr 1997 11:41:17 -0700 (PDT) Received: (qmail 17322 invoked by uid 666); 29 Apr 1997 18:50:16 -0000 Date: 29 Apr 1997 18:50:16 -0000 Message-ID: <19970429185016.17321.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: URL type Sender: owner-ietf-822@imc.org Precedence: bulk > We want to use the MIME typing system as a generic datatyping/naming > mechanism (outside of mail) in our system. Why? There are several well-known extensible type identification systems with far less overhead than MIME. Are you subject to the constraints that MIME was designed to satisfy? Human readability, RFC 822 header field use, variable content encodings, invulnerability to various forms of corruption? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Fri Jun 13 12:05:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA17811 for ietf-822-bks; Fri, 13 Jun 1997 12:05:11 -0700 (PDT) Received: from porta-sparc.mcom.com (h-205-217-229-148.netscape.com [205.217.229.148]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA17805 for ; Fri, 13 Jun 1997 12:05:08 -0700 (PDT) Received: from jgmyers-nt (h-205-217-229-208.mcom.com [205.217.229.208]) by porta-sparc.mcom.com (1.0.b2/8.8.5) with ESMTP id MAA27348 for ; Fri, 13 Jun 1997 12:06:46 -0700 (PDT) Message-ID: <33A19AB6.E026E93F@netscape.com> Date: Fri, 13 Jun 1997 12:08:38 -0700 From: John Gardiner Myers X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-822@imc.org Subject: Accept-Language: proposal X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk I have a need to localize the human-readable text inside of DSN's and other automated responses to 822-format messages. Here is a proposal I would like to float here, prior to issuing an internet-draft. Rough definition: Define an "Accept-Language" header with the following syntax. accept-language = "Accept-Language" ":" 1#Language-tag ; Language-tag as defined in RFC 1766 This header discloses the language preference(s) of the sender. Languages listed earlier in the list are preferred. The existence of this header also indicates that the sender is capable of handling text encoded in the utf-8 charset [RFC 2044], when properly MIME labeled. Comments: The syntax of this header is deliberately a subset of that in HTTP. Since this header is presumably only going to be generated by "new" UA's, it is not unreasonable to require these "new" UA's to support UTF-8. The alternative of also negotiating acceptable charset is worse. Disadvantages: Does not necessarily work correctly if the message goes through list expansion. The language preferences of the list maintainer can be different than those of the original sender, so if the list expander does not know to strip or replace the Accept-Language header, the list maintainer could get DSN's in a language and charset they don't understand. So, what do people think? From owner-ietf-822 Fri Jun 13 12:56:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA18366 for ietf-822-bks; Fri, 13 Jun 1997 12:56:38 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA18362 for ; Fri, 13 Jun 1997 12:56:35 -0700 (PDT) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <16902(6)>; Fri, 13 Jun 1997 12:58:37 PDT Received: from bronze.parc.xerox.com ([13.1.100.114]) by casablanca.parc.xerox.com with SMTP id <71897>; Fri, 13 Jun 1997 12:58:30 PDT Message-ID: <33A1A65C.430D@parc.xerox.com> Date: Fri, 13 Jun 1997 12:58:20 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: John Gardiner Myers CC: ietf-822@imc.org Subject: Re: Accept-Language: proposal References: <33A19AB6.E026E93F@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk > The existence of this header also indicates that the sender is capable > of handling text encoded in the utf-8 charset [RFC 2044], when properly > MIME labeled. > Please no. > The syntax of this header is deliberately a subset of that in HTTP. Please don't use something with the same syntax but different semantics. In HTTP, accept-language and accept-charset are orthogonal, and the reasons for making them so in HTTP apply equally to mail. Larry -- http://www.parc.xerox.com/masinter From owner-ietf-822 Fri Jun 13 13:16:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA18653 for ietf-822-bks; Fri, 13 Jun 1997 13:16:56 -0700 (PDT) Received: from black-ice.cc.vt.edu (root@black-ice.cc.vt.edu [128.173.14.71]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA18649 for ; Fri, 13 Jun 1997 13:16:52 -0700 (PDT) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.6.Beta3/8.8.6.Beta3) with ESMTP id QAA16698; Fri, 13 Jun 1997 16:19:15 -0400 Message-Id: <199706132019.QAA16698@black-ice.cc.vt.edu> To: John Gardiner Myers Cc: ietf-822@imc.org Subject: Re: Accept-Language: proposal In-Reply-To: Your message of "Fri, 13 Jun 1997 12:08:38 PDT." <33A19AB6.E026E93F@netscape.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <33A19AB6.E026E93F@netscape.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_2109757544P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 13 Jun 1997 16:19:15 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk --==_Exmh_2109757544P Content-Type: text/plain; charset=us-ascii On Fri, 13 Jun 1997 12:08:38 PDT, you said: > The existence of this header also indicates that the sender is capable > of handling text encoded in the utf-8 charset [RFC 2044], when properly > MIME labeled. Umm.. yeah, but.. this may not do what you hope. This AIX 4.2 box I'm typing on has *some* UFT-8 support. However, my MUA does not support it, nor do I have fonts to cover the entire UTF-8 space. Also, remember that UTF-8 is only an *encoding* scheme. It is *not* an internationalization or localization scheme. As such, things like currency formats, date/time preferences, and sorting/collating issues are totally not addressed. If the person requests Cyrillic, what's the format of the date? Why are you implying UTF-8 support? What does this buy you? > Since this header is presumably only going to be generated by "new" > UA's, it is not unreasonable to require these "new" UA's to support > UTF-8. The alternative of also negotiating acceptable charset is worse. How about an alternative of "Return English if you can't supply in one of the requested languages"? This would eliminate a UTF-8 requirement, and be more backward-compatible as well.. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech --==_Exmh_2109757544P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM6GrPdQBOOoptg9JAQGNkwP9GvZ7ViG69mBlq5JV82pQQ5u42lw9vsQE VZrj9V3OIgf4550jAuvs7c8NXJ/BKOxNi7j7AxNN+xeiFP9WFidBAc3kfx3uMQv/ KrYfVpkL2PibhJjgLjO1D+5+Nzvw/GUTRx0LaAwjpDKz47hga7T+4rxUNzMC9lTR QWl/nVqsYmA= =1Olx -----END PGP MESSAGE----- --==_Exmh_2109757544P-- From owner-ietf-822 Fri Jun 13 15:17:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA19965 for ietf-822-bks; Fri, 13 Jun 1997 15:17:35 -0700 (PDT) Received: from porta-sparc.mcom.com (h-205-217-229-148.netscape.com [205.217.229.148]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA19961 for ; Fri, 13 Jun 1997 15:17:32 -0700 (PDT) Received: from jgmyers-nt (h-205-217-229-208.mcom.com [205.217.229.208]) by porta-sparc.mcom.com (1.0.b2/8.8.5) with ESMTP id PAA27903 for ; Fri, 13 Jun 1997 15:19:11 -0700 (PDT) Message-ID: <33A1C7CF.843F0690@netscape.com> Date: Fri, 13 Jun 1997 15:21:03 -0700 From: John Gardiner Myers X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-822@imc.org Subject: Re: Accept-Language: proposal X-Priority: 3 (Normal) References: <33A19AB6.E026E93F@netscape.com> <33A1A65C.430D@parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk Larry Masinter wrote: > Please no. Do you mean "no, please define accept-charset as well" or "no, please call this header something other than accept-charset"? I strongly disagree with the former, I could be convinced of the latter. > In HTTP, accept-language and accept-charset are orthogonal, > and the reasons for making them so in HTTP apply equally to mail. I disagree that the reasons for accept-charset in HTTP apply equally to mail. 1) In mail, the lack of interactivity significantly raises the importance of using a canonical format over the importance of having the sender avoid the cost of converting from local form to canonical form. 2) Time has passed on since accept-charset was designed. The report of the IAB Character Set Workshop strongly recommends transitioning to ISO-10646 based charsets, such as UTF-8 and/or UTF-7. Valdis.Kletnieks@vt.edu wrote: > This AIX 4.2 box I'm typing on has *some* UFT-8 support. However, > my MUA does not support it, nor do I have fonts to cover the entire UTF-8 > space. Your MUA also doesn't support the accept-language header. In order for it to support the accept-language header, it would have to be extended to understand the UTF-8 charset. It is not necessary that your MUA be able to display the entire UTF-8 codepoint space. It is only necessary for your MUA to be able to display that subset of the space that is necessary to display text in the languages that are advertised. If text in your languages all fit into iso-8859-1, for example, your MUA only has to be able to convert from UTF-8 to iso-8859-1 when displaying text. > Also, remember that UTF-8 is only an *encoding* scheme. It is *not* an > internationalization or localization scheme. As such, things like currency > formats, date/time preferences, and sorting/collating issues are totally > not addressed. If the person requests Cyrillic, what's the format of the > date? These issues are addressed by the language tags in the accept-language header. The person does not request Cyrillic, they request a specific language that happens to use Cyrillic characters. > Why are you implying UTF-8 support? What does this buy you? Simplicity. It removes the need for senders and recipients to negotiate and convert amongst a large number of different charsets. It removes the possibility of having a successful negotiation of a common language be stymied by a failure to negotiate a common charset capable of representing the necessary characters. > How about an alternative of "Return English if you can't supply in one of > the requested languages"? This would eliminate a UTF-8 requirement, and > be more backward-compatible as well.. This alternative would not remove the UTF-8 requirement. Once a sender has determined which language to use, it has the problem of figuring out which charset is both capable of expressing text in that language and which will be understood by the recipient. Without either a separate charset negotiation or charset support being communicated by the accept-language header itself, only us-ascii is known to be supported by the recipient. From owner-ietf-822 Fri Jun 13 16:20:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA20674 for ietf-822-bks; Fri, 13 Jun 1997 16:20:50 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA20657 for ; Fri, 13 Jun 1997 16:20:46 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id TAA00955; Fri, 13 Jun 1997 19:22:21 -0400 (EDT) Message-Id: <199706132322.TAA00955@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John Gardiner Myers cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: Accept-Language: proposal In-reply-to: Your message of "Fri, 13 Jun 1997 12:08:38 PDT." <33A19AB6.E026E93F@netscape.com> Date: Fri, 13 Jun 1997 19:21:17 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk If it's not going to have the syntax used in HTTP, I'd rather have it called by some other name. I don't think the UTF-8 requirement is reasonable. It seems like this would impose a huge implementation burden for most UAs. With this requirement in place, most people can't use it or benefit from it. Without this requirement, many users could just add a header field to outgoing mail specifying the languages and charsets that the user can deal with, without needing UTF-8 support. Also, the chosen I18N approach to DSNs was to define precise error codes and include enough information so that the error could be presented in the user's language by the user agent. As far as I can tell, the error codes are usually adequate for this purpose, in that they can describe most conditions with sufficient precision. So I have to wonder if this is really needed for DSNs. And while I could see something like this header being used for email-based document requests, for it to affect DSNs would require that MTAs look at the header of the subject message. This is a layering violation. Keith From owner-ietf-822 Fri Jun 13 17:44:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA21439 for ietf-822-bks; Fri, 13 Jun 1997 17:44:20 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA21435 for ; Fri, 13 Jun 1997 17:44:16 -0700 (PDT) Received: from casablanca.parc.xerox.com ([13.2.16.111]) by alpha.xerox.com with SMTP id <18228(7)>; Fri, 13 Jun 1997 17:46:16 PDT Received: from bronze-208.parc.xerox.com ([13.0.209.122]) by casablanca.parc.xerox.com with SMTP id <71898>; Fri, 13 Jun 1997 17:45:59 PDT Message-ID: <33A1E9BB.6F5B@parc.xerox.com> Date: Fri, 13 Jun 1997 17:45:47 PDT From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (Win95; U) MIME-Version: 1.0 To: John Gardiner Myers CC: ietf-822@imc.org Subject: Re: Accept-Language: proposal References: <33A19AB6.E026E93F@netscape.com> <33A1A65C.430D@parc.xerox.com> <33A1C7CF.843F0690@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-822@imc.org Precedence: bulk Let me try to say this differently: Headers should be compatible between HTTP and mail: that is, a single message header should have the same meaning, no matter which protocol is being used. Accept-Language already has a meaning in HTTP. If you want to use it in mail, you should only use it with the same meaning. Do not attach new meanings to the same header. If you really need a different meaning, then use a different header name. > I disagree that the reasons for accept-charset in HTTP apply equally to > mail. > > 1) In mail, the lack of interactivity significantly raises the > importance of using a canonical format over the importance of having the > sender avoid the cost of converting from local form to canonical form. > > 2) Time has passed on since accept-charset was designed. The report of > the IAB Character Set Workshop strongly recommends transitioning to > ISO-10646 based charsets, such as UTF-8 and/or UTF-7. I don't see what these have to do with it; you might as well just assume you can always send UTF-8, then. Whether or not "Accept-Language" is present in the message doesn't have much to do with it. In fact, "Accept-Language" is a misnomer; it should probably have been called "Prefer-Language". If you want to have a header that means "You can reply with UTF-8", why not make it "Mime-Version: 1.1" or something; the appearance of accept-language is not by itself an indication of anything other than language preference. Larry From owner-ietf-822 Sat Jun 14 23:30:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA03067 for ietf-822-bks; Sat, 14 Jun 1997 23:30:40 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA03063 for ; Sat, 14 Jun 1997 23:30:37 -0700 (PDT) Received: from eleanor.innosoft.com ("port 61137"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IK2WWEEM3YANC4L3@INNOSOFT.COM> for ietf-822@imc.org; Sat, 14 Jun 1997 23:32:13 PDT Date: Sat, 14 Jun 1997 23:33:52 -0700 (PDT) From: Chris Newman Subject: Re: Accept-Language: proposal In-reply-to: <199706132322.TAA00955@spot.cs.utk.edu> To: Keith Moore Cc: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk On Fri, 13 Jun 1997, Keith Moore wrote: > I don't think the UTF-8 requirement is reasonable. > It seems like this would impose a huge implementation burden for most UAs. > With this requirement in place, most people can't use it or benefit > from it. Without this requirement, many users could just add a header > field to outgoing mail specifying the languages and charsets that the > user can deal with, without needing UTF-8 support. I disagree with this point. UTF-8 is not particularly hard to support -- it's certainly much easier to support than a large table of multiple charsets for each language and all the cross-conversions (which often use Unicode as an intermediate). We need to start "hooking" UTF-8 to proposals like this so that we can transition away from the current mess of character sets we have. In addition, an "accept-language" header which requires UTF-8 is a far simpler architecture than a combination of "accept-language" and "accept-charset". Given the IAB charset workshop guidelines I think it would be a mistake to let "accept-charset" leak out of HTTP. From owner-ietf-822 Mon Jun 16 00:13:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA01303 for ietf-822-bks; Mon, 16 Jun 1997 00:13:40 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA01299 for ; Mon, 16 Jun 1997 00:13:36 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IK41ER0CBKANC2N5@INNOSOFT.COM> for ietf-822@imc.org; Sun, 15 Jun 1997 19:41:13 PDT Date: Sun, 15 Jun 1997 19:15:10 -0700 (PDT) From: Ned Freed Subject: Re: Accept-Language: proposal In-reply-to: "Your message dated Fri, 13 Jun 1997 12:08:38 -0700" <33A19AB6.E026E93F@netscape.com> To: John Gardiner Myers Cc: ietf-822@imc.org Message-id: <01IK434D9SOOANC2N5@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk > I have a need to localize the human-readable text inside of DSN's and > other automated responses to 822-format messages. Here is a proposal I > would like to float here, prior to issuing an internet-draft. > Rough definition: > Define an "Accept-Language" header with the following syntax. > accept-language = "Accept-Language" ":" 1#Language-tag > ; Language-tag as defined in RFC 1766 > This header discloses the language preference(s) of the sender. > Languages listed earlier in the list are preferred. I agree with Larry that use of Accept-Language: in this fashion, which doesn't correspond to the HTTP semantics, is a showstopper. The IETF has both critiqued and modified HTTP usage where that usage conflicts with MIME, and I think the IETF was correct in doing this. But it is only fair that when the shoe is on the other foot, and we're defining stuff for MIME-based but non-HTTP-based protocols like Internet mail, that we pay attention to HTTP usage and not do things that conflict with it. There are two ways to solve this problem. One is to use the same field name and keep the semantics the same. The other is to define a new field with limited semantics. I see problems with both approaches. The first seems excessive for the stated application. And the second only solves this one problem without providing a basis for other sorts of capability discovery (e.g. discovery of support for things other than langauge, support for different capabilities for different sorts of messages like notifications, receipts, replies, or new mail). Capability discovery in email should either be done right or not done at all. A point solution specifically for this one limited application is a good idea if and only if we decide right her and now that this is the only sort of capability discovery we ever intend to do. And since I do not believe that this is the only sort we want I don't think this is a good idea. > The existence of this header also indicates that the sender is capable > of handling text encoded in the utf-8 charset [RFC 2044], when properly > MIME labeled. I agree with Larry about this as well -- the issue of language and character set are largely orthogonal, and as such should not be coupled in this bizzarre way. I have no problem with a mechanismm that lets you say you want responses to be in UTF-8 per se; however, such a mechanism should be part of a more general capability discovery system and not coupled to language like it was an afterthought as this proposal does. > Does not necessarily work correctly if the message goes through list > expansion. The language preferences of the list maintainer can be > different than those of the original sender, so if the list expander > does not know to strip or replace the Accept-Language header, the list > maintainer could get DSN's in a language and charset they don't > understand. This is exactly why such a mechanism has to be done right -- there's clearly a distinction between what the list moderator wants in notifications and what a message originator wants in a reply. And don't think for a minute that should you define a field like this that it won't end up being used to control other sorts of automated and even manual replies -- it will. Ned From owner-ietf-822 Mon Jun 16 08:41:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA08495 for ietf-822-bks; Mon, 16 Jun 1997 08:41:25 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA08490 for ; Mon, 16 Jun 1997 08:41:23 -0700 (PDT) Received: by DOGGATE with Internet Mail Service (5.0.1608.0) id ; Mon, 16 Jun 1997 08:42:48 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050E825F@DINO> From: "Jeff Stephenson (Exchange)" To: "'John Gardiner Myers'" , ietf-822@imc.org Subject: RE: Accept-Language: proposal Date: Mon, 16 Jun 1997 08:42:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1608.0) Content-Type: text/plain Sender: owner-ietf-822@imc.org Precedence: bulk It seems to me that it would be better to have the UA provide a localized human-readable explanation of the error based on the enhanced error codes, for two reasons: 1) This proposal, to be useful, requires that MTAs be able to generate DSNs in a large number of languages. In practice, I suspect that you'd find maybe 5 or 6 major languages being supported, with the result that in many cases DSNs would still end up being generated in English. 2) The user agent, almost by definition, is going to be localized for any particular user; it can use the enhanced error codes to generate an appropriate message. Further the UA is in a position to tell the user what, if anything, they can do about the problem using that particular UA. I also share Keith's concern about the layering issue: this functionality should be an SMTP extension rather than an 822 header. But unless I'm missing something, I don't think it should be either - enhanced error codes should be all that's required. -- jeff > -----Original Message----- > From: John Gardiner Myers [SMTP:jgmyers@netscape.com] > Sent: Friday, June 13, 1997 12:09 PM > To: ietf-822@imc.org > Subject: Accept-Language: proposal > > I have a need to localize the human-readable text inside of DSN's and > other automated responses to 822-format messages. Here is a proposal > I > would like to float here, prior to issuing an internet-draft. > <...snip...> > Disadvantages: > > Does not necessarily work correctly if the message goes through list > expansion. The language preferences of the list maintainer can be > different than those of the original sender, so if the list expander > does not know to strip or replace the Accept-Language header, the list > maintainer could get DSN's in a language and charset they don't > understand. > > So, what do people think? From owner-ietf-822 Mon Jun 16 11:21:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA10674 for ietf-822-bks; Mon, 16 Jun 1997 11:21:17 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA10670 for ; Mon, 16 Jun 1997 11:21:14 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id OAA14761; Mon, 16 Jun 1997 14:21:04 -0400 (EDT) Message-Id: <199706161821.OAA14761@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Chris Newman cc: Keith Moore , ietf-822@imc.org Subject: Re: Accept-Language: proposal In-reply-to: Your message of "Sat, 14 Jun 1997 23:33:52 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Jun 1997 14:21:03 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > On Fri, 13 Jun 1997, Keith Moore wrote: > > I don't think the UTF-8 requirement is reasonable. > > It seems like this would impose a huge implementation burden for most UAs. > > With this requirement in place, most people can't use it or benefit > > from it. Without this requirement, many users could just add a header > > field to outgoing mail specifying the languages and charsets that the > > user can deal with, without needing UTF-8 support. > > I disagree with this point. UTF-8 is not particularly hard to support -- It would require a huge effort to take every tool that I use to process mail, and extend them all to use UTF-8. This remains true even if I only care about supporting the 8859/1 subset. (in my case, we're talking MH, exmh, metamail, xterm, procmail, /bin/mail, and numerous scripts) > We need to start "hooking" UTF-8 to proposals like this so that we can > transition away from the current mess of character sets we have. I strongly disagree. I want to encouage a transition to UTF-8, but not by "hooking" it to what would otherwise be a very simple and useful extension, and not in such a way that it would have a severe adverse impact on the installed base. We haven't yet recovered from the 822-to-MIME transition. The vast majority of mailers out there can't yet deal with it adequately. (They may have some support for it, but in general it seems to be lousy.) To raise the bar further at this point would not encourage adoption of UTF-8, it would just degrade interoperability. Some tools would ignore the UTF-8 requirement and generate accept-language anyway; other tools would use this as an excuse to send UTF-8 to those in the first set and thus annoy the user. Many tools would implement UTF-8 poorly (just as they have implemented MIME poorly) and this would be an additional source of user complaints. Neither is it reasonable for every UA that sends messages, to assume that the reply will be read (or processed) by a UA with the same capabilities. It might be reasonable to assume that it will be read by the same *user*, but it's quite unreasonable to assume that the message will be read by the same *tool*, or even on the same host. Keith From owner-ietf-822 Sun Jun 29 22:02:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA21346 for ietf-822-bks; Sun, 29 Jun 1997 22:02:19 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id WAA21342 for ; Sun, 29 Jun 1997 22:02:15 -0700 (PDT) Received: (qmail 7986 invoked by uid 666); 30 Jun 1997 05:12:47 -0000 Date: 30 Jun 1997 05:12:47 -0000 Message-ID: <19970630051247.7985.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk ``Every time you do a "Group-reply" some poor shmoes are receiving duplicate e-mails.'' This is one user's description of what happens when you follow up to From: Member To: List It's used as a justification---in fact, the only justification---for reply-to munging, i.e., adding Reply-To: mailing-list@some.net. As http://www.unicom.com/FAQ/reply-to-harmful.html explains in detail, reply-to munging is harmful. But the user's criticism is still valid. Followups produce duplicates. You might suggest leaving From out of the followup address list. But that's even worse: if the sender isn't in the To line he won't get a copy of the followup. This problem is well known. The solution---having a header field that says where to send followups---has been proposed many times. But MUAs don't seem to support any such field. Why not? Perhaps it would help to have a good name. ``Followup-To'' is taken by news, unfortunately. ``Wide-Reply-To'' and ``Group-Reply-To'' are incomprehensible to novice users. ``Followups'' might work, but it's probably too close to ``Followup-To''. Any ideas? How many MUA implementors do we have here, anyway? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Mon Jun 30 13:56:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA01791 for ietf-822-bks; Mon, 30 Jun 1997 13:56:50 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA01787 for ; Mon, 30 Jun 1997 13:56:46 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA22990; Mon, 30 Jun 1997 16:58:38 -0400 (EDT) Message-Id: <199706302058.QAA22990@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "30 Jun 1997 05:12:47 -0000." <19970630051247.7985.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Jun 1997 16:58:36 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > ``Every time you do a "Group-reply" some poor shmoes are receiving > duplicate e-mails.'' > > This is one user's description of what happens when you follow up to > > From: Member > To: List > > It's used as a justification---in fact, the only justification---for > reply-to munging, i.e., adding Reply-To: mailing-list@some.net. > [...] > > This problem is well known. The solution---having a header field that > says where to send followups---has been proposed many times. But MUAs > don't seem to support any such field. Why not? Partially because there's not a consensus that this is a good idea. Even if you only have reply, sometimes you want to reply to author only, sometimes to author and all recipients, sometimes to author and particular recipients, etc. Sometimes you want to use the reply-to field; other times you want to override that field. Add a followup-to (wide-reply-to, group-reply-to whatever) field to the mix and it just makes things more confusing. (e.g. Sometimes you really do want to reply to the From/to/cc addresses instead of the addresses in either the followup-to or reply-to fields. etc.) Followup-to would also not solve many of the problems that currently exist with list reply-to munging: + The author of the subject message isn't always on the mailing list, in which case he misses the replies/followups. + A single message can be posted to multiple mailing lists, in which case followups should arguably go to all lists. (Yes, this is annoying for those on several of those lists, but cross-list discussions are often useful.) + The author may post from a different address than his list subscription. I post from moore@cs.utk.edu but get inbound list mail at moore+listname@cs.utk.edu; and inbound list mail gets read at a lower priority than mail sent to my primary mailbox. When replies from my list postings go to moore@cs.utk.edu, I can respond more quickly. And a followup-to like header is certainly not "the" only available solution. For instance, UAs could suppress duplicate messages. This doesn't require any changes to the protocols, or to the list servers, and has immediate benefit for anyone whose UA implements it. (Though there are security risks with trusting message-ids alone for this...you have to actually compare the messages to see if they're similar enough to call them duplicates. But message-ids should be a good way to identify *candidates* for duplicate suppression.) > Perhaps it would help to have a good name. ``Followup-To'' is taken by > news, unfortunately. ``Wide-Reply-To'' and ``Group-Reply-To'' are > incomprehensible to novice users. ``Followups'' might work, but it's > probably too close to ``Followup-To''. We've already had proposals for a name. What we haven't had is agreement that such proposals, if adopted, would do more good than harm. Keith From owner-ietf-822 Mon Jun 30 16:37:53 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA03407 for ietf-822-bks; Mon, 30 Jun 1997 16:37:53 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA03403 for ; Mon, 30 Jun 1997 16:37:49 -0700 (PDT) Received: (qmail 14283 invoked by uid 666); 30 Jun 1997 23:48:23 -0000 Date: 30 Jun 1997 23:48:22 -0000 Message-ID: <19970630234822.14282.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk It's important to understand that the author sets followups. Let me emphasize once again that reply-to munging is harmful; the question is how to fix the message duplication _without_ reply-to munging. In light of this understanding, let's review Keith's complaints: > + The author of the subject message isn't always on the mailing list, > in which case he misses the replies/followups. No, he doesn't miss anything, because he puts his own address into the followup field along with the list address. Of course, he doesn't have to bother with a followup field in this case, since the default followup targets will work properly. If he _is_ on the list, he should supply a followup field without his address. His MUA can do this automatically if it knows that he's on the list; some MUAs already support the necessary database. > + A single message can be posted to multiple mailing lists, in which > case followups should arguably go to all lists. So the user puts all the lists into the followup field. MUAs configured as above will do the right thing automatically. > When replies > from my list postings go to moore@cs.utk.edu, I can respond more > quickly. So leave your address in the followup field. You have control. (Btw, why is ietf-822 so slow? It doesn't look good for a mailing list to take half an hour to distribute a message---especially when it's a mailing list for mail implementors!) > And a followup-to like header is certainly not "the" only available > solution. For instance, UAs could suppress duplicate messages. Suppressing duplicates is fine, if you can afford to do it securely, but it solves only half the problem. After a long sequence of followups---let's say a sequence of 500 messages from different contributors---there are, with current defaults, 501 recipient addresses in the header. Software breaks. Humans can no longer read the header. Each new message takes ten times as much archive space as it should. Every contributor is at risk of being a permanent recipient of a neverending discussion; there is no escape. Of course, people don't let the header grow so much. They trim it down to just the list address. But this introduces some of the same problems as reply-to munging; for example, it destroys cross-posted discussions. With a followup field, the solution is trivial: the MUA copies the message's followup field into subsequent followups by default. > Even if you only have reply, sometimes you want to reply to author > only, sometimes to author and all recipients, sometimes to author and > particular recipients, etc. So what? Are you going to argue that we shouldn't have Reply-To since people sometimes want followups instead? > Add a followup-to > (wide-reply-to, group-reply-to whatever) field to the mix and it just > makes things more confusing. Explanation, please. Who exactly would be confused? Users will have a button for replies, just as they do now. Users will have a button for followups, just as they do now. They can control replies with Reply-To, just as they do now. They can control followups with the new field. This is much simpler than the current situation. > What we haven't had is > agreement that such proposals, if adopted, would do more good than > harm. Explanation, please. How exactly would a followup field hurt anyone? > We've already had proposals for a name. I know. I don't think ``Wide-Reply-To'' will work. As you can easily verify, ``wide reply'' is meaningless for a typical user. (``Does that have something to do with the window size?'') Even when the MUA has a ``wide reply'' feature, most users have no clue what it does. ``Group reply'' is somewhat better (and apparently more common in MUAs), but still not immediately clear to most users. Any other suggestions? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 2 13:42:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA05161 for ietf-822-bks; Wed, 2 Jul 1997 13:42:41 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA05157 for ; Wed, 2 Jul 1997 13:42:35 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA03204; Wed, 2 Jul 1997 16:44:34 -0400 (EDT) Message-Id: <199707022044.QAA03204@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "30 Jun 1997 23:48:22 -0000." <19970630234822.14282.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 1997 16:44:33 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > It's important to understand that the author sets followups. Let me > emphasize once again that reply-to munging is harmful; the question is > how to fix the message duplication _without_ reply-to munging. In this case, there's no need for a Followup-To header field. The existing Reply-To field (as defined in the current 822bis draft) is sufficient to allow the author to specify his preference as to where replies should go. One could argue that Reply-To is broken because so many lists mung it, and because so many UAs use it only as a replacement for the "From" address, when doing a "reply to sender and recipients". I don't really think there is a big need to allow a sender to separately specify "reply to address-list X if you want to just reply to me", and "reply to address-list Y if you want to followup". Even for those times when this is needed, the author can use From for the former, and Reply-to for the latter. (With Sender used to indicate the author's "real" address) > > And a followup-to like header is certainly not "the" only available > > solution. For instance, UAs could suppress duplicate messages. > > Suppressing duplicates is fine, if you can afford to do it securely, but > it solves only half the problem. > > After a long sequence of followups---let's say a sequence of 500 > messages from different contributors---there are, with current defaults, > 501 recipient addresses in the header. Software breaks. Humans can no > longer read the header. Each new message takes ten times as much archive > space as it should. Every contributor is at risk of being a permanent > recipient of a neverending discussion; there is no escape. The existing Reply-To header could be used to prevent such problems. Why isn't it used that way more often? Because humans blindly reply to their mail without checking the recipient list, or because UAs don't encourage people to check the recipient list when forming replies, or because UAs don't make it easy to change the recipient list. None of these problems can be fixed by adding another frob to the mail protocol. > Of course, people don't let the header grow so much. They trim it down > to just the list address. But this introduces some of the same problems > as reply-to munging; for example, it destroys cross-posted discussions. There's a difference between a human making an intelligent choice about where she wants her replies to go, and a list robot that blindly (and often incorrectly) assumes that replies should go to the entire mailing list. And if a followup-to field were introduced, lists would add or mung that field also, along with reply-to. > With a followup field, the solution is trivial: the MUA copies the > message's followup field into subsequent followups by default. A UA that blindly copy followup-to to followups, creates much the same problem as list robots that blindly mung reply-to. > > Even if you only have reply, sometimes you want to reply to author > > only, sometimes to author and all recipients, sometimes to author and > > particular recipients, etc. > > So what? Are you going to argue that we shouldn't have Reply-To since > people sometimes want followups instead? Followups are an artifact of the netnews environment, where you have separate address schemes for email and netnews. Depending on how you look at it, this was a big mistake, or an accident of history, but having two different address schemes creates lots of problems. Propagating any of this mess into the email world is a Bad Idea. People who have used netnews are accustomed to the notion of public responses (aka "followups") as opposed to private responses (aka "email"). So they may tend to think that their email UA should have a "followup" button (and UAs for both email and news do have such a button). But in the email world there's no inherent distinction between "public responses" and "private responses" and it's silly to pretend that there is one. You can define some notion of "followup" for email using a followup-to header, but doing so doesn't add any new services -- it just replicates services that already exist. It might makes people feel better because there's something for the followup button to do, but it's not useful purpose. > > Add a followup-to > > (wide-reply-to, group-reply-to whatever) field to the mix and it just > > makes things more confusing. > > Explanation, please. Who exactly would be confused? Besides you? (sorry, that was too easy.) > Users will have a button for replies, just as they do now. > > Users will have a button for followups, just as they do now. Good UAs already have separate commands for reply-to-sender and reply-to-sender-and-recipients. Ideally, users should be able to override reply-to for those cases where they really want to send the message somewhere else, so you need a way to do that. And users need to be able to set their reply-to and from addresses on outgoing mail. This is already getting confusing for most users -- who don't understand why "reply" doesn't "do the right thing". (these same users would never have such a problem with snail mail -- they'd simply address the snail mail reply to whomever they thought should receive it.) Support for followup-to would require that UAs add other commands ("followup", "set followup-to") in addition to the set above. Users who are confused by existing reply options would be even more confused by the addition of followup options which basically do the same thing as replies. They'll make more mistakes, there will be more variation in behaviors between different UAs (thus confusing authors who expect that their recipients' UAs work the same as theirs), and there will be more calls to Tech Support. > > What we haven't had is > > agreement that such proposals, if adopted, would do more good than > > harm. > > Explanation, please. How exactly would a followup field hurt anyone? I've already explained this. > > We've already had proposals for a name. > > I know. I don't think ``Wide-Reply-To'' will work. As you can easily > verify, ``wide reply'' is meaningless for a typical user. (``Does that > have something to do with the window size?'') Even when the MUA has a > ``wide reply'' feature, most users have no clue what it does. > > ``Group reply'' is somewhat better (and apparently more common in MUAs), > but still not immediately clear to most users. > > Any other suggestions? First explain how "followup" would differ from "reply", beyond the fact that it would use different header names and that it's not supported by any of the installed base. Also please explain why it would not suffer from the same problems that reply suffers from. Once you have defined the new feature, convince people that the new feature is worth implementing and supporting. *Then* worry about what to call the header field. Keith From owner-ietf-822 Wed Jul 2 17:05:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA07092 for ietf-822-bks; Wed, 2 Jul 1997 17:05:25 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA07088 for ; Wed, 2 Jul 1997 17:05:22 -0700 (PDT) Received: (qmail 2131 invoked by uid 666); 3 Jul 1997 00:16:05 -0000 Date: 3 Jul 1997 00:16:05 -0000 Message-ID: <19970703001605.2130.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk Keith says that users can control replies with Reply-To (in the absence of reply-to munging). I agree. However, users currently have no way to control followups. Keith then suggests that there's no need for users to control replies and followups separately. That's absurd. One of the big munging harms discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the user's inability to control replies. Next Keith proposes using Sender in place of From, using From to control replies, and using Reply-To to control followups. This is a massive change from the RFC 822 Reply-To semantics supported by dozens of existing clients. The transition would be a disaster. > There's a difference between a human making an intelligent choice > about where she wants her replies to go, Here Keith is referring to people deleting recipients from followups. The problem is that these people don't have the information they need: are those recipients members of the mailing list? The result is that non-subscribers are often accidentally removed. > And if a followup-to field were introduced, lists would add or mung > that field also, along with reply-to. If Keith doesn't understand why Reply-To munging happens right now, he should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The more clients that support a followup field, the less motivation there is for this type of munging. > A UA that blindly copy followup-to to followups, creates much the same > problem as list robots that blindly mung reply-to. If Keith doesn't understand the harms caused by Reply-To munging, he should read http://www.unicom.com/FAQ/reply-to-harmful.html. > Followups are an artifact of the netnews environment, where you have > separate address schemes for email and netnews. Nonsense. Replies and followups are fundamentally different operations. Practically every mailer supports both replies and followups. This has nothing to do with the difference between mail addresses and news addresses. > having two different address schemes creates lots of problems. I agree. One solution is to integrate the newsgroup address space into the mail address space. Here's a working example: To: djb@koobera.math.uic.edu, sci.crypt@pubnews.demon.co.uk It would be easy to set up a global usenet.news domain, configured locally to talk to a nearby NNTP server. Newsgroups are simply high-volume mailing lists with many entry points and a fancy distribution mechanism. > But in the email world there's no inherent distinction > between "public responses" and "private responses" and it's silly to > pretend that there is one. Every popular MUA supports both replies and followups. > You can define some notion of "followup" > for email using a followup-to header, but doing so doesn't add any new > services -- it just replicates services that already exist. False. It provides a direct way to control followups; this feature does not exist right now. MUAs will check the followup field before checking From/To/Cc or Reply-To/To/Cc. Many simple situations can be handled with the proposed Mail-Copies-To field, which says whether to include the sender in followups, but a followup field is a much more direct solution. > > Explanation, please. Who exactly would be confused? > Besides you? (sorry, that was too easy.) I find this comment rather amusing, given the number of ridiculous statements that Keith has made in this discussion---claiming that the followup field is for MLMs to set, claiming that the widely recognized problem of duplicates doesn't exist, claiming that the problem is solved by MUA duplicate elimination, etc. > Users who are confused by existing reply options would be even more confused > by the addition of followup options which basically do the same thing > as replies. [ ... ] > Support for followup-to would require that UAs add other commands > ("followup", "set followup-to") in addition to the set above. Here Keith makes yet another stupid mistake: he seems to think that followups are something different from the MUA's existing ``wide reply'' or ``group reply'' or ``reply to all'' feature. One wonders how many times Keith needs to see the problem statement before he understands it. Here it is again: Right now, when someone _follows up_ to a mailing list message from a subscriber, the subscriber and the mailing list are both in the followup's recipient list by default. The obvious fix is to let the subscriber override the default _followup_ target, omitting his own address. > > Explanation, please. How exactly would a followup field hurt anyone? > I've already explained this. Nonsense. Keith has explained bad consequences of two red herrings: first, having MLMs munge the followup field; second, having followups distinguished from reply-to-sender-and-recipients. > First explain how "followup" would differ from "reply", beyond the > fact that it would use different header names and that it's not > supported by any of the installed base. Nonsense. It's supported by most, perhaps all, of the installed base. It's even supported by Berkeley Mail. What isn't standardized is the _name_. > Also please explain why it > would not suffer from the same problems that reply suffers from. The motivation for reply-to munging is that, in its absence, a typical user has no easy way to follow up without the problem of duplicates discussed above. If, on the other hand, his MUA supports a followup field, subscribers suddenly have the ability to eliminate those duplicates. Once the followup field is universally supported, the motivation for reply-to munging will be gone. > Once you have defined the new feature, convince people that the new feature > is worth implementing and supporting. *Then* worry about what to call > the header field. Is there anyone other than Keith who's confused about the function and benefits of a followup field? I don't see Keith's self-imposed blindness as a major problem here; MUA implementors have never paid much attention to him in the past, and aren't likely to pay attention to him now. The introduction of Mail-Copies-To in two MUAs indicates that other people understand the problem here. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 3 02:14:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA13523 for ietf-822-bks; Thu, 3 Jul 1997 02:14:49 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id CAA13519 for ; Thu, 3 Jul 1997 02:14:44 -0700 (PDT) Received: from eleanor.innosoft.com ("port 35456"@ELEANOR.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-8 #8694) with SMTP id <01IKS7ULGWXA8WVYX7@INNOSOFT.COM> for ietf-822@imc.org; Thu, 3 Jul 1997 02:15:55 PDT Date: Thu, 03 Jul 1997 02:17:39 -0700 (PDT) From: Chris Newman Subject: Re: best name for followups? In-reply-to: <19970703001605.2130.qmail@koobera.math.uic.edu> To: ietf-822@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com Sender: owner-ietf-822@imc.org Precedence: bulk I find the arguments in: very technically compelling. I'd love to know of any way to make it politically compelling... I also find Keith's comment that users don't have the information necessary to set a followup-to email header correctly, and won't want to enter one manually compelling; although I disagree that reply-to offers sufficient functionality. I think the current situation is broken as I hate having to manually edit people out of headers all the time and worry that some of the people I'm removing might not be on the list. Now what information does the person who sends to a list have which is useful to know? I think there are three useful preferences the sender can communicate: (1) Keep my personal address in all group replies. (2) I read the list; but like to get a bcc of group replies to messages I post. (3) I read the list; so don't use my personal address in replies. What about a new header which simply communicates this information? Group-Reply-Pref: include-me Group-Reply-Pref: bcc-me Group-Reply-Pref: exclude-me Defaults to "include-me" if not present since that's current practice and we don't want to surprise users with a behavior change. If this got deployed I know a bunch of people who would love to use it. - Chris From owner-ietf-822 Thu Jul 3 09:17:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA18388 for ietf-822-bks; Thu, 3 Jul 1997 09:17:49 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA18380 for ; Thu, 3 Jul 1997 09:17:46 -0700 (PDT) Received: (qmail 7149 invoked by uid 666); 3 Jul 1997 16:28:33 -0000 Date: 3 Jul 1997 16:28:33 -0000 Message-ID: <19970703162833.7148.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > users don't have the information > necessary to set a followup-to email header correctly, The user simply has to (1) create a followup field from Reply-To/To/Cc or From/To/Cc, and (2) remove his address if it's covered by a mailing list. Exactly which information is he missing? #1 is trivial to do automatically. #2 is also trivial for MUAs that know which lists the user is on, such as mutt. > Group-Reply-Pref: exclude-me This is the Mail-Copies-To approach. It covers many simple situations, as I mentioned---for example, the default situation described above. However, I prefer a followup field, for the same reason that I like having a followup field in news: it's more flexible. For example, I can manually redirect a crossposted discussion away from an inappropriate mailing list. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Thu Jul 3 17:06:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA23795 for ietf-822-bks; Thu, 3 Jul 1997 17:06:02 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA23790 for ; Thu, 3 Jul 1997 17:05:57 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id UAA10034; Thu, 3 Jul 1997 20:08:02 -0400 (EDT) Message-Id: <199707040008.UAA10034@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "03 Jul 1997 16:28:33 -0000." <19970703162833.7148.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jul 1997 20:08:02 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > However, I prefer a followup field, for the same reason that I like > having a followup field in news: it's more flexible. For example, I can > manually redirect a crossposted discussion away from an inappropriate > mailing list. In email, using reply-to, I can manually redirect a discussion away from inappropriate recipients. What's the difference? Keith From owner-ietf-822 Thu Jul 3 17:02:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA23755 for ietf-822-bks; Thu, 3 Jul 1997 17:02:20 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA23751 for ; Thu, 3 Jul 1997 17:02:15 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id UAA09966; Thu, 3 Jul 1997 20:04:20 -0400 (EDT) Message-Id: <199707040004.UAA09966@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: ietf-822@imc.org, moore@cs.utk.edu Subject: Re: best name for followups? In-reply-to: Your message of "03 Jul 1997 00:16:05 -0000." <19970703001605.2130.qmail@koobera.math.uic.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Jul 1997 20:04:19 -0400 Sender: owner-ietf-822@imc.org Precedence: bulk > Keith says that users can control replies with Reply-To (in the absence > of reply-to munging). I agree. However, users currently have no way to > control followups. True. But you haven't demonstrated that followups are (a) significantly distinct from replies and (b) worth having. > Keith then suggests that there's no need for users to control replies > and followups separately. That's absurd. Not if there's no good reason to have followups (as distinct from replies) in the first place. > One of the big munging harms > discussed in http://www.unicom.com/FAQ/reply-to-harmful.html is the > user's inability to control replies. Yes, but the same problems and more would exist for followups if followup-to were defined, because lists would mung those as well. Oddly enough, the best way I can see to get lists to stop munging reply-to is to define some sort of list-reply-to header and get UAs to support that. This would still be confusing to users, but at least there would be a clear separation of function - reply-to is specified by the message author, and list-reply-to is specified by the list that you received the message from. And it wouldn't stop reply-to munging entirely, but it might decrease its incedence. > Next Keith proposes using Sender in place of From, using From to control > replies, and using Reply-To to control followups. This is a massive > change from the RFC 822 Reply-To semantics supported by dozens of > existing clients. The transition would be a disaster. This is of course not what I had in mind. Part of your confusion is due to your insistence on a notion of followup as separate from reply, even when interpreting a message that I wrote. Since I don't believe that there is a significant difference between these operations, I obviously would not propose "using Reply-To to control followups". > > There's a difference between a human making an intelligent choice > > about where she wants her replies to go, > > Here Keith is referring to people deleting recipients from followups. Nope. I don't believe in followups as distinct from replies. > The problem is that these people don't have the information they need: > are those recipients members of the mailing list? The result is that > non-subscribers are often accidentally removed. If someone replies to a message addressed to both me and this mailing list, they shouldn't be trying to figure out whether I'm on the mailing list. I am on this mailing list, but I don't receive mail from this list at the same address that appears in the From field of mail I send. If someone deletes me from the recipient list of a response because they assume I'm on the mailing list, chances are that I won't see the response anytime soon. > > And if a followup-to field were introduced, lists would add or mung > > that field also, along with reply-to. > > If Keith doesn't understand why Reply-To munging happens right now, he > should read http://www.unicom.com/BBS/bbs_forum.cgi?forum=replyto. The > more clients that support a followup field, the less motivation there is > for this type of munging. I understand why Reply-To munging happens (actually there are lots of reasons), but I disagree that adding a followup-to header will actually lessen the degree of header munging, or simplify things for the user, or increase the probability that hitting a single button on the user's UA will do the right thing. > > A UA that blindly copy followup-to to followups, creates much the same > > problem as list robots that blindly mung reply-to. > > If Keith doesn't understand the harms caused by Reply-To munging, he > should read http://www.unicom.com/FAQ/reply-to-harmful.html. I pretty much agree with everything in Chip's statement, and have publically expressed support for it in the past. Your implication that I don't understand his argument is disingenuous. > > Followups are an artifact of the netnews environment, where you have > > separate address schemes for email and netnews. > > Nonsense. Replies and followups are fundamentally different operations. please explain what's different about them in a way that doesn't either: refer to netnews or change the definition of reply and reply-to. > Practically every mailer supports both replies and followups. Perhaps every UA that supports netnews supports both replies and followups (at least for netnews), but none of the email-only UAs that I've used support both. Most UAs support reply-to-sender and reply-to-all, with some variation as to (a) whether "reply-to" is used instead of the "from" address, or as the "default" recipient list, and (b) the definition of "all" (does it include cc addresses or just to addresses?) I think we'd be better off defining "reply" and "reply-to-all" in terms of existing to/cc/from/reply-to headers, than to add new headers in the mix. > This has nothing to do with the difference between mail addresses and > news addresses. > > > having two different address schemes creates lots of problems. > > I agree. One solution is to integrate the newsgroup address space into > the mail address space. Here's a working example: > > To: djb@koobera.math.uic.edu, sci.crypt@pubnews.demon.co.uk > > It would be easy to set up a global usenet.news domain, configured > locally to talk to a nearby NNTP server. I wouldn't mind seeing something like that, though it would be really difficult to get people to agree on a domain name for news. (technically it may be easy; politically it would be very difficult. locally-configured domain names aren't supposed to exist. don't try to argue otherwise; this is an old war and reopening it won't get anywhere useful) Easier would be to establish a convention for domain literals, e.g. sci.crypt@[news:] or keith_moore@[fax:+14239748295] > Newsgroups are simply high-volume mailing lists with many entry points > and a fancy distribution mechanism. > > > But in the email world there's no inherent distinction > > between "public responses" and "private responses" and it's silly to > > pretend that there is one. > > Every popular MUA supports both replies and followups. Depends on what you mean by followups. > > You can define some notion of "followup" > > for email using a followup-to header, but doing so doesn't add any new > > services -- it just replicates services that already exist. > > False. It provides a direct way to control followups; circular argument. Having X would provide a way to control X. to which my response is: Not having X would rid me of the need to control X. unless you can give me a much better justification for X, I'm quite sure that I'm better off without it. (and no, the fact that something called X apparently exists on some UAs, which is almost certainly implemented differently on each UA, and also differently than what you propose, is not a justification for perpetuating X or standardizing X') > > > Explanation, please. Who exactly would be confused? > > Besides you? (sorry, that was too easy.) > > I find this comment rather amusing, given the number of ridiculous > statements that Keith has made in this discussion---claiming that the > followup field is for MLMs to set, claiming that the widely recognized > problem of duplicates doesn't exist, claiming that the problem is solved > by MUA duplicate elimination, etc. Your mis-statement of my position provides more evidence of your confusion. > > Users who are confused by existing reply options would be even more confused > > by the addition of followup options which basically do the same thing > > as replies. > [ ... ] > > Support for followup-to would require that UAs add other commands > > ("followup", "set followup-to") in addition to the set above. > > Here Keith makes yet another stupid mistake: he seems to think that > followups are something different from the MUA's existing ``wide reply'' > or ``group reply'' or ``reply to all'' feature. Absolutely they are. Reply-to-all doesn't recognize a followup-to header, and the operation that you're proposing would recognize such a header. If such an operation were implemented, I would still need a different operation to allow me to send a reply-to-all WITHOUT looking at the followup-to field, because I might have reasons for not following the author's suggestion of where I send my responses. Above you stated that followups and replies are fundamentally different operations, and now you're telling me that followup is no different than "reply to all". For a large number of users, "reply" is no different than "reply to all". > One wonders how many times Keith needs to see the problem statement > before he understands it. Here it is again: > > Right now, when someone _follows up_ to a mailing list message from a > subscriber, the subscriber and the mailing list are both in the > followup's recipient list by default. > > The obvious fix is to let the subscriber override the default _followup_ > target, omitting his own address. Your problem statement uses an undefined term, and so is meaningless. If I choose a definition for that term, you'll pick a different definition and claim that my arguments based on my defintion are stupid. And if I equate your word "followup" to my UA's "reply-to-all" command, the author of the subject message does have the ability to override the default recipient list of "reply-to-all", using reply-to. I realize that many UAs don't handle "reply-to-all" this way, in particular a lot of UAs use Reply-to only as a replacement for From. But the DRUMS document already clarifies that reply-to is the author's preference as to where replies should be sent. Adding yet another header to define replies provides marginal additional value at best, and increases the complexity (and variation among UAs) as to how recipients can respond to messages. It's not worth it. > > > Explanation, please. How exactly would a followup field hurt anyone? > > I've already explained this. > > Nonsense. Keith has explained bad consequences of two red herrings: > first, having MLMs munge the followup field; second, having followups > distinguished from reply-to-sender-and-recipients. And you completely ignore my argument against unnecessary complexity, by citing points irrelevant to this argument and calling them red harrings. > > First explain how "followup" would differ from "reply", beyond the > > fact that it would use different header names and that it's not > > supported by any of the installed base. > > Nonsense. It's supported by most, perhaps all, of the installed base. > It's even supported by Berkeley Mail. Okay, but whatever that operation is, it doesn't recognize a followup-to header, and we're better off without one. If someone modified Berekeley Mail to support a followup-to header, I'd end up manually editing headers even more often than I do now. > > Also please explain why it > > would not suffer from the same problems that reply suffers from. > > The motivation for reply-to munging is that, in its absence, a typical > user has no easy way to follow up without the problem of duplicates > discussed above. The problem of duplicates won't be solved by a followup-to header, in any way that couldn't be solved by use of reply-to. Let's take this message as an example. If my preference is for replies to this message to go to me only, I can set "reply-to: moore@cs.utk.edu". If my preference is for replies to go to the 822ext list only, I can set "reply-to: ietf-822@imc.org". If my preference is for replies to go to sender and all recipients, but to get only one copy of the message, I can set "reply-to: ietf-822@imc.org, djb@koobera.math.uic.edu" The recipient of the message can of course override my defaults. Some, perhaps most, UAs will not do what I intend: e.g. if the recipient uses "reply to sender" they will send the reply to the reply-to address, but if the recipient uses "reply to all" they will send the reply to reply-to+to[+cc]. In which case I'll get a duplicate. Followup-to won't fix this: for the forseeable future UAs won't either recognize it or generate it. By the time UAs do recognize it, lists will mung it. If the followup-to field is somehow specified so that lists don't mung it, lists will want their own header that specifies how to send mail to the list (further increasing the complexity of UAs' reply operations). > If, on the other hand, his MUA supports a followup field, subscribers > suddenly have the ability to eliminate those duplicates. But the followup-to field would also be used in other ways, just as reply-to has been used in other ways. It would increase the degree of variation in UA behavior and thereby increase user confusion and tech support costs. If anything, it seems like we have plenty of experience with reply-to that indicates that yet another header to "control" where replies go is a Bad Idea. > Once the followup field is universally supported, the motivation for > reply-to munging will be gone. There's a lot more motivation for reply-to munging than duplicate suppression. Some lists want to keep discussion on the list. Some lists want to keep discussion off of the list. Some lists are built with the assumption that recipient's UAs are broken and can't reply to To or Cc addreses. (If these UAs aren't yet fixed to allow replies to To/Cc, how likely is it that they will be "fixed" to support followup-to?) Many lists are set up to mung reply-to based on the false assumption that "lists are supposed to work this way", proabably because of experience with LISTSERV and listproc and other header-munging list software. (LISTSERV was originally written for BITNET where almost none of the UAs in use could reply to other than a single address). > > Once you have defined the new feature, convince people that the new feature > > is worth implementing and supporting. *Then* worry about what to call > > the header field. > > Is there anyone other than Keith who's confused about the function and > benefits of a followup field? I freely admit that I'm confused about what exists in your mind. Most people can argue with some flexibility: by clearly communicating their ideas, tolerating some difference in definitions from one person to another, using intuition to guess what someone else means in the absence of precise specification, and not assuming that others will uniformly adopt their world-view. You don't seem to be capable of any of these. Consequently, the only reason to discuss things with you at all is for damage control -- to demonstrate to others that your ideas aren't well formed. Which is not to say that you never have good ideas, but you are apparently incapable of adapting your ideas to accomodate others' experience. The surest way to destroy a potentially useful suggestion is for you to argue about it, because you'll exhaust anyone who tries to modify it based on their own experience. Your tendency to name calling, misstating others positions, reiterating positions that have been modified, diverting from the original argument and finding something else to attack when you start to lose, "wife beating" attacks, and non sequitors and other lapses of logic, do not lend credibility to your arguments. Keith From owner-ietf-822 Sat Jul 5 09:18:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA16510 for ietf-822-bks; Sat, 5 Jul 1997 09:18:48 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA16503; Sat, 5 Jul 1997 09:18:42 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.5/8.8.5) with ESMTP id SAA06253; Sat, 5 Jul 1997 18:21:02 +0200 (MET DST) X-Sender: jpalme@dsv.su.se (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 5 Jul 1997 18:20:51 +0200 To: IETF mail extensions mailing list From: Jacob Palme Subject: Advise on the implementation of Supersedes, In-Reply-To and References e-mail headers Sender: owner-ietf-822@imc.org Precedence: bulk I have written a draft document with advice on how to implement the Supersedes, In-Reply-To and References headers in mail and news user agents. The document has been submitted to IETF drafts is available at URL: ftp://ftp.dsv.su.se/users/jpalme/draft-palme-newfields-info-00.txt, and its text is copied below in this message: --- --- cut here --- --- Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-palme-newfields-info-00.doc IETF status: To become an informational RFC Expires: January 1998 July 1997 Advise on the implementation of In-Reply-To, References and Supersedes e-mail and netnews headers Status of this Document This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Separate Internets standards documents define the e-mail headers, In-Reply-To, References, Supersedes and Expires. This document, which is an informational RFC, gives some advise on the implementation of these features. Table of Contents 1. User interface 2. Hard and soft Supersedes 3. Data base 4. References 5. Author's Address 1. User interface The fields "In-Reply-To", "References" and "Supersedes" are all used to convey information about references between different e-mail messages or netnews articles. The best way to implement these fields is to tell the recipient that two messages reference each other, and to make it easy for readers to traverse threads (series of linked messages) up and down. In the particular case of "Supersedes", a user who has not yet read either the old or the new version, may be shown only the new version as a new message, but with methods to easily find the old version. A good way to show this information to users is to show the "In-Reply- To", "Supersedes" and "References" fields and allow the user to click on the parameters of these fields to get to the referred-to messages. Additionally, it is useful to add reverse fields to message headers, i.e. "Replied-By", "Referenced-By" and "Superseded-By". This allows a user, when reading a message, to see if someone else has already replied, and it allows users to traverse threads downwards and not only upwards. Such reverse fields should not be sent in e-mail, they are just for local handling in user mailbox databases. 2. Hard and soft Supersedes By a hard supersedes is meant a Supersedes which causes deletion of the supersedes message. By a soft supersedes is meant a Supersedes which still keeps both messages, and allows a user to see and use the reference between them, similarly to In-Reply-To and References. Supersedes should be implemented as soft supersedes. Some implementations, especially in Usenet News, do however implement it as hard supersedes. Hard supersedes has the same security problem as the Cancel command of Usenet News. They can be used to malicuosly deleting other people's messages. Use of strong authentication of the author can reduce this risk. 3. Data base In order to implement this, a data base is needed which, given a Message-ID, can find the message which this Message-ID refers to. This data base has a very simple structure, just a single value mapped to one or more messages. Note, however, that the same message can be stored in more than one mailbox, so the data base should not be restricted to only one location for each Message-ID. Every time a message is added, moved, copied, deleted or purged, this data base need to be updated. The main problem with these kinds of Message-ID data bases is that they tend to become very large with time, and they easily collect garbage (Message-ID-s of messages not any more available in the mailbox data base). The two most common methods to implement such data bases are: (a) Implement a large data base, but with some method of garbage collection to avoid unlimited growth of the data base. (b) Implement a smaller data base, where all objects are deleted after a certain time, for example a few months. With implementation method (b), information about the references in the form of "In-Reply-To", "References", "Supersedes", "Replied-By", "Referenced-By" and "Superseded-By" should also be stored in the message headers themselves. The reason method (b) works is that it is very uncommon that a message has a reference to other than very recent messages. Thus, the lack of "Replied-By", "Referenced-By" and "Superseded-By" headers in these very uncommon cases is acceptable. The advantage with method (b) is that a complex garbage collection method, as for method (a), is not needed. A much simpler garbage collection method, just removing records after a certain expiration time, can be used instead. 4. References Ref. Author, title --------- -------------------------------------------------------- [AUTOLOOP] J. Palme: "Loop control for the Auto-Submitted e-mail header", draft-palme-autosub-03.txt, July 1997. [MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. . [MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996. [MIME3] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996. [MIME4] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, January 1997. [MIME5] "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996. [NEWFIELDS] J. Palme: "The Auto-Submitted, Supersedes and Expires E-mail Headers", draft-ietf-mailext-new-fields-08.txt, July 1997. [NEWS] M.R. Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987. [RFC822] D. Crocker: "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982. [SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. 5. Author's Address Jacob Palme Phone: +46-8-16 16 67 Stockholm University and KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme From owner-ietf-822 Tue Jul 8 16:43:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA29427 for ietf-822-bks; Tue, 8 Jul 1997 16:43:03 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA29423 for ; Tue, 8 Jul 1997 16:43:00 -0700 (PDT) Received: (qmail 9269 invoked by uid 666); 8 Jul 1997 23:54:12 -0000 Date: 8 Jul 1997 23:54:12 -0000 Message-ID: <19970708235412.9268.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk Time for a reality check. BSD Mail supports two response functions: 1. ``reply to originator'' = From. 2. ``send mail to sender and all recipients'' = From + To + Cc. Elm supports two response functions: 1. ``reply'' = From. 2. ``group reply'' = From + To + Cc. Pine supports one function but asks ``reply to all recipients?'': 1. ``no'' = From. 2. ``yes'' = From + To + Cc. Mutt supports two response functions: 1. ``reply'' = From. 2. ``reply to all recipients'' = From + To + Cc. Does Keith see the pattern yet? Or shall I start listing non-UNIX mailers too? There's certainly no standardization at the edges of these functions. For example, some MUAs copy the original To into the new Cc field; some copy it into the new To field. But there's always a reply function, using From in the common case, and a followup function, using From + To + Cc in the common case. Now, once again, here's the problem: A subscriber sends a message to a mailing list. Someone follows up. The response is sent to both the subscriber and the mailing list. As I've already discussed in detail, the extra address is generally harmful. I don't think there's any dispute about this. Unfortunately, the person following up can't tell that situation apart from the following situation, where the extra address is generally beneficial: A non-subscriber sends a message to a mailing list. Someone follows up. The response is sent to the non-subscriber and the mailing list. So the original author has to put some extra information into his header to differentiate the two situations. The obvious solution is a followup field. This would put control directly in the hands of the original author, and it would be trivial to implement. My question is what this field should be called. > But you haven't demonstrated that followups are (a) significantly > distinct from replies and (b) worth having. Existing MUAs support followups. Followups have vastly different effects from replies. I really don't care whether Keith accepts these facts; his willful ignorance is not typical of MUA implementors. > And if I equate your word "followup" to my UA's "reply-to-all" command, > the author of the subject message does have the ability to override > the default recipient list of "reply-to-all", using reply-to. > I realize that many UAs don't handle "reply-to-all" this way, That's because they're following RFC 822, section 4.4.4. > And you completely ignore my argument against unnecessary complexity, I agree with Keith that RFC 822 is unnecessarily complex. But we're stuck with it. Keith's proposed change in semantics would be a disaster. > Okay, but whatever that operation is, it doesn't recognize a > followup-to header, and we're better off without one. If someone > modified Berekeley Mail to support a followup-to header, I'd end up > manually editing headers even more often than I do now. Let's see some specific examples supporting this claim. In exactly what situation would a followup field, implemented as I described, produce worse results than the current defaults? > Followup-to won't fix this: for the forseeable future UAs won't > either recognize it or generate it. Duh. There's no transition problem here. MUAs can support a followup field without trouble. As support spreads, duplicate messages will disappear. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Tue Jul 8 20:06:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA01248 for ietf-822-bks; Tue, 8 Jul 1997 20:06:15 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id UAA01244 for ; Tue, 8 Jul 1997 20:06:11 -0700 (PDT) Received: (qmail 12396 invoked by uid 666); 9 Jul 1997 03:17:24 -0000 Date: 9 Jul 1997 03:17:24 -0000 Message-ID: <19970709031724.12395.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > In email, using reply-to, I can manually redirect a discussion away from > inappropriate recipients. What's the difference? My proposal---using Reply-To to control replies, and a followup field to control followups---is a _labelled_ change from RFC 822 semantics. Your proposal---using From to control replies, and Reply-To to control followups---is an _unlabelled_ change from RFC 822 semantics. You keep complaining that MUAs don't use From and Reply-To the way you suggest. That's because they're following RFC 822, section 4.4.4. Of course, this is only a guess at what your proposal means, since you consistently refuse to say what you want real MUAs to do with their two built-in response functions. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 00:39:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA03306 for ietf-822-bks; Wed, 9 Jul 1997 00:39:11 -0700 (PDT) Received: from candle.brasslantern.com (root@ncs-39.nbn.com [199.4.66.39]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA03301 for ; Wed, 9 Jul 1997 00:39:06 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id XAA09577; Tue, 8 Jul 1997 23:52:16 -0700 From: "Bart Schaefer" Message-Id: <970708235216.ZM9576@candle.brasslantern.com> Date: Tue, 8 Jul 1997 23:52:15 -0700 In-Reply-To: <19970709031724.12395.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 9, 3:17am) References: <19970709031724.12395.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 9, 3:17am, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } > In email, using reply-to, I can manually redirect a discussion away from } > inappropriate recipients. What's the difference? } } My proposal---using Reply-To to control replies, and a followup field to } control followups---is a _labelled_ change from RFC 822 semantics. } } Your proposal---using From to control replies, and Reply-To to control } followups---is an _unlabelled_ change from RFC 822 semantics. That's not Keith's proposal, and you ought to know that it isn't. Keith's proposal is to use Reply-To to control replies, and to ignore the concept of followups entirely. I happen to agree with him on the latter point; I don't think it's useful to apply the netnews concept of `followup' to the common email UA function of `reply using From + To + Cc'. They happen to have a similar effect if and only if one of those headers contains the address of a mailing list, but they're still not really the same thing. } You keep complaining that MUAs don't use From and Reply-To the way you } suggest. That's because they're following RFC 822, section 4.4.4. Actually, none of them are following 4.4.4 when they do `reply to all', because 4.4.4 doesn't apply to the To and Cc fields. It applies only to From, Sender, and Reply-To. Anything that automatically uses To and Cc in that way is extended functionality, not covered by RFC822. There is no mention anywhere in 822 of using To and Cc that way. Even if you grant dispensation for common practice, it's debatable whether they're following 4.4.4; the statement there is: If the "Reply-To" field exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the "From" field. It's been argued that the "and not to ..." clause is extraneous, and that the interpretation was meant to be "... go to the addresses indicated in that field, and nowhere else." Which is exactly what the basic `reply' function does in all the UAs that you listed; the `reply to all' function is ignoring the implicit "and nowhere else." (Section 4.3.1: The "Reply-To" field is added by the originator and serves to direct replies, ... Section 4.4.3: The "Reply-To" field is added by the originator and is intended to direct replies. But they both muddy the issue by attaching clauses about Return-Path, so there's no definitive "and nowhere else" anywhere.) Furthermore, most of those UAs' `reply to all' functions behave as `reply using (Reply-To OR From) + To + Cc'; some do even more complex things, but in any case they're usually doing a 4.4.4 `reply' and then, in addition, using some other set of addresses. That fits the definition of extended functionality, I'd say. I happen to think it's useful enough extended functionality that it ought to be recognized by the standards; but confusing it with the concept of `following up' is the wrong approach. } Of course, this is only a guess at what your proposal means, since you } consistently refuse to say what you want real MUAs to do with their two } built-in response functions. I won't presume to speak for him, but my understanding is that the second response function should be `reply using Reply-To OR (From + To + Cc)' (note the change in parenthesization). Maybe a better characterization is that `reply' should always mean `using Reply-To OR From', and tacking on addresses from any other source should be in a different category. This essentially means that we don't change RFC882, but rather that we start insisting that UAs obey the strictest possible interpretation of the Reply-To header. I dislike that for various reasons, but I find it even more distasteful to stir `followups' into the mix. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 01:43:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA03822 for ietf-822-bks; Wed, 9 Jul 1997 01:43:47 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@ncs-46.nbn.com [199.4.66.46]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id BAA03818 for ; Wed, 9 Jul 1997 01:43:41 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id BAA10045 for ietf-822@imc.org; Wed, 9 Jul 1997 01:46:15 -0700 From: "Bart Schaefer" Message-Id: <970709014614.ZM10044@candle.brasslantern.com> Date: Wed, 9 Jul 1997 01:46:14 -0700 In-Reply-To: <19970708235412.9268.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 8, 11:54pm) References: <19970708235412.9268.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 8, 11:54pm, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } A subscriber sends a message to a mailing list. Someone follows up. } The response is sent to both the subscriber and the mailing list. } } A non-subscriber sends a message to a mailing list. Someone follows } up. The response is sent to the non-subscriber and the mailing list. Let's restate those two cases as: A subscriber sends a message to a mailing list. Some recipient uses the reply-using-destination-fields function of his user agent. The response is sent both to the subscriber and to the mailing list. A non-subscriber sends a message to a mailing list. Some recipient uses the reply-using-destination-fields function of his user agent. The response is sent to the non-subscriber and to the mailing list. Now we can all agree, I think, on this: } So the original author has to put some extra information into his header } to differentiate the two situations. There are three ways to approach this problem: 1. The originator who is on the mailing list can ask (not require) the recipients to omit him from the replies. 2. The originator who is NOT on the mailing list can ask the recipients to include him in the replies. 3. Both kinds of originators can suggest the full list of destinations to which the recipients should direct replies. } The obvious solution is a followup field. This would put control } directly in the hands of the original author, and it would be trivial to } implement. My question is what this field should be called. I agree with Keith that a followup field is not an obvious solution, and therefore that debating what to call it is premature. It is not obvious because: * It is introducing a new concept; reply-using-destination-fields is not the same as the traditional netnews concept of `followup'. * It requires UAs to restrict their reply-using-destination-fields behavior when it is present, rather than permitting them to extend their basic reply behavior when it is present. * It requires originators to supply too much information; they must not only suggest how recipients should deal with their own address, but must also suggest how to deal with all destination addresses. I don't think using Reply-To is a viable solution, because: * It requires UAs to restrict their reply-using-destination-fields behavior when it is present. Sounds familiar, but in this case it's worse, because it retroactively changes the interpretation of reply-using-destination-fields for messages sent long ago. * It requires originators to supply too much information (a generic problem with approach #3 above). * Mailing lists must stop rewriting Reply-To. List managers are not going to give up control over list policy (direct replies to the list or away from it) and Reply-To is the only way to influence a large number of existing user agents. So it does seem that a new differentiator is necessary, but I don't think `followup' is the obvious or correct one. The claimed benefits of `followup' are: * Gives control to the original author (but too much so). * Easy to implement (maybe). * Existing UAs support the concept (but they don't, really). * No transition problem from current practice. Here's an alternative which I think betters `followup' on every one of those points: Define a `Reply-Cc' field, with the semantics that the address(es) in the Reply-Cc field should be copied to the Cc field of the reply; the semantics of all existing fields remain unchanged, except of course that the presence of Reply-To does not exclude the Reply-Cc. Gives control to the original author: In approach #1, the originator places the address of the mailing list in Reply-To and omits Reply-Cc. In approach #2, the originator places his own address in Reply-Cc and does whatever he likes with Reply-To. Using both provides approach #3. Easy to implement: Many UAs can begin sending it immediately. Simple rule for what to do with the addresses when constructing a reply. Existing UAs support the concept: Every UA has replies and Cc fields, and every user knows what they mean. Nothing new to learn. No transition problem: `Reply-using-destination-fields' behaviors are completely unchanged. As support spreads, users can use `reply' instead, even in mailing-list circumstances to get `followup'-like behavior, and thereby reduce duplications. List servers don't have to change. There's probably even some mailer out there somewhere that already has a Reply-Cc field that works this way. A final remark: This whole debate could have been avoided by dumping the term `followup'. Call the silly thing `Reply-Destinations' and stick with the concept of `reply'. That doesn't solve any of the other problems with it, but at least Dan can stop pretending that he and Keith don't understand each other. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 06:57:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA08767 for ietf-822-bks; Wed, 9 Jul 1997 06:57:07 -0700 (PDT) Received: from transarc.com (transarc.com [192.54.226.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA08760 for ; Wed, 9 Jul 1997 06:57:02 -0700 (PDT) Received: by transarc.com (5.54/3.15) id for ietf-822@imc.org; Wed, 9 Jul 97 09:59:38 EDT Received: via switchmail; Wed, 9 Jul 1997 09:59:38 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Wed, 9 Jul 1997 09:58:37 -0400 (EDT) Received: from bigbend.transarc.com via qmail ID ; Wed, 9 Jul 1997 09:58:25 -0400 (EDT) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.bigbend.transarc.com.sun4c.53 via MS.5.6.bigbend.transarc.com.sun4_51; Wed, 9 Jul 1997 09:58:13 -0400 (EDT) Message-Id: Date: Wed, 9 Jul 1997 09:58:13 -0400 (EDT) From: Craig_Everhart@transarc.com To: ietf-822@imc.org Subject: Re: best name for followups? In-Reply-To: <970709014614.ZM10044@candle.brasslantern.com> References: <19970708235412.9268.qmail@koobera.math.uic.edu> <970709014614.ZM10044@candle.brasslantern.com> Sender: owner-ietf-822@imc.org Precedence: bulk Thank you, thank you for applying more light and less heat to this discussion. And particularly for an actual proposal that looks like forward progress! Excerpts from transarc.system.ietf-822: 9-Jul-97 Re: best name for followups? "Bart Schaefer"@candle.b (5133*) > Here's an alternative which I think betters `followup' on every one of > those points: Define a `Reply-Cc' field, with the semantics that the > address(es) in the Reply-Cc field should be copied to the Cc field of > the reply; the semantics of all existing fields remain unchanged, except > of course that the presence of Reply-To does not exclude the Reply-Cc. > Gives control to the original author: In approach #1, the originator > places the address of the mailing list in Reply-To and omits Reply-Cc. > In approach #2, the originator places his own address in Reply-Cc and > does whatever he likes with Reply-To. Using both provides approach #3. Sounds perfect. Craig From owner-ietf-822 Wed Jul 9 08:50:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA10508 for ietf-822-bks; Wed, 9 Jul 1997 08:50:31 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA10500 for ; Wed, 9 Jul 1997 08:50:25 -0700 (PDT) Received: (qmail 16451 invoked by uid 666); 9 Jul 1997 16:01:41 -0000 Date: 9 Jul 1997 16:01:41 -0000 Message-ID: <19970709160141.16450.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk > Keith's proposal is to use Reply-To to control replies, and to ignore > the concept of followups entirely. I know that _Keith_ is ignoring the concept of followups. However, _MUAs_ already have the concept, and they're not going to throw it away. > I don't think it's useful to apply the netnews concept of `followup' to the > common email UA function of `reply using From + To + Cc'. Until I hear better terminology, I'm going to continue to use ``reply'' and ``followup'' as generic terms for the two response functions in existing MUAs. > Actually, none of them are following 4.4.4 when they do `reply to all', You misunderstand. Keith is proposing a change in _replies_, not just followups. The relevant part of 4.4.4 is the third bulleted item: when Reply-To exists, it replaces From as the target of replies. Keith proposes using From whether or not Reply-To exists. Whenever From and Reply-To are different---e.g., a secretary sending a message for the boss---Keith's change in semantics poses an impossible transition problem. The only way for users to retain control over replies is to copy Reply-To into From, violating the RFC 822 From semantics. > Even if you grant dispensation for common practice, Perhaps you should read RFC 822. It explicitly recognizes that MUAs can provide additional response facilities. > I happen to think it's useful enough extended functionality that it ought > to be recognized by the standards; Standards? I'm talking about reality, not the IETF. ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 09:42:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA11223 for ietf-822-bks; Wed, 9 Jul 1997 09:42:09 -0700 (PDT) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA11219 for ; Wed, 9 Jul 1997 09:42:06 -0700 (PDT) Received: (qmail 16746 invoked by uid 666); 9 Jul 1997 16:53:22 -0000 Date: 9 Jul 1997 16:53:22 -0000 Message-ID: <19970709165322.16745.qmail@koobera.math.uic.edu> From: "D. J. Bernstein" To: ietf-822@imc.org Subject: Re: best name for followups? Sender: owner-ietf-822@imc.org Precedence: bulk [ criticism of a followup field ] > * It is introducing a new concept; It is working with the concept that already exists in dozens of MUAs. The big problem, as is obvious from this discussion, is coming up with a good name. > * It requires UAs to restrict their reply-using-destination-fields > behavior when it is present, Yes, it's a change in the followup behavior. That's the whole point. > rather than permitting them to extend > their basic reply behavior when it is present. I don't understand. Do you have some specific change in mind? How does it conflict with a change in followup behavior? Hmmm. I get the feeling that you think I'm talking about writing a spec. I'm not. I'm talking about changing the behavior of real MUAs. The only relevant people are MUA implementors. > * It requires originators to supply too much information; they must > not only suggest how recipients should deal with their own address, > but must also suggest how to deal with all destination addresses. Why is this a problem? Could you give a specific example where the originator would have trouble coming up with the information? The followup field is the same as From+To+Cc by default. The MUA can automatically remove the From address if it knows that the user is on a mailing list shown in To+Cc. The followup field is copied into subsequent followups. [ new proposal ] > Here's an alternative which I think betters `followup' on every one of > those points: Define a `Reply-Cc' field, with the semantics that the > address(es) in the Reply-Cc field should be copied to the Cc field of > the reply; Later you make clear that you're proposing a change purely in reply behavior, not in followup behavior. Replies are typically sent to Reply-To defaulting to From. You're saying that they should be sent to Reply-To+Reply-Cc defaulting to From. Right? Aside from Reply-To munging and the difference between To and Cc, your proposal adds no new capabilities. A user can simply merge your Reply-Cc into Reply-To to obtain the same results. Your real proposal is the same as Keith's: you want to put the mailing list into Reply-To, and the sender's personal reply address into From. You expect MUAs to have a respond-to-From-ignoring-Reply-To function. Right? ---Dan Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html From owner-ietf-822 Wed Jul 9 10:26:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA11870 for ietf-822-bks; Wed, 9 Jul 1997 10:26:16 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA11856 for ; Wed, 9 Jul 1997 10:26:09 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id KAA12146 for ietf-822@imc.org; Wed, 9 Jul 1997 10:28:42 -0700 From: "Bart Schaefer" Message-Id: <970709102841.ZM12145@candle.brasslantern.com> Date: Wed, 9 Jul 1997 10:28:41 -0700 In-Reply-To: <19970709160141.16450.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 9, 4:01pm) References: <19970709160141.16450.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 9, 4:01pm, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } Until I hear better terminology, I'm going to continue to use ``reply'' } and ``followup'' as generic terms for the two response functions in } existing MUAs. I hope you enjoy talking to yourself, then. } > Actually, none of them are following 4.4.4 when they do `reply to all', } } You misunderstand. Keith is proposing a change in _replies_, not just } followups. What's the connection between that and whether UAs are following 4.4.4? } The relevant part of 4.4.4 is the third bulleted item: You'll note that I had quoted that specific item. } when Reply-To exists, it replaces From as the target of replies. When Reply-To exists, it replaces From when automatically generating address lists from originator fields, yes. } Keith proposes using From whether or not Reply-To exists. I've seen no evidence that this is what Keith proposes, other than your willful misrepresentations. Based on what Keith has written, I interpret his proposal as "never use the contents of destination fields to generate reply addresses when a Reply-To header is present." This does not imply "always use From." Keith does also propose "don't send a Reply-To field when that isn't what you mean," but that's a recommendation for originators, not a change for responders. } > Even if you grant dispensation for common practice, } } Perhaps you should read RFC 822. It explicitly recognizes that MUAs can } provide additional response facilities. You refer to this text: This recommendation is intended only for automated use of originator-fields and is not intended to suggest that replies may not also be sent to other recipients of messages. It is up to the respective mail-handling programs to decide what additional facilities will be provided. I agree that this supports the position that UAs should not be restricted from using destination fields to generate reply addresses. However, that undermines your own proposal as much as it does Keith's. It also supports, by the phrase "additional facilities," my assertion that `reply using From + To + Cc' is extended functionality and explicitly not covered (though also explicitly not prohibited) by 4.4.4. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com From owner-ietf-822 Wed Jul 9 11:10:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA12551 for ietf-822-bks; Wed, 9 Jul 1997 11:10:04 -0700 (PDT) Received: from candle.brasslantern.com (schaefer@zagzig.zanshin.com [206.155.48.241]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA12543 for ; Wed, 9 Jul 1997 11:09:57 -0700 (PDT) Received: (from schaefer@localhost) by candle.brasslantern.com (8.8.5/8.8.5) id LAA12289 for ietf-822@imc.org; Wed, 9 Jul 1997 11:12:32 -0700 From: "Bart Schaefer" Message-Id: <970709111231.ZM12288@candle.brasslantern.com> Date: Wed, 9 Jul 1997 11:12:31 -0700 In-Reply-To: <19970709165322.16745.qmail@koobera.math.uic.edu> Comments: In reply to "D. J. Bernstein" "Re: best name for followups?" (Jul 9, 4:53pm) References: <19970709165322.16745.qmail@koobera.math.uic.edu> X-Mailer: Z-Mail (4.0b.820 20aug96) To: ietf-822@imc.org Subject: Re: best name for followups? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-822@imc.org Precedence: bulk On Jul 9, 4:53pm, D. J. Bernstein wrote: } Subject: Re: best name for followups? } } > * It requires UAs to restrict their reply-using-destination-fields } > behavior when it is present, } } Yes, it's a change in the followup behavior. That's the whole point. } } > rather than permitting them to extend } > their basic reply behavior when it is present. } } I don't understand. Do you have some specific change in mind? See below. } How does it conflict with a change in followup behavior? It doesn't conflict; I just don't believe that a change in reply-using- destination-fields is a good or likely thing. Even if it does change, the change is more likely to be that it becomes `reply using From + To + Cc + The-New-Field', which is exactly the opposite of what you want. Hence if you're going to add a new field, you might as well add a field that has fits that behavior to begin with. } Hmmm. I get the feeling that you think I'm talking about writing a spec. } I'm not. I'm talking about changing the behavior of real MUAs. The only } relevant people are MUA implementors. That's a lovely idea, but if you don't write a spec the chances approach zero of more than two different implementors agreeing on how it works. Look at all the odd edge conditions in reply-using-destination-fields. } > * It requires originators to supply too much information; they must } > not only suggest how recipients should deal with their own address, } > but must also suggest how to deal with all destination addresses. } } Why is this a problem? Could you give a specific example where the } originator would have trouble coming up with the information? The problem is not that the originator can't come up with the information. The problem is that the responding UA can't obey both the originator's recommendation and the responding user's instructions. The responding UA must either ignore the destination fields even when instructed (by the responding user) to include them, which I think is bad; or it must ignore the originator's recommendation when asked to do a simple reply. Skipping ahead for a bit: } Replies are typically sent to Reply-To defaulting to From. You're saying } that they should be sent to Reply-To+Reply-Cc defaulting to From. Right? Right so far. } Aside from Reply-To munging and the difference between To and Cc, your } proposal adds no new capabilities. A user can simply merge your Reply-Cc } into Reply-To to obtain the same results. Essentially correct; the minor difference being that Reply-Cc goes into the Cc field, not into To. In fact, it is exactly the intention that there are no new capabilities *except* the ability to bypass Reply-To munging. } Your real proposal is the same as Keith's: you want to put the mailing } list into Reply-To, and the sender's personal reply address into From. } You expect MUAs to have a respond-to-From-ignoring-Reply-To function. } Right? Completly wrong. To address the "followup problem," I want to put the sender's personal reply address into Reply-Cc if and only if he is not a member of the mailing list; if he is a member of the mailing list, I think the Reply-Cc should be left out entirely. What goes in Reply-To is whatever goes in Reply-To right now, munged however the list server munges it right now; I don't care. I expect MUAs to expand the `reply' function to mean `send to (Reply-To OR From) + Reply-Cc'. I expect `Reply-To' to continue to replace `From' as it does now. I further expect MUAs to expand `reply-using-destination-fields' to mean `send to (Reply-To OR From) + Reply-Cc + To + Cc'. However, I expect users to realize that `reply-using-destination-fields' is no longer the right thing to use to "follow up," because `reply' does what they want. That means I expect UAs that support Reply-Cc to stop making `reply to all' be the most-easily-accessed reply function. } Later you make clear that you're pro