From ima-bounces@ietf.org Tue Nov 01 10:06:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxiM-0001KE-6z; Tue, 01 Nov 2005 10:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxiK-0001I5-BU for ima@megatron.ietf.org; Tue, 01 Nov 2005 10:06:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25648 for ; Tue, 1 Nov 2005 10:05:56 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWxwh-0003Rg-Ms for ima@ietf.org; Tue, 01 Nov 2005 10:21:10 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C95862580EE for ; Tue, 1 Nov 2005 16:05: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 30695-03 for ; Tue, 1 Nov 2005 16:05: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 44628258085 for ; Tue, 1 Nov 2005 16:05:17 +0100 (CET) Date: Tue, 01 Nov 2005 16:05:59 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <10F51E8E35F9463521580E8B@[10.61.65.50]> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [IMA] Updated agenda - no changes X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0139475252==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0139475252== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========32E1CED9D0F615A43DA3==========" --==========32E1CED9D0F615A43DA3========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have uploaded a new agenda to the IETF website at The only change is that the downgrade draft is added to the agenda, and=20 that the hyperlinks now work. Harald --==========32E1CED9D0F615A43DA3========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDZ4RXOMj+2+WY0F4RAtgZAKC7zya0+tBYtw1Vpd1avtjYUFyYMACfWQNh iKLK7NjSVUasQ/ARDoYEZbQ= =6mbH -----END PGP SIGNATURE----- --==========32E1CED9D0F615A43DA3==========-- --===============0139475252== 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 --===============0139475252==-- From ima-bounces@ietf.org Tue Nov 01 21:30:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8Ob-0006ul-6z; Tue, 01 Nov 2005 21:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX8OY-0006tV-Q2 for ima@megatron.ietf.org; Tue, 01 Nov 2005 21:30:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01158 for ; Tue, 1 Nov 2005 21:30:14 -0500 (EST) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EX8cw-0006H0-DO for ima@ietf.org; Tue, 01 Nov 2005 21:45:34 -0500 Received: (eyou send program); Wed, 02 Nov 2005 10:29:53 +0800 Message-ID: <330898593.07194@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, 02 Nov 2005 10:29:53 +0800 Message-ID: <00f501c5df55$6f205010$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Harald Tveit Alvestrand" References: <330857611.03276@cnnic.cn> Subject: Re: [IMA] Updated agenda - no changes Date: Wed, 2 Nov 2005 10:30:47 +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: 3.0 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1622175835==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1622175835== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RGVhciBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCwNCm9uIHRoZSB3ZWJwYWdlDQogaHR0cDovL3d3 dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDVub3YvYWdlbmRhL2llZS5odG1sLA0KDQp0aGUgbWVl dGluZyB0aW1lIGlzIG5lZWRlZCB0byBiZSB1cGRhdGVkLg0KZnJvbSB0aGUgQk9GIHRpbWUgKERh dGUgYW5kIHRpbWU6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgYXQgMDkwMC0xMTMwKSANCiB0byB0 aGUgZm9sbG93aW5nOg0KVEhVUlNEQVksIE5vdmVtYmVyIDEwLCAyMDA1DQoxMzAwLTE1MDAgQWZ0 ZXJub29uIFNlc3Npb24gSQ0KU2Fsb24gQS9CICBBUFAgIGllZSAgICAgICBJbnRlcm5hdGlvbmFs aXplZCBFbWFpbCBhbmQgRXh0ZW5zaW9ucyBCT0YNCg0KWWFvIEppYW5rYW5nDQpDTk5JQw0KDQoN Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSGFyYWxkIFR2ZWl0IEFsdmVz dHJhbmQiIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDog VHVlc2RheSwgTm92ZW1iZXIgMDEsIDIwMDUgMTE6MDUgUE0NClN1YmplY3Q6IFtJTUFdIFVwZGF0 ZWQgYWdlbmRhIC0gbm8gY2hhbmdlcw0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo+IA== --===============1622175835== 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 --===============1622175835==-- From ima-bounces@ietf.org Wed Nov 02 10:25:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKU8-0001fj-0n; Wed, 02 Nov 2005 10:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKU7-0001eb-0X for ima@megatron.ietf.org; Wed, 02 Nov 2005 10:25:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12710 for ; Wed, 2 Nov 2005 10:24:46 -0500 (EST) Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKii-0006jG-0g for ima@ietf.org; Wed, 02 Nov 2005 10:40:13 -0500 Received: from host81-144-65-32.midband.mdip.bt.net ([81.144.65.32]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.198) id 4368da46.d7e8.9e3; Wed, 2 Nov 2005 15:24:54 +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 jA2CXCm09844; Wed, 2 Nov 2005 12:33:12 GMT Date: Wed, 02 Nov 2005 12:33:06 -0000 To: "Harald Tveit Alvestrand" , ima@ietf.org Subject: Re: [IMA] Updated agenda - no changes References: <10F51E8E35F9463521580E8B@[10.61.65.50]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Message-ID: In-Reply-To: <10F51E8E35F9463521580E8B@[10.61.65.50]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA12710 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Tue, 01 Nov 2005 15:05:59 -0000, Harald Tveit Alvestrand =20 wrote: > I have uploaded a new agenda to the IETF website at > > > > The only change is that the downgrade draft is added to the agenda, and > that the hyperlinks now work. Just a couple of remarks concerning the proposed Charter. It says: This working group will address one basic approach to emai =20 internationalization. That approach is based on the use of an SMTP =20 extension to enable both the use of UTF-8 in envelope address local-parts= =20 and the use of UTF-8 in mail headers -- both in address contexts and =20 wherever encoded-words are permitted today. .... Although this work was motivated by the needs of IMA, it has the potentia= l =20 to do much more by way of permitting UTF-8 in headers in all sorts of =20 other situations. And certainly it has the potential to allow UTF-8 in =20 more places than just address contexts and wherever encoded-words are =20 permitted. Also, that present wording seems to preclude UTF-8 in envelope= =20 domains. So I would suggest something more like: "That approach is based on the use of UTF-8 in mail headers -- not only i= n =20 address contexts but also at least where encoded-words are currently =20 permitted-- together with an SMTP extension to enable such headers to be = =20 transported and UTF-8 to be used in envelope addresses." Whilst we may well limit the use of UTF-8 to address contexts and =20 encoded-words initially, I think it is important to devise a scheme which= =20 will accomodate UTF-8 extensions in other header contexts later on (the =20 use of IRIs in some headers which durrently use URIs is an obvious =20 example). Again, once the principle of UTF-8 in headers has been accepted, that wil= l =20 also leave the way open for similar extensions to transports other than =20 SMTP. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 02 11:03:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXL5H-00087D-4N; Wed, 02 Nov 2005 11:03:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXL5E-00086x-Ly for ima@megatron.ietf.org; Wed, 02 Nov 2005 11:03:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15130 for ; Wed, 2 Nov 2005 11:03:07 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLJq-0008Pb-0n for ima@ietf.org; Wed, 02 Nov 2005 11:18:35 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 465192596CB; Wed, 2 Nov 2005 17:02:34 +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 06920-03; Wed, 2 Nov 2005 17:02:31 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id E043F2596CA; Wed, 2 Nov 2005 17:02:30 +0100 (CET) Date: Wed, 02 Nov 2005 17:04:06 +0100 From: Harald Tveit Alvestrand To: Charles Lindsey , ima@ietf.org Subject: Re: [IMA] Updated agenda - no changes Message-ID: <028E7F6E377D60D1F402CCFD@svartdal.hjemme.alvestrand.no> In-Reply-To: References: <10F51E8E35F9463521580E8B@[10.61.65.50]> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On onsdag, november 02, 2005 12:33:06 +0000 Charles Lindsey wrote: > Also, that present wording seems to preclude UTF-8 in envelope domains. I think that's deliberate. EITHER the sender OR the intermediate node has to do the IDN encoding of the domain part of email addresses in the envelope before looking them up in the DNS. Doing it once (at origin) seems sensible to me. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 02 12:06:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXM3k-0002JQ-0X; Wed, 02 Nov 2005 12:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXM3i-0002Ga-E4 for ima@megatron.ietf.org; Wed, 02 Nov 2005 12:05:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21510 for ; Wed, 2 Nov 2005 12:05:37 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMIK-0003o6-9t for ima@ietf.org; Wed, 02 Nov 2005 12:21:05 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EXM3P-0000Sr-95; Wed, 02 Nov 2005 12:05:39 -0500 Date: Wed, 02 Nov 2005 12:05:39 -0500 From: John C Klensin To: Harald Tveit Alvestrand , Charles Lindsey , ima@ietf.org Subject: Re: [IMA] Updated agenda - no changes Message-ID: <25781E694B97F82D9F0303C8@scan.jck.com> In-Reply-To: <028E7F6E377D60D1F402CCFD@svartdal.hjemme.alvestrand.no> References: <10F51E8E35F9463521580E8B@[10.61.65.50]> <028E7F6E377D60D1F402CCFD@svartdal.hjemme.alvestrand.no> 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Wednesday, 02 November, 2005 17:04 +0100 Harald Tveit Alvestrand wrote: > > > --On onsdag, november 02, 2005 12:33:06 +0000 Charles Lindsey > wrote: > >> Also, that present wording seems to preclude UTF-8 in >> envelope domains. > > I think that's deliberate. EITHER the sender OR the > intermediate node has to do the IDN encoding of the domain > part of email addresses in the envelope before looking them up > in the DNS. > > Doing it once (at origin) seems sensible to me. Actually not. Independent of what the current documents might seem to say, if the local-part is in UTF-8, who cares whether the domain-part is in UTF-8 or in punycode? The only important requirement from IDNA is that any application that is about to query the DNS for a label whose semantics are non-ASCII do so only with properly nameprepped data in punycode form. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 03 22:26:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXsDo-00016Q-OW; Thu, 03 Nov 2005 22:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXsDn-00014E-AD for ima@megatron.ietf.org; Thu, 03 Nov 2005 22:26:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17259 for ; Thu, 3 Nov 2005 22:26:07 -0500 (EST) Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXsSg-0006Su-Mz for ima@ietf.org; Thu, 03 Nov 2005 22:41:56 -0500 Received: from host81-144-66-169.midband.mdip.bt.net ([81.144.66.169]) by lon-mail-1.gradwell.net with esmtp (Gradwell gwh-smtpd 1.198) id 436ad4d4.9102.1c29 for ima@ietf.org; Fri, 4 Nov 2005 03:26:12 +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 jA3JRRm02980 for ; Thu, 3 Nov 2005 19:27:28 GMT To: ima@ietf.org Subject: Re: [IMA] Updated agenda - no changes References: <10F51E8E35F9463521580E8B@[10.61.65.50]> <028E7F6E377D60D1F402CCFD@svartdal.hjemme.alvestrand.no> <25781E694B97F82D9F0303C8@scan.jck.com> Message-ID: Date: Thu, 03 Nov 2005 19:27:19 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <25781E694B97F82D9F0303C8@scan.jck.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA17259 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Wed, 02 Nov 2005 17:05:39 -0000, John C Klensin wrot= e: > Actually not. Independent of what the current documents might > seem to say, if the local-part is in UTF-8, who cares whether > the domain-part is in UTF-8 or in punycode? The only important > requirement from IDNA is that any application that is about to > query the DNS for a label whose semantics are non-ASCII do so > only with properly nameprepped data in punycode form. Indeed so. If the RCPT TO address comes in in UTF-8, then it might as wel= l =20 go out in UTF-8 when it gets passed on to the next MTA. Tranlating to IDNA is only required when you actually want to look up a =20 real IP address (or MX) to forward to. What I suspect will probably happe= n =20 before long is that system libraries will soon contain a routine by the =20 name of i18ngethostbyname, which will take a domain in UTF-8, put it =20 through Nameprep, translate it to punucode, look it up in the DNS, and =20 return the IP to you. So MTA writers will hardly have to do anything =20 different to what they do now. Or, if the MTA sees that the incoming message is addressed to its own =20 domain, it will probably do no lookup at all, but proceed straight to its= =20 final delivery mode. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Nov 03 22:43:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXsTp-000539-9P; Thu, 03 Nov 2005 22:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXsTn-000534-4T for ima@megatron.ietf.org; Thu, 03 Nov 2005 22:43:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17810 for ; Thu, 3 Nov 2005 22:42:38 -0500 (EST) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXsia-0006n5-9D for ima@ietf.org; Thu, 03 Nov 2005 22:58:27 -0500 Received: (eyou send program); Fri, 04 Nov 2005 11:37:21 +0800 Message-ID: <331075441.16060@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Fri, 04 Nov 2005 11:37:21 +0800 Message-ID: <017c01c5e0f1$2c57d120$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: , "Charles Lindsey" References: <10F51E8E35F9463521580E8B@[10.61.65.50]><028E7F6E377D60D1F402CCFD@svartdal.hjemme.alvestrand.no><25781E694B97F82D9F0303C8@scan.jck.com> <331074828.00766@cnnic.cn> Subject: Re: [IMA] Updated agenda - no changes Date: Fri, 4 Nov 2005 11:38:08 +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: 3.0 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1244856451==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1244856451== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXks IE5vdmVtYmVyIDA0LCAyMDA1IDM6MjcgQU0NClN1YmplY3Q6IFJlOiBbSU1BXSBVcGRhdGVkIGFn ZW5kYSAtIG5vIGNoYW5nZXMNCj4gPiBBY3R1YWxseSBub3QuICAgSW5kZXBlbmRlbnQgb2Ygd2hh dCB0aGUgY3VycmVudCBkb2N1bWVudHMgbWlnaHQNCj4gPiBzZWVtIHRvIHNheSwgaWYgdGhlIGxv Y2FsLXBhcnQgaXMgaW4gVVRGLTgsIHdobyBjYXJlcyB3aGV0aGVyDQo+ID4gdGhlIGRvbWFpbi1w YXJ0IGlzIGluIFVURi04IG9yIGluIHB1bnljb2RlPyAgVGhlIG9ubHkgaW1wb3J0YW50DQo+ID4g cmVxdWlyZW1lbnQgZnJvbSBJRE5BIGlzIHRoYXQgYW55IGFwcGxpY2F0aW9uIHRoYXQgaXMgYWJv dXQgdG8NCj4gPiBxdWVyeSB0aGUgRE5TIGZvciBhIGxhYmVsIHdob3NlIHNlbWFudGljcyBhcmUg bm9uLUFTQ0lJIGRvIHNvDQo+ID4gb25seSB3aXRoICBwcm9wZXJseSBuYW1lcHJlcHBlZCBkYXRh IGluIHB1bnljb2RlIGZvcm0uDQo+IA0KPiBJbmRlZWQgc28uIElmIHRoZSBSQ1BUIFRPIGFkZHJl c3MgY29tZXMgaW4gaW4gVVRGLTgsIHRoZW4gaXQgbWlnaHQgYXMgd2VsbCAgDQo+IGdvIG91dCBp biBVVEYtOCB3aGVuIGl0IGdldHMgcGFzc2VkIG9uIHRvIHRoZSBuZXh0IE1UQS4NCj4gDQo+IFRy YW5sYXRpbmcgdG8gSUROQSBpcyBvbmx5IHJlcXVpcmVkIHdoZW4geW91IGFjdHVhbGx5IHdhbnQg dG8gbG9vayB1cCBhICANCj4gcmVhbCBJUCBhZGRyZXNzIChvciBNWCkgdG8gZm9yd2FyZCB0by4g V2hhdCBJIHN1c3BlY3Qgd2lsbCBwcm9iYWJseSBoYXBwZW4gIA0KPiBiZWZvcmUgbG9uZyBpcyB0 aGF0IHN5c3RlbSBsaWJyYXJpZXMgd2lsbCBzb29uIGNvbnRhaW4gYSByb3V0aW5lIGJ5IHRoZSAg DQo+IG5hbWUgb2YgaTE4bmdldGhvc3RieW5hbWUsIHdoaWNoIHdpbGwgdGFrZSBhIGRvbWFpbiBp biBVVEYtOCwgcHV0IGl0ICANCj4gdGhyb3VnaCBOYW1lcHJlcCwgdHJhbnNsYXRlIGl0IHRvIHB1 bnVjb2RlLCBsb29rIGl0IHVwIGluIHRoZSBETlMsIGFuZCAgDQo+IHJldHVybiB0aGUgSVAgdG8g eW91LiBTbyBNVEEgd3JpdGVycyB3aWxsIGhhcmRseSBoYXZlIHRvIGRvIGFueXRoaW5nICANCj4g ZGlmZmVyZW50IHRvIHdoYXQgdGhleSBkbyBub3cuDQo+IA0KPiBPciwgaWYgdGhlIE1UQSBzZWVz IHRoYXQgdGhlIGluY29taW5nIG1lc3NhZ2UgaXMgYWRkcmVzc2VkIHRvIGl0cyBvd24gIA0KPiBk b21haW4sIGl0IHdpbGwgcHJvYmFibHkgZG8gbm8gbG9va3VwIGF0IGFsbCwgYnV0IHByb2NlZWQg c3RyYWlnaHQgdG8gaXRzICANCj4gZmluYWwgZGVsaXZlcnkgbW9kZS4NCj4gDQo+IC0tIA0KPiBD aGFybGVzIEguIExpbmRzZXkgLS0tLS0tLS0tQXQgSG9tZSwgZG9pbmcgbXkgb3duIHRoaW5nLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRlbDogKzQ0IDE2MSA0MzYgNjEzMSBGYXg6ICs0NCAx NjEgNDM2IDYxMzMgV2ViOiBodHRwOi8vd3d3LmNzLm1hbi5hYy51ay9+Y2hsDQo+IEVtYWlsOiBj aGxAY2xlcmV3Lm1hbi5hYy51ayBTbmFpbDogNSBDbGVyZXdvb2QgQXZlLCBDSEVBRExFLCBTSzgg M0pVLCBVLksuDQo+IFBHUDogMkMxNUYxQTkgRmluZ2VycHJpbnQ6IDczIDZEIEMyIDUxIDkzIEEw IDAxIEU3IDY1IEU4IDY0IDdFIDE0IEE0IEFCIEE1DQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWENCj4= --===============1244856451== 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 --===============1244856451==-- From ima-bounces@ietf.org Thu Nov 03 23:34:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXtHC-000187-5U; Thu, 03 Nov 2005 23:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXtHB-000182-BX for ima@megatron.ietf.org; Thu, 03 Nov 2005 23:34:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20672 for ; Thu, 3 Nov 2005 23:33:42 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXtW4-0008Ex-L0 for ima@ietf.org; Thu, 03 Nov 2005 23:49:31 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EXtH1-0005of-LJ; Thu, 03 Nov 2005 23:33:55 -0500 Date: Thu, 03 Nov 2005 23:33:55 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [IMA] Updated agenda - no changes Message-ID: In-Reply-To: References: <10F51E8E35F9463521580E8B@[10.61.65.50]> <028E7F6E377D60D1F402CCFD@svartdal.hjemme.alvestrand.no> <25781E694B97F82D9F0303C8@scan.jck.com> 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: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Thursday, 03 November, 2005 19:27 +0000 Charles Lindsey wrote: > Tranlating to IDNA is only required when you actually want to > look up a real IP address (or MX) to forward to. What I > suspect will probably happen before long is that system > libraries will soon contain a routine by the name of > i18ngethostbyname, which will take a domain in UTF-8, put it > through Nameprep, translate it to punucode, look it up in the > DNS, and return the IP to you. So MTA writers will hardly > have to do anything different to what they do now. Indeed. And I imagine that i18ngethostbyname will inspect the string it is given, invoking IDNA only if it encounters a UTF-8 string (as distinct from an ASCII one, punycode or not). In 8bit-clean environments, I'd expect "gethostbyname" or equivalent to simply be replaced by a routine that behaves that way. In other words, an MTA that needs to resolve a domain will, probably without looking a it at all, simply pass the domain part to an enhanced resolver which will know how to take any of conventional name, punycode, or UTF-8 and return an address. > Or, if the MTA sees that the incoming message is addressed to > its own domain, it will probably do no lookup at all, but > proceed straight to its final delivery mode. Indeed, the more substantive change in the logic of the MTA is that, today, the MTA needs to know its own name (for a variety of reasons, including that optimization). Typically, the comparison that is made is domain-part-from-address .eq?. FQDN-of-machine. In an IDN world, a machine whose name has more than one IDN components will either (i) need to put the entire domain-part through IDNA (one label at a time, of course) and then make the above comparison on the punycode strings, or (ii) it will need to parse the domain-part into labels and then test as FOR number-of-labels label-from-domain-part .eq?. (label-from-machine-FQDN | punycode(label-from-machine-FQDN) So, incrementally, getting from the classic "is this me" test to its IDN version becomes more complex in terms of MTA implementation than dealing with and looking up an arbitrary FQDN that might contain IDNs. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Nov 04 00:54:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXuX1-00042Y-9q; Fri, 04 Nov 2005 00:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXuWy-00041o-MJ for ima@megatron.ietf.org; Fri, 04 Nov 2005 00:54:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24387 for ; Fri, 4 Nov 2005 00:54:05 -0500 (EST) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EXulm-0001v6-Pt for ima@ietf.org; Fri, 04 Nov 2005 01:09:54 -0500 Received: (eyou send program); Fri, 04 Nov 2005 13:53:54 +0800 Message-ID: <331083634.21819@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by 159.226.7.151 with SMTP; Fri, 04 Nov 2005 13:53:54 +0800 Message-ID: <023701c5e104$3fd37a70$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Charles Lindsey" References: <10F51E8E35F9463521580E8B@[10.61.65.50]><028E7F6E377D60D1F402CCFD@svartdal.hjemme.alvestrand.no><25781E694B97F82D9F0303C8@scan.jck.com> <331074828.00766@cnnic.cn> Subject: Re: [IMA] Updated agenda - no changes Date: Fri, 4 Nov 2005 13:54:41 +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: 3.0 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1449395950==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1449395950== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 cGxzIGlnbm9yZSB0aGUgbGFzdCBlbWFpbCBzZW50IGJ5IG1lLCBuYW1lZCB3aXRoICJSZTogW0lN QV0gVXBkYXRlZCBhZ2VuZGEgLSBubyBjaGFuZ2VzIi4NCml0IGlzIHNlbnQgd2l0aG91dCBhbnkg Y29tbWVudHMuDQpUaGlzIGlzIGR1ZSB0byBlcnJvciBvcGVyYXRpb24gb2YgbXkgT3V0bG9vayBF eHByZXNzLg0KU29ycnkgdG8gZGlzdHVyYi4NCm15IGNvbW1lbnRzIHRvIHRoaXMgZW1haWwgaXMg ZGVzY3JpYmVkIGJlbG93Lg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IkNoYXJsZXMgTGluZHNleSIgPGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86IDxpbWFAaWV0Zi5v cmc+DQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDA0LCAyMDA1IDM6MjcgQU0NClN1YmplY3Q6IFJl OiBbSU1BXSBVcGRhdGVkIGFnZW5kYSAtIG5vIGNoYW5nZXMNCg0KDQo+IEluZGVlZCBzby4gSWYg dGhlIFJDUFQgVE8gYWRkcmVzcyBjb21lcyBpbiBpbiBVVEYtOCwgdGhlbiBpdCBtaWdodCBhcyB3 ZWxsICANCj4gZ28gb3V0IGluIFVURi04IHdoZW4gaXQgZ2V0cyBwYXNzZWQgb24gdG8gdGhlIG5l eHQgTVRBLg0KPiANCj4gVHJhbmxhdGluZyB0byBJRE5BIGlzIG9ubHkgcmVxdWlyZWQgd2hlbiB5 b3UgYWN0dWFsbHkgd2FudCB0byBsb29rIHVwIGEgIA0KPiByZWFsIElQIGFkZHJlc3MgKG9yIE1Y KSB0byBmb3J3YXJkIHRvLiANCg0KWWVzLCBhZ3JlZS4NCg0KPldoYXQgSSBzdXNwZWN0IHdpbGwg cHJvYmFibHkgaGFwcGVuICANCj4gYmVmb3JlIGxvbmcgaXMgdGhhdCBzeXN0ZW0gbGlicmFyaWVz IHdpbGwgc29vbiBjb250YWluIGEgcm91dGluZSBieSB0aGUgIA0KPiBuYW1lIG9mIGkxOG5nZXRo b3N0YnluYW1lLCB3aGljaCB3aWxsIHRha2UgYSBkb21haW4gaW4gVVRGLTgsIHB1dCBpdCAgDQo+ IHRocm91Z2ggTmFtZXByZXAsIHRyYW5zbGF0ZSBpdCB0byBwdW51Y29kZSwgbG9vayBpdCB1cCBp biB0aGUgRE5TLCBhbmQgIA0KPiByZXR1cm4gdGhlIElQIHRvIHlvdS4gU28gTVRBIHdyaXRlcnMg d2lsbCBoYXJkbHkgaGF2ZSB0byBkbyBhbnl0aGluZyAgDQo+IGRpZmZlcmVudCB0byB3aGF0IHRo ZXkgZG8gbm93Lg0KDQpob3BlIHRoYXQgc2NlbmFyaW8gYXBwZWFyIHNvb24uDQoNCj4gDQo+IE9y LCBpZiB0aGUgTVRBIHNlZXMgdGhhdCB0aGUgaW5jb21pbmcgbWVzc2FnZSBpcyBhZGRyZXNzZWQg dG8gaXRzIG93biAgDQo+IGRvbWFpbiwgaXQgd2lsbCBwcm9iYWJseSBkbyBubyBsb29rdXAgYXQg YWxsLCBidXQgcHJvY2VlZCBzdHJhaWdodCB0byBpdHMgIA0KPiBmaW5hbCBkZWxpdmVyeSBtb2Rl Lg0KDQpZZXMsIGFncmVlLg0KDQpZYW8gSmlhbmthbmcNCkNOTklDDQo= --===============1449395950== 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 --===============1449395950==-- From ima-bounces@ietf.org Mon Nov 07 13:20:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBc1-0005st-CA; Mon, 07 Nov 2005 13:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBc0-0005so-Dp for ima@megatron.ietf.org; Mon, 07 Nov 2005 13:20:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27003 for ; Mon, 7 Nov 2005 13:20:30 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZBre-0003a8-3l for ima@ietf.org; Mon, 07 Nov 2005 13:37:07 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F27152596AF for ; Mon, 7 Nov 2005 19:19:58 +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 13128-10 for ; Mon, 7 Nov 2005 19:19:54 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 864C72596B7 for ; Mon, 7 Nov 2005 19:19:50 +0100 (CET) Date: Mon, 07 Nov 2005 10:19:48 -0800 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <0E540526882E5837A0FF74AB@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.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [IMA] Commentary on the downgrade draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0677677390==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0677677390== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========61032EC48D906BCC3C67==========" --==========61032EC48D906BCC3C67========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John Klensin has written a long commentary on the document=20 "draft-yoneya-ima-downgrade". I have added a link to it to the IEE BOF page: http://www.alvestrand.no/ietf/iee-bof/ - the document is formatted as an=20 I-D for practical reasons, but is not intended to be published as such. I recommend reading through the note before the meeting. Harald --==========61032EC48D906BCC3C67========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDb5rEOMj+2+WY0F4RAlyJAKCz71aPax473JOaTPkarLAep+0g2QCgz1+O AhvHPTZhtctFlxEE2EXG9M0= =Y5zn -----END PGP SIGNATURE----- --==========61032EC48D906BCC3C67==========-- --===============0677677390== 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 --===============0677677390==-- From ima-bounces@ietf.org Tue Nov 08 13:53:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYaq-0004vK-9F; Tue, 08 Nov 2005 13:53:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYao-0004uv-RW for ima@megatron.ietf.org; Tue, 08 Nov 2005 13:53:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25450 for ; Tue, 8 Nov 2005 13:52:47 -0500 (EST) From: fujiwara@jprs.co.jp Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYqe-0004fI-TP for ima@ietf.org; Tue, 08 Nov 2005 14:09:38 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id jA8IqRR9026717; Wed, 9 Nov 2005 03:52:29 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2005110903522722119 ; Wed, 09 Nov 2005 03:52:27 +0900 Date: Wed, 09 Nov 2005 03:52:27 +0900 (JST) Message-Id: <20051109.035227.54203025.fujiwara@jprs.co.jp> To: chl@clerew.man.ac.uk Subject: Re: [IMA] Re: draft-downgrade-00 In-Reply-To: <1452.213.122.132.192.1130449790.squirrel@www.gradwell.com> References: <1452.213.122.132.192.1130449790.squirrel@www.gradwell.com> X-Mailer: Mew version 4.2.54 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Dear Charles H. Lindsey, Thanks a lot for your good comments. This ID needs: - Reference to MIME/RFC2047 - with examples - Detail consideration/definition for each headers - structured header: Received, ... - headers which has no downgrade method - Rename X-IMA-Downgraded to IMA-Downgraded - consideration for non-SMTP transport for Envelop-From/To - Explanation of downgrading architecture Yoneya and I will update after IETF meeting. -- Fujiwara, Kazunori JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Nov 29 09:24:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6PT-0004aG-0G; Tue, 29 Nov 2005 09:24:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6PR-0004ZW-8V for ima@megatron.ietf.org; Tue, 29 Nov 2005 09:24:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10752 for ; Tue, 29 Nov 2005 09:23:56 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh6jV-0005EN-QM for ima@ietf.org; Tue, 29 Nov 2005 09:45:26 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18FFE2596F8 for ; Tue, 29 Nov 2005 15:23:56 +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 12498-01 for ; Tue, 29 Nov 2005 15:23:50 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 673D42596F7 for ; Tue, 29 Nov 2005 15:23:49 +0100 (CET) Date: Tue, 29 Nov 2005 15:22:48 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <7F75A871305ABCDCD01B15F1@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.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Subject: [IMA] DRAFT minutes from IEE BOF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239405233==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1239405233== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========9AAB73FE40563EE3174D==========" --==========9AAB73FE40563EE3174D========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please send corrections, additions, spelling errors to me. Minutes of the IEE BOF at IETF64, Vancouver, CA Minutes take by: Sheldon Lee, Ed Lewis Post-editing: Harald Alvestrand Meeting held Thursday, November 10, 2005, in Salon A/B, Westin Bayshore=20 Hotel Meeting chair: Harald Alvestrand 1.Agenda Bashing Keith Moore: Q - What is the scope of this BOF? Harald Alvestrand: For this bof, the question of whether there are better=20 apporaches is out of scope. It focuses on the architeture proposed, trying=20 to see whether that is viable. Conclusion: no objection for agenda. 2. Draft framework, draft-klensin-ima-framework - John Klensin Outline:Overview and Framework for Internationalized Email Conclusion: no discussion and no questions for this presentation now. 3. SMTP Extension, draft-yao-ima-smtpext - J. Yao Outline:SMTP extension for internationalized email address. Describes the=20 "IMA" SMTP extension negotiating support for messages that use UTF-8 in addresses = and headers Conclusion: no questions 4. UTF-8 header, draft-yeh-ima-utf8headers - J. Yeh Outline: Transmission of email headers in utf8 encoding, specifiy the use=20 of unicode encoded in utf8 on email header bodies Conclusion:no questions 5. Downgrading, draft-yoneya-ima-downgrade - K. Fujiwarea Outline:Downgrading can occur before sending, after reception or in the=20 middle of transmission Conclusion:no questions 6. Question and Answer/Discussion Q1:[Ted Hardie] One of John's early comments was that the downgrading issue = was less important than the previous other three document, and may be a=20 local matter. I expect that that is a critical question? Answer [John Klensin]: The internationalized email address is most=20 important within a community, for instance Chinese, or Arabic. Those people = are interested and need to communication with each other. Communication=20 between groups is far less prevalent. The 8bitMIME experience showed that downgrade wasn't as important as first=20 thought - it was not a long term problem Q2:[Chris Newman] I'd like to address downgrading. I think the charter need to say that we need the RFC about downgrading - at least=20 experimental. The email system is made of multiple subsystems, and each subsystem needs=20 to be upgraded. These are very large products and very complicated, so if I am going to=20 start supporting internationalized email address in the product, I have to=20 work on one subsystem at a time. Downgrading is most important actually for = software implementation, we need something common for dowgrading. POP/IMAP should do = some changes. WG charter may need to have POP/IMAP Experimental documents. John Klensin: Need to be able to do things incrementally - Web clients,=20 User interfaces. Then stuff in the middle. Q3:[Keith Moore]: I am entirely supportive of this effort. I am also really familar with this kind of problem. Two questions: if someone sends a message to more than one person, and some = people have an user agent that supports the internationalized email=20 address, and others not, what should happen? The second question is about the user experience. Different users have=20 different experience on email uses. How to integrate these different user=20 experiences is an issue that should be considered. We should consider the=20 MUA first. SMTP is the least hard part, and the last step we need to worry about. John Klensin: It's time to get started on the SMTP part. Please don't refer = to the effort as "you" - we want you (Keith) to be part of it. Q4:[Chris] Imap and POP should be discussed, I think those are necessary=20 drafts, and I might do one of them. I think we do want to talk about the=20 upgrading of punycode, that will be the normative part of that. Klensin: Punycode upgrading won't work. This effort is not meant to solve=20 all the problems of email at the same time. Q5:[Dave Croker]: Why do we need SMTP Extension? Why not just focus on an=20 ACE-type implementation? Why is utf-8 used in transportation instead of = ACE? Klensin: Most operating systems are changing to support utf-8. Using utf-8=20 is cooperating with the trend. Encodings tend to leak all over the place -=20 and negatively impact the user experience. Big problem is Envelope address=20 not equal to header address. Q6: [Dave Croker] Leakage happens with UTF8 as well. utf8 is nothing but=20 encoding. Q7:[Pete Resnick]: I think UTF8 is better because current status of OS is=20 changed, if you take a block of data, it should be utf8. [Dave]: that problem is solved, thank you Q8:[Chris Newman]: Internationalizing email local parts is different from=20 the internationalizing domain name (IDN). These are different=20 infrastructures. IDN can not use the negotiation mechanism. IEE can use=20 some negotiation mechanisms. Q9:[Pete Resnick]: The current work is a good framework with SMTP extension. But the hard work is how to deal with the issues related to end systems. How do we jump start the user interface/experience work? Klensin: Violently agree. We focus on the MTA issues. End systems is about=20 the presentation layer issues, MUA is traditionally not discussed much in=20 the IETF. There are already MUAs for this stuff; we need to get the network protocols = in place to connect them. Q10:[Dave Crocker]: Should we follow the "PR" 2282 object & pseudo push? The presentation layer is worrisome, no details documented, object needs to = be labelled. Klensin: If necessary then next generation of email is needed. Q10:[Philip Ganther]: utf-8 is one kind of Unicode. I am afraid that some=20 country such as china use local characters in GB encoding instead of=20 Unicode in applications. Answer by Yao: We do not need to worry about this. In China, most Web=20 systems and email systems or applications support Unicode by transforming=20 GB coding into Unicode. Most systems can transform GB to Unicode. Q11:[Philip Ganther]Is language tag needed? Answer by harald : RFC 2231 is a solution if we need it. It's not been very = popular. Ganther: Needs to be discussed as a work item. Q12:[Ted Hardie]: There are islands of consenting adults using it already. The problem is to deal with those who do not not consent yet. One problem can be mailing lists. Another concern is whether this is a constantly moving target. Do we cause failures for consenting or=20 non-consenting participants? Klensin: We are no longer operating in the world with clean bounce. Spam=20 filters throw stuff away. This is the most risky part of the effort. Q13:[Chris Newman]: I think the charter need to say that the downgrading=20 will be a experimental document and part of the initial document set. Need=20 POP and IMAP, volunteering to write the POP draft. Q14:[Randall Gellens]: We cannot have SMTP without POP and IMAP. Concerned about label for RFC2822 Q15:[Macos Sanz] It's important to address this from the beginning; we need = a syntactic definition of the new local part. Klensin: Agree. Need to define which characters are allowed, lengths and so = on. Q16:[Dave Croker]: This is a focus on mechanisms for walled gardens. The default charset has been defined to ASCII. Defaults are bad because=20 defaults can be changed. No default tagging should remain; all tags should=20 be explicit. Labelling is easy and essential. Q17:[Tony Hansen]: POP and IMAP are important. I'm willing to work on=20 these. Guidance from MUA authors is needed. Q18:[Keith Moore]: I'm disturbed about where the discussion is going. We must first deal with the user experience - document what user experience = we are trying to create. Q19:[John Klensin]: IMAP and POP both need to be considered. The=20 differences between them do not make it easy to generalize. Q20:[Chris]: What the MUA does should be defined in one draft, it need a=20 draft. POP will be the first doc; both POP and IMAP are needed. We must deal with user experience - MUA, but think this new effort is=20 informed by that. Need MUA draft to deal with leakage. POP and IMAP at the = same time is ok, but should not be held up by IMAP. Q21:[Randy Glellens] Community's there. That's good. Still need IMAP and=20 POP. Ugly addresses vs unexpected 8bit problem. Q22:[Cyrus Daboo, via Jabber]: Impact on LDAP, ACAP, vcard too. Q23:[Harald]: Massive support for going forward with the work. Are we good=20 with charter? With updates adding documents for POP, IMAP, mailing lists and=20 other considerations for storing email addresses? Q24:[Keith Moore] The first deliverable needs to be a document describing=20 the user interface in mixed cases - description of the moving parts. All=20 other work should be tabled until then. When you send mail with UTF8 headers out, but have one or more receipients=20 that do not support it, what happens must be defined. Q25:[Pete Resnick] There is existing stuff, we can't stop for that=20 document. But we need the model soon. Q26:[John Klensin] An "user experience" document as a gating criterion can=20 block progress; this is not a normal type of document for the IETF, so it's = unclear what it should say. Harald: Keith Moore defined it as "what happens when users send IEE mail to = non-island users". Keith:Should be longer term and not rushed just because there are already=20 consenting adults doing it. Q27:[DaveCrocker] Want another paragraph in charter, 2nd sentence of 2nd=20 paragraph is backwards. Enable UTF8 address natively, consider it the=20 default. SNMTP extension decleares a new characte rset. Q28:[Ted Hardie]: Basically, I believe we need to make sure the mail system = will not be fragmented. Q29:[Keith Moore]: Fragmentation is one failure. Garbage leaking is = another. Q30:[Harald] I'd like a show of hand for three question. 1: Should we work on this charter, send to IESG, request a WG? almost all raise hand. 2: Should we start working on this? almost all raise hand. 3: Are you willing to help ? many raise hand. Q31:[Harald] who want to implement the MUA and SMTP server? one (small, scared) for MUA, and CNNIC and 7 others for SMTP server Q32:[Philip Ganther] Also need a webmail author involved. Q33:[Harald] The acronym IMA is already used by another BOF, should we=20 suggest that we use IEE, or use another term? Answer: hope to continue using IEE. 7. Others The follow-on work is to revise the charter, and send to the area director, = ask the IESG to approve the WG, and to find a WG chair. --==========9AAB73FE40563EE3174D========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDjGQ5OMj+2+WY0F4RAozHAKCQ3C/FOxLKtZxhULK3qKEYvRLP5QCfXiGq hUI7ewSZI88nZjHdwIh/bOs= =pZeC -----END PGP SIGNATURE----- --==========9AAB73FE40563EE3174D==========-- --===============1239405233== 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 --===============1239405233==-- From ima-bounces@ietf.org Wed Nov 30 00:56:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhKxB-0006Vd-U1; Wed, 30 Nov 2005 00:56:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhKxA-0006VY-0p for ima@megatron.ietf.org; Wed, 30 Nov 2005 00:56:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29023 for ; Wed, 30 Nov 2005 00:55:40 -0500 (EST) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EhLHG-00052G-UP for ima@ietf.org; Wed, 30 Nov 2005 01:17:20 -0500 Received: (snipe 19426 invoked by uid 0); 30 Nov 2005 14:58:32 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.052987 secs); Received: from unknown (HELO ?210.107.249.21?) (Z?a?own@210.107.249.21) by unknown with SMTP; 30 Nov 2005 14:58:31 +0900 X-RCPTTO: harald@alvestrand.no, ima@ietf.org Message-ID: <438D3EF0.3050908@icu.ac.kr> Date: Wed, 30 Nov 2005 14:56:00 +0900 From: yangwoo ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [IMA] DRAFT minutes from IEE BOF References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> In-Reply-To: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > Please send corrections, additions, spelling errors to me. > > Minutes of the IEE BOF at IETF64, Vancouver, CA > Minutes take by: Sheldon Lee, Ed Lewis > Post-editing: Harald Alvestrand > > Meeting held Thursday, November 10, 2005, in Salon A/B, Westin Bayshore > Hotel > > Meeting chair: Harald Alvestrand > > 1.Agenda Bashing > Keith Moore: Q - What is the scope of this BOF? > Harald Alvestrand: For this bof, the question of whether there are > better apporaches is out of scope. It focuses on the architeture > proposed, trying to see whether that is viable. > Conclusion: no objection for agenda. > > 2. Draft framework, draft-klensin-ima-framework - John Klensin > Outline:Overview and Framework for Internationalized Email > Conclusion: no discussion and no questions for this presentation now. > > 3. SMTP Extension, draft-yao-ima-smtpext - J. Yao > Outline:SMTP extension for internationalized email address. Describes > the "IMA" > SMTP extension negotiating support for messages that use UTF-8 in > addresses and headers > Conclusion: no questions > > 4. UTF-8 header, draft-yeh-ima-utf8headers - J. Yeh > Outline: Transmission of email headers in utf8 encoding, specifiy the > use of unicode encoded in utf8 on email header bodies > Conclusion:no questions > > 5. Downgrading, draft-yoneya-ima-downgrade - K. Fujiwarea > Outline:Downgrading can occur before sending, after reception or in the > middle of transmission > Conclusion:no questions > > 6. Question and Answer/Discussion > > Q1:[Ted Hardie] One of John's early comments was that the downgrading > issue was less important than the previous other three document, and may > be a local matter. I expect that that is a critical question? > > Answer [John Klensin]: The internationalized email address is most > important within a community, for instance Chinese, or Arabic. Those > people are interested and need to communication with each other. > Communication between groups is far less prevalent. > The 8bitMIME experience showed that downgrade wasn't as important as > first thought - it was not a long term problem > > Q2:[Chris Newman] I'd like to address downgrading. I think the > charter need to say that we need the RFC about downgrading - at least > experimental. > The email system is made of multiple subsystems, and each subsystem > needs to be upgraded. > These are very large products and very complicated, so if I am going to > start supporting internationalized email address in the product, I have > to work on one subsystem at a time. Downgrading is most important > actually for software > implementation, we need something common for dowgrading. POP/IMAP should dowgrading -> downgrading > do some changes. WG charter may need to have POP/IMAP Experimental > documents. > > John Klensin: Need to be able to do things incrementally - Web clients, > User interfaces. Then stuff in the middle. > > Q3:[Keith Moore]: I am entirely supportive of this effort. > I am also really familar with this kind of problem. > Two questions: if someone sends a message to more than one person, and > some people have an user agent that supports the internationalized email > address, and others not, what should happen? > The second question is about the user experience. Different users have > different experience on email uses. How to integrate these different > user experiences is an issue that should be considered. We should > consider the MUA first. > SMTP is the least hard part, and the last step we need to worry about. > > John Klensin: It's time to get started on the SMTP part. Please don't > refer to the effort as "you" - we want you (Keith) to be part of it. > > Q4:[Chris] Imap and POP should be discussed, I think those are necessary > drafts, and I might do one of them. I think we do want to talk about the > upgrading of punycode, that will be the normative part of that. > Klensin: Punycode upgrading won't work. This effort is not meant to > solve all the problems of email at the same time. > > Q5:[Dave Croker]: Why do we need SMTP Extension? Why not just focus on > an ACE-type implementation? Why is utf-8 used in transportation instead > of ACE? > Klensin: Most operating systems are changing to support utf-8. Using > utf-8 is cooperating with the trend. Encodings tend to leak all over the > place - and negatively impact the user experience. Big problem is > Envelope address not equal to header address. > > Q6: [Dave Croker] Leakage happens with UTF8 as well. utf8 is nothing but > encoding. > > Q7:[Pete Resnick]: I think UTF8 is better because current status of OS > is changed, if you take a block of data, it should be utf8. > [Dave]: that problem is solved, thank you > > Q8:[Chris Newman]: Internationalizing email local parts is different > from the internationalizing domain name (IDN). These are different > infrastructures. IDN can not use the negotiation mechanism. IEE can use > some negotiation mechanisms. > > Q9:[Pete Resnick]: The current work is a good framework with SMTP > extension. But the hard work is how to deal with the issues related to end > systems. How do we jump start the user interface/experience work? > Klensin: Violently agree. We focus on the MTA issues. End systems is > about the presentation layer issues, MUA is traditionally not discussed > much in the IETF. > There are already MUAs for this stuff; we need to get the network > protocols in place to connect them. > > Q10:[Dave Crocker]: Should we follow the "PR" 2282 object & pseudo push? > The presentation layer is worrisome, no details documented, object needs > to be labelled. > My understanding is that Dave want to be able to recognize a "stored" message be of new format(i.e. IEE compliant) or old one (i.e. RFC 822 compliant). > Klensin: If necessary then next generation of email is needed. > > Q10:[Philip Ganther]: utf-8 is one kind of Unicode. I am afraid that > some country such as china use local characters in GB encoding instead > of Unicode in applications. > Answer by Yao: We do not need to worry about this. In China, most Web > systems and email systems or applications support Unicode by > transforming GB coding into Unicode. Most systems can transform GB to > Unicode. > > Q11:[Philip Ganther]Is language tag needed? > Answer by harald : RFC 2231 is a solution if we need it. It's not been > very popular. > Ganther: Needs to be discussed as a work item. > > Q12:[Ted Hardie]: There are islands of consenting adults using it already. > The problem is to deal with those who do not not consent yet. > One problem can be mailing lists. Another concern is whether this is a > constantly moving target. Do we cause failures for consenting or > non-consenting participants? > Klensin: We are no longer operating in the world with clean bounce. Spam > filters > throw stuff away. This is the most risky part of the effort. > > Q13:[Chris Newman]: I think the charter need to say that the downgrading > will be a experimental document and part of the initial document set. > Need POP and IMAP, volunteering to write the POP draft. > > Q14:[Randall Gellens]: We cannot have SMTP without POP and IMAP. > Concerned about label for RFC2822 > > Q15:[Macos Sanz] It's important to address this from the beginning; we > need a syntactic definition of the new local part. > Klensin: Agree. Need to define which characters are allowed, lengths and > so on. > > Q16:[Dave Croker]: This is a focus on mechanisms for walled gardens. > The default charset has been defined to ASCII. Defaults are bad because > defaults can be changed. No default tagging should remain; all tags > should be explicit. Labelling is easy and essential. > > Q17:[Tony Hansen]: POP and IMAP are important. I'm willing to work on > these. Guidance from MUA authors is needed. > > Q18:[Keith Moore]: I'm disturbed about where the discussion is going. > We must first deal with the user experience - document what user > experience we are trying to create. > > Q19:[John Klensin]: IMAP and POP both need to be considered. The > differences between them do not make it easy to generalize. > > Q20:[Chris]: What the MUA does should be defined in one draft, it need a > draft. POP will be the first doc; both POP and IMAP are needed. > We must deal with user experience - MUA, but think this new effort is > informed by that. Need MUA draft to deal with leakage. POP and IMAP at > the same time is ok, but should not be held up by IMAP. > > Q21:[Randy Glellens] Community's there. That's good. Still need IMAP and > POP. Ugly addresses vs unexpected 8bit problem. > > Q22:[Cyrus Daboo, via Jabber]: Impact on LDAP, ACAP, vcard too. > > Q23:[Harald]: Massive support for going forward with the work. Are we > good with > charter? With updates adding documents for POP, IMAP, mailing lists and > other considerations for storing email addresses? > > Q24:[Keith Moore] The first deliverable needs to be a document > describing the user interface in mixed cases - description of the moving > parts. All other work should be tabled until then. > When you send mail with UTF8 headers out, but have one or more > receipients that do not support it, what happens must be defined. > > Q25:[Pete Resnick] There is existing stuff, we can't stop for that > document. But we need the model soon. > > Q26:[John Klensin] An "user experience" document as a gating criterion > can block progress; this is not a normal type of document for the IETF, > so it's unclear what it should say. > Harald: Keith Moore defined it as "what happens when users send IEE mail > to non-island users". > Keith:Should be longer term and not rushed just because there are > already consenting adults doing it. > > Q27:[DaveCrocker] Want another paragraph in charter, 2nd sentence of 2nd > paragraph is backwards. Enable UTF8 address natively, consider it the > default. SNMTP extension decleares a new characte rset. default. SMTP extension declares a new character set. > > Q28:[Ted Hardie]: Basically, I believe we need to make sure the mail > system will not be fragmented. > > Q29:[Keith Moore]: Fragmentation is one failure. Garbage leaking is > another. > > Q30:[Harald] I'd like a show of hand for three question. > 1: Should we work on this charter, send to IESG, request a WG? > almost all raise hand. > 2: Should we start working on this? > almost all raise hand. > 3: Are you willing to help ? > many raise hand. > > Q31:[Harald] who want to implement the MUA and SMTP server? > one (small, scared) for MUA, and CNNIC and 7 others for SMTP server > > Q32:[Philip Ganther] Also need a webmail author involved. > > Q33:[Harald] The acronym IMA is already used by another BOF, should we > suggest that we use IEE, or use another term? > Answer: hope to continue using IEE. > > 7. Others > The follow-on work is to revise the charter, and send to the area > director, ask the IESG to approve the WG, and to find a WG chair. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Nov 30 10:36:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhU0C-00074C-CQ; Wed, 30 Nov 2005 10:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhU0B-000746-J5 for ima@megatron.ietf.org; Wed, 30 Nov 2005 10:36:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01278 for ; Wed, 30 Nov 2005 10:35:25 -0500 (EST) Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhUKQ-0007HT-R7 for ima@ietf.org; Wed, 30 Nov 2005 10:57:10 -0500 Received: from host81-144-65-236.midband.mdip.bt.net ([81.144.65.236]) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.203) id 438dc6cf.16a26.3a5; Wed, 30 Nov 2005 15:35:43 +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 jAUCM7L09359; Wed, 30 Nov 2005 12:22:07 GMT To: "yangwoo ko" , "Harald Tveit Alvestrand" Subject: Re: [IMA] DRAFT minutes from IEE BOF References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> Message-ID: Date: Wed, 30 Nov 2005 12:21:59 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <438D3EF0.3050908@icu.ac.kr> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA01278 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Wed, 30 Nov 2005 05:56:00 -0000, yangwoo ko wrote: >> Q10:[Dave Crocker]: Should we follow the "PR" 2282 object & pseudo =20 >> push? >> The presentation layer is worrisome, no details documented, object =20 >> needs to be labelled. >> > > My understanding is that Dave want to be able to recognize a > "stored" message be of new format(i.e. IEE compliant) or old one > (i.e. RFC 822 compliant). Yes, I would like to see that. I have suggested a header which says, in =20 effect "I am an I18N message". It may not be needed when messages are sen= t =20 by SMTP, but it would be useful for all sorts of other purposes, such as = =20 when other transport protocols are used, or for use inside IMAP =20 implementations. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 30 11:28:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUp7-0001Zr-Pt; Wed, 30 Nov 2005 11:28:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhUp6-0001Zm-QT for ima@megatron.ietf.org; Wed, 30 Nov 2005 11:28:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06779 for ; Wed, 30 Nov 2005 11:28:03 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhV9N-0000aT-8L for ima@ietf.org; Wed, 30 Nov 2005 11:49:48 -0500 Received: from [192.168.0.3] (adsl-71-131-42-52.dsl.sntc01.pacbell.net [71.131.42.52]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAUGSqsH009554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2005 08:28:52 -0800 Message-ID: <438DD319.20204@dcrocker.net> Date: Wed, 30 Nov 2005 08:28:09 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: yangwoo ko Subject: Re: [IMA] DRAFT minutes from IEE BOF References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> In-Reply-To: <438D3EF0.3050908@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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org >> Q10:[Dave Crocker]: Should we follow the "PR" 2282 object & pseudo push? >> The presentation layer is worrisome, no details documented, object >> needs to be labelled. >> > > My understanding is that Dave want to be able to recognize a > "stored" message be of new format(i.e. IEE compliant) or old one > (i.e. RFC 822 compliant). I do not recall my words, but you the gist of my concern is approximately what you understood. The general form of my concerns: When there are multiple choices in content form, the choice that applies for a given message needs to be labeled explicitly within the message. Messages need to be self-contained, rather than relying on their context for interpretation. This is during transit, as well as storage. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 30 12:26:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhVir-0001eH-LR; Wed, 30 Nov 2005 12:26:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhViq-0001V9-7Y for ima@megatron.ietf.org; Wed, 30 Nov 2005 12:26:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14153 for ; Wed, 30 Nov 2005 12:25:38 -0500 (EST) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhW39-0002aG-Ub for ima@ietf.org; Wed, 30 Nov 2005 12:47:24 -0500 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EhVia-000GFf-Dy; Wed, 30 Nov 2005 12:26:08 -0500 Date: Wed, 30 Nov 2005 12:26:07 -0500 From: John C Klensin To: dcrocker@bbiw.net, yangwoo ko Message-ID: <78EF5B4A20A4F218B6968ABF@scan.jck.com> In-Reply-To: <438DD319.20204@dcrocker.net> References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@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: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: [IMA] Header for stored messages (was: Re: DRAFT minutes from IEE BOF) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --On Wednesday, 30 November, 2005 08:28 -0800 Dave Crocker wrote: > >>> Q10:[Dave Crocker]: Should we follow the "PR" 2282 object & >>> pseudo push? The presentation layer is worrisome, no details >>> documented, object needs to be labelled. >>> >> >> My understanding is that Dave want to be able to recognize a >> "stored" message be of new format(i.e. IEE compliant) or old >> one (i.e. RFC 822 compliant). > > > I do not recall my words, but you the gist of my concern is > approximately what you understood. > > The general form of my concerns: > > When there are multiple choices in content form, the > choice that applies for a given message needs to be labeled > explicitly within the message. Messages need to be > self-contained, rather than relying on their context for > interpretation. This is during transit, as well as storage. Dave, While this clearly belongs in the minutes since it was discussed, I want to open a bit of discussion on this topic. I want to stress that I don't have a strong position on it; I'm just trying to understand the claimed requirement and what would satisfy it a little better. In theory, the content of messages in transit is not examined at all, so it makes little difference what is in the headers except at the endpoints. I'm also reminded of the famous "MIME-Version: 1.0" header field, which was supposed to denote a new way of identifying headers (particularly the presence and interpretation of "Content-type:") as well as a formatted body. Now, it was arguably necessary because "Content-type:" was already in use for slightly different information in a slightly different format -- only if "MIME-version:" was also present could one be reasonably assured that "Content-type:" could safely be interpreted according to MIME rules. But, for all the other good it has done us -- and, in particular, our inability to change the version number in a meaningful way -- we could have named the Content-type field "MIME-Content-Type:", required it, and saved the extra header line. So, first, for amusement value, is this "MIME-Version: 2.0"? My gut tells me this isn't a good idea, but at least the odds of some intermediary filter discarding the message would be reduced. More generally, is this a header that should be required to be pushed into the message on final delivery or as part of a gateway process, not unlike "Return-path:". And, if not, what is the value of having it in transit? It also seems to me that the _real_ point at which this is most important is in the message store and in the mechanisms used to pick the message up from the store and deliver them to, e.g., a POP server or client. If that is the case, are we going to start specifying message store formats now? We have carefully avoided it in the past and, as you know better than anyone else, 822 is specified as the format of headers on delivery, not the format that has to be used in message stores and otherwise within systems. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Nov 30 15:49:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYtA-0000cw-8b; Wed, 30 Nov 2005 15:49:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYt8-0000cf-AB for ima@megatron.ietf.org; Wed, 30 Nov 2005 15:49:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11229 for ; Wed, 30 Nov 2005 15:48:29 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhZDR-0002cB-F1 for ima@ietf.org; Wed, 30 Nov 2005 16:10:15 -0500 Received: from [192.168.0.3] (adsl-71-131-42-52.dsl.sntc01.pacbell.net [71.131.42.52]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAUKnaLA015569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2005 12:49:37 -0800 Message-ID: <438E1036.2070706@dcrocker.net> Date: Wed, 30 Nov 2005 12:48:54 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: John C Klensin References: <7F75A871305ABCDCD01B15F1@B50854F0A9192E8EC6CDA126> <438D3EF0.3050908@icu.ac.kr> <438DD319.20204@dcrocker.net> <78EF5B4A20A4F218B6968ABF@scan.jck.com> In-Reply-To: <78EF5B4A20A4F218B6968ABF@scan.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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: [IMA] Re: Header for stored messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "IMA \(Internationalized eMail Address\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org > In theory, the content of messages in transit is not examined at > all, so it makes little difference what is in the headers except > at the endpoints. Parts of transit are packaging and unpackaging for posting and delivery. These are examples of needing self-labeling. > I'm also reminded of the famous "MIME-Version: 1.0" header > field, which was supposed to denote a new way of identifying > headers (particularly the presence and interpretation of > "Content-type:") as well as a formatted body. Now, it was > arguably necessary because "Content-type:" was already in use Right. Self-labeling. We can quibble about the how, but the main point is that a message with a free-text body has a different labeling than a message with a MIME body, so that a processor can know which model to apply. > More generally, is this a header that should be required to be > pushed into the message on final delivery or as part of a > gateway process, not unlike "Return-path:". And, if not, what > is the value of having it in transit? Yeah, I suppose we could quibble whether to have it only in the SMTP commands during transit, but in the message itself otherwise, but my main concern is robustness in the absence of context. d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima