Received: from localhost by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA13212; Thu, 14 Sep 1995 14:04:12 -0400 X-Resent-To: drums@CS.UTK.EDU ; Thu, 14 Sep 1995 14:04:11 EDT Errors-to: owner-drums@CS.UTK.EDU Received: from smtp.interramp.com by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id OAA13198; Thu, 14 Sep 1995 14:03:55 -0400 From: Received: from interramp.com by smtp.interramp.com (8.6.12/SMI-4.1.3-PSI) id NAA08355; Thu, 14 Sep 1995 13:52:04 -0400 Date: Thu, 14 Sep 95 13:40:10 PDT Sender: Manros@interramp.com Subject: Re: Another header-munging example To: IETF-DRUMS Cc: moore@CS.UTK.EDU X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Friends, Concerning this debate, I support Jacob's proposal to add further alternatives in the header. I have difficulty to believe that people will actually change their implementations if we just try to re-interpret the behaviour, or favor one current behaviour over another, while keeping the same header parameter as before. Jacob's proposal gives a much cleaner new solution, while keeping the old parameter, with its ambiguities, for a migration period. Carl-Uno Carl-Uno Manros Manros Consulting Tel: (617) 776-8300 125 Walnut Street Fax: (617) 776-0330 Somerville, MA E-mail: manros@interramp.com ---------------Part of Original Message--------------- (from the floor :) ) > If existing 822 headers are interpreted in two different ways > by much existing software, then there is an obvious risk that > the outcome of the process you describe will be either: > > (a) An ambiguous compromise to make everyone happy, but keeping > the two different interpretations and the trouble which is caused > by them. > > (b) Recommending only one of the two, after which much existing > software maybe will not follow the new standard because they do > not like it. Other outcomes are possible. In particular, I believe it is possible to *encourage* (rather than mandate) a narrower set of behaviors for mailing lists which is more-or-less compatible with the installed base of user agents. Present-day lists might not change their behavior, but new lists might be more likely to adhere to the recommended behavior. (some present-day lists might offer the recommended behavior as a per-recipient option.) Eventually we would gain uniformity than we have now -- the rate being governed by how well the recommended solution meets people's needs. Keith ----------End of Original Message----------