From ima-bounces@ietf.org Mon Jul 02 16:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SrB-0002my-EX; Mon, 02 Jul 2007 16:50:49 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I5SrA-0002bf-H7 for ima-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 16:50:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5SrA-0002VQ-1A; Mon, 02 Jul 2007 16:50:48 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5Sr9-0007vw-PG; Mon, 02 Jul 2007 16:50:47 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A38AA2AC61; Mon, 2 Jul 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5SqQ-0001y0-Cc; Mon, 02 Jul 2007 16:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 02 Jul 2007 16:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-dsn-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : International Delivery and Disposition Notifications Author(s) : C. Newman, A. Melnikov Filename : draft-ietf-eai-dsn-02.txt Pages : 18 Date : 2007-07-02 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-dsn-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-dsn-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-dsn-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-07-02164309.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-dsn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-dsn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-07-02164309.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Thu Jul 05 14:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WS8-00035p-3Y; Thu, 05 Jul 2007 14:53:20 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I6WS5-00033e-Sz for ima-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 14:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WS5-00033E-I7 for ima@ietf.org; Thu, 05 Jul 2007 14:53:17 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6WR9-0001ZS-6C for ima@ietf.org; Thu, 05 Jul 2007 14:53:17 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 534D62596FF for ; Thu, 5 Jul 2007 20:52:18 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20304-06 for ; Thu, 5 Jul 2007 20:52:11 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 920CF2596FB for ; Thu, 5 Jul 2007 20:52:11 +0200 (CEST) Date: Thu, 05 Jul 2007 20:51:05 +0200 From: Harald Tveit Alvestrand To: EAI WG Subject: [EAI] FINAL POLL RESULTS on the "what MIME type" question Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The poll close on Friday, 12:00 GMT. Apart from my opinion, all of the opinions listed below have been posted to the list. Not all respondents responded to all questions. QUESTION 1: Should there be a new MIME type for UTF8SMTP messages when carried inside messages in an UTF8SMTP environment? A: No, message/rfc822 can be used. Kari Hurtta (very slight preference) Charles Lindsey B: Yes. Harald Alvestrand Chris Newman John Klensin Yangwoo Ko Martin Duerst Kazunori Fujiwara Mao Wei Randall Gellens Yao Jiankang Tony Hansen Jaeyoun Kim Abel Yang Bjoern Hoerhmann Andrew Sullivan Yoshiro Yoneya C: I have another opinion, which is.... Based on this result, I am declaring this question closed. QUESTION 2: Should the same MIME type be used to carry UTF8SMTP messages in a SMTP environment (without the UTF8SMTP extension, and without requiring the 8BITMIME extension)? This implies that it's possible to encode the message. A: Yes. Harald Alvestrand Chris Newman John Klensin Yangwoo Ko Martin Duerst Kazunori Fujiwara Mao Wei Randall Gellens Yao Jiankang Tony Hansen Jaeyoun Kim Abel Yang Andrew Sullivan Bjoern Hoehrmann Yoshiro Yoneya B: No, that should not be allowed. C: I have another opinion, which is.... Kari Hurtta Charles Lindsey Based on this result, I am declaring this question closed. QUESTION 3: Should the new type be a subtype of Message/? A: Yes Harald Alvestrand Chris Newman (slight preference) John Klensin Yangwoo Ko Martin Duerst Kazunori Fujiwara Mao Wei Randall Gellens Tony Hansen Abel Yang Andrew Sullivan Bjoern Hoehrmann Yoshiro Yoneya B: No, it should be application/something C: I have another opinion, which is.... Kari Hurtta Charles Lindsey Based on this result, I am declaring this question closed. QUESTION 4: What should the new MIME type be called? On this question, people tended to list "good" and "bad" names, with some left unmentioned. This is reflected in the reporting format; however, this format loses distinctions present in the original responses, such as preferences between the "good" types. A: Message/utf8smtp Good: Martin Duerst, Kazunori Fujiwara, Charles Lindsey, Abel Yang, Andrew Sullivan Bad: Chris Newman, John Klensin B: Message/i18n Good: Yangwoo Ko, Yao Jiankang, Tony Hansen Bad: Martin Duerst C: Message/international Good: Chris Newman, Yangwoo Ko, Mao Wei, Randall Gellens, Tony Hansen, Jaeyoun Kim Bad: Martin Duerst D: Message/global Good: Mao Wei, Randall Gellens, Yao Jiankang, Tony Hansen, Jaeyoun Kim Bad: Martin Duerst E: Message/rfcxxxx (to be assigned) Bad: Chris Newman, John Klensin, Martin Duerst F: Message/rfc822 (consistent with an "A" answer on question 1) Good: Kari Hurtta Bad: Chris Newman, John Klensin, Martin Duerst G: Message/utf8 Good: Chris Newman, Abel Yang Bad: John Klensin, Martin Duerst H: Message/rfc822u Good: Martin Duerst Bad: Chris Newman, John Klensin I: Message/mail Good: John Klensin, Martin Duerst, Randall Gellens J: Message/i18n-email Good: Yangwoo Ko, Martin Duerst, Charles Lindsey, Yao Jiankang, Yoshiro Yoneya K: Message/eai Good: Yangwoo Ko, Martin Duerst, Kazunori Fujiwara, Tony Hansen, Abel Yang L: Message/smtp Bad: Chris Newman, John Klensin, Martin Duerst M: Message/smtp8 Good: Martin Duerst Bad: Chris Newman, John Klensin N: Message/utf8eai Good: Martin Duerst, Kari Hurtta, Yao Jiankang, Abel Yang O: Message/utf8-headers Good: Martin Duerst, Charles Lindsey Bad: Chris Newman, John Klensin P: Message/utf8-email Good: Martin Duerst, Kari Hurtta, Jaeyoun Kim, Yoshiro Yoneya Q: Message/ima Good: Yangwoo Ko, Martin Duerst R: Message/intl-email Good: Martin Duerst, Mao Wei, Charles Lindsey, Yoshiro Yoneya S: I have another opinion, which is.... Kari Hurtta (application/utf8-email, message-eai-email, application/eai-email) Yao Jiankang (message/i-address) This response doesn't lend itself to a definite conclusion. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 05 17:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YgH-0005uf-3e; Thu, 05 Jul 2007 17:16:05 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I6Yfq-0004xs-7c for ima-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 17:15:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Yfp-0004xJ-4K; Thu, 05 Jul 2007 17:15:37 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Yfk-0003TO-8F; Thu, 05 Jul 2007 17:15:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 393A032905; Thu, 5 Jul 2007 21:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6YfG-0004NP-3c; Thu, 05 Jul 2007 17:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 05 Jul 2007 17:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-06.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-06.txt Pages : 17 Date : 2007-7-5 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-5165810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-5165810.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Fri Jul 06 14:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sLV-0007Qg-FM; Fri, 06 Jul 2007 14:15:57 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I6sLK-0006mr-K9 for ima-confirm+ok@megatron.ietf.org; Fri, 06 Jul 2007 14:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6sLK-0006m2-9A; Fri, 06 Jul 2007 14:15:46 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6sL6-0001gf-00; Fri, 06 Jul 2007 14:15:46 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EFCC332914; Fri, 6 Jul 2007 18:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6sKb-0002ts-Rn; Fri, 06 Jul 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 06 Jul 2007 14:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-downgrade-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Downgrading mechanism for Email Address Internationalization Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-ietf-eai-downgrade-04.txt Pages : 22 Date : 2007-7-6 Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) allows UTF-8 characters in SMTP envelope and mail header fields. To deliver internationalized Email messages to/via UTF8SMTP non-compliant environment, some sort of converting mechanism is required. This document describes downgrading mechanism for Email Address Internationalization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-downgrade-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-downgrade-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-6133618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-downgrade-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-downgrade-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-6133618.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Sat Jul 07 17:21:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Hir-0002xb-Rx; Sat, 07 Jul 2007 17:21:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I7Hiq-0002xQ-Eq for ima-confirm+ok@megatron.ietf.org; Sat, 07 Jul 2007 17:21:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Hiq-0002xH-3l for ima@ietf.org; Sat, 07 Jul 2007 17:21:44 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7Hia-0003Al-AB for ima@ietf.org; Sat, 07 Jul 2007 17:21:43 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew*man^ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46900392.6a59.1ba for ima@ietf.org; Sat, 7 Jul 2007 22:20:18 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l67LKHQw020676 for ; Sat, 7 Jul 2007 22:20:18 +0100 (BST) To: IMA Subject: Re: [EAI] FINAL POLL RESULTS on the "what MIME type" question References: Message-ID: Date: Sat, 07 Jul 2007 22:20:17 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 05 Jul 2007 19:51:05 +0100, Harald Tveit Alvestrand wrote: > QUESTION 2: Should the same MIME type be used to carry UTF8SMTP messages > in > a SMTP environment (without the UTF8SMTP extension, and without requiring > the 8BITMIME extension)? > This implies that it's possible to encode the message. > > A: Yes. > Harald Alvestrand > Chris Newman > John Klensin > Yangwoo Ko > Martin Duerst > Kazunori Fujiwara > Mao Wei > Randall Gellens > Yao Jiankang > Tony Hansen > Jaeyoun Kim > Abel Yang > Andrew Sullivan > Bjoern Hoehrmann > Yoshiro Yoneya > B: No, that should not be allowed. > C: I have another opinion, which is.... > Kari Hurtta > Charles Lindsey > > Based on this result, I am declaring this question closed. This question has two premises: 1. That a message/utf8smtp should be transportable in the current SMTP environment. 2. That encoding of message/utf8smtp will be necessary in that environment. Since these two premises are mutually incompatible, the question as asked is meaningless. I shall address these issues in terms of the new draft-ietf-eai-utf8headers-06.txt. 1.2. Relation to other standards This document updates section 6.4 of RFC 2045. It removes the blanket ban on applying a content-transfer-encoding to all subtypes of message/, and instead specifies that a composite subtype MAY specify whether or not a content-transfer-encoding can be used for that subtype, with "cannot be used" as the default. This document also update [RFC2822] and MIME, and the fact that an experimental specification updates a standards-track spec means that people who participate in the experiment have to consider those standards updated. The second of those paragraphs is fine; it is what we have been saying and doing all along. But you just cannot write that first paragraph in an Experimental RFC, because it requires/expects changed behaviour from those NOT participating in the experiment. 4.6. message/utf8smtp The second type, used for content return, is message/utf8smtp which is similar to message/rfc822, except it contains a message with UTF-8 headers. This type has profound implications on the email infrastructure. First, [RFC3501] servers MUST NOT descend a message/ utf8smtp when generating the message BODYSTRUCTURE, it is likely a new variant on BODYSTRUCTURE will be necessary that does descend message/utf8smtp body parts. Second, if this type is sent to a 7-bit-only system, it could be encoded in [RFC2045].... Note that this applies principally to MTAs which find themselves forwarding the message to an environment which does not support 8BITMIME [RFC 1652] - I am less concerned what happens at 7-bit MUAs. It is to be noted here that the change you have made to RFC 2045 has, as a side effect, changed the meaning of RFC 1652, which contains the wording "the resulting message must be valid 7bit MIME" since you have just changed the definition of valid 7bit MIME. This needs to be pointed out. ........ (Note that a system compliant with MIME that doesn't recognize message/utf8smtp would treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].) But that is simply NOT TRUE. As has already been pointed out, the wording in RFC 2046 regarding the treatment of unrecognized types as application/octet-stream was clearly intended, from the way it is worded, to apply to end-points such as MUAs, and relates solely to the manner of disposition of the unrecognixed type (hence the advice to offer to place it in a file). It was never intended to apply to RFC 1652, because any current agent adopting that behaviour would be in clear violation of the sentence I have quoted (I think we may assume that, in those days, there was not the modern distinction between "must" and "MUST"). Now if it were shown to be the case that a substantial part of the currently installed MTAs did in fact violate RFC 1652 (and hence RFC 2045) in that way, then I might well be persuaded to take a different view of the matter. But in actuallity there is not a shred of evidence for such current practice. I am not aware of a single current MTA that would treat a message/utf8smtp in that fashion, whereas several examples have been pointed out that will not. Therefore the bald words you have written "a system compliant with MIME that doesn't recognize message/utf8smtp would treat it as "application/octet-stream" are quite out of order. ......... Alternatively, SMTP servers and other systems which transfer a message/utf8smtp body part MAY choose to down- convert it to a message/rfc822 body part using the rules described in [EAI-downgrading]. But, on a more cheerful note, I am glad to see that last sentence. AFAICS, this matter can be resolved in one of the following ways: 1. Admit up front that current MTAs may fail to handle a message/utf8smtp when forwarding it to a non-8BITMIME system, and that this is considered an acceptablle risk during the experiment on the grounds that non-8BITMIME systems are exceedigly rare nowadays. 2. State that current agents MAY encode a message/utf8smtp in the manner you have suggested, or alternatively they MAY "just send 8bits", or alternatively they MAY bounce them (not much use if the Return-Path is '<>'), or finally they MAY downgrade them to message/rfc822 (but an agent smart enough to do that would likely be giving full UTF8SMTP support anyway). 3. Define a REQUIRED downgrade from message/utf8smtp to message rfc822 before the message leaves the UTF8SMTP environment. 4. Revert to to one of the earlier suggestions to use an application type or to use message/rfc822 rather than message/utf8smtp. BUT, if the matter cannot be resolved in one of those ways, or in yet some other way, then I give notice that I shall raise a Formal Objection at IETF Last Call. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jul 10 14:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8KEu-0003DB-N6; Tue, 10 Jul 2007 14:15:08 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I8KEo-0003Bx-NW for ima-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 14:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8KEo-0003BV-A0; Tue, 10 Jul 2007 14:15:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8KEo-00066B-2y; Tue, 10 Jul 2007 14:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 023B0329F1; Tue, 10 Jul 2007 18:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8KEn-0000WS-RN; Tue, 10 Jul 2007 14:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 14:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-mailinglist-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Mailing Lists and Internationalized Email Addresses Author(s) : R. Gellens, E. Chung Filename : draft-ietf-eai-mailinglist-02.txt Pages : 15 Date : 2007-7-10 This document describes considerations for mailing lists with the introduction of internationalized email addressing capabilities. Different scenarios involving interaction between mailing lists and internationalized email addresses are examined. Furthermore, mailing list header fields are discussed. This document makes specific recommendations on how mailing lists should act in various situations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-mailinglist-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-mailinglist-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10130553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-mailinglist-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-mailinglist-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10130553.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Wed Jul 11 00:48:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8U7g-0002Wc-63; Wed, 11 Jul 2007 00:48:20 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1I8U7e-0002WX-Ti for ima-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 00:48:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8U7e-0002WP-Hd for ima@ietf.org; Wed, 11 Jul 2007 00:48:18 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8U7W-0005zO-Va for ima@ietf.org; Wed, 11 Jul 2007 00:48:18 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l6B4lZwG028690 for ; Wed, 11 Jul 2007 13:47:35 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007071113473511249 for ; Wed, 11 Jul 2007 13:47:35 +0900 Date: Wed, 11 Jul 2007 13:47:35 +0900 (JST) Message-Id: <20070711.134735.104032526.fujiwara@jprs.co.jp> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Subject: [EAI] example fix for draft-ietf-eai-downgrade-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I missed updating exaples on downgrade-04 document. Please check attached example fix for downgrade-04. I'm working on text for the next version to respond to the list discussion about trivial downgrading with a clarification. changes from 04 to 05 will be: - fixed examples - ALT-ADDRESS parameter mistake - RFC2047(x) notation was changed to =?UTF-8?Q?x?= - Add "Trivial downgrading" inside "Implementation notes" section. Regards, -- Kazunori Fujiwara, JPRS ---------------------------------------------------------------------------- Appendix B. Examples B.1. Downgrading example 1 This section shows an SMTP Downgrading example. Consider a downgradable mail message. o The sender address is "NON-ASCII-FROM" which is non-ASCII address. Its ASCII alternative is "ASCII-FROM". o The "To" address is "NON-ASCII-TO" which is non-ASCII address. Its ASCII alternative is "ASCII-TO". o The "CC" address is non-ASCII address "NON-ASCII-CC" without alternative US-ASCII address. o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII characters. The example SMTP envelope/message is showin in Figure 3. MAIL From: ALT-ADDRESS=ASCII-FROM RCPT TO: ALT-ADDRESS=ASCII-TO RCPT TO: ------------------------------------------------------------- Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: NON-ASCII-SUBJECT From: > To: > CC: Date: DATE MAIL_BODY Figure 3: Original envelope/message (example 1) In this example, there are two SMTP recipients, one is To:, the other is CC:. In this example, assume the Cc: recipient's MTA supports UTF8SMTP and the To: recipient's MTA does not support UTF8SMTP. The SMTP downgrading treats To: session downgrading. Figure 4 shows SMTP downgraded example. MAIL From: RCPT TO: ------------------------------------------------------------- Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= Envelope-Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO=3E?= Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: NON-ASCII-SUBJECT From: > To: > CC: Date: DATE MAIL_BODY Figure 4: SMTP Downgraded envelope/message (example 1) After SMTP downgrading, header fields downgrading is performed. Final downgraded message is shown in Figure 5. Return-Path header will be added by the final destination MTA. Return-Path: Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= Envelope-Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO=3E?= Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM?= > From: Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO?= > To: Downgraded: CC: =?UTF-8?Q?=3CNON-ASCII-CC=3E?= CC: Internationalized address =?UTF-8?Q?NON-ASCII-CC?= removed:; Date: DATE MAIL_BODY Figure 5: Downgraded message (example 1) B.2. Displaying example Figure 6 shows MIME decoded message of Figure 5. Return-Path: Envelope-Downgraded: From: Envelope-Downgraded: To: Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: NON-ASCII-SUBJECT Downgraded: From: > From: Downgraded: To: > To: Downgraded: CC: CC: Internationalized address NON-ASCII-CC removed:; Date: DATE MAIL_BODY Figure 6: MIME decoded message B.2.1. Displaying technique 1 example After removing 'Downgraded:' from decoded 'Downgraded:' header fields Return-Path: Envelope-Downgraded: From: Envelope-Downgraded: To: Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: NON-ASCII-SUBJECT From: > From: To: > To: CC: CC: Internationalized address NON-ASCII-CC removed:; Date: DATE MAIL_BODY Figure 7: Displaying technique 1 B.2.2. Displaying technique 2 example This example shows displaying process of Appendix A.2 for Figure 5. First, check 'Downgraded:' header existence. Downgraded: From: > Downgraded: To: > Downgraded: CC: Figure 8: Displaying technique 2: selecting Downgraded header fields Apply header fields downgrading to the decoded header without re- generating Downgraded: header. From: To: CC: Internationalized address =?UTF-8?Q?NON-ASCII-CC?= removed:; Figure 9: Displaying technique 2: downgraded decoded 'Downgraded:' Remove the header line which is the same with the downgraded line. If the headers contain [RFC2047] encoded part, decode it before comparison. Return-Path: Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= Envelope-Downgraded: To: =?UTF-8?Q?=3CNON-ASCII-TO=3E?= Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= Downgraded: From: > Downgraded: To: > Downgraded: CC: > Date: DATE MAIL_BODY Figure 10: Displaying technique 2: Removing duplicated headers Decode each 'Downgraded' header and replace it with its decoded header. If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. Return-Path: Envelope-Downgraded: From: Envelope-Downgraded: To: Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: UTF-8_SUBJECT From: > To: > CC: > Date: DATE MAIL_BODY Figure 11: Display technique 2: decoded message As a result, in this simple example, all original header fields are displayed in the original form. B.3. Downgrading example 2 In many cases, the sender wants to use non-ASCII address, the recipient does not support UTF8SMTP and does not have non-ASCII address. o The sender address is "NON-ASCII-FROM" which is non-ASCII address. Its ASCII alternative is "ASCII-FROM". o The "To" address is "ASCII-TO" which is ASCII only. o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII characters. The second example envelope/message is shown in Figure 12. MAIL From: ALT-ADDRESS=ASCII-FROM RCPT TO: ------------------------------------------------------------- Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: NON-ASCII-SUBJECT From: > To: Date: DATE MAIL_BODY Figure 12: Original message (example 2) In this example, SMTP session is downgradable. Figure 13 shows SMTP downgraded envelope/message. MAIL From: RCPT TO: ------------------------------------------------------------- Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: NON-ASCII-SUBJECT From: > To: Date: DATE MAIL_BODY Figure 13: SMTP Downgraded envelope/message (example 2) After SMTP downgrading, header fields downgrading is performed. The downgraded example is shown in Figure 14. Return-Path: Envelope-Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM=3E?= Message-Id: MESSAGE_ID Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= Downgraded: From: =?UTF-8?Q?=3CNON-ASCII-FROM?= > From: To: Date: DATE MAIL_BODY Figure 14: Downgraded message (example 2) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jul 15 13:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA8E1-0002IS-Q1; Sun, 15 Jul 2007 13:49:41 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IA8E0-0002IM-Le for ima-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 13:49:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA8E0-0002IE-BL for ima@ietf.org; Sun, 15 Jul 2007 13:49:40 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA8Dl-00061d-1C for ima@ietf.org; Sun, 15 Jul 2007 13:49:40 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E3092596EE; Sun, 15 Jul 2007 19:48:52 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14774-06; Sun, 15 Jul 2007 19:48:47 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED6D52596EC; Sun, 15 Jul 2007 19:48:46 +0200 (CEST) Date: Sun, 15 Jul 2007 19:47:36 +0200 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: Re: [EAI] FINAL POLL RESULTS on the "what MIME type" question Message-ID: <909F39D5441E6B0A61F10DA4@[192.168.1.119]> In-Reply-To: References: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 7. juli 2007 22:20 +0100 Charles Lindsey wrote: >> Based on this result, I am declaring this question closed. > > This question has two premises: > > 1. That a message/utf8smtp should be transportable in the current SMTP > environment. > 2. That encoding of message/utf8smtp will be necessary in that > environment. > > Since these two premises are mutually incompatible, the question as asked > is meaningless. I shall address these issues in terms of the new > draft-ietf-eai-utf8headers-06.txt..... Charles, you have made these arguments many times. I cannot see that you are bringing any argument to the discussion that you have not brought before. The fact that the great majority of the respondents on this poll responded as they did means that they did not find your previous statements convincing. Repeating them is not likely to change anyone's minds. This issue is declared closed. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jul 20 13:31:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwJr-00021Z-CE; Fri, 20 Jul 2007 13:31:11 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IBwJq-00021U-Bk for ima-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 13:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwJq-00021M-2H for ima@ietf.org; Fri, 20 Jul 2007 13:31:10 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBwJo-0003dV-E9 for ima@ietf.org; Fri, 20 Jul 2007 13:31:10 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DB882596E1 for ; Fri, 20 Jul 2007 19:31:07 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27166-05 for ; Fri, 20 Jul 2007 19:31:00 +0200 (CEST) Received: from [10.71.13.238] (unknown [38.114.142.252]) by eikenes.alvestrand.no (Postfix) with ESMTP id 88C422596CD for ; Fri, 20 Jul 2007 19:30:59 +0200 (CEST) Date: Fri, 20 Jul 2007 08:19:35 -0700 From: Harald Tveit Alvestrand To: EAI WG Message-ID: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [EAI] MIME type selection - finishing the process X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The poll result on the MIME type name ended up with a fairly inconclusive result, with quite a few names having multiple people on both the "good" and "bad" sides. Here is the list of candidates, culled according to the following criteria: - At least 2 people need to say "good" - More people need to say "good" than "bad" That leaves us with: A: message/utf8smtp (5:2) B: message/i18n (3:1) C: message/international (6:1) D: message/global (5:1) E: message/mail (3:0) F: message/i18n-email (5:0) G: message/eai (5:0) H: message/utf8eai (4:0) I: message/utf8-email (4:0) J: message/ima (2:0) K: message(intl-email (4:0) I'm ignoring the 3 "write-in candidates", since each was proposed by only one participant. I suggest, as an input to the discussion in Chicago and subsequent mailing list discussion, the following procedure: - Each participant ranks the proposals he has an opinion about, in order of preference, and sends that to the mailing list. (It's OK to not give an opinion for all proposals.) - The chairs will perform an Instant Runoff Voting algorithm on the ranked lists. The procedure for Instant Runoff Voting is: - We count the number of "first" positions for each candidate - If there is more than 50% for one candidate, that is the winner - If not, the candidate with the least "first" position is removed from all ballots, and on the ballots with that in the first place, the second choice is moved up to first place. (If there are no more candidates, discard ballot.) - Repeat until a winner is found The nice thing about this method is that people need to "vote" only once, and it's guaranteed to produce a result no matter what the distribution is. In this particular issue, I think making a decision is more important than what decision is made - so even though we do not do voting in the IETF, making the pick based on an opinion poll of active email participants is better than not making a choice at all. Comments? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jul 22 15:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICgxi-00035L-Rl; Sun, 22 Jul 2007 15:19:26 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ICgxh-00035F-Li for ima-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 15:19:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICgxh-000356-B2 for ima@ietf.org; Sun, 22 Jul 2007 15:19:25 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICgxg-0000EX-Lk for ima@ietf.org; Sun, 22 Jul 2007 15:19:25 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1ICgxf-0003p7-Bw; Sun, 22 Jul 2007 15:19:23 -0400 Date: Sun, 22 Jul 2007 15:19:21 -0400 From: John C Klensin To: Harald Tveit Alvestrand , EAI WG Subject: Re: [EAI] MIME type selection - finishing the process Message-ID: <3BD4BE47F32C6381EC189877@[172.28.168.244]> In-Reply-To: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> References: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 20 July, 2007 08:19 -0700 Harald Tveit Alvestrand wrote: > The poll result on the MIME type name ended up with a fairly > inconclusive result, with quite a few names having multiple > people on both the "good" and "bad" sides. > > Here is the list of candidates, culled according to the > following criteria: > - At least 2 people need to say "good" > - More people need to say "good" than "bad" > > That leaves us with: > > A: message/utf8smtp (5:2) > B: message/i18n (3:1) > C: message/international (6:1) > D: message/global (5:1) > E: message/mail (3:0) > F: message/i18n-email (5:0) > G: message/eai (5:0) > H: message/utf8eai (4:0) > I: message/utf8-email (4:0) > J: message/ima (2:0) > K: message(intl-email (4:0) Preferences: 1 E 2 C 3 D 4 K For me and given this list, there is a large preference gap between 1 and 2 and all of the others (i.e. past preference 4) fall into the "disaster we almost certainly will regret later" category. > I suggest, as an input to the discussion in Chicago and > subsequent mailing list discussion, the following procedure: > > - Each participant ranks the proposals he has an opinion > about, in order of preference, and sends that to the mailing > list. (It's OK to not give an opinion for all proposals.) >... > - We count the number of "first" positions for each candidate > - If there is more than 50% for one candidate, that is the > winner > - If not, the candidate with the least "first" position is > removed from all ballots, and on the ballots with that in the > first place, the second choice is moved up to first place. (If > there are no more candidates, discard ballot.) The difficulty with this plan is that some of us feel much more negatively about some options than we feel positively about others. For example, given a choice between anything containing the string "UTF-8" (with or without a hyphen), I prefer any other option, including things that are not on the list such as message/2008. > The nice thing about this method is that people need to "vote" > only once, and it's guaranteed to produce a result no matter > what the distribution is. Perhaps the wrong one :-(. Incidentally, if anyone might be amused by less crude statistics, I spent an hour before I left trying to see if multidimensional scaling would produce a clear winner from the original poll. It does not, but it produces some interesting rankings, especially if one ranks the "bad"s more strongly than the "goods" > In this particular issue, I think making a decision is more > important than what decision is made - so even though we do > not do voting in the IETF, making the pick based on an opinion > poll of active email participants is better than not making a > choice at all. Agree. But I'd like to see a process that weights "Hate this because..." more strongly than "like that": there are some substantive issues in this name and, as with "Punycode" when we pick something techie/geeky on the assumption that users won't see it, we often turn out to regret that. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jul 23 05:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICu02-0000Sb-7x; Mon, 23 Jul 2007 05:14:42 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ICu00-0000SW-G6 for ima-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 05:14:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICu00-0000SO-2v for ima@ietf.org; Mon, 23 Jul 2007 05:14:40 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ICtzz-0006vH-1K for ima@ietf.org; Mon, 23 Jul 2007 05:14:39 -0400 Received: (eyou send program); Mon, 23 Jul 2007 17:14:29 +0800 Message-ID: <385182069.03304@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [218.241.111.1]) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 23 Jul 2007 17:14:29 +0800 Message-ID: <46A47176.2080600@cnnic.cn> Date: Mon, 23 Jul 2007 17:14:30 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.5 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] absence for WG meeting@IETF69 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@cnnic.cn List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear all EAI colleagues, It's pity that I cannot get visa to US, so only Harald will chair this WG meeting, hope you have a nice time in Chicago. Regards! -- -- Xiaodong LEE [The best answer is doing] +86-10-58813020 mailto:lee@cnnic.cn http://www.lixiaodong.cn _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jul 23 06:02:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICuk9-0005jG-GB; Mon, 23 Jul 2007 06:02:21 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ICuk8-0005jA-Ol for ima-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 06:02:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICuk8-0005j2-E7 for ima@ietf.org; Mon, 23 Jul 2007 06:02:20 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICuk7-0007rZ-Gj for ima@ietf.org; Mon, 23 Jul 2007 06:02:19 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3#clerew*man*ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46a47ca9.a044.2a5 for ima@ietf.org; Mon, 23 Jul 2007 11:02:17 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l6NA2FrG015565 for ; Mon, 23 Jul 2007 11:02:16 +0100 (BST) To: IMA Subject: Re: [EAI] MIME type selection - finishing the process References: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> Message-ID: Date: Mon, 23 Jul 2007 11:02:15 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 20 Jul 2007 16:19:35 +0100, Harald Tveit Alvestrand wrote: > The poll result on the MIME type name ended up with a fairly > inconclusive result, with quite a few names having multiple people on > both the "good" and "bad" sides. > > Here is the list of candidates, culled according to the following > criteria: > - At least 2 people need to say "good" > - More people need to say "good" than "bad" > > That leaves us with: > > A: message/utf8smtp (5:2) > B: message/i18n (3:1) > C: message/international (6:1) > D: message/global (5:1) > E: message/mail (3:0) > F: message/i18n-email (5:0) > G: message/eai (5:0) > H: message/utf8eai (4:0) > I: message/utf8-email (4:0) > J: message/ima (2:0) > K: message(intl-email (4:0) 1. F 2. K 3. I 4. A 5. B 6. C 7. D 8. E 9. H 10.G 11.J -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jul 23 09:37:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICy66-0001i8-OU; Mon, 23 Jul 2007 09:37:14 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ICy64-0001hy-9x for ima-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 09:37:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICy63-0001hq-Vm for ima@ietf.org; Mon, 23 Jul 2007 09:37:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICy63-0005Iz-Kw for ima@ietf.org; Mon, 23 Jul 2007 09:37:11 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6NDbADK024148 for ; Mon, 23 Jul 2007 13:37:10 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLM00801W5H4A00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 23 Jul 2007 07:37:10 -0600 (MDT) Received: from [10.1.110.5] (dhcp-1572.ietf69.org [130.129.21.114]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLM003E3WHWAH00@mail-amer.sun.com> for ima@ietf.org; Mon, 23 Jul 2007 07:37:10 -0600 (MDT) Date: Mon, 23 Jul 2007 08:37:48 -0500 From: Chris Newman Subject: Re: [EAI] MIME type selection - finishing the process In-reply-to: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> To: EAI WG Message-id: <3D415D090417DCF034B64093@dhcp-1572.ietf69.org> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote on 7/20/07 8:19 -0700: > A: message/utf8smtp (5:2) > B: message/i18n (3:1) > C: message/international (6:1) > D: message/global (5:1) > E: message/mail (3:0) > F: message/i18n-email (5:0) > G: message/eai (5:0) > H: message/utf8eai (4:0) > I: message/utf8-email (4:0) > J: message/ima (2:0) > K: message(intl-email (4:0) 1. C 2. D 3. K 4. E 5. I 6. F 7. B 8. H 9. G 10. J I concur making a decision is more important than the name. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jul 23 09:55:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyNJ-0005LR-R0; Mon, 23 Jul 2007 09:55:01 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ICyNI-0005H9-EZ for ima-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 09:55:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyNI-0005Fk-3o for ima@ietf.org; Mon, 23 Jul 2007 09:55:00 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICyNH-0005nd-KT for ima@ietf.org; Mon, 23 Jul 2007 09:55:00 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6NDshtH024258; Mon, 23 Jul 2007 16:54:56 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 16:54:40 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 16:54:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [EAI] MIME type selection - finishing the process Date: Mon, 23 Jul 2007 16:54:17 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157D2C86A@esebe199.NOE.Nokia.com> In-Reply-To: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [EAI] MIME type selection - finishing the process Thread-Index: AcfK88cB9mzNu+1XQbugHfmT56fNsACPHS2w References: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> From: To: , X-OriginalArrivalTime: 23 Jul 2007 13:54:39.0982 (UTC) FILETIME=[038A10E0:01C7CD31] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A: message/utf8smtp (5:2) B: message/i18n (3:1) C: message/international (6:1) D: message/global (5:1) E: message/mail (3:0) F: message/i18n-email (5:0) G: message/eai (5:0) H: message/utf8eai (4:0) I: message/utf8-email (4:0) J: message/ima (2:0) K: message(intl-email (4:0) 1. C 2. K 3. I 4. F 5. A 6. E 7. D 8. B 9. J 10. G 11. H _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jul 23 10:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyqO-0000Op-Bs; Mon, 23 Jul 2007 10:25:04 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ICyqN-0000Ok-Nn for ima-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 10:25:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyqN-0000ON-BW for ima@ietf.org; Mon, 23 Jul 2007 10:25:03 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICyqN-0006Rm-0i for ima@ietf.org; Mon, 23 Jul 2007 10:25:03 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 246D02596D8 for ; Mon, 23 Jul 2007 16:25:02 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16532-02 for ; Mon, 23 Jul 2007 16:24:52 +0200 (CEST) Received: from [172.28.172.61] (unknown [130.129.80.246]) by eikenes.alvestrand.no (Postfix) with ESMTP id 639272580CC for ; Mon, 23 Jul 2007 16:24:52 +0200 (CEST) Date: Mon, 23 Jul 2007 09:23:36 -0500 From: Harald Tveit Alvestrand To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [EAI] Please - Don't state preferences yet! X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Note - my message was intended to start the discussion on the subject on how to decide on a MIME type. I am NOT recording people's position until we've decided what mechanism to use to decide! This is an agenda item for Chicago. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jul 23 19:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7l5-0006cd-GV; Mon, 23 Jul 2007 19:56:11 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ID7l3-0006Vf-PZ for ima-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 19:56:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7l3-0006SJ-Bf for ima@ietf.org; Mon, 23 Jul 2007 19:56:09 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID7l2-00069f-Lh for ima@ietf.org; Mon, 23 Jul 2007 19:56:09 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8195B2596D7 for ; Tue, 24 Jul 2007 01:56:07 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31129-10 for ; Tue, 24 Jul 2007 01:55:58 +0200 (CEST) Received: from htat43p-no.corp.google.com (unknown [130.129.81.128]) by eikenes.alvestrand.no (Postfix) with ESMTP id B632D2596D8 for ; Tue, 24 Jul 2007 01:55:57 +0200 (CEST) Date: Mon, 23 Jul 2007 18:54:33 -0500 From: Harald Tveit Alvestrand To: EAI WG Message-ID: <15C383437E658781840C1884@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [EAI] Draft agenda, EAI WG meeting, Chicago X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Note: I have not merged in issues listed in the tracker. This needs to be done. ---------------------------------------------- AGENDA for the Email Address Internationalization (EAI) WG Date: THURSDAY, July 26, 2007 Time: 0900-1130 Place: Red Lacquer Room 0900: Agenda bashing, selection of scribes, blue sheets 0910: Status update (chair) - SMTPEXT and UTF8HEADERS believed to be ready - DSN, POP and Mailinglist has seen an absence of discussion - Downgrade nearly ready, some open issues 0920: SMTPExt status and open issues - Are we ready for WG Last Call? 0930: UTF8Headers status and open issues - Are we ready for WG Last Call? 0940: DSN status and open issues - Are we ready for WG Last Call? 1000: Downgrade status and open issues - Downgrade: header fields - issues with multiple occurences of the same header field in a header - Handling of unknown header fields - to remove or not to remove? - Downgrading messages with some header addresses that don't have alt-addr: is the group syntax an acceptable solution? What are the consequences of using it in practice? - Are we ready for WG Last Call? 1030: POP status and open issues 1040: Mailinglist status and open issues 1100: Timeline of finishing our work - What dates are realistic? - What commitment do we need from WG members? - Do we need to plan to meet in Vancouver? 1115: Summary of action items 1130: Close of meeting Active Documents: draft-ietf-eai-downgrade-04 2007-07-06 Active draft-ietf-eai-dsn-02 2007-07-02 Active draft-ietf-eai-mailinglist-02 2007-07-10 Active draft-ietf-eai-pop-02 2007-07-06 Active draft-ietf-eai-smtpext-07 2007-06-29 Active draft-ietf-eai-utf8headers-06 2007-07-05 Active Documents with no recent activity: draft-ietf-eai-imap-utf8-01 2007-03-07 Active draft-ietf-eai-scenarios-02 2007-02-26 Active _______________________________________________ EAI-DT mailing list EAI-DT@alvestrand.no http://www.alvestrand.no/mailman/listinfo/eai-dt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jul 24 07:35:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDIfI-0001hT-Ke; Tue, 24 Jul 2007 07:34:56 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDIfH-0001hH-Mj for ima-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 07:34:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDIfG-0001h5-Qu for ima@ietf.org; Tue, 24 Jul 2007 07:34:55 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDIfF-0003VN-CK for ima@ietf.org; Tue, 24 Jul 2007 07:34:54 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew$man&ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46a5e3da.454b.121 for ima@ietf.org; Tue, 24 Jul 2007 12:34:50 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l6OBYocA016403 for ; Tue, 24 Jul 2007 12:34:51 +0100 (BST) Date: Tue, 24 Jul 2007 12:34:49 +0100 To: IMA Subject: Re: [EAI] Please - Don't state preferences yet! References: From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 23 Jul 2007 15:23:36 +0100, Harald Tveit Alvestrand wrote: > Note - my message was intended to start the discussion on the subject on > how to decide on a MIME type. I am NOT recording people's position until > we've decided what mechanism to use to decide! Ah! The methods you have proposed is known as "Alternative Vote", or "AV". It usually works fine, but can sometimes go completely wrong. For example, in the Lilliput Referendum to decide on which end an egg should be opened, the alternatives were: Big-Endian Little-Endian Scrambled-egg Naturally, the Big-Endians all voted for Big first and Little last, with Scrambled in the middle. The Little-Endians all votes for Little first and Big last, with Scrambled in the middle. Only 1 person actually put Scranbled first, and hence it got eliminated from the count, leaving a dead heat between Big and Little. Whereas in fact, if Scrambled has won, everybody would have been reasonably happy (their real desire was to ensure that the other main party failed, rather than that their own succeeded). Hence the compromise got squeezed out. The ideal mathod, designed by the Marquis de Condorcet, copes better with such situations, since it examines the complete matrix of how many people prefer each possible option over each of the others. So with 50 people voting 1. Big, 2. Scrambled, 3. Little and 50 people voting 1. Little, 2. Scrambled, 3. Big and 1 person voting 1. Scrambled 2. [don't care between B and L] you get the matrix B S L B - 50 50 S 50 - 50 L 51 51 - And Scrambled wins because it was preferred over Big by 51:50 and it was preferred ov Little by 51:50. The Condorcet can result in a tie (but so can AV). And it can also result in a cycle (but very rarely does, and when it does it indicates a totally confused electorate). I have a program, written in C, that will work it all out, which I can supply on request. For example, on the group of people who have voted so far (which is not terribly meaningful, given that lots more people have not yet voted at all), my program would give: K: message/intl-email--------------------------------------------------------+ J: message/ima------------------------------------------------------------+ | I: message/utf8-email--------------------------------------------------+ | | H: message/utf8eai--------------------------------------------------+ | | | G: message/eai---------------------------------------------------+ | | | | F: message/i18n-email-----------------------------------------+ | | | | | E: message/mail--------------------------------------------+ | | | | | | D: message/global---------------------------------------+ | | | | | | | C: message/international-----------------------------+ | | | | | | | | B: message/i18n-----------------------------------+ | | | | | | | | | A: message/utf8smtp----------------------------+ | | | | | | | | | | | | | | | | | | | | | Klensin - - 2 3 1 - - - - - 4 Lindsey 4 5 6 7 8 1 10 9 3 11 2 Newman - 7 1 2 4 6 9 8 5 10 3 Zoltan 5 8 1 7 6 4 10 11 3 9 2 RESULT: C: message/international is preferred to A: message/utf8smtp by 3 : 1 C: message/international is preferred to B: message/i18n by 3 : 1 C: message/international is preferred to D: message/global by 4 : 0 C: message/international is preferred to E: message/mail by 3 : 1 C: message/international is preferred to F: message/i18n-email by 3 : 1 C: message/international is preferred to G: message/eai by 4 : 0 C: message/international is preferred to H: message/utf8eai by 4 : 0 C: message/international is preferred to I: message/utf8-email by 3 : 1 C: message/international is preferred to J: message/ima by 4 : 0 C: message/international is preferred to K: message/intl-email by 3 : 1 C: message/international is therefore a condorcet winner The following matrix shows the votes in more detail. The number at [row,column] indicates the number of voters who placed the [row] option ahead of the [column] option in their order of preference K: message/intl-email--------------------------------------------------+ | J: message/ima----------------------------------------------------+ | | | I: message/utf8-email----------------------------------------+ | | | | | H: message/utf8eai--------------------------------------+ | | | | | | | G: message/eai-------------------------------------+ | | | | | | | | | F: message/i18n-email-------------------------+ | | | | | | | | | | | E: message/mail--------------------------+ | | | | | | | | | | | | | D: message/global-------------------+ | | | | | | | | | | | | | | | C: message/international-------+ | | | | | | | | | | | | | | | | | B: message/i18n-----------+ | | | | | | | | | | | | | | | | | | | A: message/utf8smtp--+ | | | | | | | | | | | | | | | | | | | | +----------------- \\ 2 1 2 2 0 2 2 0 2 0 | | | | | | | | | +------------------- 1 \\ 1 1 1 0 3 3 0 3 0 | | | | | | | | +--------------------- 3 3 \\ 4 3 3 4 4 3 4 3 | | | | | | | +----------------------- 2 3 0 \\ 2 2 4 4 2 4 2 | | | | | | +------------------------- 2 3 1 2 \\ 2 4 4 2 4 1 | | | | | +--------------------------- 3 3 1 2 2 \\ 3 3 1 3 1 | | | | +----------------------------- 1 0 0 0 0 0 \\ 1 0 2 0 | | | +------------------------------- 1 0 0 0 0 0 2 \\ 0 2 0 | | +--------------------------------- 3 3 1 2 2 2 3 3 \\ 3 0 | +----------------------------------- 1 0 0 0 0 0 1 1 0 \\ 0 +------------------------------------- 4 4 1 2 3 3 4 4 4 4 \\ The second matrix shows the effect of subtracting [column,row] from [row.column] so as to give the majority in favour of [row] as against [column]. Observe that the winning row(s) has no negative entries. K: message/intl-email--------------------------------------------------+ | J: message/ima----------------------------------------------------+ | | | I: message/utf8-email----------------------------------------+ | | | | | H: message/utf8eai--------------------------------------+ | | | | | | | G: message/eai-------------------------------------+ | | | | | | | | | F: message/i18n-email-------------------------+ | | | | | | | | | | | E: message/mail--------------------------+ | | | | | | | | | | | | | D: message/global-------------------+ | | | | | | | | | | | | | | | C: message/international-------+ | | | | | | | | | | | | | | | | | B: message/i18n-----------+ | | | | | | | | | | | | | | | | | | | A: message/utf8smtp--+ | | | | | | | | | | | | | | | | | | | | +----------------- \\ 1 -2 0 0 -3 1 1 -3 1 -4 | | | | | | | | | +------------------- -1 \\ -2 -2 -2 -3 3 3 -3 3 -4 | | | | | | | | +--------------------- 2 2 \\ 4 2 2 4 4 2 4 2 winner | | | | | | | +----------------------- 0 2 -4 \\ 0 0 4 4 0 4 0 | | | | | | +------------------------- 0 2 -2 0 \\ 0 4 4 0 4 -2 | | | | | +--------------------------- 3 3 -2 0 0 \\ 3 3 -1 3 -2 | | | | +----------------------------- -1 -3 -4 -4 -4 -3 \\ -1 -3 1 -4 | | | +------------------------------- -1 -3 -4 -4 -4 -3 1 \\ -3 1 -4 | | +--------------------------------- 3 3 -2 0 0 1 3 3 \\ 3 -4 | +----------------------------------- -1 -3 -4 -4 -4 -3 -1 -1 -3 \\ -4 +------------------------------------- 4 4 -2 0 2 2 4 4 4 4 \\ -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jul 24 08:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJc1-0004qA-NU; Tue, 24 Jul 2007 08:35:37 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDJc1-0004q1-E1 for ima-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 08:35:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJc1-0004pq-3l for ima@ietf.org; Tue, 24 Jul 2007 08:35:37 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDJc0-00057P-ND for ima@ietf.org; Tue, 24 Jul 2007 08:35:37 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 098952596E4; Tue, 24 Jul 2007 14:35:36 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22185-08; Tue, 24 Jul 2007 14:35:27 +0200 (CEST) Received: from htat43p-no.corp.google.com (unknown [67.97.210.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id 543FE2596E3; Tue, 24 Jul 2007 14:35:27 +0200 (CEST) Date: Tue, 24 Jul 2007 07:34:11 -0500 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: Re: [EAI] Please - Don't state preferences yet! Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 24. juli 2007 12:34 +0100 Charles Lindsey wrote: > On Mon, 23 Jul 2007 15:23:36 +0100, Harald Tveit Alvestrand > wrote: > >> Note - my message was intended to start the discussion on the subject on >> how to decide on a MIME type. I am NOT recording people's position >> until we've decided what mechanism to use to decide! > > Ah! The methods you have proposed is known as "Alternative Vote", or > "AV". It usually works fine, but can sometimes go completely wrong. ..... > > The ideal mathod, designed by the Marquis de Condorcet, copes better with > such situations, since it examines the complete matrix of how many people > prefer each possible option over each of the others. Thanks for the pointer - gives more detail of Concordet voting mechanisms. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jul 24 08:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJpk-00054M-8J; Tue, 24 Jul 2007 08:49:48 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDJpj-00052a-2S for ima-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 08:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJpi-00052Q-Od for ima@ietf.org; Tue, 24 Jul 2007 08:49:46 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDJpi-0006Ds-Fi for ima@ietf.org; Tue, 24 Jul 2007 08:49:46 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1185281384!21881603!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 13942 invoked from network); 24 Jul 2007 12:49:45 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-13.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 24 Jul 2007 12:49:45 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6OCniQG009829 for ; Tue, 24 Jul 2007 05:49:44 -0700 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6OCndfK009818 for ; Tue, 24 Jul 2007 05:49:39 -0700 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6OCndOp016036 for ; Tue, 24 Jul 2007 05:49:39 -0700 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6OCnVYm015972 for ; Tue, 24 Jul 2007 05:49:31 -0700 Received: from [135.210.34.177] (unknown[135.210.34.177](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070724124930gw10010g3se> (Authid: tony); Tue, 24 Jul 2007 12:49:30 +0000 Message-ID: <46A5F55B.5000409@att.com> Date: Tue, 24 Jul 2007 08:49:31 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [EAI] MIME type selection - finishing the process References: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> In-Reply-To: <690D1F65D551443F90D04DA4@B50854F0A9192E8EC6CDA126> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 1 C: message/international (6:1) | D: message/global (5:1) v K: message(intl-email (4:0) F: message/i18n-email (5:0) B: message/i18n (3:1) J: message/ima (2:0) G: message/eai (5:0) I: message/utf8-email (4:0) H: message/utf8eai (4:0) E: message/mail (3:0) A: message/utf8smtp (5:2) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jul 24 09:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKJ8-0000Gh-LX; Tue, 24 Jul 2007 09:20:10 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDKJ7-0000GO-7E for ima-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 09:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKJ6-0000GE-TD for ima@ietf.org; Tue, 24 Jul 2007 09:20:08 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDKJ5-0006w3-8F for ima@ietf.org; Tue, 24 Jul 2007 09:20:08 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 947AD2596E4 for ; Tue, 24 Jul 2007 15:20:06 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23470-03 for ; Tue, 24 Jul 2007 15:20:01 +0200 (CEST) Received: from htat43p-no.corp.google.com (unknown [67.97.210.2]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCF052596DB for ; Tue, 24 Jul 2007 15:20:00 +0200 (CEST) Date: Tue, 24 Jul 2007 08:18:44 -0500 From: Harald Tveit Alvestrand To: EAI WG Message-ID: <3F54DB9D89D9A2C0DC720F54@[172.28.172.61]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [EAI] Issues from the tracker that I believe are resolved X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org In going through the tracker yesterday, I found the following issues that I = believe are either resolved by current text in the documents or punted as=20 matters for which the IETF Trust is clearly given the responsibility of=20 writing text. If the list and the physical WG meeting agree that this is the case, I will = close these items after the meeting. My apologies for not doing so continuously. Please reply with a message with the issue # in the subject line if you=20 want to comment on the disposition of a specific issue. Harald Resolved issues: #1166 Quotations from RFCs and I-Ds Resolved =E2=80=93 permitted #1167 Excerpt labelling: Resolved =E2=80=93 IETF Trust makes rules, with guidance #1168 Non-code excerpts: Resolved =E2=80=93 permitted #1169 Modified non-code excerpts: Resolved =E2=80=93 not permitted #1175 Distinguishing code from non-code Resolved =E2=80=93 type-of-content list + marker mechanism #1199 What licensing to use for outgoing Resolved =E2=80=93 principles decided, details left to trust #1212 Copyright statements in I-Ds and RFCs Resolved =E2=80=93 IETF Trust claims copyright in RFCs only #1237 Should incoming rights be published as 3978 delta or replacement? Resolved =E2=80=93 replacement #1246 Incoming rights: How much should be said about outgoing rights? Resolved =E2=80=93 not much, current text is proposal #1337 Notices and rights in RFC-Editor contributions Resolved: Left to the RFC Editor to document #1400 Right to modify code: Unlimited or restrictable? Resolved: Unlimited Punted issues: #1273 How do we usefully define "excerpt"? Punted: An informal definition seems to be OK =E2=80=93 details left to = Trust. #1282 Should multiple copyright statements be permitted in RFCs and I-Ds? Punted: IETF Trust writes the rules #1338 Notices "normally placed at the end" Punted: Left details of notices to IETF Trust #1339 Does RFC 3978 grant third parties right to modify source? Punted: intent to grant is made clear in new docs, IETF Trust will write=20 new grant text _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jul 24 10:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDL03-0004jw-O6; Tue, 24 Jul 2007 10:04:31 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDL02-0004jn-Cd for ima-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 10:04:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDL01-0004je-PS for ima@ietf.org; Tue, 24 Jul 2007 10:04:30 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDL01-0002nC-Ev for ima@ietf.org; Tue, 24 Jul 2007 10:04:29 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C23282596EA for ; Tue, 24 Jul 2007 16:04:28 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24831-04 for ; Tue, 24 Jul 2007 16:04:24 +0200 (CEST) Received: from htat43p-no.corp.google.com (dhcp-14e2.ietf69.org [130.129.20.226]) by eikenes.alvestrand.no (Postfix) with ESMTP id B4AC82596EC for ; Tue, 24 Jul 2007 16:04:23 +0200 (CEST) Date: Tue, 24 Jul 2007 09:03:05 -0500 From: Harald Tveit Alvestrand To: EAI WG Subject: Re: [EAI] Issues from the tracker that I believe are resolved Message-ID: <8E140F859C8991976B931ABD@htat43p-no.corp.google.com> In-Reply-To: <3F54DB9D89D9A2C0DC720F54@[172.28.172.61]> References: <3F54DB9D89D9A2C0DC720F54@[172.28.172.61]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Apologies for the misdirected message. It was intended for the IPR WG. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jul 25 04:20:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDc6i-0008Sk-Jm; Wed, 25 Jul 2007 04:20:32 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDc6i-0008Sf-39 for ima-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 04:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDc6h-0008SX-MU for ima@ietf.org; Wed, 25 Jul 2007 04:20:31 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDc6g-00080a-7K for ima@ietf.org; Wed, 25 Jul 2007 04:20:31 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IDc6d-000JcA-70; Wed, 25 Jul 2007 04:20:27 -0400 Date: Wed, 25 Jul 2007 04:20:26 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Charles Lindsey , IMA Subject: Re: [EAI] Please - Don't state preferences yet! Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 24 July, 2007 07:34 -0500 Harald Tveit Alvestrand wrote: > > > --On 24. juli 2007 12:34 +0100 Charles Lindsey > wrote: > >> On Mon, 23 Jul 2007 15:23:36 +0100, Harald Tveit Alvestrand >> wrote: >> >>> Note - my message was intended to start the discussion on >>> the subject on how to decide on a MIME type. I am NOT >>> recording people's position until we've decided what >>> mechanism to use to decide! >> >> Ah! The methods you have proposed is known as "Alternative >> Vote", or "AV". It usually works fine, but can sometimes go >> completely wrong. > ..... > >> >> The ideal mathod, designed by the Marquis de Condorcet, copes >> better with such situations, since it examines the complete >> matrix of how many people prefer each possible option over >> each of the others. > > Thanks for the pointer - > gives more > detail of Concordet voting mechanisms. Since I used to do election analysis for a living, long ago, the reality is that any of these methods can produce results that are inconsistent with the desires/ intent of those responding, and differ largely by the assumptions one makes about the intent one wants to optimize. Alternate vote optimizes first choices; while there are edge cases (including possibilities for ties) something basically has to be someone's first choice in order to win. Condorcet optimizes one particular preference model. In particular, as Charles's model illustrates very well, it assumes that an option that is everyone's second choice is better than any option that is the first choices of a minority of the voters. As such, one might think of it as one version of the model that a good choice is the one that leaves everyone more or less equally unhappy. It is important to note that any of the systems, including the ones discussed below, get a lot more complicated, with more ways to get into strange cases, as the number of options rises above three. And any of them can be gamed by colluding voters, although some are more easily gamed than others. But there are many other options. For example, in a situation like the one we have, there is a strong argument that one should first examine "I completely hate this" votes, eliminating any options that are intensely disliked by a non-trivial number of people, and only then applying a model based on affirmative preferences to what is left. Some feel that works better in environments in which there is a lot of indifference (as long as an answer is found) but a desire to eliminate really bad choices before one is approved based on weak preferences. This sort of system is often considered bad for elections but good for some other types of preference choices. And then there are a whole series of "weight and scale" techniques, some of them involving explicit elucidation of strength of preferences and giving more weight to those who care. Again, none of these is "right"; they just balance the factors and considerations differently. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jul 25 04:58:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDchb-0000KL-8G; Wed, 25 Jul 2007 04:58:39 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDchZ-0000Hz-6f for ima-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 04:58:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDchY-0000FJ-Q7 for ima@ietf.org; Wed, 25 Jul 2007 04:58:36 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDchY-0005GH-A2 for ima@ietf.org; Wed, 25 Jul 2007 04:58:36 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id DD25B4ACA1; Wed, 25 Jul 2007 10:58:34 +0200 (CEST) Message-Id: Date: Wed, 25 Jul 2007 10:58:39 +0200 From: Arnt Gulbrandsen To: John C Klensin Subject: Re: [EAI] Please - Don't state preferences yet! References: In-Reply-To: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Charles, ima@ietf.org, Lindsey X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes: > For example, in a situation like the one we have, there is a strong > argument that one should first examine "I completely hate this" > votes, eliminating any options that are intensely disliked by a > non-trivial number of people, and only then applying a model based on > affirmative preferences to what is left. +1 But please name/suggest a method that has these properties and wasn't designed by a na=EFve layman. Arnt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jul 25 17:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo9D-0003Rq-9G; Wed, 25 Jul 2007 17:11:55 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDo9C-0003Rb-Bx for ima-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:11:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo9B-0003RO-Q5 for ima@ietf.org; Wed, 25 Jul 2007 17:11:53 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDo9B-0001IM-3I for ima@ietf.org; Wed, 25 Jul 2007 17:11:53 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 66485259718 for ; Wed, 25 Jul 2007 23:11:52 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13372-09 for ; Wed, 25 Jul 2007 23:11:44 +0200 (CEST) Received: from [172.28.172.61] (dhcp-149d.ietf69.org [130.129.20.157]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3AD4725970B for ; Wed, 25 Jul 2007 23:11:44 +0200 (CEST) Date: Wed, 25 Jul 2007 16:10:22 -0500 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <0BF34B9F54A8E6D43E9826A3@htat43p-no.corp.google.com> In-Reply-To: <20070725160214.7B831DAA63@bosco.isi.edu> References: <20070725160214.7B831DAA63@bosco.isi.edu> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [EAI] Re: RFC 4952 on Overview and Framework for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org My heartfelt congratulations and thanks to ALL the working group members who contributed to getting us past this important milestone! And, especially, to our tireless editors. Thank you! Harald --On 25. juli 2007 09:02 -0700 rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 4952 > > > > Title: Overview and Framework for Internationalized > > Email > > Author: J. Klensin, Y. Ko > > Status: Informational > > Date: July 2007 > > Mailbox: john-ietf@jck.com, > > yw@mrko.pe.kr > > Pages: 20 > > Characters: 48409 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-eai-framework-05.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc4952.txt > > > > > > Full use of electronic mail throughout the world requires that people > > be able to use their own names, written correctly in their own > > languages and scripts, as mailbox names in email addresses. This > > document introduces a series of specifications that define mechanisms > > and protocol extensions needed to fully support internationalized > > email addresses. These changes include an SMTP extension and > > extension of email header syntax to accommodate UTF-8 data. The > > document set also includes discussion of key assumptions and issues > > in deploying fully internationalized email. This memo provides > > information for the Internet community. > > > > > > This document is a product of the Email Address Internationalization > > Working Group of the IETF. > > > > > > INFORMATIONAL: This memo provides information for the Internet community. > > It does not specify an Internet standard of any kind. Distribution > > of this memo is unlimited. > > > > This announcement is sent to the IETF list and the RFC-DIST list. > > Requests to be added to or deleted from the IETF distribution list > > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > > added to or deleted from the RFC-DIST distribution list should > > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > > > > help: ways_to_get_rfcs. For example: > > > > To: rfc-info@RFC-EDITOR.ORG > > Subject: getting rfcs > > > > help: ways_to_get_rfcs > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution. > > > > Submissions for Requests for Comments should be sent to > > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > > Authors, for further information. > > > > > > The RFC Editor Team > > USC/Information Sciences Institute > > > > ... > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jul 25 17:16:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoDi-0000Tm-B5; Wed, 25 Jul 2007 17:16:34 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDoDh-0000SG-BH for ima-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:16:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoDh-0000S8-14 for ima@ietf.org; Wed, 25 Jul 2007 17:16:33 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDoDf-0004iI-IB for ima@ietf.org; Wed, 25 Jul 2007 17:16:33 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A230A259718 for ; Wed, 25 Jul 2007 23:16:30 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13690-02 for ; Wed, 25 Jul 2007 23:16:25 +0200 (CEST) Received: from [172.28.172.61] (dhcp-149d.ietf69.org [130.129.20.157]) by eikenes.alvestrand.no (Postfix) with ESMTP id 233E125970B for ; Wed, 25 Jul 2007 23:16:24 +0200 (CEST) Date: Wed, 25 Jul 2007 16:15:08 -0500 From: Harald Tveit Alvestrand To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Status of issue tracker tickets X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I believe the following tickets are resolved, and the resolved consensus text is in the current drafts: Against SMTP: #1483 2.7 Non-ASCII in response texts #1484 2.2: More exact definition of action choices #1486 2.7.2: Message retry #1492 2.7.3: syntax #1493 2.4: Redefining of RCPT TO and MAIL FROM commands (ABNF grammar) #1495 2.5/2.6: Reply code used on DATA Against UTF8HDR: #1487 4.2: Does this specification update MIME? #1488 4.2: List MIME headers that are modified? #1490 4.2: Including Content-Description to picture (grammar) #1491 4.2: Extending MIME (ABNF grammar) #1494 4.4: should include I believe the following tickets are open: #1485 UTF8HDR 4.6/DSN: Choice of body part for transport of UTF8SMTP messages If the physical WG meeting doesn't disagree with me tomorrow, and if there are no mails to the mailing list disagreeing with me tomorrow, I'll close the resolved issues in the tracker tomorrow. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jul 25 18:38:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpVJ-0001N0-Qr; Wed, 25 Jul 2007 18:38:49 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDjLZ-00083U-6d for ima-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 12:04:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjLU-000830-GE; Wed, 25 Jul 2007 12:04:20 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDjLU-0007FG-1Z; Wed, 25 Jul 2007 12:04:16 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 7B831DAA63; Wed, 25 Jul 2007 09:02:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070725160214.7B831DAA63@bosco.isi.edu> Date: Wed, 25 Jul 2007 09:02:14 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Wed, 25 Jul 2007 18:38:48 -0400 Cc: ima@ietf.org, rfc-editor@rfc-editor.org Subject: [EAI] RFC 4952 on Overview and Framework for Internationalized Email X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4952 Title: Overview and Framework for Internationalized Email Author: J. Klensin, Y. Ko Status: Informational Date: July 2007 Mailbox: john-ietf@jck.com, yw@mrko.pe.kr Pages: 20 Characters: 48409 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-eai-framework-05.txt URL: http://www.rfc-editor.org/rfc/rfc4952.txt Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This memo provides information for the Internet community. This document is a product of the Email Address Internationalization Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 00:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDutZ-0003P3-PY; Thu, 26 Jul 2007 00:24:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IDutY-0003Oj-EF for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 00:24:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDutX-0003OP-AH; Thu, 26 Jul 2007 00:24:11 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDutX-0003D1-03; Thu, 26 Jul 2007 00:24:11 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-146.messagelabs.com!1185423848!4932887!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.160.128.149] Received: (qmail 8156 invoked from network); 26 Jul 2007 04:24:09 -0000 Received: from sbcsmtp9.sbc.com (HELO flph024.enaf.ffdc.sbc.com) (144.160.128.149) by server-12.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 26 Jul 2007 04:24:09 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4O8CH014427; Wed, 25 Jul 2007 21:24:08 -0700 Received: from flph023.ffdc.sbc.com (flph023.ffdc.sbc.com [150.234.117.36]) by flph024.enaf.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4O5SD014421; Wed, 25 Jul 2007 21:24:05 -0700 Received: from ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4O5fb009833; Wed, 25 Jul 2007 21:24:05 -0700 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by flph023.ffdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6Q4O1oR009817; Wed, 25 Jul 2007 21:24:02 -0700 Received: from [135.210.96.137] (unknown[135.210.96.137](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070726042243gw10010gs8e> (Authid: tony); Thu, 26 Jul 2007 04:24:01 +0000 Message-ID: <46A82184.7030200@att.com> Date: Thu, 26 Jul 2007 00:22:28 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ietf-822 mailing list X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: LEMONADE WG , POP3 extensions mailing list , USEFOR WG , EAI WG , IMAP extensions mailing list , SMTP Interest Group , SIMPLE WG Subject: [EAI] Mailing List Last Call for 2822 update internet-draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org There have been some comments on draft-resnick-2822upd-* but they have dwindled down to none. This is a "formal" Mailing List Last Call on draft-resnick-2822upd-02.txt. The last call will last for two weeks time, ending on August 10, 2007. The document will be discussed on the 822 mailing list, . Please send your comments there. For a copy of the current draft, you can find it at http://www.ietf.org/internet-drafts/draft-resnick-2822upd-02.txt or http://tools.ietf.org/html/draft-resnick-2822upd Depending on the outcome of the Mailing List Last Call, the next step will be to submit the document (or its revision) to the IESG for IETF-wide Last Call. Thanks! Tony Hansen tony@att.com _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 06:43:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE0o9-000117-8t; Thu, 26 Jul 2007 06:43:01 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE0o7-0000wF-Ma for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 06:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE0o7-0000tN-4R for ima@ietf.org; Thu, 26 Jul 2007 06:42:59 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE0o5-000287-C4 for ima@ietf.org; Thu, 26 Jul 2007 06:42:58 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew*man&ac*uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46a87aaf.3e50.1e for ima@ietf.org; Thu, 26 Jul 2007 11:42:55 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l6QAgtfo015517 for ; Thu, 26 Jul 2007 11:42:56 +0100 (BST) To: IMA Subject: Re: [EAI] Please - Don't state preferences yet! References: Message-ID: Date: Thu, 26 Jul 2007 11:42:54 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 25 Jul 2007 09:20:26 +0100, John C Klensin wrote: > Alternate vote optimizes first choices; while there are edge > cases (including possibilities for ties) something basically has > to be someone's first choice in order to win. > > Condorcet optimizes one particular preference model. In > particular, as Charles's model illustrates very well, it assumes > that an option that is everyone's second choice is better than > any option that is the first choices of a minority of the > voters. As such, one might think of it as one version of the > model that a good choice is the one that leaves everyone more or > less equally unhappy. > > It is important to note that any of the systems, including the > ones discussed below, get a lot more complicated, with more ways > to get into strange cases, as the number of options rises above > three. And any of them can be gamed by colluding voters, > although some are more easily gamed than others. AFAIK, there is no known way of "gaming" the Condorcet system. > > But there are many other options. For example, in a situation > like the one we have, there is a strong argument that one should > first examine "I completely hate this" votes, eliminating any > options that are intensely disliked by a non-trivial number of > people, and only then applying a model based on affirmative > preferences to what is left. Some feel that works better in > environments in which there is a lot of indifference (as long as > an answer is found) but a desire to eliminate really bad choices > before one is approved based on weak preferences. This sort of > system is often considered bad for elections but good for some > other types of preference choices. Yes, and that also relates to the "equally unhappy" idea, which is probably as good as you will ever get when there are extremely polarized opinions. Condorcet gets a little nearer to that than AV, but not entirely so. The main benefit of Condorcet lies in resolving cases where there are a large number of similar cases (e.g. message/international vs message/intl) between which nobody really cares). And it works best when everybody is encouraged to give at least some preference value to _every_ option, even the ones they don't like. We have used Condorcet for creation of Newsgroups in uk.* in cases where there have been disagreements over alternative names or alternative moderation options, and it seems to work well. Nobody understands quite how it works, but when the results are presented clearly, everyone can see, and accept, that it has reached a sensible conclusion (usually, it turns out the way people were expecting it to, and the mavericks who insisted on including the unpopular options on the ballot are easily seen to have attracted no support). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 06:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE10t-0001uS-4x; Thu, 26 Jul 2007 06:56:11 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE10r-0001uI-FH for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 06:56:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE10r-0001uA-46 for ima@ietf.org; Thu, 26 Jul 2007 06:56:09 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE10q-0000gL-M6 for ima@ietf.org; Thu, 26 Jul 2007 06:56:09 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 399AE4AC8F; Thu, 26 Jul 2007 12:56:07 +0200 (CEST) Message-Id: Date: Thu, 26 Jul 2007 12:56:13 +0200 From: Arnt Gulbrandsen To: Charles Lindsey Subject: Re: [EAI] Please - Don't state preferences yet! References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey writes: > AFAIK, there is no known way of "gaming" the Condorcet system. IETF participants aren't exactly notorious for gaming WG decisions. The most important concern (IMO) is that people might spew flames over a result they dislike. Arnt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 08:31:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2VU-0000oM-Lj; Thu, 26 Jul 2007 08:31:52 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE2VT-0000oG-Mz for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 08:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2VS-0000o8-VJ for ima@ietf.org; Thu, 26 Jul 2007 08:31:50 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE2VR-00041x-HD for ima@ietf.org; Thu, 26 Jul 2007 08:31:50 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IE2VN-000Eb7-S3; Thu, 26 Jul 2007 08:31:46 -0400 Date: Thu, 26 Jul 2007 08:31:45 -0400 From: John C Klensin To: Arnt Gulbrandsen Subject: Re: [EAI] Please - Don't state preferences yet! Message-ID: <6BC1C6466605FB744994C7EF@[172.28.168.244]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Charles Lindsey , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 25 July, 2007 10:58 +0200 Arnt Gulbrandsen wrote: > John C Klensin writes: >> For example, in a situation like the one we have, there is a >> strong argument that one should first examine "I completely >> hate this" votes, eliminating any options that are intensely >> disliked by a non-trivial number of people, and only then >> applying a model based on affirmative preferences to what is >> left. >=20 > +1 >=20 > But please name/suggest a method that has these properties and > wasn't designed by a na=C3=AFve layman. Unfortunately, I am a long distance from my library, haven't reread the literature in years (more or less since I stopped teaching it). This is also not a good week for me to try to engage in an extended discussion. For all I know, something new and better has been invented, although the reasons most of the procedures don't work universally can be demonstrated with rather clear mathematics. The key is not to find an universally-optimal method, but to understand that each one measures something slightly different and that, by choosing the method/measure, one can affect the outcome. Charles's recent on-list argument is ultimately close to tautology, something that would be immediately recognizable if he stated it as "Condorcet measures what I consider valid, therefore it works and there are no attacks on it". =20 So, _ because I believe that negative preferences are very important_ --clearly a statement about ideology, not voting/ measurement methods-- I would prefer that we=20 (i) pick a threshold for eliminating noise/ outliers. It turns out to not make a lot of difference what that threshold is. There are scaling techniques to reduce the variance introduced by people who express themselves strongly about everything versus those who don't, but they are time-consuming and rarely worth the trouble in this sort of situation. Given the level of participation in the WG, I'd pick a number greater than 1 and less than 5. (ii) Go through the options and count "I hate this" votes that can be supported with an explanation/ argument that will pass a laugh test. Laugh tests are better administered/validated by judges whom almost everyone believes are fair than by voting. (iii) Drop anything that gets more than the threshold value of "I hate this" votes. (iv) From the rest, pick. It may not make much difference how one picks: Condorcet works well, Alternate Vote works pretty well, and lotteries may work adequately well. Remind me sometime to tell you what we found out about MIT undergraduate admissions -- decisions that have far more effect on people's lives than this sort of thing. It all depends on how much one really cares, how much trouble one wants to go to, and the ideology one holds about what is fair (or about what one wants to optimize). And, like just about everything else that has statistical properties, the results are more satisfying when one has thousands, or even hundreds, of voters (or whatever) in the decision universe than when there are a handful. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 15:20:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8t4-0002Bn-N2; Thu, 26 Jul 2007 15:20:38 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE8t4-00029r-4C for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 15:20:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8t3-00029f-Og for ima@ietf.org; Thu, 26 Jul 2007 15:20:37 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE8t1-0006sQ-RS for ima@ietf.org; Thu, 26 Jul 2007 15:20:37 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew#man*ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 46a8f400.4744.6f for ima@ietf.org; Thu, 26 Jul 2007 20:20:32 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l6QJKUe8018043 for ; Thu, 26 Jul 2007 20:20:32 +0100 (BST) To: ima@ietf.org Date: Thu, 26 Jul 2007 20:20:29 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Subject: [EAI] Comments on draft-ietf-eai-downgrade-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Sorry, I should have got around to commenting on this much earlier, but it only just reached the top of my 'todo' list :-( . > 3. New header fields definition > fields =/ downgraded > downgraded = "Downgraded:" [FWS] field-name ":" unstructured CRLF > Encapsulating a header in a Downgraded: header is defined as: ^ ^ field field > 1. Generate new Downgraded: header whose former value is the > original header field name and latter value is the original > header fleid value. > 2. Encode the generated header by [RFC2047] section 5(1) method with > charset='UTF-8'. > 3. Replace the original header field as the generated header field. That Step 3 does not always apply; for example when the original was a From:/To:/etc field, which then remains (in altered form) in addition to the new Downgraded: > fields =/ edowngraded > edowngraded = "Envelope-Downgraded:" [FWS] edowngraded-field ":" > [FWS] "<" uPath ">" [FWS] > "<" Mailbox ">" [FWS] CRLF > edowngraded-field = "From" / "To" Why not > edowngraded-field = "Mail From" / "Rcpt To" to avoid any possible confusion with the From: and To: headers? > Original non-ASCII address is defined in > [I-D.ietf-eai-smtpext]. is defined in [RFC2821], section > 4.1.2. The "Envelope-Downgraded:" header field is encoded by > [RFC2047] in the downgraded message. I think it is wrong to say (as you do frequently) that 'The "Some-Header:" is encoded by [RFC2047]' RFC2047 encodes carefully regulated _parts_ of header fields (such as s, s and s), never the whole header field. In this case it is the (treated as if it were ) that gets encoded (or maybe even only a part of it - 2047 allows you to split it up in many ways). Your later examples indeed indicate that is what you intend to happen. > 4. SMTP Downgrading > MTA replaces non-ASCII mail address with specified alternative US- > ASCII address when downgrading. Before replacing, decode the ALT- > ADDRESS parameter value because it is encoded as xtest [RFC3461]. Eh? That last sentence only applies to an ORCPT parameter, I think. > Also MTA preserves original information using "Envelope-Downgraded" > header defined in Section 3 with From or To field name. The non- > ASCII mail addresses are encoded by [RFC2047] and put into "Envelope- > Downgraded" header. Yes, that wording is correct, as opposed to what you said about encoding the whole header earlier. > 5. Email header fields downgrading I found the whole of this section very confusing. You have done an exhaustive analysis of lots of particular cases, resulting in much unnecessary repetition, instead of setting out the _principles_ on which the whole thing was based. For example, it is always correct to encode a whatever header it occurs in and whether or not that header contains further stuff (e.g. addresses) that have to be downgraded specially. So you might as well state that once up-front (even in a conceptual first pass over all the headers), rather than mention it as an extra thing to do when performing other more particular downgrade operations. > o Downgrading Address header fields > From: > Sender: > Reply-To: > To: > Cc: > Bcc: > Resent-From: > Resent-Sender: > Resent-To: > Resent-Cc: But that is only the present list. Surely the process you describe MAY also be used for any header defined in the future which contains an etc. The upgrade/display mechanisms you describe in A1 and A2 would work just fine on such headers. > The header field value is composed of single or multiple addr>/ fields defined in > [I-D.ietf-eai-utf8headers]. > If the header has no or which > contains non-ASCII characters, only "display-name" part or > comments contain non-ASCII characters, the "display-name" or > comments are encoded by [RFC2047] with charset='UTF-8'. > Otherwise, preserve the header field in "Downgraded:" header, > generate US-ASCII only address header, and replace the original > header field with the generated US-ASCII only header field. New > header generation method are shown in below. > Extract every field and downgrade each // > . Remove there. The other two are just particular cases of . > If the non-ASCII address is in form, then rewrite ^ (i.e. it contains no ) > it as "Internationalized Address utf8-addr-spec-encoded > Removed:;". "utf8-addr-spec" is encoded to "utf8-addr-spec- > encoded" by [RFC2047]. That is exceedingly confusing until you have worked out what it means. What you really mean to say is: rewrite it as a [RFC2822] of the form Internationalized Address "" Removed: ; where the is the original encoded according to [RFC2047] (and needs to be within a ). That is essential because, for sure, the will have at least an '@' somewhere inside it. And yes, I liked that idea once I had worked out what you were doing. > The field may contain multiple fields. The > fields are encoded by [RFC2047] with charset='UTF-8', if > necessary. Which is an example of the unnecessary repetition I mentioned earlier. > is defined as "display-name " in > [I-D.ietf-eai-utf8headers]. Well no it isn't. What you really meant to say was If the non-ASCII address is in <[display-name] angle-addr> form, then ... The "display-name" field, if present, is encoded > UTF8SMTP defined in [I-D.ietf-eai-utf8headers] > consists of 3 forms. Downgrading method is defined for each form. > * > Non-ASCII mail address without sender-specified US-ASCII > address is replaced as > "Internationalized Address non-ASCII-encoded Removed:;". > non-ASCII address is encoded to "non-ASCII-encoded" by > [RFC2047]. No, that is not right, becuase if there is both a and a you would then get: Internationalized Address "" Removed: ; which might not by a syntactically valid according to RFC2822. Well I am not quite sure about that, but in any case it would look better if you cuold arrange it as: Internationalized Address "" Removed: ; > * > > Non-ASCII mail address with sender-specified US-ASCII address > MUST be replaced as "display-name ". And there you mean 'MUST be replaced by " " where the is a obtained by encoding the non-ASCII according to [RFC2047]'. And you probably need a in there as well, as before. > o Downgrading Non-ASCII in comments > Date: > Message-ID: > In-Reply-To: > References: > Resent-Date: > Resent-Message-ID: > MIME-Version: > Content-ID: Actually, it is any structured header where CFWS is allowed (or its equivalent in [RFC822]) and that includes structured headers that might be defined in the future. Which is why I would much prefer you to cover all such cases by generaic wording right at the start. > o Trace header ^ fields > Received: > If the FOR clause contains non-ASCII addresses, remove the FOR ^^^ ^^^ any that > clause in the header. The other part does not contain non-ASCII > values. > o MIME Content header ^ fields > Content-Type: > Content-Disposition: But again, this applies to ANY header that contains s as defined in RFC2045. For example the Auto-Submitted header in [RFC3834] and the Injection-Info header in draft-ietf-usefor-usefor-11 (already approved as a proposed standard and now in the rfc-editor's queue). Both of those documents mention [RFC2231] explicitly, so downgrading those headers would indeed yield something already valid on the current network. > Encode the header by [RFC2231] with charset='UTF-8'. Again, RFC2231 does not encode headers; it encodes s, which may be found in headers. > o Unstructured text headers and structured text headers > Subject: > Comments: > Keywords: > Content-Description: > Encode the header by [RFC2047] with charset='UTF-8'. And there is it the in the header that gets encoded (or a in the case of Keywords). > o URI headers ^ fields > o Other target headers > All other headers which contains non-ASCII characters are > preserved in Downgraded: header and removed. Again, what you really mean is: All other header fields which contains non-ASCII characters outside of s, s and , and for which no rule is given above, are preserved in a Downgraded: header field and then removed. > o ASCII only headers ^ fields > 6. MIME body part headers downgrading ^ fields > Content-ID: ....... > Content-Type: ...... > Content-Disposition: ......... > Content-Description: ......... But again, the downgrading of these is exactly the same as downgrading the same headers at the top level, which you have already explained. Moreover, there might be further such headers allowed in future which would come to no harm if downgraded using 2047 or 2231. I agree that creating a Downgraded: header in a MIME body part header might not be such a good idea (though I doubt it wold break anything in practice) so you might forbid that. There is no current situation where that might be needed, though. Here, however, you need to specify how to downgrade a message/utf8smtp, since there is a promise in section 4.6 of draft-ietf-eai-utf8headers-06.txt that such a downgrading (to message/rfc822) would be defined here. Presumably this would involve the usual recursive descent through the message/utf8smtp, downgrading individual headers as described above, and applying Content-Transfer-Encodings to bodies, as needed. And, having done that, you could also say that downgraders MAY do the same thing to message/rfc822. Yes, I know we have forbidden these to contain any utf8smtp headers, but such "leaks" are surely going to happen, so being "liberal" here might undo some such blunders. > 7. Security considerations > o It is likely that the techniques suggested here will invalidate > methods that depend on signatures over headers or the envelope. > "Issues" does talk about that, but, because this document strongly > implies that one can downgrade and then upgrade again with no risk > of loss of information, the topic should be explored further. But this document "implies" no such thing. Moreover, RFC2047 encoding will surely change the folding, and simply undoing every RFC2047 will not solve the problem because such encoding might have already been present in the original version, as signed before downgrading. The only way out of this dilemma is some pretty aggressive canonicalization in the signature algorithms. Tne recent DKIM standard goes some way towards such canonicalization, but it is nowhere near aggressive enough. Agreed it needs further exploration, so all we can do here is to identify the pitfalls. > Appendix A. Displaying downgraded message > I presume this appendix is intended to replace the former discussion of "upgrading". I have no problem with that. > A.1. Displaying technique 1 > MUA can remove 'Downgraded:' from decoded 'Downgraded:' header > fields. With this technique, The address header fields may be > displayed twice, one is ASCII-only downgraded header field and the > other is from decoded Downgraded: header. Ugh! I think I prefer the next method for normal use. >A.2. Displaying technique 2 > + Remove the header field which is the same with the generated > ASCII only header from the header fields. If the headers > contain [RFC2047] encoded part, decode it before comparison. But that last sentence will not always work because, sometimes, the [RFC2047] encoded part might have been present before downgrading. And, in any case, you have to unfold before doing the comparison. >Appendix B. Examples >B.1. Downgrading example 1 > Result of the header downgrading. > Return-Path: It is customary to insert the Return-Path: at the _end_ of the headers. > Envelope-Downgraded: From: > Envelope-Downgraded: To: > Message-Id: MESSAGE_ID > Mime-Version: 1.0 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: 8bit > Subject: RFC2047(UTF-8_SUBJECT) > Downgraded: From: RFC2047(>) > From: > Downgraded: To: RFC2047(>) > To: > Downgraded: CC: RFC2047() > CC: Internationalized address RFC2047(NON-ASCII-CC) removed:; It would be nice to show an example with a in it there. > Date: DATE > MAIL_BODY > Figure 5: Header downgraded message > Figure 13: Header downgraded message 2 > The previous draft had a useful paragraph here about a MIME encapsulated subject header. Why has it been removed? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 15:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8xQ-0006cK-SA; Thu, 26 Jul 2007 15:25:08 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE8xP-0006Ur-Re for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 15:25:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8xP-0006RO-EP for ima@ietf.org; Thu, 26 Jul 2007 15:25:07 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE8xP-0005sO-1Z for ima@ietf.org; Thu, 26 Jul 2007 15:25:07 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9CC4259704; Thu, 26 Jul 2007 21:25:05 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20054-08; Thu, 26 Jul 2007 21:24:59 +0200 (CEST) Received: from htat43p-no.corp.google.com (dhcp-149d.ietf69.org [130.129.20.157]) by eikenes.alvestrand.no (Postfix) with ESMTP id 58299259700; Thu, 26 Jul 2007 21:24:59 +0200 (CEST) Date: Thu, 26 Jul 2007 14:23:42 -0500 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: Concordet voting (Re: [EAI] Please - Don't state preferences yet!) Message-ID: <2C718E921C864A360E35E758@htat43p-no.corp.google.com> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org In the WG meeting today, the consensus of the room (decided, literally, by a coin toss) was to use Concordet voting for our decision-making process on the MIME type issue. Unless the mailing list erupts in protest against this, I take that as our next step. Since this string is blocking our next round of draft, we'd also better get it done as soon as possible. Charles, you mentioned having software available - can you offer to run the counting for this particular vote? If yes, is there a particular format for the ballot that would make this task easier for you? (as per the wikipedia article, you'd better specify which tie-breaking mechanism the software uses before we start, just so that all the information is available ahead of time...) WRT more alternatives: Up to the time the ballot is issued, I'll add more to the ballot if 3 people say "this should be added", but please don't use this list to gather those 3 people; we've got a lot of alternatives (and much mail about them) already.... Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 15:35:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE97G-0000MK-Md; Thu, 26 Jul 2007 15:35:18 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE97E-0000M0-T9 for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 15:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE97E-0000Ls-JR for ima@ietf.org; Thu, 26 Jul 2007 15:35:16 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE97B-0007Hk-7D for ima@ietf.org; Thu, 26 Jul 2007 15:35:16 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 23AF924080E; Thu, 26 Jul 2007 21:35:10 +0200 (CEST) Received: by fetiche (Postfix, from userid 1000) id 382C51817F; Thu, 26 Jul 2007 14:33:57 -0500 (CDT) Date: Thu, 26 Jul 2007 14:33:57 -0500 From: Stephane Bortzmeyer To: Harald Tveit Alvestrand Subject: Re: Condorcet voting (Re: [EAI] Please - Don't state preferences yet!) Message-ID: <20070726193356.GA4030@laperouse.bortzmeyer.org> References: <2C718E921C864A360E35E758@htat43p-no.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2C718E921C864A360E35E758@htat43p-no.corp.google.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Jul 26, 2007 at 02:23:42PM -0500, Harald Tveit Alvestrand wrote a message of 29 lines which said: > In the WG meeting today, the consensus of the room (decided, > literally, by a coin toss) was to use Concordet voting Condorcet http://en.wikipedia.org/wiki/Condorcet _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 16:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9YK-0002aG-7W; Thu, 26 Jul 2007 16:03:16 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE9YJ-0002a6-7p for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 16:03:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9YI-0002Zs-Tj for ima@ietf.org; Thu, 26 Jul 2007 16:03:14 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE9YI-0006rt-JP for ima@ietf.org; Thu, 26 Jul 2007 16:03:14 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id A69D924080E; Thu, 26 Jul 2007 22:03:09 +0200 (CEST) Received: by fetiche (Postfix, from userid 1000) id 5CED5183AA; Thu, 26 Jul 2007 14:58:34 -0500 (CDT) Date: Thu, 26 Jul 2007 14:58:34 -0500 From: Stephane Bortzmeyer To: Harald Tveit Alvestrand Subject: Re: Condorcet voting (Re: [EAI] Please - Don't state preferences yet!) Message-ID: <20070726195833.GA4424@laperouse.bortzmeyer.org> References: <2C718E921C864A360E35E758@htat43p-no.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2C718E921C864A360E35E758@htat43p-no.corp.google.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Jul 26, 2007 at 02:23:42PM -0500, Harald Tveit Alvestrand wrote a message of 29 lines which said: > Charles, you mentioned having software available - can you offer to > run the counting for this particular vote? Another alternative is to use an online service: http://www.cs.cornell.edu/andru/civs.html _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jul 26 16:24:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9sz-0002sb-MC; Thu, 26 Jul 2007 16:24:37 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IE9sy-0002sO-1m for ima-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 16:24:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9sx-0002sG-9j for ima@ietf.org; Thu, 26 Jul 2007 16:24:35 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE9sv-0008Jp-QO for ima@ietf.org; Thu, 26 Jul 2007 16:24:35 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6QKOQna020544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Jul 2007 13:24:32 -0700 Received: from [[67.97.210.160]] (vpn-10-50-16-2.qualcomm.com [10.50.16.2]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6QKOKhl019667 for ; Thu, 26 Jul 2007 13:24:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 26 Jul 2007 13:24:13 -0700 To: ima@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [EAI] POP Draft Open Issue: Up-conversion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org One open issue for the POP draft that was discussed in today's meeting is upconversion. Currently, Section 5 of the draft requires up-conversion of certain headers, and encourages up-conversion of MIME headers and embedded body parts. Up-conversion is required when the mail store is 7-bit. Up-conversion is prohibited of multipart/signed. This text doesn't specify exactly how up-conversion is to be done, and doesn't mention down-graded messages in a UTF-8 mail store. If there is any difference between messages that were downgraded on final delivery into a 7-bit store compared to those that were downgraded in transit, the draft is silent. In theory, I don't think there is any difference. Should up-conversion be a reversal of the downgrade process? Specifically, should 'downgraded-' header fields be decoded and the original header field name and value extracted? So, 'downgraded-to' is decoded and replaces the 'to' that presently exists? If so, what about cases where there are multiple occurrences of a header field? Or what about situations where the header was mucked with subsequent to the downgrade? For example, a UTF8 message is sent to a UTF8 list which adds 'list-*', 'reply-to' and 'sender' header fields containing UTF8 addresses. One recipient is an ASCII list. The message is downgraded in order to be sent to the ACII list's server. So there are now 'downgraded-list-*', 'downgraded-reply-to' and 'downgraded-sender' header fields. The ASCII list replaces some of the 'list-*' header and the 'reply-to' and 'sender' fields with its own values. The ASCII list sends the message to a POP user. The POP server up-converts by replacing the ASCII list's 'list-*', 'reply-to' and 'sender' header fields with those of the UTF8 list, extracted from the 'downgraded-*' header fields. We can say "This is what happens when one list is subscribed to another, too bad." We can even say "This shows why lists should not replace 'sender' and 'reply-to'. Or is this how it should behave? We have been saying "downgrade is officially a one-way process, but if a client wants to extract downgraded data for display or reply purposes, it is free to do so, but we don't specify how." That may be fine for clients. But here we are talking about servers, where presumably we want the behavior to be deterministic and clients to know what to expect. Specifically, if the server is going to up-convert to make life easy for the client, it should up-convert everything, right? So we should be very clear on this. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- wabi (wah-BI; Japanese; noun): a flawed detail that creates an elegant whole. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jul 28 17:40:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEu1k-0005K2-6D; Sat, 28 Jul 2007 17:40:44 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IEu1i-0005Jw-Er for ima-confirm+ok@megatron.ietf.org; Sat, 28 Jul 2007 17:40:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEu1i-0005Jn-3a for ima@ietf.org; Sat, 28 Jul 2007 17:40:42 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEu1h-0008FU-BW for ima@ietf.org; Sat, 28 Jul 2007 17:40:42 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6SLeecV015242 for ; Sat, 28 Jul 2007 21:40:40 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLW00B01QSS6M00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Sat, 28 Jul 2007 15:40:40 -0600 (MDT) Received: from [10.1.110.5] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLW00J8LS7RHC00@mail-amer.sun.com>; Sat, 28 Jul 2007 15:40:40 -0600 (MDT) Date: Fri, 27 Jul 2007 14:10:53 -0500 From: Chris Newman Subject: Re: [EAI] POP Draft Open Issue: Up-conversion In-reply-to: <0JLS00A0EZD4U700@brm-avmta-1.central.sun.com> To: Randall Gellens , ima@ietf.org Message-id: <3A89B166A5D01C1412F68E6E@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <0JLS00A0EZD4U700@brm-avmta-1.central.sun.com> X-Spam-Score: 1.6 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Speaking as a technical participant: I have a preference to have the POP server up-convert RFC 2047, RFC 2231 on behalf of the client. POP clients have had lots of problems in practice with white space handling in RFC 2047 and I've seen clients with a much smaller charset vocabulary than the typical server. Given that people rarely get paid much to work on desktop mail clients, it's possible they'll be patched to add UTF-8 header display support but I'm dubious we'll get a lot more from desktop clients. It's also more efficient and simpler for thinner clients. Beyond that, the less the document says, the better IMHO. It is impossible in the general case to provide a command to fetch a message as it was prior to message store insertion. However, I neither support nor oppose adding a mechanism to fetch a message as stored in the mail store. I suspect it's unwise to attempt to fully reverse down-conversion and not worth the trouble. I see little value in up-converting IDN as the ugly form works and clients have to implement IDN up-conversion for UI consistency regardless. IDN also lacks the white space and charset issues that make 2047/2231 problematic for clients. I view IRI/URI conversion in the same class as IDN (the 7-bit URI works, and clients need an up-converter for consistency anyway). Replacing the "From" with "Downgraded-From" or the equivalent for other address headers seems problematic to me. - Chris Randall Gellens wrote on 7/26/07 13:24 -0700: > One open issue for the POP draft that was discussed in today's meeting is > upconversion. > > Currently, Section 5 of the draft requires up-conversion of certain headers, > and encourages up-conversion of MIME headers and embedded body parts. > Up-conversion is required when the mail store is 7-bit. Up-conversion is > prohibited of multipart/signed. > > This text doesn't specify exactly how up-conversion is to be done, and > doesn't mention down-graded messages in a UTF-8 mail store. If there is any > difference between messages that were downgraded on final delivery into a > 7-bit store compared to those that were downgraded in transit, the draft is > silent. In theory, I don't think there is any difference. > > Should up-conversion be a reversal of the downgrade process? Specifically, > should 'downgraded-' header fields be decoded and the original header field > name and value extracted? So, 'downgraded-to' is decoded and replaces the > 'to' that presently exists? If so, what about cases where there are multiple > occurrences of a header field? Or what about situations where the header was > mucked with subsequent to the downgrade? For example, a UTF8 message is sent > to a UTF8 list which adds 'list-*', 'reply-to' and 'sender' header fields > containing UTF8 addresses. One recipient is an ASCII list. The message is > downgraded in order to be sent to the ACII list's server. So there are now > 'downgraded-list-*', 'downgraded-reply-to' and 'downgraded-sender' header > fields. The ASCII list replaces some of the 'list-*' header and the > 'reply-to' and 'sender' fields with its own values. The ASCII list sends the > message to a POP user. The POP server up-converts by replacing the ASCII > list's 'list-*', 'reply-to' and 'sender' header fields with those of the UTF8 > list, extracted from the 'downgraded-*' header fields. > > We can say "This is what happens when one list is subscribed to another, too > bad." We can even say "This shows why lists should not replace 'sender' and > 'reply-to'. Or is this how it should behave? > > We have been saying "downgrade is officially a one-way process, but if a > client wants to extract downgraded data for display or reply purposes, it is > free to do so, but we don't specify how." That may be fine for clients. But > here we are talking about servers, where presumably we want the behavior to > be deterministic and clients to know what to expect. Specifically, if the > server is going to up-convert to make life easy for the client, it should > up-convert everything, right? So we should be very clear on this. > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > wabi (wah-BI; Japanese; noun): a flawed detail that creates an > elegant whole. > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jul 31 06:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFotO-0000z5-RJ; Tue, 31 Jul 2007 06:23:54 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IFotN-0000ys-JZ for ima-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 06:23:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFotN-0000yk-7X for ima@ietf.org; Tue, 31 Jul 2007 06:23:53 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFotL-00029z-Is for ima@ietf.org; Tue, 31 Jul 2007 06:23:53 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l6VAMOwK008488; Tue, 31 Jul 2007 19:22:38 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007073119222912854 ; Tue, 31 Jul 2007 19:22:29 +0900 Date: Tue, 31 Jul 2007 19:22:28 +0900 (JST) Message-Id: <20070731.192228.25149676.fujiwara@jprs.co.jp> To: chl@clerew.man.ac.uk Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-04 From: fujiwara@jprs.co.jp In-Reply-To: References: X-Mailer: Mew version 5.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Thank you very much for your comments. > From: "Charles Lindsey" > Sorry, I should have got around to commenting on this much earlier, but it > only just reached the top of my 'todo' list :-( . > > > 3. New header fields definition > > fields =/ downgraded > > downgraded = "Downgraded:" [FWS] field-name ":" unstructured CRLF > > Encapsulating a header in a Downgraded: header is defined as: > ^ ^ > field field > > 1. Generate new Downgraded: header whose former value is the > > original header field name and latter value is the original > > header fleid value. > > 2. Encode the generated header by [RFC2047] section 5(1) method with > > charset='UTF-8'. > > 3. Replace the original header field as the generated header field. > > That Step 3 does not always apply; for example when the original was a > From:/To:/etc field, which then remains (in altered form) in addition to > the > new Downgraded: I removed 3. The Header field downgrading section will be changed to adopt the IETF69 discussion. > > fields =/ edowngraded > > edowngraded = "Envelope-Downgraded:" [FWS] edowngraded-field ":" > > [FWS] "<" uPath ">" [FWS] > > "<" Mailbox ">" [FWS] CRLF > > edowngraded-field = "From" / "To" > > Why not > > > edowngraded-field = "Mail From" / "Rcpt To" > > to avoid any possible confusion with the From: and To: headers? It's reasonable. And I changed them as "Downgraded-MAIL-FROM" and "Downgraded-RCPT-TO". > > Original non-ASCII address is defined in > > [I-D.ietf-eai-smtpext]. is defined in [RFC2821], section > > 4.1.2. The "Envelope-Downgraded:" header field is encoded by > > [RFC2047] in the downgraded message. > > I think it is wrong to say (as you do frequently) that > > 'The "Some-Header:" is encoded by [RFC2047]' > > RFC2047 encodes carefully regulated _parts_ of header fields (such as > s, s and s), never the whole header field. > In this case it is the (treated as if it were ) that > gets encoded (or maybe even only a part of it - 2047 allows you to split it > up in many ways). Your later examples indeed indicate that is what you > intend to happen. OK, I will check and rewrite all "encoded by [RFC2047]" carefully. > > 4. SMTP Downgrading > > MTA replaces non-ASCII mail address with specified alternative US- > > ASCII address when downgrading. Before replacing, decode the ALT- > > ADDRESS parameter value because it is encoded as xtest [RFC3461]. > > Eh? That last sentence only applies to an ORCPT parameter, I think. smtpext-07 section 2.4 says: ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value ALT-ADDRESS-esmtp-value=xtext > > Also MTA preserves original information using "Envelope-Downgraded" > > header defined in Section 3 with From or To field name. The non- > > ASCII mail addresses are encoded by [RFC2047] and put into "Envelope- > > Downgraded" header. > > Yes, that wording is correct, as opposed to what you said about encoding > the > whole header earlier. But this description is a duplication. I removed it. > > 5. Email header fields downgrading > > I found the whole of this section very confusing. You have done an > exhaustive analysis of lots of particular cases, resulting in much > unnecessary repetition, instead of setting out the _principles_ on which > the > whole thing was based. I'm considering how to write them clearly. > For example, it is always correct to encode a whatever header it > occurs in and whether or not that header contains further stuff (e.g. > addresses) that have to be downgraded specially. So you might as well state > that once up-front (even in a conceptual first pass over all the headers), > rather than mention it as an extra thing to do when performing other more > particular downgrade operations. > > > > o Downgrading Address header fields > > From: > > Sender: > > Reply-To: > > To: > > Cc: > > Bcc: > > Resent-From: > > Resent-Sender: > > Resent-To: > > Resent-Cc: > > But that is only the present list. Surely the process you describe MAY also > be used for any header defined in the future which contains an > etc. It is true but currently supported header fields list is necessary. > The upgrade/display mechanisms you describe in A1 and A2 would work > just fine on such headers. > > > The header field value is composed of single or multiple > addr>/ fields defined in > > [I-D.ietf-eai-utf8headers]. > > If the header has no or which > > contains non-ASCII characters, only "display-name" part or > > comments contain non-ASCII characters, the "display-name" or > > comments are encoded by [RFC2047] with charset='UTF-8'. > > Otherwise, preserve the header field in "Downgraded:" header, > > generate US-ASCII only address header, and replace the original > > header field with the generated US-ASCII only header field. New > > header generation method are shown in below. > > Extract every field and downgrade each // > > . > > Remove there. The other two are just particular cases of > . I changed it as only. > > If the non-ASCII address is in form, then rewrite > ^ > (i.e. it contains no ) > > it as "Internationalized Address utf8-addr-spec-encoded > > Removed:;". "utf8-addr-spec" is encoded to "utf8-addr-spec- > > encoded" by [RFC2047]. > > That is exceedingly confusing until you have worked out what it means. What > you really mean to say is: > > rewrite it as a [RFC2822] of the form > > Internationalized Address "" Removed: ; > > where the is the original encoded > according to [RFC2047] (and needs to be within a ). > > That is essential because, for sure, the > will have at least an '@' somewhere inside it. I changed as your lines. (without '"') > No, that is not right, becuase if there is both a and a > you would then get: > > Internationalized Address "" > Removed: ; > > which might not by a syntactically valid according to RFC2822. Well > I am not quite sure about that, but in any case it would look better if you > cuold arrange it as: > > Internationalized Address "" > Removed: ; According to RFC2822, word = atom / quoted-string phrase = 1*word / obs-phrase display-name = phrase group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] RFC 2047 updates phrase phrase = 1*( encoded-word / word ) "encoded-word word word encoded-word word:;" is allowed. And more, according to RFC 2047 section 5, + An 'encoded-word' MUST NOT appear within a 'quoted-string'. So, I removed double quotes which enclose an encoded-word. > > o Trace header > ^ > fields > > Received: > > If the FOR clause contains non-ASCII addresses, remove the FOR > ^^^ ^^^ > any that > > clause in the header. The other part does not contain non-ASCII > > values. > > o MIME Content header > ^ > fields Adopt them > > Content-Type: > > Content-Disposition: > > But again, this applies to ANY header that contains s as defined > in RFC2045. For example the Auto-Submitted header in [RFC3834] and the > Injection-Info header in draft-ietf-usefor-usefor-11 (already approved as a > proposed standard and now in the rfc-editor's queue). Both of those > documents mention [RFC2231] explicitly, so downgrading those headers would > indeed yield something already valid on the current network. > > Encode the header by [RFC2231] with charset='UTF-8'. > > Again, RFC2231 does not encode headers; it encodes s, which may > be > found in headers. > > o Unstructured text headers and structured text headers > > Subject: > > Comments: > > Keywords: > > Content-Description: > > Encode the header by [RFC2047] with charset='UTF-8'. > > And there is it the in the header that gets encoded (or a > in the case of Keywords). I changed the title as 'Non-ASCII in or ' > > o URI headers > ^ > fields > > > > o Other target headers > > All other headers which contains non-ASCII characters are > > preserved in Downgraded: header and removed. > > Again, what you really mean is: > > All other header fields which contains non-ASCII characters outside > of s, s and , and for which no rule > is given above, are preserved in a Downgraded: header field and then > removed. adopt this and will change the Downgraded: header field as "Downgraded-*:". > > o ASCII only headers > ^ > fields > > > > 6. MIME body part headers downgrading > ^ > fields > > > > Content-ID: ....... > > Content-Type: ...... > > Content-Disposition: ......... > > Content-Description: ......... > > But again, the downgrading of these is exactly the same as downgrading the > same headers at the top level, which you have already explained. Moreover, > there might be further such headers allowed in future which would come to > no harm if downgraded using 2047 or 2231. I agree that creating a > Downgraded: header in a MIME body part header might not be such a good idea > (though I doubt it wold break anything in practice) so you might forbid > that. There is no current situation where that might be needed, though. I agree. I will consider how to write. > Here, however, you need to specify how to downgrade a message/utf8smtp, > since there is a promise in section 4.6 of > draft-ietf-eai-utf8headers-06.txt > that such a downgrading (to message/rfc822) would be defined here. > > Presumably this would involve the usual recursive descent through the > message/utf8smtp, downgrading individual headers as described above, and > applying Content-Transfer-Encodings to bodies, as needed. > > And, having done that, you could also say that downgraders MAY do the same > thing to message/rfc822. Yes, I know we have forbidden these to contain any > utf8smtp headers, but such "leaks" are surely going to happen, so being > "liberal" here might undo some such blunders. This comment is not agreed in WG. In my opinion, a rfc822 message which contains message/utf8smtpMIMEtype part confronts 7bit transport, it may be encoded to BASE64 and its MIME headers will be Content-Type: message/utf8smtpMIMEtype; charset="UTF-8" Content-Transfer-Encoding: base64 This rfc822 message is deliverable via 7bit transport. > > 7. Security considerations > > o It is likely that the techniques suggested here will invalidate > > methods that depend on signatures over headers or the envelope. > > "Issues" does talk about that, but, because this document strongly > > implies that one can downgrade and then upgrade again with no risk > > of loss of information, the topic should be explored further. > > But this document "implies" no such thing. Moreover, RFC2047 encoding will > surely change the folding, and simply undoing every RFC2047 will not solve > the problem because such encoding might have already been present in the > original version, as signed before downgrading. The only way out of this > dilemma is some pretty aggressive canonicalization in the signature > algorithms. Tne recent DKIM standard goes some way towards such > canonicalization, but it is nowhere near aggressive enough. > > Agreed it needs further exploration, so all we can do here is to identify > the pitfalls. I will add some text about DKIM in Security considerations. > > Appendix A. Displaying downgraded message > > > I presume this appendix is intended to replace the former discussion of > "upgrading". I have no problem with that. > > > A.1. Displaying technique 1 > > MUA can remove 'Downgraded:' from decoded 'Downgraded:' header > > fields. With this technique, The address header fields may be > > displayed twice, one is ASCII-only downgraded header field and the > > other is from decoded Downgraded: header. > > Ugh! I think I prefer the next method for normal use. > >A.2. Displaying technique 2 > > + Remove the header field which is the same with the generated > > ASCII only header from the header fields. If the headers > > contain [RFC2047] encoded part, decode it before comparison. > > But that last sentence will not always work because, sometimes, the > [RFC2047] encoded part might have been present before downgrading. And, in > any case, you have to unfold before doing the comparison. It is a difficult problem. RFC 2047 encoding does not preserve a space between words. it needs further consideration. > >Appendix B. Examples > >B.1. Downgrading example 1 > > Result of the header downgrading. > > Return-Path: > > It is customary to insert the Return-Path: at the _end_ of the headers. Some MTA insert the Return-Path: at the top of the headers. > > Envelope-Downgraded: From: > > Envelope-Downgraded: To: > > Message-Id: MESSAGE_ID > > Mime-Version: 1.0 > > Content-Type: text/plain; charset="UTF-8" > > Content-Transfer-Encoding: 8bit > > Subject: RFC2047(UTF-8_SUBJECT) > > Downgraded: From: RFC2047(>) > > From: > > Downgraded: To: RFC2047(>) > > To: > > Downgraded: CC: RFC2047() > > CC: Internationalized address RFC2047(NON-ASCII-CC) removed:; > > It would be nice to show an example with a in it there. Ok, I will try to add display-names for each addresses. > > Date: DATE > > MAIL_BODY > > Figure 5: Header downgraded message > > > > > Figure 13: Header downgraded message 2 > > > The previous draft had a useful paragraph here about a MIME encapsulated > subject header. Why has it been removed? Is the paragraph this? | And more, the body part contains UTF-8 message. "ascii user" needs | to accept UTF-8 mail body and UTF-8 subject which is MIME encoded. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima