From ima-bounces@ietf.org Tue Feb 21 13:05:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbt3-0007NS-VS; Tue, 21 Feb 2006 13:05:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbt2-0007Mb-0M; Tue, 21 Feb 2006 13:05:20 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBbt1-00071j-Ku; Tue, 21 Feb 2006 13:05:19 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k1LI5J0e032191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2006 18:05:19 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FBbt1-0006Yx-6q; Tue, 21 Feb 2006 13:05:19 -0500 Content-Type: text/plain Mime-Version: 1.0 To: IETF Announcement list From: IESG Secretary Message-Id: Date: Tue, 21 Feb 2006 13:05:19 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ima@ietf.org Subject: [IEE] WG Review: Email Address Internationalization (eai) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by March 1st. +++ Email Address Internationalization (eai) ======================================== Current Status: Proposed Working Group 1.1. Chair(s) TBD 1.2. Applications Area Director(s) Ted Hardie Scott Hollenbeck 1.3. Applications Area Advisor To be determined 1.4. Mailing Lists General Discussion: ima@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ima Archive: http://www1.ietf.org/mail-archive/web/ima/index.html 1.5. Description of Working Group Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is even more important. After all, most prefer variations on their names for those addresses. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one --constraints that go back to before RFC 821 and that have been vital to the operation of the Internet's email environment-- make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behaviours. NOTE IN DRAFT: Additional possible documents suggested: Advice for MUA implementors (Info) 1.7. Goals and Milestones (Very tentative so far) +-------------+--------------------------------------+--------------+ | DONE | Overview/architecture draft first | | | | draft | | | Feb 2006 | Interworking scenarios first draft | | | DONE | SMTP Extensions first draft | | | DONE | Header format first draft | | | Mar 2006 | Downgrading in SMTP first draft | | | Mar 2006 | Downgrading in POP first draft | | | Mar 2006 | Downgrading in IMAP first draft | | | Jun 2006 | Overview/architecture draft to IESG | | | Jun 2006 | Interworking scenarios to IESG | | | Sep 2006 | SMTP Extensions to IESG | | | Sep 2006 | Header format to IESG | | | Sep 2006 | Downgrading in SMTP to IESG | | | Sep 2006 | Downgrading in POP to IESG | | | Sep 2006 | Downgrading in IMAP to IESG | | | Dec 2006 | Results and evaluation first draft | | | Mar 2007 | Results and evaluation to IESG | | | Mar 2007 | Group recharter for standards track | | | | or disband | | +-------------+--------------------------------------+--------------+ Table 1 1.8. Internet-Drafts Drafts listed below were posted as initial discussion documents, significantly preceeding the meeting at IETF 64 (Vancouver, 2005 Oct). 2005.06.27 draft-lee-jet-ima-00.txt 2005.07.18 draft-klensin-emailaddr-i18n-03.txt Drafts listed below were prepared and posted to inform the discussion at IETF 64. They replace those above. o draft-klensin-ima-framework-00.txt o draft-yao-ima-smtpext-00.txt o draft-yeh-ima-utf8headers-00.txt o draft-yoneya-ima-downgrade-00.txt Drafts produced by the WG None as yet 1.9. Request For Comments None as yet _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 22 03:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBpjc-00046R-3X; Wed, 22 Feb 2006 03:52:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBpjb-00046I-Aa; Wed, 22 Feb 2006 03:52:31 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBpjZ-0007u9-OA; Wed, 22 Feb 2006 03:52:31 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k1M8qOu24056; Wed, 22 Feb 2006 17:52:24 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 7f91_8b110086_a380_11da_8cee_0014221fa3c9; Wed, 22 Feb 2006 17:52:23 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k1M8oP1p009562; Wed, 22 Feb 2006 17:51:36 +0900 Message-Id: <6.0.0.20.2.20060222173147.06c88970@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 22 Feb 2006 17:37:59 +0900 To: Larry Masinter , iesg@ietf.org From: Martin Duerst In-Reply-To: <001501c6372e$f5613690$fb822099@corp.adobe.com> References: <001501c6372e$f5613690$fb822099@corp.adobe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Jamie Zawinski , ima@ietf.org Subject: [IEE] RE: WG Review: Email Address Internationalization (eai) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 06:37 06/02/22, Larry Masinter wrote: >Should the group to also consider internationalization >of "mailto" URIs, > > draft-duerst-mailto-bis-01.txt > >because "email address internationalization" isn't fully >specified without doing so. Hello Larry, That's a good question. I asked that question previously, at http://www1.ietf.org/mail-archive/web/ima/current/msg00082.html. You were copied on that mail, but probably not on all of the followup. I think the general opinion (most prominently voiced by John Klensin) on the ima mailing list was that the WG should review draft-duerst-mailto-bis-01.txt, but not tie it up in formalities. (see http://www1.ietf.org/mail-archive/web/ima/current/msg00087.html). Did you come to a different conclusion, or are you just asking to make sure this has been thought about? Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 22 07:17:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBsw3-0007l8-1L; Wed, 22 Feb 2006 07:17:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBsw1-0007kt-TR; Wed, 22 Feb 2006 07:17:33 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBsvy-0007Hi-9U; Wed, 22 Feb 2006 07:17:33 -0500 Received: from host81-144-67-136.midband.mdip.bt.net ([81.144.67.136]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.211) id 43fc5653.cfc7.1b8; Wed, 22 Feb 2006 12:17:23 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k1MBmDg21268; Wed, 22 Feb 2006 11:48:13 GMT To: iesg@ietf.org Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: Message-ID: Date: Wed, 22 Feb 2006 11:48:07 -0000 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 21 Feb 2006 18:05:19 -0000, IESG Secretary wrote: > Email Address Internationalization (eai) > ======================================== > > Current Status: Proposed Working Group > > 1.5. Description of Working Group > This working group will address one basic approach to email > internationalization. That approach is based on the use of an SMTP > extension to enable both the use of UTF-8 in envelope address local- > parts and optionally in domain-parts and the use of UTF-8 in mail > headers -- both in address contexts and wherever encoded-words are > permitted today. s/both/including/ There may well be other headers, whether in current use or to be invented, and even possibly invented as part of this exercise, where the UTF-8 approach might be introduced. For example, headers containing IRIs as oposed to URIs, and the Newsgroups header, in the event that this work is later extended to Netnews Tbis is not included in the present charter, but is a likely extension in the future. The WG needs to address issues that might arise with such future headers (e.g. a general-purpose fallback downgrading mechanism). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Wed Feb 22 19:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4hD-0005VX-4P; Wed, 22 Feb 2006 19:51:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4hB-0005VP-Nj for ima@ietf.org; Wed, 22 Feb 2006 19:51:01 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FC4h9-000462-H7 for ima@ietf.org; Wed, 22 Feb 2006 19:51:01 -0500 Received: (snipe 31196 invoked by uid 0); 23 Feb 2006 09:50:57 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.480633 secs); Received: from unknown (HELO ?220.69.185.15?) (ZXD?own@220.69.185.15) by unknown with SMTP; 23 Feb 2006 09:50:56 +0900 X-RCPTTO: ima@ietf.org Message-ID: <43FD06EC.8090003@icu.ac.kr> Date: Thu, 23 Feb 2006 09:50:52 +0900 From: Yangwoo Ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org Content-Type: multipart/mixed; boundary="------------050406040601000307090005" X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [IEE] [Fwd: I-D ACTION:draft-klensin-ima-framework-01.txt] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --------------050406040601000307090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Newly updated framework document is posted as I-D. Your precious comments are invited. Regards --------------050406040601000307090005 Content-Type: message/rfc822; name="I-D ACTION:draft-klensin-ima-framework-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-klensin-ima-framework-01.txt" X-Account-Key: account2 Received: from ietf.org by icu.ac.kr with ESMTP (BeeHive 1.4.1_03) for newcat@icu.ac.kr; Thu, 23 Feb 2006 06:01:52 +0900 Received: (snipe 17503 invoked by uid 0); 23 Feb 2006 06:05:28 +0900 Received: from i-d-announce-bounces@ietf.org with Spamsniper 2.91.12 (Processed in 0.952974 secs); Received: from unknown (HELO nexus.zerota.com) (222.106.68.9) by unknown with SMTP; 23 Feb 2006 06:05:27 +0900 X-RCPTTO: newcat@icu.ac.kr Received: from megatron.ietf.org (megatron.ietf.org [156.154.16.145]) by nexus.zerota.com (8.12.8/8.12.8) with ESMTP id k1ML5Qwk017048 for ; Thu, 23 Feb 2006 06:05:26 +0900 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0wj-0005Y9-Cq; Wed, 22 Feb 2006 15:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0w0-00052t-4H for i-d-announce@ietf.org; Wed, 22 Feb 2006 15:50:04 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0vz-000718-4l for i-d-announce@ietf.org; Wed, 22 Feb 2006 15:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1MKo2vP004512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FC0vy-0004Su-Ju for i-d-announce@ietf.org; Wed, 22 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Feb 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: I-D ACTION:draft-klensin-ima-framework-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-klensin-ima-framework-01.txt Pages : 16 Date : 2006-2-22 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 and operational suggestions 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 will include discussion of key assumptions and issues in deploying fully internationalized email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-klensin-ima-framework-01.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-klensin-ima-framework-01.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-klensin-ima-framework-01.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: <2006-2-22145740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-klensin-ima-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-klensin-ima-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-22145740.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------050406040601000307090005 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 --------------050406040601000307090005-- From ima-bounces@ietf.org Wed Feb 22 20:16:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC56H-0007gC-6o; Wed, 22 Feb 2006 20:16:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC56F-0007g4-AW for ima@ietf.org; Wed, 22 Feb 2006 20:16:55 -0500 Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FC56C-0005np-O6 for ima@ietf.org; Wed, 22 Feb 2006 20:16:55 -0500 Received: (eyou send program); Thu, 23 Feb 2006 09:16:34 +0800 Message-ID: <340657394.15989@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Thu, 23 Feb 2006 09:16:34 +0800 Message-ID: <005801c63817$15fccc50$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: Date: Thu, 23 Feb 2006 09:18:42 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0056_01C6385A.240AAF90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Larry Masinter Subject: [IEE] Fw: WG Review: Email Address Internationalization (eai) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0056_01C6385A.240AAF90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 dGhlIGF0dGFjaG1lbnQgbWVzc2FnZSBpcyBzZW50IGZyb20gTGFycnkgTWFzaW50ZXIuDQoNCklu IG9yZGVyIHRvIHByZXZlbnQgdGhlIHBvc3NpYmxlIHNwYW0sIHdlIHNldCB0aGF0IG9ubHkgbWVt YmVycyBvZiB0aGUgbGlzdCBjYW4gc2VuZCB0aGUgbWVzc2FnZXMgdG8gdGhlIGxpc3QuIA0Kc29y cnkgZm9yIHRoZSB1bi1jb252ZW5pZW50IGNhdXNlZCBieSB0aGlzIHNldC4NCkkgaGF2ZSBhZGRl ZCBMYXJyeSdzIGVtYWlsIGluIHRoZSBMaXN0IG9mIG5vbi1tZW1iZXIgYWRkcmVzc2VzIHdob3Nl IHBvc3RpbmdzIHNob3VsZCBiZSBhdXRvbWF0aWNhbGx5IGFjY2VwdGVkLiANCg0KWWFvIEppYW5r YW5nDQpDTk5JQw0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJMYXJyeSBN YXNpbnRlciIgPExNTUBhY20ub3JnPg0KVG86IDxpbWEtb3duZXJAaWV0Zi5vcmc+DQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMDYgMTI6MzcgQU0NClN1YmplY3Q6IEZXOiBXRyBSZXZp ZXc6IEVtYWlsIEFkZHJlc3MgSW50ZXJuYXRpb25hbGl6YXRpb24gKGVhaSkNCg0KDQo+IFByb2Jh Ymx5IHRoaXMgc2hvdWxkIGdvIHRvIHRoZSBpbWEgbGlzdC4g ------=_NextPart_000_0056_01C6385A.240AAF90 Content-Type: message/rfc822; name="RE_ WG Review_ Email Address Internationalization (eai).eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="RE_ WG Review_ Email Address Internationalization (eai).eml" Date: Wed, 22 Feb 2006 08:35:24 -0800 From: Larry Masinter Subject: RE: WG Review: Email Address Internationalization (eai) In-reply-to: <6.0.0.20.2.20060222173147.06c88970@localhost> To: 'Martin Duerst' , iesg@ietf.org Cc: ima@ietf.org, 'Jamie Zawinski' Message-id: <000601c637cd$fb4a9430$a8f0070a@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcY3jU7iV9nLeVS+TBKyzsqfYK/2vgAQCyXg X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 In reply to > >Should the group to also consider internationalization > >of "mailto" URIs, > > > > draft-duerst-mailto-bis-01.txt > > > >because "email address internationalization" isn't fully > >specified without doing so. Martin noted: > I think the general opinion (most prominently voiced by > John Klensin) on the ima mailing list was that the WG should > review draft-duerst-mailto-bis-01.txt, but not tie it up in > formalities. > (see http://www1.ietf.org/mail-archive/web/ima/current/msg00087.html). > > Did you come to a different conclusion, or are you just asking > to make sure this has been thought about? What John said was: # I think some of us should just look at the thing, soon, and get # comments to you, rather than tying things up in formalities. and it's not clear that that's happened. I'd like to make sure that it does happen. Adding "mailto" to the IMA WG charter would be one way of insuring that it does happen. Larry ------=_NextPart_000_0056_01C6385A.240AAF90 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_000_0056_01C6385A.240AAF90-- From ima-bounces@ietf.org Thu Feb 23 10:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIC8-0001K6-Sl; Thu, 23 Feb 2006 10:15:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIC8-0001K1-9c for ima@ietf.org; Thu, 23 Feb 2006 10:15:52 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIC5-0006Or-Vs for ima@ietf.org; Thu, 23 Feb 2006 10:15:52 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A2064259715 for ; Thu, 23 Feb 2006 16:14:21 +0100 (CET) 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 22582-01 for ; Thu, 23 Feb 2006 16:14:17 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DDD625970F for ; Thu, 23 Feb 2006 16:14:17 +0100 (CET) Date: Thu, 23 Feb 2006 16:15:31 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <6F11B3824B2AB49973222B22@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [IEE] Agenda slot for IMA in Dallas X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0797984003==" Errors-To: ima-bounces@ietf.org --===============0797984003== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========D27531E13F3822D63C8F==========" --==========D27531E13F3822D63C8F========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline A slot has been reserved for this BOF, which may be a WG at the time: 0900-1130 Morning Session I APP eai Email Address Internationalization BOF INT netlmm Network-based Localized Mobility Management WG INT trill Transparent Interconnection of Lots of Links WG OPS adslmib ADSL MIB WG OPS radext RADIUS Extensions WG RAI avt Audio/Video Transport WG RAI ecrit Emergency Context Resolution with Internet Technologies WG RTG forces Forwarding and Control Element Separation WG If anyone sees a dramatic conflict in this slot, please holler. I do hope that we can get up to speed on the issues on the mailing list -=20 it's been very quiet here so far. Please suggest points for the agenda; if we have enough to talk about, I'll = get one together; if we don't have enough to talk about, I'll cancel. Harald --==========D27531E13F3822D63C8F========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD/dGUOMj+2+WY0F4RAlFTAKDBPf1DgdhZYfliwYwTkZtP84GtiwCfUtYG r+/Apl8l3aYHk/bEnDFSu38= =ryQx -----END PGP SIGNATURE----- --==========D27531E13F3822D63C8F==========-- --===============0797984003== 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 --===============0797984003==-- From ima-bounces@ietf.org Thu Feb 23 10:24:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIKo-0008D4-Nu; Thu, 23 Feb 2006 10:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIKo-0008Cx-Cs for ima@ietf.org; Thu, 23 Feb 2006 10:24:50 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIKn-00079O-2s for ima@ietf.org; Thu, 23 Feb 2006 10:24:50 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FCIKm-0002Lr-No; Thu, 23 Feb 2006 10:24:48 -0500 Date: Thu, 23 Feb 2006 10:24:48 -0500 From: John C Klensin To: Harald Tveit Alvestrand Subject: Re: [IEE] Agenda slot for IMA in Dallas Message-ID: <643C7111088709DBA52AE36D@p3.JCK.COM> In-Reply-To: <6F11B3824B2AB49973222B22@B50854F0A9192E8EC6CDA126> References: <6F11B3824B2AB49973222B22@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.4 (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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald, You forgot to mention that this was Tuesday morning (not some other day). Agenda comments soon... I'm busy trying to generate documents to discuss on it :-) john --On Thursday, 23 February, 2006 16:15 +0100 Harald Tveit Alvestrand wrote: > A slot has been reserved for this BOF, which may be a WG at > the time: > > 0900-1130 Morning Session I > APP eai Email Address Internationalization BOF > INT netlmm Network-based Localized Mobility Management WG > INT trill Transparent Interconnection of Lots of Links WG > OPS adslmib ADSL MIB WG > OPS radext RADIUS Extensions WG > RAI avt Audio/Video Transport WG > RAI ecrit Emergency Context Resolution with Internet > Technologies WG > RTG forces Forwarding and Control Element Separation WG > > If anyone sees a dramatic conflict in this slot, please holler. > > I do hope that we can get up to speed on the issues on the > mailing list - it's been very quiet here so far. > > Please suggest points for the agenda; if we have enough to > talk about, I'll get one together; if we don't have enough to > talk about, I'll cancel. > > Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 23 13:43:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLRS-0006gy-B4; Thu, 23 Feb 2006 13:43:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLRR-0006fY-Dn; Thu, 23 Feb 2006 13:43:53 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLRR-0008IW-1N; Thu, 23 Feb 2006 13:43:53 -0500 Received: from [192.168.0.3] (adsl-71-131-78-135.dsl.sntc01.pacbell.net [71.131.78.135]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1NIiMKP003109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 10:44:22 -0800 Message-ID: <43FE025F.9000504@dcrocker.net> Date: Thu, 23 Feb 2006 10:43:43 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: iesg@ietf.org Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Folks, This is clearly a necessary effort, to enhance Internet Mail. A few comments/questions about the charter: Standard, general observation about the first paragraph: IETF working group charters use their first paragraph very widely -- such as when sending notice to the ietf-announce list of the wg creation. So, that it should summarize the problem and, at least, the deliverable of the working group. In other words, the paragraph should stand on its own, as a summary of the working group. > Since early in the effort to internationalize domain names, which > resulted in the standards associated with IDNA, it has been > understood that internationalization of email address local parts is > even more important. After all, most prefer variations on their > names for those addresses. At the same time, email address What does "most prefer variations on their names for those addresses" mean? Perhaps it means something like: "most users of Internet mail would prefer a mailbox name that can be represented in characters other than basic ASCII"? > --constraints that go back to before RFC 821 and > that have been vital to the operation of the Internet's email > environment-- make address encoding nearly impossible. The need to Although I realize that there is quite a bit of history to this topic and even have some recollection of participating in at least one such conversation, and equally realize that the SMTP world (and RFC2822 world) of address do have some interesting limitations in the permissible characters for the mailbox string, I have not understood that an encoding scheme would be "impossible". (As a counter-example, note that the BATV work on rfc2821.mailfrom has been doing special encoding work and has found a syntax that seems universally acceptable. To be fair, that's not the syntax in the public draft of BATV, but a safer scheme HAS been developed.) Therefore, what is the basis for asserting such an absolute barrier? The approach of this working group is sufficiently radical/disruptive, so as to make it a good idea to have the charter cite or explain why an encoding overlay scheme is not viable. > Its initial target will be a set of experimental > RFCs that specify the details of this approach and provide the basis > for generating and testing interoperable implementations. Its work If an effort has its primary goal be the production of experimental specifications, shouldn't that make it an IRTF activity, rather than an IETF activity? This question is not a mere formality. The entire tone and scope of the described work is quite candid (and I suspect accurate) about the effort. What is described is research, not standards-making. Based on the nature of the work defined here, it is going to be some years before the work is ready for a standards effort. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 23 16:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOMo-0005AC-IH; Thu, 23 Feb 2006 16:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOMn-00058Y-Gg for ima@ietf.org; Thu, 23 Feb 2006 16:51:17 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCOMn-0006k0-18 for ima@ietf.org; Thu, 23 Feb 2006 16:51:17 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FCOMk-0003Aa-P1; Thu, 23 Feb 2006 16:51:15 -0500 Date: Thu, 23 Feb 2006 01:17:58 -0500 From: John C Klensin To: YAO Jiankang , ima@ietf.org Subject: Re: [IEE] Fw: WG Review: Email Address Internationalization (eai) Message-ID: <5E51110F4845F791DE9D1D44@JCK-ACR.jck.com> In-Reply-To: <340657394.15989@cnnic.cn>, <005801c63817$15fccc50$1206e29f@cnnicyaojk> References: <340657394.15989@cnnic.cn>, <005801c63817$15fccc50$1206e29f@cnnicyaojk> X-Mailer: Mulberry/4.0.4 (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: 082a9cbf4d599f360ac7f815372a6a15 Cc: Larry Masinter X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, February 23, 2006 9:18 AM +0800 YAO Jiankang wrote: > the attachment message is sent from Larry Masinter. > Martin noted: > >> I think the general opinion (most prominently voiced by >> John Klensin) on the ima mailing list was that the WG should >> review draft-duerst-mailto-bis-01.txt, but not tie it up in >> formalities. >> (see >> http://www1.ietf.org/mail-archive/web/ima/current/msg00087.ht >> ml). >> >> Did you come to a different conclusion, or are you just asking >> to make sure this has been thought about? > > What John said was: > ># I think some of us should just look at the thing, soon, and ># get comments to you, rather than tying things up in ># formalities. > > and it's not clear that that's happened. I'd like to make sure > that it does happen. Adding "mailto" to the IMA WG charter > would be one way of insuring that it does happen. Larry, Informally, it has happened. Formally, it cannot happen because there is no WG to look. Either way, looking now is nearly pointless because there are two separate issues in looking at the IRI form of mailto: (i) Easy problem: Can the mailto IRI handle UTF-8 addresses? The answer is either "yes" or "no". If it is "no", we need to do a little fussing. No big deal either way, IMO. (ii) Hard problem: It seems likely that one or more optional parameters will be introduced into the process to provide information needed to do downgrades. We don't even have a complete downgrade proposal on the table yet, much less one that has been vetted through, and approved and/or adjusted by, a WG. If there are parameters, and arguments to some or all of those parameters, then MAILTO will need to be adjusted to permit them. So you are far ahead of anything resembling a definitive answer in this area. For the record, this is all just my personal opinion. john p.s. whether you put a line in the charter requiring that someone formally take a look makes no difference to me and, with the possible exception of tying MAILTO up until this WG is finished, won't make any difference to what is done, either. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 23 17:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOiE-0003rd-8N; Thu, 23 Feb 2006 17:13:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOiD-0003qE-1a; Thu, 23 Feb 2006 17:13:25 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCOiC-0007Os-Hk; Thu, 23 Feb 2006 17:13:25 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1FCOMw-0003Aa-Az; Thu, 23 Feb 2006 16:51:26 -0500 Date: Wed, 22 Feb 2006 08:42:13 -0500 From: John C Klensin To: Charles Lindsey , iesg@ietf.org Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) Message-ID: <55D3C45CF178DA8111D82857@JCK-ACR.jck.com> In-Reply-To: References: X-Mailer: Mulberry/4.0.4 (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.8 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles, Just a heads-up on part of your comment below. The WG will certainly work hard to find one, and this is personal opinion only, but I don't think there is going to be a "general-purpose downgrading mechanism" for addresses. To have such a mechanism appears to require changing the very strict requirement of RFC 2821 and its predecessors that nothing other than the final delivery MTA ever try to figure out what a local-part means. Given your netnews experience, you are presumably familiar with the difficulties we got into when various systems tried to outsmart the presumed explicit routing of bang-paths and %-hacks, especially when they were mixed. Many of us can also remember difficulties with intermediate systems --sometimes even originating systems that tried to second-guess the user-- that parsed the local part, applied their assumptions about what was going on, and then attempted to remap and optimize it, thereby trashing imbedded commands, subaddresses, and so on. In the general case, if one has an i18n local part and wants to alter it into a traditional one in transit, the same issues apply: the intermediate system has to know how the destination host might interpret that address in order to downgrade it. The current working drafts (versions of ima-framework and ima-smtpext that should appear within the next few days) contain two suggested mechanisms that should help with downgrading, but they are not the general case: requiring either or both causes other problems. The difficulties with downgrading headers are a bit different but, because the future headers to which you refer cannot generally be parsed by a system that has never heard of them, the only fully-general way to downgrade a message body may turn out to require extracting critical information and then encapsulating the rest, using an extended version of message/rfc822 that permits Base64 or Q-P encoding of the headers. If my pessimistic and conservative view is correct, the constraints on "general-purpose fallback downgrading" are such that a requirement for such downgrading are roughly equivalent to "no IETF standard i18n addresses". Please note that I didn't say "no use of i18n addresses": I believe that, should the IETF opt-out of the solution, either by declining to charter the WG or by imposing enough constraints to make a result impossible, the inevitable consequence will be the adoption of a collection of local and non-interoperable solutions, not a globally interoperable solution that admits that, sometimes, there will be non-downgradable messages that will need to be bounced. This issue is discussed further in another forthcoming I-D named draft-klensin-ima-constraints-00 .. I do not expect it to become a WG product, incidentally. regards, john --On Wednesday, February 22, 2006 11:48 AM +0000 Charles Lindsey wrote: >> internationalization. That approach is based on the use of an >> SMTP extension to enable both the use of UTF-8 in envelope >> address local- parts and optionally in domain-parts and the >> use of UTF-8 in mail headers -- both in address contexts and >> wherever encoded-words are permitted today. > > s/both/including/ > > There may well be other headers, whether in current use or to > be invented, and even possibly invented as part of this > exercise, where the UTF-8 approach might be introduced. For > example, headers containing IRIs as oposed to URIs, and the > Newsgroups header, in the event that this work is later > extended to Netnews Tbis is not included in the present > charter, but is a likely extension in the future. The WG > needs to address issues that might arise with such future > headers (e.g. a general-purpose fallback downgrading > mechanism). _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 23 20:14:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCRWZ-0004An-DZ; Thu, 23 Feb 2006 20:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCRWZ-0004Ab-2H; Thu, 23 Feb 2006 20:13:35 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCRWX-000675-Ki; Thu, 23 Feb 2006 20:13:35 -0500 Received: from [192.168.0.3] (adsl-71-131-78-135.dsl.sntc01.pacbell.net [71.131.78.135]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1O1E8QN016091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 17:14:09 -0800 Message-ID: <43FE5DB9.2050003@dcrocker.net> Date: Thu, 23 Feb 2006 17:13:29 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Ted, > Constraints on the interpretation of local-parts by any system other than the > final delivery one make address encoding nearly impossible. ... > I think the idea that the final delivery system may have some unique parsing of > the local part is pretty strong--so you can identify lots of common syntaxes, but you > could never be totally sure you got everyone's idiosyncratic behavior covered. It is certainly known that some characters cause problems. Given that the proposed effort is for experimental, one would expect to see experiments that seek to demonstrate that there is no reasonable solution, before doing larger violence to the email infrastructure. Stated differently: If the concern is that an encoding convention might break in some transit situations, we should validate the concern before adopting a convention that is expected to break in *all* transit situations. > Can you publish the updated BATV draft, so we can see how you got around that? Indeed, that project is already in the queue. >> The approach of this working group is sufficiently radical/disruptive, so as to make it a good idea to have the charter cite or explain why an encoding overlay scheme is not viable. > > Prior to the BoF in Vancouver, John produced draft-klensin-emailaddr-i18n > (available at http://bgp.potaroo.net/ietf/idref/draft-klensin-emailaddr-i18n/), > which went through some of this as background to the BoF discussion. Are > there specific aspects of that draft which it would be valuable to include here, > or would a specific pointer to an updated doc help? I haven't reviewed the paper in quite awhile. As I recall, the document is not trivially short. So a citation to the specific text that substantiates the claim would be appropriate. > My personal answer here is that these are experimental specifications because > of the weight of standardization and deployment in this area. Making a > proposed standard change to header formats at this stage of the game without > some real-world experience to say it is worth it seems pretty risky. But that > doesn't mean this is necessarily IRTF stuff. If someone were to propose IRTF > work in this area, I would personally strongly urge them to start with a > green field and see what vision they could come together on. But that's not > what we are doing here. Ted, here is a list of the existing IRTF groups: * Anti-Spam Research Group (ASRG) * Crypto Forum Research Group * Delay-Tolerant Networking Research Group (DTNRG) * End-to-End Research Group Charter * Host Identity Protocol (HIP) * Internet Measurement Research Group * IP Mobility Optimizations (Mob Opts) Research Group * Network Management Research Group Charter (NMRG) * Peer-to-Peer Research Group * Routing Research Group Charter * Transport Modeling Research Group * Internet Congestion Control Research Group As I understand the goals and activities of most of them, they are attempting to enhance existing services, rather than start 'with a green field'. I know that DTN is an exceptions. I believe crypto, e2e, hip, mobops, p2p, routing, transport and ccrg are not. So, my question stands. WHat I'll add is that one could argue that the pressure to produce "standards" has been one of the problems with recent email internationalization efforts. What should have prompted experimentation with alternatives has instead prompted locking into details before their efficacy has been demonstrated. > I believe we are asking people to engineer a solution within an existing constrained > environment, rather than research potential solutions without regard to the existing > constraints. Again: The IRTF generally does not have the goal of researching potential solutions without regard to existing constraints. There I do not see the relevance of that distinction here. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 24 11:47:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCg6B-0007oM-Cu; Fri, 24 Feb 2006 11:47:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCg6A-0007oE-KH; Fri, 24 Feb 2006 11:47:18 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCg69-0000vR-6p; Fri, 24 Feb 2006 11:47:18 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1OGljxM031602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 08:47:45 -0800 Message-ID: <43FF388A.2090100@dcrocker.net> Date: Fri, 24 Feb 2006 08:47:06 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Folks, > Constraints on the interpretation of local-parts by any system other than the > final delivery one make address encoding nearly impossible. ... > Prior to the BoF in Vancouver, John produced draft-klensin-emailaddr-i18n > (available at http://bgp.potaroo.net/ietf/idref/draft-klensin-emailaddr-i18n/), > which went through some of this as background to the BoF discussion. Are I am finally remembering more of the discussion at a BOF about this topic. The response to the concerns I expressed, then, landed on a statement that went along the lines of "15 years ago, we could not 'just do binary' email, but today we can. In particular, support of UTF is now universal among hosts." Upon thinking about this perspective, further, it occurred to me that the way to resolve the debate over whether to create another encoding overlay -- as we have done in the past -- versus make UTF the "native" form instead of ASCII, is to completely skip the negative side of the discussion. In other words, don't have the debate. Just pursue the positive. One example of why the previous model of "debate" is problematic is that UTF-8 is, itself, merely another encoding form. (Raw UTF is not an 8-bit representation, so UTF-8 is a means of encoding the raw stuff into bytes.) So, debating whether to use UTF-8, which does violence to the existing infrastructure, versus creating an encoding form that fits comfortably over the existing infrastructure, is a relatively problematic process, as we have been seeing for quite awhile. For some years, the incremental enhancement of Internet mail has carried the meta-question of: when will it be more appropriate to change the infrastructure, rather than to add another micro-layer on top of it? I think the current round of difficult internationalization effort legitimately suggests consideration that "we have reached it now", at least with respect to making a move from classic network ascii over to UTF, at least for some data. So, instead of conducting the debate, the charter should strictly focus on a positive line of need, availability and benefit. Here is some text that attempts to provide that alternative view, in the opening paragraphs of the charter: ///// Given the scale and variety of the modern Internet, the email user experience needs to be enhanced, to support addresses and mail header fields comprising characters native to that wide variety of user environments. Basic network ASCII does not permit this, but UTF does. UTF is now widely supported in user systems. Therefore, it is Internet mail's reliance upon classic network ASCII that has become the bottleneck for the user experience, regarding email handling data and other meta-information. The current effort will develop specifications for an SMTP option to permit the direct use of UTF-8 encoded data in RFC2821 envelope address local-parts, domain-parts and RFC2822 mail header fields. It will also explore the ability to downgrade, when attempting to interact with legacy email services. [[ Hmmmm... This also creates a requirement for specifying UTF-native RFC2822 header fields, doesn't it? /d ] Because the specifications attempt to make a significant change to the Internet's mail infrastructure, these specifications will target Experimental RFC status. The work will include examining whether "downgrading" -- transforming a UTF-based message, to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. ///// Charter language notwithstanding, I will, again, note that the question of whether downgrading can be reasonably performed, is sufficiently basic as to make this an IRTF task, rather than an IETF standards task. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 24 12:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgWz-0000TF-BA; Fri, 24 Feb 2006 12:15:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCgWy-0000SC-4v; Fri, 24 Feb 2006 12:15:00 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCgWw-0001xd-IK; Fri, 24 Feb 2006 12:15:00 -0500 Received: from host81-144-67-46.midband.mdip.bt.net ([81.144.67.46]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.211) id 43ff3f0b.db43.47; Fri, 24 Feb 2006 17:14:51 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id k1OCFOg24415; Fri, 24 Feb 2006 12:15:25 GMT To: "John C Klensin" , iesg@ietf.org Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <55D3C45CF178DA8111D82857@JCK-ACR.jck.com> Message-ID: Date: Fri, 24 Feb 2006 12:15:17 -0000 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: <55D3C45CF178DA8111D82857@JCK-ACR.jck.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 22 Feb 2006 13:42:13 -0000, John C Klensin wrote: > Charles, > > Just a heads-up on part of your comment below. > > The WG will certainly work hard to find one, and this is personal > opinion only, but I don't think there is going to be a "general-purpose > downgrading mechanism" for addresses. > > To have such a mechanism appears to require changing the very strict > requirement of RFC 2821 and its predecessors that nothing other than the > final delivery MTA ever try to figure out what a local-part means. > Given your netnews experience, you are presumably familiar with the > difficulties we got into when various systems tried to outsmart the > presumed explicit routing of bang-paths and %-hacks, especially when > they were mixed. Many of us can also remember difficulties with > intermediate systems --sometimes even originating systems that tried to > second-guess the user-- that parsed the local part, applied their > assumptions about what was going on, and then attempted to remap and > optimize it, thereby trashing imbedded commands, subaddresses, and so on. Sure. For the case of headers involving s, the WG will invent special purpose downgrade mechanisms Including alternative addresses, and whatever else is needed, Likewise, for headers involving s, s, etc, it will invent a specific downgrade mechanism (essentially, using RFC 2047). But for headers not yet invented, it will be hard to introduce a special purpose downgrading mechanism, because it will be hard to deploy it in the field. Therefore we need a general purpose mechanism. Clearly, such a mechanism would be unsuitable for any header that needed to be looked at by the transport system, but it would be fine for headers only intended for use by the ultimate user agent (headers for human consumption, for a start), or for headers that were only intended for specialized gateways. One can expect ultimate user agents and specialized gateways to have the capability to understand it (e.g. to upgrade it and then act upon it, or at least display it). An example is the Newsgroups header, if Netnews ever adopts this system. Currently, if sent in UTF-8, it would already work fine with the existing news transport mechanisms (this has already been demonstrated, and there exists a Danish test group with a UTF-8 name). But if you wanted to gateway such a news article to a mailing list, the gateway would have to downgrade it. But, at that point, it ceases to fulfil any purpose for directing the transport and is just for human consumption, so it matters not if it arrives at systems that don't know how to upgrade it (though any user agent that was so capable might well be able to show the reader some information that might be of interest to him). > > In the general case, if one has an i18n local part and wants to alter it > into a traditional one in transit, the same issues apply: the > intermediate system has to know how the destination host might interpret > that address in order to downgrade it. Sure. Any general-purpose fallback downgrading mechanism, would be quite unsuitable for s. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 Fri Feb 24 15:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCj7E-0002fp-Iv; Fri, 24 Feb 2006 15:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCj7D-0002er-0j; Fri, 24 Feb 2006 15:00:35 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCj7B-0007KL-Vp; Fri, 24 Feb 2006 15:00:34 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FCj78-0005Ju-4Q; Fri, 24 Feb 2006 15:00:30 -0500 Date: Fri, 24 Feb 2006 15:00:28 -0500 From: John C Klensin To: dcrocker@bbiw.net Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) Message-ID: <1B34A2809628E40E6255763F@p3.JCK.COM> In-Reply-To: <43FF388A.2090100@dcrocker.net> References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> X-Mailer: Mulberry/4.0.4 (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: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dave, My apologies for not addressing some of your comments sooner -- I've been trying to get documents out that explain what is being suggested here in context, rather than writing lengthy notes to try to deal with separate questions and perspectives. I want to try to respond to what I think are some of your main points in your recent notes. If I have missed things that you consider important, I'd appreciate your patience as I either reread notes and find them or in identifying them again. The issues I've identified below are not completely separate either: a good deal of this falls into the "everything is connected to everything else" problem whether we like it or not. Issue 1: Why UTF-8? At one level, you are correct that UTF-8 is just another encoding. But it is also a very special encoding in the following way: * We started out with ASCII. ASCII in addresses, ASCII in headers, ASCII in those protocol elements and exchanges for which we did not go to essentially binary data structures like ASN.1. This wasn't US-bias: ISO and ITU went down the same path, calling ASCII or restricted ASCII by such names at ISO 646 and IA-5 and using them in almost every protocol that required some sort of control information and didn't use ASN.1 or another highly-structured coding. * For a number of purposes, when early internationalization efforts started, the preferred character sets were ASCII (aka ISO 646 IRV) based. In Europe and North America, the base character set used the high order bit of an 8-bit octet, but, if that bit was off, the code value was identical to ASCII prefixed by a zero bit. ISO 8859-1 and indeed ISO 8859-N, for many values of N, have that property, sometimes called "extended ASCII". In Asia, the same thing was accomplished by use of ISO 2022 switching or shifting sequences: if there were no shifts, the characters had the same codes as ASCII and were interpreted as ASCII. In either case, there is a certain upward-compatibility involved because, if one writes an ASCII character, one uses the ASCII code and an all-ASCII string in the alternate coding system looks (at the bit level) just like an all-ASCII string with ASCII right-justified in an eight-bit byte. This was not a property of, say, EBCDIC or various EBCDIC-based code pages. If one wanted to get back and forth between them the ASCII/ISO646BV/IA5 requirements of some protocol, one had to do actual code translation. And one also needed to hope the all of the relevant characters appeared both character sets in exactly-translate-able form. * Now we get to UTF-8. There are several reasons to dislike it, but it preserves the "ASCII is ASCII" properties of the above. A collection of RFC822 header fields is valid UTF-8, both in the header names and in the data fields. If UTF-8 is used to code the non-ASCII characters in Unicode and some of those characters are put into the data fields of what would otherwise be RFC822 headers the field names remain bit-wise identical with the original 822 forms even though the header set now requires UTF-8 to encode all of the data. Even in the data fields, ASCII data remains ASCII data: we don't need state, or character-code labels, any number of other ways around the problem of keeping ASCII characters in ASCII coding while introducing other characters. That is a very useful, and important, property. It does not exist with UCS-2 or UCS-4 encoding. It would not exist if we somehow forced everything into punycode, or base64, or... We might be able to invent other codings with the same properties, but the reality is that UTF-8 is fairly widely deployed and used and those hypothetical alternatives are not. And, for better or worse, there was some IETF consensus to favor UTF-8 when RFC 2277 was adopted. So it is not really just one more coding. It is ASCII-code- preserving and hence preserving of all of the definitions and properties of 2821 and 2822 except where non-ASCII characters are actually used in a particular address or message. Issue 2: The "impossibility" of downgrading addresses in transport in the general case. You are often credited, I think correctly, with being the inventor of the %-hack for message routing without using the explicit routes of RFC 821. You remember the difficulties we had when bang-paths and percent-hacks were mixed and no one could figure out which one to apply first (or many people could figure it out; they just didn't agree). Probably you remember the times at which organizations with a small number of characters available for addresses tried to encode all sorts of things into them for internal routing purposes. For example, when there was one institutional gateway host, we might have PHYSJB@host and CHEMJD@host to designate Joe Blow in the Physics department and John Doakes in the Chemistry department as effective synonyms for jb%phys@host or chem!jd@host or worse. And then there are "subaddresses" based either on positional arrangements similar to PHSYSJB or on delimiters which, like "%" or "!" have no special meaning in the transport of message header specifications. We have survived all of this so far by strict application of the "no one messes with the local part other than the delivery server" rule. And we have a long history of discovering that violations of that rule, including especially having intermediate hosts try to "improve" on !a!b!c%d@e by rewriting it into a!b!c%d%e@a and similar things or to optimize the same thing by presuming knowledge about the path and rewriting it into x!c@f get us into huge trouble. If we internationalize this, we can't make any guarantees about the delimiters that will be used for explicit routing, or to delimit subaddresses, and given the positional approach, even that such characters will appear at all. Can we code this stuff into some sort of ACE, or downgrade to one, and move it along? Yes, but we can't do it naively: the destination system must know what was done to the address and must also agree to decode the ACE before it has to decide what to do with the address. If there is some analogy of a%b as explicit routing in the local part, the delivery server must be able to decode the ACE and find the trick characters before, e.g., it tries to drop the message into the local mail store. Can that be done? Of course. But it implies not only that everyone is using the same ACE-encoding conventions, but that all of the delivery servers that can accept mail are doing decoding and doing that decoding early enough: there is, for example, no general way to simply drop the ACE into the mail store and let the MUA do the decoding -- far too late to do most sorts of mail routing by that time. Moreover, we have never tried to standardize the order in which delivery MTAs do their decoding and delivery steps. We could start now as part of an internationalization activity but, as a matter of personal taste and a preference for not constraining diversity of conforming implementations when it can be avoided, I'd rather not. That, however, is very much a matter of taste -- "impossible" ultimately means "not without applying a number of other constraints, or more significant rewriting of the mail system, including new ports and/or maybe flag days, that we might not like or be able to accept". And that brings us to the next issue... (3) Why target "experimental", what does that mean, and why not dump this on the IRTF? I suggest that there are research-experiments and engineering-experiments, and that they are different. If the question here was "can we figure out some way to do internationalized email and demonstrate that", it would, IMO, clearly be a research issue. If the question were "what is the absolutely optimal way to do internationalized email" then that is a research question too (and one about whose utility in engineering I think we agree about). What we have here, however, is a strong hypothesis about a way to do the job and what constraints are, and are not, appropriate to go with it. There have been experimental implementations of some of the ideas: they show us that, at least for some email implementations, that they can be implemented and give us an idea about complexity of implementation. But we haven't examined all of the cases we can identify and probably haven't identified all of the cases. This is, IMO, precisely the point at which an IETF WG is useful: the small group discussions about framework, starting point, and feasibility are done. There isn't complete agreement within the design group about how far some of the strategies can be pushed and we need IETF input about that and about the case analyses. There are a number of tricky issues about protocols, interfaces, and interactions with the user, and broader IETF input is needed there too. But these are engineering problems, not research ones, unless one pushes anything that involves design decisions and some need to tinker over into "research". The reason to go for experimental within the IETF is a bit different. There may be other ways to get address internationalization. My belief is that there are not perfect solutions, so each set will probably come with a different set of constraints and things that it makes hard to do. The quest for the best solution before we start working out the details of any of them is pointless (and we have already wasted a lot of time trying to do that). So the goal is produce a complete set of specifications for one approach, see how it works, and only then examine the questions of what other approaches are feasible, out there, reasonable candidates for alternatives. If there are, then there will be a question of what to standardize. But, in the meantime, it is an explicit plan for this WG to deal with someone coming along and saying "I have this completely different idea even though it isn't written up and may or may not be as good as yours, please stop and consider it" with "go away, make your own WG to consider it and see if it gets any traction". Understanding that the analogy is not exact, this situation is both similar to and different from DKIM: on the one hand, a good deal of design work and testing have been done within a design team, many of whose members are active in the IETF. We are ready to open things up and get IETF input and make changes as needed within the general model. But we want to preserve that model --if only to avoid thrashing-- until we are certain that it will or will not usefully work. And experimental, with some constraints on the range of discussions and outcomes, seems to us (and the ADs and others who have been consulted) to be the right way to approach that. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 24 15:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjKY-0004g3-Fd; Fri, 24 Feb 2006 15:14:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjKW-0004fs-Ms; Fri, 24 Feb 2006 15:14:20 -0500 Received: from nic-naa.net ([65.99.1.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCjKV-0007gy-FN; Fri, 24 Feb 2006 15:14:20 -0500 Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.13.4/8.13.4) with ESMTP id k1OK8K3h022772; Fri, 24 Feb 2006 15:08:20 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-Id: <200602242008.k1OK8K3h022772@nic-naa.net> To: John C Klensin Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) In-Reply-To: Your message of "Fri, 24 Feb 2006 15:00:28 EST." <1B34A2809628E40E6255763F@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22770.1140811700.1@nic-naa.net> Date: Fri, 24 Feb 2006 15:08:20 -0500 From: Eric Brunner-Williams X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ima@ietf.org, Aaron Falk , dcrocker@bbiw.net, iesg@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John, When I looked at the national standards in Asia, I found most had the property you point out as a desirable property of utf-8, that is, the code points defined in ASCII are defined as in ASCII. Eric _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 24 15:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjdj-0001aG-CM; Fri, 24 Feb 2006 15:34:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjdi-0001a8-9Z; Fri, 24 Feb 2006 15:34:10 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCjdg-0008I2-S3; Fri, 24 Feb 2006 15:34:10 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1OKYMPl026917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 12:34:25 -0800 Message-ID: <43FF6DA8.4000206@dcrocker.net> Date: Fri, 24 Feb 2006 12:33:44 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John C Klensin Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> In-Reply-To: <1B34A2809628E40E6255763F@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John, et al, > Issue 1: Why UTF-8? ... > So it is not really just one more coding. I had neglected to mention that UTF-8 has the nice property of being upward compatible with ASCII. And that point certainly adds to its appeal. But I think this is actually secondary to the main point I (finally) cited : UTF-8 has become the universal, host-based equivalent, today, of what ASCII was 30 years ago. And since the needs of today require using its enhanced capabilities, using it directly makes more sense than emulating it or layering it over ASCII. > Issue 2: The "impossibility" of downgrading addresses in > transport in the general case. Fun history lesson. And, yes, it underscores the difficulty in doing a local-part overlay encoding. (By the way, as I recall, the research I did in 1978, that finally chose the %, produced a list of perhaps 3 letters that were viable candidates. But, then, I had to team with the terminal interface, and we are at least spared that indignity, today. Still, I think there is no question that finding free characters to use as syntactic markers is challenging at best.) > Can we code this stuff into some sort of ACE, or downgrade to > one, and move it along? Yes, but we can't do it naively: the > destination system must know what was done to the address and > must also agree to decode the ACE before it has to decide what > to do with the address. I think the issues are more interesting than that: 1. If downgrading can be done well enough to preserve all of the information, then the 'native utf-8' mode is merely an efficiency hack, modulo the considerable burden of having to translate between the two forms. That burden is sufficient to force one to ask why it is necessary to have parallel encodings. 2. If downgrading cannot be done that well, then what is being proposed is a new Internet mail infrastructure, with gateway translation between them. We have some experience doing email gatewaying. We know how to make it work. Or rather, we know how challenging it is to make it at all useful. Calling such an effort "research", when one of the two sides does not already have extensive history, is not all that creative. > (3) Why target "experimental", what does that mean, and why not > dump this on the IRTF? I suggest that there are > research-experiments and engineering-experiments, and that they > are different. > > If the question here was "can we figure out some way to do > internationalized email and demonstrate that", it would, IMO, > clearly be a research issue. If the question were "what is the > absolutely optimal way to do internationalized email" then that > is a research question too (and one about whose utility in > engineering I think we agree about). What we have here, > however, is a strong hypothesis about a way to do the job and > what constraints are, and are not, appropriate to go with it. All that is reasonable. What I think is that there is nowhere near enough operational experience to know that this is constrained enough to call "engineering". Although the approach re-uses much of the existing Internet mail technology, it really is re-inventing the service. That is, I think that the infrastructure's reliance on net-ASCII is so deeply ingrained as to make switching to UTF-8 a near-term research effort. As I noted before, I think that much of the dns and email internationalization efforts have suffered from trying to be IETF working groups, because the community knowledge and focus were not (yes) sufficient for that model of effort. The same concern applies here. > There have been experimental implementations of some of the > ideas: they show us that, at least for some email > implementations, that they can be implemented and give us an > idea about complexity of implementation. But we haven't > examined all of the cases we can identify and probably haven't > identified all of the cases. This is, IMO, precisely the point > at which an IETF WG is useful: the small group discussions about > framework, starting point, and feasibility are done. I apologize for missing this, but which of the existing references documents the results of this extensive research work? d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 24 16:39:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkf5-00033R-DA; Fri, 24 Feb 2006 16:39:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCkf4-00032p-2B; Fri, 24 Feb 2006 16:39:38 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCkf2-00035M-NZ; Fri, 24 Feb 2006 16:39:38 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FCkf0-0005Tj-6s; Fri, 24 Feb 2006 16:39:34 -0500 Date: Fri, 24 Feb 2006 16:39:33 -0500 From: John C Klensin To: Eric Brunner-Williams Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) Message-ID: <106501D92D804283C1ED339B@p3.JCK.COM> In-Reply-To: <200602242008.k1OK8K3h022772@nic-naa.net> References: <200602242008.k1OK8K3h022772@nic-naa.net> X-Mailer: Mulberry/4.0.4 (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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ima@ietf.org, Aaron Falk , dcrocker@bbiw.net, iesg@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 24 February, 2006 15:08 -0500 Eric Brunner-Williams wrote: > John, > > When I looked at the national standards in Asia, I found most > had the property you point out as a desirable property of > utf-8, that is, the code points defined in ASCII are defined > as in ASCII. Yes. If I appeared to say anything different, I didn't intend to. The intent about my observation about traditional practices in East Asia is that, while the European internationalization trend was to go first to 8-bit character sets (of the ISO 8859 family and national and other variants on it), East Asian practice branched into two other directions: 16-bit character sets and, especially in Japan, the use of stateful, ISO 2022-based, code table switching to access a much larger set of characters than are needed for European languages. While UTF-8 is clearly a step forward from the ASCII->8859 trend, debate continues about whether it represents a step forward from the earlier East Asian character sets or a step in some other direction. Part, but only part, of the reasons for that debate is due to the fact that UTF-8 tends to take up a lot of octets per character once one gets to the East Asian characters. Another part, but still only part, is dissatisfaction with "Han unification" in some parts of the CJK community. For the record, I'm taking no position at all about those debates, just identifying them because it is unwise to pretend that they are not part of the picture. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 24 17:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl0T-00027W-AJ; Fri, 24 Feb 2006 17:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCl0R-00026S-Tz; Fri, 24 Feb 2006 17:01:43 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCl0Q-0003Pt-Hy; Fri, 24 Feb 2006 17:01:43 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1OM2GQ6004022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 14:02:17 -0800 Message-ID: <43FF8241.1030005@dcrocker.net> Date: Fri, 24 Feb 2006 14:01:37 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John C Klensin Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> In-Reply-To: <1B34A2809628E40E6255763F@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > My apologies for not addressing some of your comments sooner -- John, I meant to ask about a point you didn't comment on: I offered some candidate text for the first 2 paragraphs. Whether the text applies to an ietf group charter or an irtf strikes me as secondary. If the charter text works well, it means there is coherence to the project. Where it is housed is important, but separate. Any comments on the alternative text? Any comments from anyone else? d/ ps. To spare folks from searching for the previous message: ///// Given the scale and variety of the modern Internet, the email user experience needs to be enhanced, to support addresses and mail header fields comprising characters native to that wide variety of user environments. Basic network ASCII does not permit this, but UTF does. UTF is now widely supported in user systems. Therefore, it is Internet mail's reliance upon classic network ASCII that has become the bottleneck for the user experience, regarding email handling data and other meta-information. The current effort will develop specifications for an SMTP option to permit the direct use of UTF-8 encoded data in RFC2821 envelope address local-parts, domain-parts and RFC2822 mail header fields. It will also explore the ability to downgrade, when attempting to interact with legacy email services. [[ Hmmmm... This also creates a requirement for specifying UTF-native RFC2822 header fields, doesn't it? /d ] Because the specifications attempt to make a significant change to the Internet's mail infrastructure, these specifications will target Experimental RFC status. The work will include examining whether "downgrading" -- transforming a UTF-based message, to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. ///// -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 26 16:02:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDT1w-0002eW-DR; Sun, 26 Feb 2006 16:02:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDT1u-0002Zn-T9; Sun, 26 Feb 2006 16:02:11 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDT1u-0006ji-6N; Sun, 26 Feb 2006 16:02:10 -0500 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1FDT1d-000ACn-Q3; Sun, 26 Feb 2006 16:01:57 -0500 Date: Sun, 26 Feb 2006 15:21:02 -0500 From: John C Klensin To: dcrocker@bbiw.net Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) Message-ID: In-Reply-To: <43FF8241.1030005@dcrocker.net> References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF8241.1030005@dcrocker.net> X-Mailer: Mulberry/4.0.4 (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: f49c97ce49302a02285a2d36a99eef8c Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, February 24, 2006 2:01 PM -0800 Dave Crocker wrote: > > My apologies for not addressing some of your comments > sooner -- > > John, > > I meant to ask about a point you didn't comment on: > > I offered some candidate text for the first 2 paragraphs. > > Whether the text applies to an ietf group charter or an irtf > strikes me as secondary. If the charter text works well, it > means there is coherence to the project. Where it is housed > is important, but separate. > > Any comments on the alternative text? > > Any comments from anyone else? I had hoped that "someone else" would say something, perhaps even something that would be more constructive from the standpoint of overall principles. But, since they haven't and your suggestion has not received any response... To me, a WG Charter serves three main purposes. They are, not in order of importance: (1) To provide a mechanism by which the community can figure out how it wants to invest its resources, whether the proposed subject matter is appropriate for the IETF, etc. (2) To provide sufficient definition of what is to be done, and to structure the work sufficiently, that the community can be assured the WG won't go wandering off into the proverbial weeds. (3) To assure the community that there are sufficient resources, both in terms of ideas and people, to have reasonable odds of being able to complete the work in a timely fashion. Each of these three exists in context. For example, the community may, justifiably, be much more skeptical of a charter proposal to do something completely new to the IETF and coming from people with no prior IETF experience than of one that is at some opposite end of the spectrum. And, to me, a charter should be as good as necessary to do the job above (and any other jobs the community may require-- any better is just a waste of time that could be better spent on the technical/engineering work. I actually get very anxious when we start talking about, e.g., a charter as a contract between the WG and the community (although I have certainly, and nervously, used that language in the past). If the IETF is operating the way I would prefer that it operate, charters can be reasonably informal as long as we have ADs who are willing to monitor progress, make decisions, and shut down WGs that are either not producing or not pronouncing anything the community wants to see. Now, it seems to me that your proposed alternate text addresses the second of these issues. Personally, although it needs a bit of editorial work, I like it at least as much as I like the text that is now in the proposed charter. But I don't think it is significantly better. So, one of my reactions is "would the WG be less likely to wander into the weeds with one set or text or the other". The answer I get to that question is "nope". That is a "nope" partially based on what I know of the context I referred to above: I am reasonably familiar with the proposed leadership of this group, I know that Harald and I have a lot of experience with the sorts of weeds that grow around the IETF and have both rather sever allergies to them and (at least in my case) exaggerated ideas about the value of my time. Consequently, regardless of what the charter says, I am confident that, should the WG head off toward the weeds and we be unable to stop it, we would rather quickly be having "shut this down, it is hopeless" conversations with the relevant AD. The result is that I can't get excited about fine-tuning charter language for that purpose. That brings me to my other reaction (and why I haven't responded to this). That reaction was one which we have both decried when it comes out of WGs or document editors late in the standards process in response to an end-stage proposed change by the IESG or RFC Editor. That reaction is, more or less, "well this doesn't make things significantly worse, so, if it makes you happy, well, whatever". If your suggested text were somehow bad news for the effort, I would have commented. If I saw it as somehow far superior to what had been written earlier, I would have commented. But, as it is, my reaction was "if this amuses either the community, or the ADs, or makes someone feel significantly more comfortable, then... why not". And that, it didn't seem to me called for much comment until and unless we found out who else it would make much more comfortable (or uncomfortable). Two substantive comments about your suggested text... > Because the specifications attempt to make a significant > change to the Internet's mail infrastructure,... I suspect we disagree about how significant this change is to the infrastructure. That may be partially a matter of definitions, but I see these changes as much less significant than the ones that created the SMTP extension mechanism and MIME and less risky than the moves we make when a new MIME multipart/ substructure is introduced. I also see it as a great deal less infrastructure-problematic than the handling of some specially-formatted stream transmissions types as text/ subtypes, for some of the same reasons. I note that none of them were sent to Experimental first (although that really is not the reason for Experimental here, as explained elsewhere). And I agree that this requires extreme caution and a good deal of analysis and examination along the way, regardless of what things are called, so any disagreement may not be substantively important. > [[ Hmmmm... This also creates a requirement for specifying > UTF-native RFC2822 header fields, doesn't it? /d ] I hope not. Part of the reason Internet mail has succeeded so far is that we have traditionally treated those header field names as protocol elements that can be _translated_ into other languages, but not expressed in those languages in transit. If we cross over into producing UTF-8 header field names, I think it would be only a short period of time before messages start flying around the network with the names of header fields that are specified in 2822 written in other languages or scripts. And I think that would lead quickly to an interoperability nightmare. But, fortunately, that isn't proposed for a work item for this WG and I hope we can keep it that way. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 26 16:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDTjF-0008K7-AM; Sun, 26 Feb 2006 16:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDTjD-0008BR-Ek; Sun, 26 Feb 2006 16:46:55 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDTjA-00087M-0y; Sun, 26 Feb 2006 16:46:55 -0500 Received: from [192.168.0.2] (adsl-71-131-36-58.dsl.sntc01.pacbell.net [71.131.36.58]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1QLlBJi004359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Feb 2006 13:47:11 -0800 Message-ID: <440221B8.1090101@dcrocker.net> Date: Sun, 26 Feb 2006 13:46:32 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: John C Klensin Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF8241.1030005@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John, > I actually get very anxious when we start talking about, e.g., a charter > as a contract between the WG and the community (although I have > certainly, and nervously, used that language in the past). If the IETF That precise language, for describing a charter, has been integral to the IETF for at least 12 years. Take a look at Section 2.2 of WG Guidelines and Procedures. When we wrote that language into the original WG G&P RFC, it used such strong language specifically in order to make clear both the constraints and the obligations that chartering a working group imposes. > is operating the way I would prefer that it operate, charters can be > reasonably informal as long as we have ADs who are willing to monitor > progress, make decisions, and shut down WGs that are either not > producing or not pronouncing anything the community wants to see. Sorry. I thought we had community consensus that there were problems with excessive ADs "flexibility" as well as their being excessively overworked. Carefully crafted charters can ameliorate both of these problems. > Consequently, > regardless of what the charter says, I am confident that, should the WG > head off toward the weeds and we be unable to stop it, we would rather > quickly be having "shut this down, it is hopeless" conversations with > the relevant AD. The result is that I can't get excited about > fine-tuning charter language for that purpose. 1. It is rather more than fine-tuning, especially for the large portion of the community who does not already have extensive background in this topic 2. Taken to its logical conclusion, your line of comments means that whenever the IESG decides it has plenty of trust in the working group chairs, there is no need for a charter. (I suspect that is not what you intended to mean.) As nearly as I can tell, what you are ignoring is just how difficult and problematic this space has already proven to be. This ought to make folks seek as much structural help as possible. I can't fathom a viable operational model that takes the charter text so lightly. > Two substantive comments about your suggested text... > >> Because the specifications attempt to make a significant >> change to the Internet's mail infrastructure,... > > I suspect we disagree about how significant this change is to the > infrastructure. That may be partially a matter of definitions, but I > see these changes as much less significant than the ones that created > the SMTP extension mechanism and MIME and less risky than the moves we MIME did not change the infrastructure, John. And the SMTP Extension mechanism was designed extremely carefully, specifically to attend to its potential impact on infrastructure change. I do not see anything like that yet showing up about IMA. > make when a new MIME multipart/ substructure is introduced. When IMA breaks, mail will not get delivered. When a multipart substructure is unknown to a receiving MUA, a portion of the message cannot (currently) be read. Frequently, the user has an ability to use an out-of band mechanism to interpret that substructure. So, I think you have the relative negative impacts of the two reversed. I also see > it as a great deal less infrastructure-problematic than the handling of > some specially-formatted stream transmissions types as text/ subtypes, > for some of the same reasons. I note that none of them were sent to How does a mime type affect deliverability? >> [[ Hmmmm... This also creates a requirement for specifying >> UTF-native RFC2822 header fields, doesn't it? /d ] > > I hope not. The current draft text says "and the use of UTF-8 in mail headers". How can this be achieved in any way other than specifying native RFC2822 header fields? Or, rather, if that is not what is meant by the charter text, then it is another example of needing to make the charter text more specific and clear. > But, fortunately, that isn't proposed for a work item for this WG and I > hope we can keep it that way. If the work is not to be done, it would probably be advisable not to have it cited in the charter as something to be done. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 26 19:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDWEL-00081D-57; Sun, 26 Feb 2006 19:27:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDWEK-0007yA-6S for ima@ietf.org; Sun, 26 Feb 2006 19:27:12 -0500 Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FDWEG-0003tK-38 for ima@ietf.org; Sun, 26 Feb 2006 19:27:12 -0500 Received: (eyou send program); Mon, 27 Feb 2006 08:26:59 +0800 Message-ID: <341000019.26061@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Mon, 27 Feb 2006 08:26:59 +0800 Message-ID: <004a01c63b34$cda21ed0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Ted Hardie" References: <340796607.01359@cnnic.cn> Subject: Re: Re: [IEE] WG Review: Email Address Internationalization (eai) Date: Mon, 27 Feb 2006 08:28:59 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.0 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0537203599==" Errors-To: ima-bounces@ietf.org --===============0537203599== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBUZWQsDQoNCiAgIEkgaGF2ZSBhZGRlZCB5b3VyIGVtYWlsICBpbiB0aGUgTGlzdCBvZiBu b24tbWVtYmVyIGFkZHJlc3NlcyB3aG9zZSBwb3N0aW5ncyBzaG91bGQgYmUgYXV0b21hdGljYWxs eSBhY2NlcHRlZC4gDQoNCllhbyBKaWFua2FuZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KRnJvbTogIlRlZCBIYXJkaWUiIDxoYXJkaWVAcXVhbGNvbW0uY29tPg0KVG86IDxpbWEt b3duZXJAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI0LCAyMDA2IDExOjU2IFBN DQpTdWJqZWN0OiBGd2Q6IFJlOiBbSUVFXSBXRyBSZXZpZXc6IEVtYWlsIEFkZHJlc3MgSW50ZXJu YXRpb25hbGl6YXRpb24gKGVhaSkNCg0KDQo+IENvdWxkIHlvdSBhZGQgbWUgdG8gdGhlIGZpbHRl ciwgcGxlYXNlPw0KPiBUaGFua3MsDQo+IFRlZCBIYXJkaWUNCj4gDQo+ID5TdWJqZWN0OiBSZTog W0lFRV0gV0cgUmV2aWV3OiBFbWFpbCBBZGRyZXNzIEludGVybmF0aW9uYWxpemF0aW9uIChlYWkp DQo+ID5Gcm9tOiBpbWEtb3duZXJAaWV0Zi5vcmcNCj4gPlRvOiBoYXJkaWVAcXVhbGNvbW0uY29t DQo+ID5EYXRlOiBGcmksIDI0IEZlYiAyMDA2IDEwOjU0OjM0IC0wNTAwDQo+ID5YLUJlZW5UaGVy ZTogaW1hQGlldGYub3JnDQo+ID5MaXN0LUlkOiAiSUVFIFwoSW50ZXJuYXRpb25hbGl6ZWQgRW1h aWwgYW5kIEV4dGVuc2lvbnNcKSIgPGltYS5pZXRmLm9yZz4NCj4gPg0KPiA+WW91IGFyZSBub3Qg YWxsb3dlZCB0byBwb3N0IHRvIHRoaXMgbWFpbGluZyBsaXN0LCBhbmQgeW91ciBtZXNzYWdlIGhh cw0KPiA+YmVlbiBhdXRvbWF0aWNhbGx5IHJlamVjdGVkLiAgSWYgeW91IHRoaW5rIHRoYXQgeW91 ciBtZXNzYWdlcyBhcmUNCj4gPmJlaW5nIHJlamVjdGVkIGluIGVycm9yLCBjb250YWN0IHRoZSBt YWlsaW5nIGxpc3Qgb3duZXIgYXQNCj4gPmltYS1vd25lckBpZXRmLm9yZy4NCj4gPg0KPiA+DQo+ ID5SZWNlaXZlZDogZnJvbSBbMTAuOTEuMzQuNDRdIChoZWxvPWlldGYtbXguaWV0Zi5vcmcpDQo+ ID4gYnkgbWVnYXRyb24uaWV0Zi5vcmcgd2l0aCBlc210cCAoRXhpbSA0LjQzKQ0KPiA+IGlkIDFG Q2ZIOC0wMDA1UnItNmo7IEZyaSwgMjQgRmViIDIwMDYgMTA6NTQ6MzQgLTA1MDANCj4gPlJlY2Vp dmVkOiBmcm9tIGl0aGlsaWVuLnF1YWxjb21tLmNvbSAoWzEyOS40Ni41MS41OV0pDQo+ID4gYnkg aWV0Zi1teC5pZXRmLm9yZyB3aXRoIGVzbXRwIChFeGltIDQuNDMpDQo+ID4gaWQgMUZDZkg2LTAw MDduaS1TZTsgRnJpLCAyNCBGZWIgMjAwNiAxMDo1NDozNCAtMDUwMA0KPiA+UmVjZWl2ZWQ6IGZy b20gc2FicmluYS5xdWFsY29tbS5jb20gKHNhYnJpbmEucXVhbGNvbW0uY29tIFsxMjkuNDYuNjEu MTUwXSkNCj4gPiBieSBpdGhpbGllbi5xdWFsY29tbS5jb20gKDguMTIuMTAvOC4xMi41LzEuMCkg d2l0aCBFU01UUCBpZA0KPiA+IGsxT0ZzVWM0MDI0NjkyDQo+ID4gKHZlcnNpb249VExTdjEvU1NM djMgY2lwaGVyPURIRS1SU0EtQUVTMjU2LVNIQSBiaXRzPTI1NiB2ZXJpZnk9RkFJTCk7DQo+ID4g RnJpLCAyNCBGZWIgMjAwNiAwNzo1NDozMSAtMDgwMA0KPiA+UmVjZWl2ZWQ6IGZyb20gWzY3LjE4 OC4xNTIuMjM3XSAodnBuLTEwLTUwLTE2LTg3LnF1YWxjb21tLmNvbSBbMTAuNTAuMTYuODddKQ0K PiA+IGJ5IHNhYnJpbmEucXVhbGNvbW0uY29tICg4LjEzLjUvOC4xMi41LzEuMCkgd2l0aCBFU01U UCBpZA0KPiA+IGsxT0ZzU3F2MDA2NzYxOyBGcmksIDI0IEZlYiAyMDA2IDA3OjU0OjI5IC0wODAw IChQU1QpDQo+ID5NaW1lLVZlcnNpb246IDEuMA0KPiA+TWVzc2FnZS1JZDogPHAwNjIzMDkwMmMw MjRkYjA2N2VkZUBbNjcuMTg4LjE1Mi4yMzddPg0KPiA+SW4tUmVwbHktVG86IDw0M0ZFNURCOS4y MDUwMDAzQGRjcm9ja2VyLm5ldD4NCj4gPlJlZmVyZW5jZXM6IDxFMUZCYnQxLTAwMDZZeC02cUBp ZXRmLm9yZz4gPDQzRkUwMjVGLjkwMDA1MDRAZGNyb2NrZXIubmV0Pg0KPiA+IDxwMDYyMzA5MDVj MDI0MDAwZGIzZjBAWzEyOS40Ni4yMjUuNjldPiA8NDNGRTVEQjkuMjA1MDAwM0BkY3JvY2tlci5u ZXQ+DQo+ID5EYXRlOiBGcmksIDI0IEZlYiAyMDA2IDA3OjU0OjI3IC0wODAwDQo+ID5UbzogZGNy b2NrZXJAYmJpdy5uZXQNCj4gPkZyb206IFRlZCBIYXJkaWUgPGhhcmRpZUBxdWFsY29tbS5jb20+ DQo+ID5TdWJqZWN0OiBSZTogW0lFRV0gV0cgUmV2aWV3OiBFbWFpbCBBZGRyZXNzIEludGVybmF0 aW9uYWxpemF0aW9uIChlYWkpDQo+ID5DYzogaWVzZ0BpZXRmLm9yZywgaW1hQGlldGYub3JnDQo+ ID5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KPiA+WC1TcGFt LVNjb3JlOiAwLjAgKC8pDQo+ID5YLVNjYW4tU2lnbmF0dXJlOiA4YWM0OTkzODExMTIzMjhkZDYw YWVhNWIxZmY1OTZlYQ0KPiA+DQo+ID5EYXZlLA0KPiA+IEkndmUgc2VudCBhIGNvcHkgb2YgdGhl IGNoYXJ0ZXIgdG8gQWFyb24gRmFsaywgYW5kIEkndmUgYXNrZWQgaGltIHRvDQo+ID5yZXZpZXcg aXQgd2l0aCBhbiBleWUgdG8gd2hldGhlciBoZSB3b3VsZCBwcmVmZXIgdG8gdGFrZSBpdCBpbiB0 byB0aGUgSVJURiBhbmQvb3INCj4gPmJlbGlldmVzIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIGZv ciB0aGUgSUVURi4gDQo+ID4gcmVnYXJkcywNCj4gPiBUZWQgSGFyZGllDQo+IA0KPiA= --===============0537203599== 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 --===============0537203599==-- From ima-bounces@ietf.org Mon Feb 27 03:17:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDdZa-0008Da-05; Mon, 27 Feb 2006 03:17:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDdZZ-0008Cv-2c for ima@ietf.org; Mon, 27 Feb 2006 03:17:37 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FDdZX-0000Bk-5M for ima@ietf.org; Mon, 27 Feb 2006 03:17:37 -0500 Received: (snipe 6377 invoked by uid 0); 27 Feb 2006 17:17:33 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 1.438806 secs); Received: from unknown (HELO ?220.69.185.37?) (Z?G?own@220.69.185.37) by unknown with SMTP; 27 Feb 2006 17:17:31 +0900 X-RCPTTO: dcrocker@bbiw.net, klensin@jck.com, falk@ISI.EDU, iesg@ietf.org, ima@ietf.org Message-ID: <4402B595.8050407@icu.ac.kr> Date: Mon, 27 Feb 2006 17:17:25 +0900 From: Yangwoo Ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF8241.1030005@dcrocker.net> <440221B8.1090101@dcrocker.net> In-Reply-To: <440221B8.1090101@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dave Crocker wrote: >> Two substantive comments about your suggested text... >> >>> Because the specifications attempt to make a significant >>> change to the Internet's mail infrastructure,... >> >> >> I suspect we disagree about how significant this change is to the >> infrastructure. That may be partially a matter of definitions, but I >> see these changes as much less significant than the ones that created >> the SMTP extension mechanism and MIME and less risky than the moves we > > > MIME did not change the infrastructure, John. > > And the SMTP Extension mechanism was designed extremely carefully, > specifically to attend to its potential impact on infrastructure > change. I do not see anything like that yet showing up about IMA. I totally agree with Dave in the point that current IMA proposal is to change Internet's mail infrastructure. Any new protocol requires changes in some part of the world. Sometimes it is done at infrastructure, some other times at somewhere else, and some yet another times at both. Any one who wants to use or to support IMA will need to update their parts (e.g. MUA/MTA/mail store/mail address registration interface/and many more). Dicussion between Dave and John, quoted above, can be understood as how significant it will be? I'd rather interpret the "significance" in somewhat different aspect. As we assume, it seems to be relatively easy to do IMA only between agreed parties. The real devil lies at the boundary. However good news is that, as a design team of this extention, we have a knob that controls how significantly we want to change the infrastructure. For example, in one extreme, we can just drop any mail that tries to cross the boundary. On the other extreme, every part of the Internet infrastructure is required to be upgraded somehow to support IMA so perfectly that users cannot even recognize that there is such boundary. In order to make IMA more usable, we want to deviate from the former extreme as much as possible. In order to make IMA be more practical, we cannot but deviate from the other extreme. Even though the current set of proposed documents is not yet clearly fixed the position of the knob, we have shown rough range within which we can move the knob back and forth. However, I would say that EAI(? IMA?) WG should be given a chance to gather wise suggestions on the proper position of the knob not only before its charter being fixed but also thorough its process toward the closeout. (If now, what is WG for?) Or, some wise ideas can come up only after having experimental IMA. In that sense, Dave's input will be helpful in finding the final position of the knob regardless of its being reflected in the WG charter or not. Best Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 27 03:21:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDddE-0001hp-DT; Mon, 27 Feb 2006 03:21:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDddD-0001hI-UN; Mon, 27 Feb 2006 03:21:23 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDddC-0000HG-AL; Mon, 27 Feb 2006 03:21:23 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k1R8HCu24083; Mon, 27 Feb 2006 17:17:12 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 11e2_740505b2_a769_11da_8c49_0014221f2a2d; Mon, 27 Feb 2006 17:17:11 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k1R8ElpL021507; Mon, 27 Feb 2006 17:16:07 +0900 Message-Id: <6.0.0.20.2.20060227125525.08b2e6e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 27 Feb 2006 13:03:52 +0900 To: dcrocker@bbiw.net, John C Klensin From: Martin Duerst Subject: UTF (was: Re: [IEE] WG Review: Email Address Internationalization (eai)) In-Reply-To: <43FF8241.1030005@dcrocker.net> References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF8241.1030005@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org In the text proposed by Dave, as well as in other mails, I have seen the abbreviation "UTF" used. "UTF" used alone doesn't mean anything. Please don't use it alone. Similar for terms like "UTF-native" or "UTF-based" or "raw UTF". Please either be specific ("UTF-8", "UTF-8-based",...) or, if you want to be general, use the acronym UCS (Universal Character Set or Unicode Character Set). And as for "raw UTF", or "raw Unicode" or whatever, there just isn't any such thing except in our heads; if the data is in electronic form, there always is an encoding, be it UTF-8 or UTF-16BE or UTF-16LE or UTF-32BE,... Regards, Martin. At 07:01 06/02/25, Dave Crocker wrote: >ps. To spare folks from searching for the previous message: > > >///// > >Given the scale and variety of the modern Internet, the email user experience needs to be enhanced, to support addresses and mail header fields comprising characters native to that wide variety of user environments. Basic network ASCII does not permit this, but UTF does. UTF is now widely supported in user systems. Therefore, it is Internet mail's reliance upon classic network ASCII that has become the bottleneck for the user experience, regarding email handling data and other meta-information. The current effort will develop specifications for an SMTP option to permit the direct use of UTF-8 encoded data in RFC2821 envelope address local-parts, domain-parts and RFC2822 mail header fields. It will also explore the ability to downgrade, when attempting to interact with legacy email services. [[ Hmmmm... This also creates a requirement for specifying UTF-native RFC2822 header fields, doesn't it? /d ] > >Because the specifications attempt to make a significant change to the Internet's mail infrastructure, these specifications will target Experimental >RFC status. The work will include examining whether "downgrading" -- transforming a UTF-based message, to one that is compatible with unextended >SMTP clients and servers and unextended MUAs -- is feasible and >appropriate and, if it is, specifying a way to do so. If it is not, >the WG will evaluate whether the effort is worth taking forward. > >///// >-- > >Dave Crocker >Brandenburg InternetWorking > > >_______________________________________________ >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 Mon Feb 27 03:21:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDddR-000236-QV; Mon, 27 Feb 2006 03:21:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDddQ-00022Y-ML; Mon, 27 Feb 2006 03:21:36 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDddP-0000Hd-3p; Mon, 27 Feb 2006 03:21:36 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k1R8HQd24988; Mon, 27 Feb 2006 17:17:26 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 08fb_7cbeb784_a769_11da_99df_0014221fa3c9; Mon, 27 Feb 2006 17:17:26 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id k1R8ElpP021507; Mon, 27 Feb 2006 17:17:00 +0900 Message-Id: <6.0.0.20.2.20060227132450.08b94e80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 27 Feb 2006 14:07:20 +0900 To: dcrocker@bbiw.net, John C Klensin From: Martin Duerst Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) In-Reply-To: <43FF6DA8.4000206@dcrocker.net> References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF6DA8.4000206@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Aaron Falk , iesg@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 05:33 06/02/25, Dave Crocker wrote: >Although the approach re-uses much of the existing Internet mail technology, it really is re-inventing the service. That is, I think that the infrastructure's reliance on net-ASCII is so deeply ingrained as to make switching to UTF-8 a near-term research effort. It may be the first time somebody is saying that using all 8 bits that TCP/IP provides needs a research effort. For the record, I agree with John and others that this should be done in the IETF, not the IRTF. I'd even be happy with standards track rather than experimental, but I can live with experimental. >As I noted before, I think that much of the dns and email internationalization efforts have suffered from trying to be IETF working groups, because the community knowledge and focus were not (yes) sufficient for that model of effort. The DNS internationalization effort suffered mostly from too much 'vendor' hype and disagreement and from constant interference of a small number of people with personal pet projects/concerns. Nothing unusual for a suffering IETF WG. The other problem was that the charter was much less specific than this one; even the basic approach (ACE or new record type or DNS extension or UTF-8 or what else) wasn't specified. The main really internationalization-relevant point in the DNS internationalization effort was how to define what characters to allow or not, and this is both much less of an issue for email address LHS or free-text header field content than for domain names, and we already have a reasonably usable and adaptable framework (stringprep). The rest of the work is mostly about downgrading/upgrading/ gatewaying and how to signal capabilities and help the user, which may not be trivial at all (while not being research), but isn't really internationalization-specific. Regards, Martin. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 28 13:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9N4-0007Rg-5j; Tue, 28 Feb 2006 13:14:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9N2-0007Qq-N9; Tue, 28 Feb 2006 13:14:48 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE9N1-0004ev-B4; Tue, 28 Feb 2006 13:14:48 -0500 Received: from [172.16.1.126] (207.47.33.25.rev.nextweb.net [207.47.33.25] (may be forged)) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k1SIErJP022106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2006 10:14:54 -0800 Message-ID: <440492F7.6030504@dcrocker.net> Date: Tue, 28 Feb 2006 10:14:15 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Yangwoo Ko Subject: Re: [IEE] WG Review: Email Address Internationalization (eai) References: <43FE025F.9000504@dcrocker.net> <43FF388A.2090100@dcrocker.net> <1B34A2809628E40E6255763F@p3.JCK.COM> <43FF8241.1030005@dcrocker.net> <440221B8.1090101@dcrocker.net> <4402B595.8050407@icu.ac.kr> In-Reply-To: <4402B595.8050407@icu.ac.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ima@ietf.org, Aaron Falk , dcrocker@bbiw.net, iesg@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > Dicussion between Dave and John, quoted above, can be understood as how > significant it will be? I'd rather interpret the "significance" in > somewhat different aspect. I think you have describe the question correctly. I think that a change in the form of email addresses that can cause delivery to fail should be considered significant. It can/will partition the functional infrastructure. > As we assume, it seems to be relatively easy to do IMA only between > agreed parties. The real devil lies at the boundary. Yes. Exactly correct. > However good news > is that, as a design team of this extention, we have a knob that > controls how significantly we want to change the infrastructure. For > example, in one extreme, we can just drop any mail that tries to cross > the boundary. On the other extreme, every part of the Internet > infrastructure is required to be upgraded somehow to support IMA so > perfectly that users cannot even recognize that there is such boundary. > In order to make IMA more usable, we want to deviate from the former > extreme as much as possible. In order to make IMA be more practical, we > cannot but deviate from the other extreme. How does a design team control the operational behavior of boundary MTAs? The experience with gatewaying between independent mail services is that it is a challenge, at best. Further, the experience with the use of "private" IP Addresses within networks is they leak out into the public Internet. In the last 25 years, there have been somewhere between 0 and few efforts to affect basic deliverability. (DSN is the possible exception and it's adoption history provides quite an education.) d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 28 22:07:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEHgy-0005bl-Iv; Tue, 28 Feb 2006 22:07:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEHgw-0005bS-Io for ima@ietf.org; Tue, 28 Feb 2006 22:07:54 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEHgu-0000C6-UJ for ima@ietf.org; Tue, 28 Feb 2006 22:07:54 -0500 Received: from jeffnb (pc091.twnic.net.tw [211.72.211.91]) by twnic.net.tw (8.13.5/8.13.5) with ESMTP id k2137m25025097 for ; Wed, 1 Mar 2006 11:07:49 +0800 Message-Id: <200603010307.k2137m25025097@twnic.net.tw> From: "Jeff Yeh" To: Date: Wed, 1 Mar 2006 11:15:05 +0800 Organization: TWNIC MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcY83lZJRmzPEx4xST23xxCGvFNlsA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [IEE] Update I-D: draft-yeh-ima-utf8headers-01.txt. X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Dear all, Newly updated header document is posted and can be found on http://www.ietf.org/internet-drafts/draft-yeh-ima-utf8headers-01.txt. Your precious comments are invited. Regards Jeff Yeh _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 28 22:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEHmO-0005Rc-1V; Tue, 28 Feb 2006 22:13:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEHmN-0005RX-63 for ima@ietf.org; Tue, 28 Feb 2006 22:13:31 -0500 Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEHmJ-0000Y2-UN for ima@ietf.org; Tue, 28 Feb 2006 22:13:31 -0500 Received: (eyou send program); Wed, 01 Mar 2006 11:13:13 +0800 Message-ID: <341182793.14671@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Wed, 01 Mar 2006 11:13:13 +0800 Message-ID: <029101c63cde$5db30f20$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: Date: Wed, 1 Mar 2006 11:15:14 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_028B_01C63D21.69E8AFF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [IEE] Fw: I-D ACTION:draft-yao-ima-smtpext-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IEE \(Internationalized Email and Extensions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_028B_01C63D21.69E8AFF0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCk5ld2x5IHVwZGF0ZWQgc210cCBleHRlbnNpb24gZG9jdW1lbnQgaXMgcG9z dGVkIA0KWW91ciBwcmVjaW91cyBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KWWFvIEppYW5rYW5n DQpDTk5JQw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPEludGVybmV0 LURyYWZ0c0BpZXRmLm9yZz4NClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KU2VudDogV2Vk bmVzZGF5LCBNYXJjaCAwMSwgMjAwNiA3OjUwIEFNDQpTdWJqZWN0OiBJLUQgQUNUSU9OOmRyYWZ0 LXlhby1pbWEtc210cGV4dC0wMi50eHQgDQoNCg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ IA0KPiANCj4gVGl0bGUgOiBTTVRQIGV4dGVuc2lvbiBmb3IgaW50ZXJuYXRpb25hbGl6ZWQgZW1h aWwgYWRkcmVzcw0KPiBBdXRob3IocykgOiBYLiBMZWUsIEouIFlhbw0KPiBGaWxlbmFtZSA6IGRy YWZ0LXlhby1pbWEtc210cGV4dC0wMi50eHQNCj4gUGFnZXMgOiAxMw0KPiBEYXRlIDogMjAwNi0y LTI4DQo+IA0KPiBJbnRlcm5hdGlvbmFsaXplZCBlTWFpbCBBZGRyZXNzIChJTUEpIGluY2x1ZGVz IHR3byBwYXJ0cywgdGhlIGxvY2FsDQo+ICAgIHBhcnQgYW5kIHRoZSBkb21haW4gcGFydC4gIFRo ZSB3YXkgZW1haWwgYWRkcmVzc2VzIGFyZSB1c2VkIGJ5DQo+ICAgIHByb3RvY29scyBhcmUgZGlm ZmVyZW50IGZyb20gdGhlIHdheSBkb21haW4gbmFtZXMgYXJlIHVzZWQuICBUaGUgbW9zdA0KPiAg ICBjcml0aWNhbCBkaWZmZXJlbmNlIGlzIHRoYXQgZW1haWxzIGFyZSBkZWxpdmVyZWQgdGhyb3Vn aCBhIGNoYWluIG9mDQo+ICAgIHBlZXJpbmcgY2xpZW50cyBhbmQgc2VydmVycyB3aGlsZSBkb21h aW4gbmFtZXMgYXJlIHJlc29sdmVkIGJ5IG5hbWUNCj4gICAgc2VydmVycyBieSBsb29raW5nIHVw IHRoZWlyIG93biB0YWJsZXMuICBJbiBhZGRpdGlvbiB0byB0aGlzLCBlbWFpbA0KPiAgICB0cmFu c3BvcnQgcHJvdG9jb2xzIFNNVFAgYW5kIEVTTVRQIHByb3ZpZGUgYSBuZWdvdGlhdGlvbiBtZWNo YW5pc20NCj4gICAgdGhyb3VnaCB3aGljaCBjbGllbnRzIGNhbiBtYWtlIGRlY2lzaW9ucyBmb3Ig ZnVydGhlciBwcm9jZXNzaW5nLiAgU28NCj4gICAgSU1BIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBp bnRlcm5hdGlvbmFsaXplZCBkb21haW4gbmFtZSAoSUROKS4gIElNQQ0KPiAgICBjYW4gYmUgc29s dmVkIGJ5IGV4cGxvaXRpbmcgdGhlIG5lZ290aWF0aW9uIG1lY2hhbmlzbSB3aGlsZSBJRE4gY2Fu DQo+ICAgIG5vdCB1c2UgdGhlIG5lZ290aWF0aW9uIG1lY2hhbmlzbS4gIFNvIElNQSBzaG91bGQg YmUgc29sdmVkIGluIHRoZQ0KPiAgICBtYWlsIHRyYW5zcG9ydC1sZXZlbCB1c2luZyB0aGUgbmVn b3RpYXRpb24gbWVjaGFuaXNtLCB3aGljaCBpcyBhbg0KPiAgICBhcmNoaXRlY3R1cmFsbHkgZGVz aXJhYmxlIGFwcHJvYWNoLiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIHVzZQ0KPiAgICBv ZiBTTVRQIGV4dGVuc2lvbiBmb3IgSU1BIGRlbGl2ZXJ5LiAgSXQgYWxzbyBtZW50aW9ucyB0aGUg YmFja3dhcmQNCj4gICAgY29tcGF0aWJsZSBtZWNoYW5pc20gZm9yIGRvd25ncmFkZSBwcm9jZWR1 cmUsIGFzIHNwZWNpZmllZCBpbiBhbg0KPiAgICBhc3NvY2lhdGVkIHNwZWNpZmljYXRpb24uICBU aGUgcHJvdG9jb2wgcHJvcG9zZWQgaGVyZSBpcyBNVEEtbGV2ZWwNCj4gICAgc29sdXRpb24gd2hp Y2ggaXMgZmVhc2libGUsIGFyY2hpdGVjdHVyYWxseSBtb3JlIGVsZWdhbnQsIGFuZCBub3QgYXMN Cj4gICAgZGlmZmljdWx0IHRvIGRlcGxveSBpbiByZWxldmFudCBjb21tdW5pdGllcy4NCj4gDQo+ IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW8taW1hLXNtdHBleHQtMDIudHh0DQo+IA0KPiBUbyBy ZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91bmNlbWVudCBsaXN0LCBzZW5kIGEgbWVz c2FnZSB0byANCj4gaS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmcgd2l0aCB0aGUgd29yZCB1 bnN1YnNjcmliZSBpbiB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZS4gIA0KPiBZb3UgY2FuIGFsc28g dmlzaXQgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFubm91bmNl IA0KPiB0byBjaGFuZ2UgeW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuDQo+IA0KPiANCj4gSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQLiBMb2dpbiB3 aXRoIHRoZSB1c2VybmFtZQ0KPiAiYW5vbnltb3VzIiBhbmQgYSBwYXNzd29yZCBvZiB5b3VyIGUt bWFpbCBhZGRyZXNzLiBBZnRlciBsb2dnaW5nIGluLA0KPiB0eXBlICJjZCBpbnRlcm5ldC1kcmFm dHMiIGFuZCB0aGVuDQo+ICJnZXQgZHJhZnQteWFvLWltYS1zbXRwZXh0LTAyLnR4dCIuDQo+IA0K PiBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBpbg0K PiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIA0KPiBvciBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiANCj4gDQo+IEludGVybmV0LURyYWZ0cyBjYW4g YWxzbyBiZSBvYnRhaW5lZCBieSBlLW1haWwuDQo+IA0KPiBTZW5kIGEgbWVzc2FnZSB0bzoNCj4g bWFpbHNlcnZAaWV0Zi5vcmcuDQo+IEluIHRoZSBib2R5IHR5cGU6DQo+ICJGSUxFIC9pbnRlcm5l dC1kcmFmdHMvZHJhZnQteWFvLWltYS1zbXRwZXh0LTAyLnR4dCIuDQo+IA0KPiBOT1RFOiBUaGUg bWFpbCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9jdW1lbnQgaW4NCj4gTUlN RS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4gIFRvIHVzZSB0aGlz DQo+IGZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3JlIHRo ZSAiRklMRSINCj4gY29tbWFuZC4gIFRvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlvdSB3aWxs IG5lZWQgIm11bnBhY2siIG9yDQo+IGEgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXIuICBEaWZm ZXJlbnQgTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXJzDQo+IGV4aGliaXQgZGlmZmVyZW50IGJl aGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyB3aXRoDQo+ICJtdWx0aXBhcnQiIE1JTUUg bWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxpdA0KPiB1cCBpbnRv IG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9uIG9u DQo+IGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3NhZ2VzLg0KPiANCj4gDQo+IEJlbG93IGlz IHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXIN Cj4gaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVy c2lvbiBvZiB0aGUNCj4gSW50ZXJuZXQtRHJhZnQuDQo+IA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+IEktRC1Bbm5vdW5jZUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UN Cj4g ------=_NextPart_000_028B_01C63D21.69E8AFF0 Content-Type: application/octet-stream; name="ATT00644.dat" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00644.dat" Content-Type: text/plain Content-ID: <2006-2-28160616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yao-ima-smtpext-02.txt ------=_NextPart_000_028B_01C63D21.69E8AFF0 Content-Type: text/plain; name="draft-yao-ima-smtpext-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-ima-smtpext-02.txt" Content-Type: text/plain Content-ID: <2006-2-28160616.I-D@ietf.org> ------=_NextPart_000_028B_01C63D21.69E8AFF0 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_000_028B_01C63D21.69E8AFF0--