From ima-bounces@ietf.org Thu Sep 01 03:25:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjRw-0002Tc-JZ; Thu, 01 Sep 2005 03:25:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjRt-0002Ry-M9 for ima@megatron.ietf.org; Thu, 01 Sep 2005 03:25:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01589 for ; Thu, 1 Sep 2005 03:25:24 -0400 (EDT) Received: from smtp2.cnnic.cn ([159.226.7.151] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EAjTh-0003Dq-JF for ima@ietf.org; Thu, 01 Sep 2005 03:27:24 -0400 Received: (eyou send program); Thu, 01 Sep 2005 15:24:45 +0800 Message-ID: <325559485.28630@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, 01 Sep 2005 15:24:45 +0800 Message-ID: <021401c5aec6$04636e70$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "John C Klensin" , References: <325469707.29749@cnnic.cn>, <01d201c5adf4$fba2e7b0$1206e29f@cnnicyaojk> <325473531.15517@cnnic.cn> Subject: Re: [IMA] re: JET IMA meeting memo Date: Thu, 1 Sep 2005 15:23:14 +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: ff03b0075c3fc728d7d60a15b4ee1ad2 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="===============1439379686==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1439379686== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQppZiB1dGYtOEB1dGYtOCBpcyB1c2VkLCB3aGVuIHRoZSB1dGYtOCBmb3IgIHRoZSBkb21haW4g cGFydCBpcyB1c2VkIHRvIGxvb2sgaW50byBETlMgdG8gZmluZCB0aGUgcmVsYXRpdmUgSVAgYWRk cmVzcywgZG9lcyB0aGUgZG9tYWluIHBhcnQgaGF2ZSB0byBiZSB0dXJuZWQgaW50byBBQ0U/DQoN CiBZYW8gSmlhbmthbmcNCkNOTklDICANCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8a2xlbnNpbkBqY2suY29tPg0KVG86ICJZQU8gSmlh bmthbmciIDx5YW9qa0Bjbm5pYy5jbj47IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAzMSwgMjAwNSAzOjMyIFBNDQpTdWJqZWN0OiBSZTogW0lNQV0gcmU6IEpFVCBJTUEg bWVldGluZyBtZW1vDQoNCg0KPiANCj4gDQo+IC0tT24gV2VkbmVzZGF5LCAzMSBBdWd1c3QsIDIw MDUgMTQ6MjYgKzA4MDAgWUFPIEppYW5rYW5nDQo+IDx5YW9qa0Bjbm5pYy5jbj4gd3JvdGU6DQo+ IA0KPiA+IGFjY29yZGluZyB0byB0aGUgcHJvcG9zYWxzIHdlIGRpc2N1c3NlZCwNCj4gPiAtIHBy b3MgYW5kIGNvbnMgb2YgMyBwcm9wb3NhbHMNCj4gPiAgICgxKSBKRVQgQUNFQEFDRQ0KPiA+ICAg KDIpIEpvaG4rQ0ROQyBVVEY4QFVURjggKG5vIGRvd25ncmFkZSkNCj4gPiAgICgzKSBKb2huK0NE TkMgVVRGOEBVVEY4ICh3LyBkb3duZ3JhZGUpDQo+ID4gDQo+ID4gaWYgcHJvcG9zYWwgMiBpcyB1 c2VkIHdpdGggbm8gZG93bmdyYWRlLCBpZiBzZW5kZXIgc210cA0KPiA+IHN1cHBvcnRzIElNQSwg YnV0IHJlY2VpdmVyIHNtdHAgZG9lc24ndCBzdXBwb3J0IElNQSwgdGhlIElNQQ0KPiA+IGFkZHJl c3MgaXMgYm91bmNlZCBieSByZWNlaXZlciBTTVRQPw0KPiANCj4gTm8sIGFjdHVhbGx5LCBpdCBp cyBib3VuY2VkIGJ5IHRoZSBzZW5kZXIgU01UUC4gIFNpbmNlIGl0IGlzDQo+IHZlcnkgaW1wb3J0 YW50IHRoYXQgZXZlcnlvbmUgdW5kZXJzdGFuZCBob3cgU01UUCBhbmQgdGhlDQo+IGV4dGVuc2lv biBtZWNoYW5pc20gYWN0dWFsbHkgd29ya3MgaW4gdGhpcyBlbnZpcm9ubWVudCwgbGV0IG1lDQo+ IHJldmlldyB0aGUgdHJhbnNhY3Rpb24gZmxvdywgYXNzdW1pbmcgdGhhdCB0aGUgcmVsZXZhbnQg b3B0aW9uDQo+IGlzIGNhbGxlZCAiSU1BIi4gICJTOiIgcmVwcmVzZW50cyB0aGUgc2VuZGVyIFNN VFAsICJSOiIgdGhlDQo+IHJlY2VpdmVyLiAgDQo+IA0KPiAoMSkgUzogb3BlbnMgY29ubmVjdGlv bg0KPiAoMikgUjogMjIwIE9rDQo+ICgzKSBTOiBFSExPIHNlbmRlci1ob3N0LmRvbWFpbi5uYW1l DQo+ICg0KSBSOiAyNTAtcmVjZWl2ZXItaG9zdC5yZWNlaXZlci1kb21haW4ubmFtZQ0KPiAoNSkg UjogMjUwLThCSVRNSU1FDQo+ICg2KSBSOiAyNTAtRVhQTg0KPiAoNykgUjogMjUwIFNJWkUNCj4g KDgpIFM6IE1BSUwgRlJPTTo8c29tZXVzZXJAc29tZS5kb21haW4+DQo+ICg5KSBSOiAyNTAgT0sN Cj4gKDEwKSBTOiBSQ1BUIFRPOjxhLW1haWxib3hAcmVjZWl2ZXItaG9zdC5yZWNlaXZlci1kb21h aW4ubmFtZT4NCj4gDQo+IA0KPiANCj4gTm90ZXM6DQo+ICgyKSBWaXJ0dWFsbHkgYW55IHRleHQg Y2FuIGZvbGxvdyB0aGUgIjIyMCAiLCBidXQgdGhlIHNlbmRlcg0KPiB3aWxsIHR5cGljYWxseSBp Z25vcmUgaXQuDQo+IA0KPiAoNSktKDcpIGluZGljYXRlIHRoYXQgOEJJVE1JTUUsIEVYUE4sIGFu ZCBTSVpFIGFyZSBzdXBwb3J0ZWQsDQo+IGJ1dCBJTUEgaXMgbm90IChzaW5jZSBpdCBpcyBub3Qg bGlzdGVkKQ0KPiANCj4gKDgpIFNpbmNlIElNQSBpcyBub3QgYWR2ZXJ0aXNlZCBieSB0aGUgcmVj ZWl2ZXIsIHRoZSBzZW5kZXIgTVVTVA0KPiBOT1Qgc2VuZCBhbnkgbm9uLUFTQ0lJIGFkZHJlc3Nl cyBpbiBlaXRoZXIgTUFJTCBvciBSQ1BUDQo+IGNvbW1hbmRzLCBub3IgbWF5IHRoZSBtYWlsIGhl YWRlcnMgY29udGFpbiBhbnkgaW50ZXJuYXRpb25hbGl6ZWQNCj4gaW5mb3JtYXRpb24gZXhjZXB0 IGluIGVuY29kZWQgd29yZHMgd2hlcmUgdGhvc2UgYXJlIHBlcm1pdHRlZC4NCj4gTm90ZSB0aGF0 IHRoZSBhcmd1bWVudCB0byB0aGUgTUFJTCBjb21tYW5kIGNvdWxkLCB1bmRlciBwcm9wb3NhbA0K PiAoMSksIGJlIGFuIEFDRTogdGhlIHNlbmRpbmcgaG9zdCB3aWxsIHVuZGVyc3RhbmQgaXRzIG93 biBuYW1pbmcNCj4gc3RydWN0dXJlLiAgSG93ZXZlciwNCj4gDQo+ICgxMCkgTWF5IG5vdCBldmVu IGNvbnRhaW4gYW4gQUNFIHVubGVzcyB0aGUgQUNFIHdhcyBwcm92aWRlZCBieQ0KPiB0aGUgc2Vu ZGluZyB1c2VyIGFuZCBvYnRhaW5lZCBpbiBzb21lIG91dCBvZiBiYW5kIHdheS4NCj4gT3RoZXJ3 aXNlLCB5b3UgaGF2ZSBubyB3YXkgdG8gYmUgYXNzdXJlZCB0aGF0IHRoZSByZWNlaXZpbmcgaG9z dA0KPiB3aWxsIGRlY29kZSBpdCwgdGhhdCBpdCB1bmRlcnN0YW5kcyB0aGUgQUNFIGNvbnZlbnRp b25zLCBhbmQNCj4gdGhhdCB0aGUgYXBwYXJlbnQgQUNFIHN5bnRheCBpcyBub3QgcmVhbGx5IGEg c3BlY2lhbCBjb21tYW5kIGluDQo+IGRpc2d1aXNlLg0KPiANCj4gU28sIGlmIHRoZSBTTVRQLXNl bmRlciBkb2VzIG5vdCBoYXZlIEFTQ0lJIHJldmVyc2UgYW5kIGZvcndhcmQNCj4gcGF0aCBhZGRy ZXNzZXMgYXZhaWxhYmxlIGZvciB1c2UgaW4gc3RlcHMgOCBhbmQgMTAsIGl0IFNIT1VMRA0KPiBz ZW5kIFFVSVQgb3IgUlNFVCBpbnN0ZWFkIG9mIHN0ZXAgKDgpIGFib3ZlIGFuZCBub3RpZnkgdGhl IHVzZXINCj4gKG9yIHRoZSBTTVRQIHRoYXQgc2VudCB0aGUgbWVzc2FnZSB0byBpdCkgYW5kIE1V U1QgZG8gc28gYmVmb3JlDQo+IHNlbmRpbmcgYW55IGkxOG4gaW5mb3JtYXRpb24uDQo+IA0KPiBX aXRoaW4gdGhlIG5vcm1hbCBkZWZpbml0aW9ucyBvZiBJbnRlcm5ldCBtYWlsLCB0aGF0IGlzIGEN Cj4gc3VjY2VzczogdGhlIG1lc3NhZ2UgaGFzIG5vdCBnb3R0ZW4gbG9zdCBidXQgaGFzIGJlZW4g cHJvcGVybHkNCj4gYWNjb3VudGVkIGZvciB0byB0aGUgc2VuZGVyLiAgSXQgd2FzIGp1c3Qgbm90 IGRlbGl2ZXJhYmxlIHRvIGENCj4gaG9zdCB0aGF0IGRpZCBub3Qgc3VwcG9ydCB0aGUgYWRkcmVz c2luZyBzeW50YXguDQo+IA0KPiA+IG9yIFByb3Bvc2FsIDIgY2FuIG9ubHkgYmUNCj4gPiB1c2Vk IGluIHRoZSBzY2VuYXJpbyB3aGVyZSBib3RoIHNlbmRlciBzbXRwIGFuZCBib3RoIHJlY2VpdmVy DQo+ID4gc210cCBzdXBwb3J0cyBJTUE/DQo+IA0KPiBEZXBlbmRzIG9uIHdoYXQgeW91IG1lYW4g YnkgImNhbiBvbmx5IGJlIHVzZWQiLiAgRXhhbWluZSBob3cgdGhlDQo+IGFib3ZlIHdvdWxkIHdv cmsgd2l0aCBJTUEgc3VwcG9ydGVkLiAgV2Ugd291bGQgdGhlbiBoYXZlLi4uDQo+IA0KPiAoMSkg Uzogb3BlbnMgY29ubmVjdGlvbg0KPiAoMikgUjogMjIwIE9rDQo+ICgzKSBTOiBFSExPIHNlbmRl ci1ob3N0LmRvbWFpbi5uYW1lDQo+ICg0KSBSOiAyNTAtcmVjZWl2ZXItaG9zdC5yZWNlaXZlci1k b21haW4ubmFtZQ0KPiAoNSkgUjogMjUwLThCSVRNSU1FDQo+ICg2KSBSOiAyNTAtRVhQTg0KPiAo NykgUjogMjUwLVNJWkUNCj4gKDdhKTogUjogMjUwIElNQQ0KPiAoOCkgUzogTUFJTCBGUk9NOjxz b21ldXNlckBzb21lLmRvbWFpbj4NCj4gKDkpIFI6IDI1MCBPSw0KPiAoMTApIFM6IFJDUFQgVE86 PGEtbWFpbGJveEByZWNlaXZlci1ob3N0LnJlY2VpdmVyLWRvbWFpbi5uYW1lPg0KPiAoMTEpIFI6 IDI1MCBhZGRyZXNzIG9rDQo+ICgxMikgUzogREFUQQ0KPiAoMTMpIFI6IDM1NCBTZW5kIGRhdGEs IDhiaXQgcGVybWl0dGVkDQo+ICgxNCkgUzogRnJvbTogc29tZXVzZXJAc29tZS5kb21haW4NCj4g ICAgICBTOiBUbzogYS1tYWlsYm94QHJlY2VpdmVyLWhvc3QucmVjZWl2ZXItZG9tYWluLm5hbWUN Cj4gICAgICBTOiBEYXRlOiBXZWQsIDMxIEF1ZyAyMDA1IDE0OjI2OjU1ICswODAwDQo+ICAgICAg UzogTUlNRS1WZXJzaW9uOiAxLjANCj4gICAgICBTOiBDb250ZW50LXR5cGU6IHRleHQvcGxhaW47 IGNoYXJzZXQ9dXRmOA0KPiAgICAgIFM6ICAgIFsuLi5dDQo+ICAgICAgUzogDQo+ICgxNSkgUzog TWVzc2FnZSB0ZXh0DQo+ICAgICAgUzogbW9yZSB0ZXh0DQo+ICgxNikgUzogLg0KPiAoMTcpIFI6 IDI1MCBNZXNzYWdlIHJlY2VpdmVkDQo+ICgxOCkgUzogUVVJVA0KPiAoMTkpIFI6IDI1MCBPaywg cXVpdHRpbmcNCj4gKDIwKSBSOiAoY2xvc2VzIGNvbm5lY3Rpb24pDQo+IA0KPiBBbmQsIHdpdGgg dGhlIElNQSBvcHRpb24gYWR2ZXJ0aXNlZCBhcyBhIHNlcnZlciBjYXBhYmlsaXR5IGluDQo+IGxp bmUgN2EsIHRoZSBzZW5kZXIgd291bGQgYmUgZnJlZSB0byB1c2UgVVRGLTggYWRkcmVzc2VzIGlu DQo+IGxpbmVzIDggYW5kL29yIDEwLiAgSWYgd2UgZG8gdGhpcyBhcyB3ZSBoYXZlIGRpc2N1c3Nl ZCwgYW55IG9mDQo+IHRoZSBoZWFkZXIgZmllbGRzIGluICgxNCkgY291bGQgYmUgc3BlY2lmaWVk IGFzIGJlaW5nIGluIFVURi04DQo+IGFuZCwgc2luY2UgYW4gYXBwcm9wcmlhdGUgY29udGVudCB0 eXBlIGlzIHNwZWNpZmllZCwgc28gY291bGQNCj4gdGhlIG1lc3NhZ2UgdGV4dCBpbiAoMTUpLg0K PiANCj4gRG9lcyB0aGF0IGhlbHA/DQo+IA0KPiA+IGlmIHdlIGNvbnNpZGVyIHRoZSBzZWNlbmFy aW8gdGhhdCB3ZSBjYW4gbm90IHVwZ3JhZGUgYWxsIHNtdHANCj4gPiBzZXJ2ZXJzIHRvIHN1cHBv cnQgSU1BLCBwcm9wb3NhbCAzIHdpdGggZG93bmdyYWRlIG1heSBiZQ0KPiA+IGJldHRlci4NCj4g DQo+IE5vdGUgdGhhdCBwcm9wb3NhbCAzIGRvZXMgbm90IGNoYW5nZSB0aGUgYWJvdmUgYXQgYWxs LiAgICBJZiB3ZQ0KPiBoYXZlIHRoZSBmaXJzdCBzY2VuYXJpbyAod2l0aCBJTUEgbm90IGFkdmVy dGlzZWQpLCB0aGUgc2VuZGluZw0KPiBTTVRQIHNlcnZlciBjYW4gZ2V0IHRvIHRoZSBlbmQgb2Yg c3RlcCA3IGFuZCB0aGVuLCByYXRoZXIgdGhhbg0KPiBzZW5kaW5nIHRoZSBvcmlnaW5hbCBub24t QVNDSUkgYWRkcmVzcyBpbmZvcm1hdGlvbiB0aGF0IHdvdWxkIGJlDQo+IGNvbnRlbXBsYXRlZCBp biBzdGVwIDgsIGl0IG11c3QgdGhlbiB0cmFuc2Zvcm0gdGhlIGFkZHJlc3NlcyBhbmQNCj4gaGVh ZGVycyBpbnRvIHN0YW5kYXJkIGZvcm0gYW5kIHRoZW4gc2VuZCB0aGVtIGFzIGlmIGl0IGhhZCBu ZXZlcg0KPiBoZWFyZCBvZiBJTUEuICAgDQo+IA0KPiBUaGF0ICJzdG9wIGluIHRoZSBtaWRkbGUg b2YgdGhlIHRyYW5zYWN0aW9uIGFuZCBjb252ZXJ0Ig0KPiBwcm9wZXJ0eSBpcywgaW5jaWRlbnRh bGx5LCBhIG1ham9yIHJlYXNvbiB3aHkgOEJJVE1JTUUNCj4gZG93bmdyYWRpbmcgd2FzIG5ldmVy IHdpZGVseSBzdXBwb3J0ZWQuICBNb3N0IGdvb2QtcXVhbGl0eSBTTVRQDQo+IHNlcnZlcnMgYXJl IGRlc2lnbmVkIHRvICJnZXQgcmlkIG9mIiBtZXNzYWdlcyBhcyBxdWlja2x5IGFzDQo+IHBvc3Np YmxlIG9uY2UgdGhlIHJlbGV2YW50IFRDUCBjb25uZWN0aW9uIGlzIG9wZW5lZC4gIEhlcmUsIGlm DQo+IElNQSAoYW5kIDhCSVRNSU1FKSBhcmUgbm90IHN1cHBvcnRlZCwgd2UgZXhwZWN0IHRoZSBz ZW5kaW5nIFNNVFANCj4gc2VydmVyIHRvIHN0b3Agd2hhdCBpdCBpcyBkb2luZyBhZnRlciByZWNl aXZpbmcgdGhlIEVITE8NCj4gcmVzcG9uc2UsIHBlcmZvcm0gYSBtb2RlcmF0ZWx5IGNvbXBsaWNh dGVkIGNvbnZlcnNpb24gd2hpbGUNCj4gaG9sZGluZyB0aGUgY29ubmVjdGlvbiB0byB0aGUgcmVj ZWl2ZXIgU01UUCBvcGVuLCB0aGVuIHNlbmQgdGhlDQo+IHJlY29uc3RydWN0ZWQgbWVzc2FnZSwg aG9waW5nIHRoYXQgdGhlIHJlY2VpdmVyIGRvZXMgbm90IHRpbWUNCj4gb3V0IGluIHRoZSBpbnRl cnZhbC4NCj4gDQo+IEluIGF0IGxlYXN0IG9uZSBjYXNlLCBpdCB3YXMgaW1wbGVtZW50ZWQgaW4g YSBkaWZmZXJlbnQgd2F5LCBvbmUNCj4gdGhhdCBpcyBwZXJtaXR0ZWQgYnkgdGhlIHNwZWNpZmlj YXRpb24gYnV0IHRoYXQgbWF5IG5vdCBiZQ0KPiBkZXNpcmFibGUuICAgSW4gdGhpcyBhbHRlcm5h dGUgbWV0aG9kLCB0aGUgbWFpbCB0cmFuc2FjdGlvbiB3YXMNCj4gdGVybWluYXRlZCAoYSBRVUlU IG9yIFJTRVQgY29tbWFuZCBzZW50KSBhcyBzb29uIGFmdGVyIHRoZSBFSExPDQo+IHJlc3BvbnNl IGFwcGVhcmVkIHdpdGhvdXQgdGhlIG5lZWRlZCBjYXBhYmlsaXRpZXMgYW5kIGl0IHdhcw0KPiBk aXNjb3ZlcmVkIHRoYXQgdGhlIGNhcGFiaWxpdHkgd2FzIG5lZWRlZC4gIFRoZSBvcmlnaW5hbCBt ZXNzYWdlDQo+IHdhcyB0aGVuIGRyb3BwZWQgaW50byBhIHNwZWNpYWwgcXVldWUgZm9yDQo+IGNv bnZlcnNhdGlvbi9kb3duZ3JhZGluZyBhbmQgc3Vic2VxdWVudCBxdWV1ZWluZyBmb3IgYSBzZWNv bmQNCj4gYXR0ZW1wdCB3aXRob3V0IGhvbGRpbmcgdGhlIFRDUCBjb25uZWN0aW9uIG9wZW4uICBU aGF0IGlzIGZhaXJseQ0KPiBlZmZpY2llbnQgZnJvbSB0aGUgc3RhbmRwb2ludCBvZiB0aGUgU01U UCBzZW5kaW5nIHNlcnZlciwgYnV0DQo+IHN0YW5kYXJkIHJldHJ5IGludGVydmFscyBjb3VsZCB0 aGVuIHJlc3VsdCBpbiBhIGRlbGF5IG9mIHNvbWUNCj4gaG91cnMgYmVmb3JlIGFuIGF0dGVtcHQg d2FzIG1hZGUgdG8gZGVsaXZlciB0aGUgZG93bmdyYWRlZCBtYWlsLg0KPiA+RnJvbSB0aGUgc3Rh bmRwb2ludCBvZiB0aGUgc2VuZGluZyB1c2VyLCBpdCBtaWdodCBoYXZlIGJlZW4NCj4gcHJlZmVy cmVkIHRoYXQgdGhlIG1lc3NhZ2UgYmUgYm91bmNlZCBzbyB0aGF0IGl0IGNvdWxkIGJlDQo+IGlt bWVkaWF0ZWx5IHJlc2VudCBpbiBjb21wYXRpYmxlLyBkb3duZ3JhZGVkIGZvcm0sIHJhdGhlciB0 aGFuDQo+IGhhdmluZyBpdCBkZWxheWVkIGluIHRyYW5zaXQgdGhhdCB3YXkuDQo+IA0KPiByZWdh cmRzLA0KPiAgICAgam9obg0KPiA= --===============1439379686== 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 --===============1439379686==-- From ima-bounces@ietf.org Thu Sep 01 03:54:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjtm-0001iQ-J2; Thu, 01 Sep 2005 03:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjtl-0001iI-DQ for ima@megatron.ietf.org; Thu, 01 Sep 2005 03:54:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02717 for ; Thu, 1 Sep 2005 03:54:12 -0400 (EDT) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EAjva-00049f-SF for ima@ietf.org; Thu, 01 Sep 2005 03:56:12 -0400 Received: (snipe 23966 invoked by uid 0); 1 Sep 2005 16:54:53 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.94 (Processed in 0.062056 secs); Received: from unknown (HELO ?220.69.185.75?) (ZO??own@220.69.185.75) by unknown with SMTP; 1 Sep 2005 16:54:53 +0900 X-RCPTTO: ima@ietf.org Message-ID: <4316B389.7030105@icu.ac.kr> Date: Thu, 01 Sep 2005 16:53:45 +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 Subject: Re: [IMA] re: JET IMA meeting memo References: <325469707.29749@cnnic.cn>, <01d201c5adf4$fba2e7b0$1206e29f@cnnicyaojk> <325473531.15517@cnnic.cn> <325559485.28630@cnnic.cn> In-Reply-To: <325559485.28630@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit 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 YAO Jiankang wrote: > if utf-8@utf-8 is used, when the utf-8 for the domain part is used to look into DNS to find the relative IP address, does the domain part have to be turned into ACE? In my understading, the step (1) of John's flow includes; * converting domain part using ACE * finding MX record using the ACE version of domain * name resolution with returned mail server name/address * open connection with the returned IP address Regards > > Yao Jiankang > CNNIC > > > ----- Original Message ----- > From: "John C Klensin" > To: "YAO Jiankang" ; > Sent: Wednesday, August 31, 2005 3:32 PM > Subject: Re: [IMA] re: JET IMA meeting memo > > > >> >>--On Wednesday, 31 August, 2005 14:26 +0800 YAO Jiankang >> wrote: >> >> >>>according to the proposals we discussed, >>>- pros and cons of 3 proposals >>> (1) JET ACE@ACE >>> (2) John+CDNC UTF8@UTF8 (no downgrade) >>> (3) John+CDNC UTF8@UTF8 (w/ downgrade) >>> >>>if proposal 2 is used with no downgrade, if sender smtp >>>supports IMA, but receiver smtp doesn't support IMA, the IMA >>>address is bounced by receiver SMTP? >> >>No, actually, it is bounced by the sender SMTP. Since it is >>very important that everyone understand how SMTP and the >>extension mechanism actually works in this environment, let me >>review the transaction flow, assuming that the relevant option >>is called "IMA". "S:" represents the sender SMTP, "R:" the >>receiver. >> >>(1) S: opens connection >>(2) R: 220 Ok >>(3) S: EHLO sender-host.domain.name >>(4) R: 250-receiver-host.receiver-domain.name >>(5) R: 250-8BITMIME >>(6) R: 250-EXPN >>(7) R: 250 SIZE >>(8) S: MAIL FROM: >>(9) R: 250 OK >>(10) S: RCPT TO: >> >> >> >>Notes: >>(2) Virtually any text can follow the "220 ", but the sender >>will typically ignore it. >> >>(5)-(7) indicate that 8BITMIME, EXPN, and SIZE are supported, >>but IMA is not (since it is not listed) >> >>(8) Since IMA is not advertised by the receiver, the sender MUST >>NOT send any non-ASCII addresses in either MAIL or RCPT >>commands, nor may the mail headers contain any internationalized >>information except in encoded words where those are permitted. >>Note that the argument to the MAIL command could, under proposal >>(1), be an ACE: the sending host will understand its own naming >>structure. However, >> >>(10) May not even contain an ACE unless the ACE was provided by >>the sending user and obtained in some out of band way. >>Otherwise, you have no way to be assured that the receiving host >>will decode it, that it understands the ACE conventions, and >>that the apparent ACE syntax is not really a special command in >>disguise. >> >>So, if the SMTP-sender does not have ASCII reverse and forward >>path addresses available for use in steps 8 and 10, it SHOULD >>send QUIT or RSET instead of step (8) above and notify the user >>(or the SMTP that sent the message to it) and MUST do so before >>sending any i18n information. >> >>Within the normal definitions of Internet mail, that is a >>success: the message has not gotten lost but has been properly >>accounted for to the sender. It was just not deliverable to a >>host that did not support the addressing syntax. >> >> >>>or Proposal 2 can only be >>>used in the scenario where both sender smtp and both receiver >>>smtp supports IMA? >> >>Depends on what you mean by "can only be used". Examine how the >>above would work with IMA supported. We would then have... >> >>(1) S: opens connection >>(2) R: 220 Ok >>(3) S: EHLO sender-host.domain.name >>(4) R: 250-receiver-host.receiver-domain.name >>(5) R: 250-8BITMIME >>(6) R: 250-EXPN >>(7) R: 250-SIZE >>(7a): R: 250 IMA >>(8) S: MAIL FROM: >>(9) R: 250 OK >>(10) S: RCPT TO: >>(11) R: 250 address ok >>(12) S: DATA >>(13) R: 354 Send data, 8bit permitted >>(14) S: From: someuser@some.domain >> S: To: a-mailbox@receiver-host.receiver-domain.name >> S: Date: Wed, 31 Aug 2005 14:26:55 +0800 >> S: MIME-Version: 1.0 >> S: Content-type: text/plain; charset=utf8 >> S: [...] >> S: >>(15) S: Message text >> S: more text >>(16) S: . >>(17) R: 250 Message received >>(18) S: QUIT >>(19) R: 250 Ok, quitting >>(20) R: (closes connection) >> >>And, with the IMA option advertised as a server capability in >>line 7a, the sender would be free to use UTF-8 addresses in >>lines 8 and/or 10. If we do this as we have discussed, any of >>the header fields in (14) could be specified as being in UTF-8 >>and, since an appropriate content type is specified, so could >>the message text in (15). >> >>Does that help? >> >> >>>if we consider the secenario that we can not upgrade all smtp >>>servers to support IMA, proposal 3 with downgrade may be >>>better. >> >>Note that proposal 3 does not change the above at all. If we >>have the first scenario (with IMA not advertised), the sending >>SMTP server can get to the end of step 7 and then, rather than >>sending the original non-ASCII address information that would be >>contemplated in step 8, it must then transform the addresses and >>headers into standard form and then send them as if it had never >>heard of IMA. >> >>That "stop in the middle of the transaction and convert" >>property is, incidentally, a major reason why 8BITMIME >>downgrading was never widely supported. Most good-quality SMTP >>servers are designed to "get rid of" messages as quickly as >>possible once the relevant TCP connection is opened. Here, if >>IMA (and 8BITMIME) are not supported, we expect the sending SMTP >>server to stop what it is doing after receiving the EHLO >>response, perform a moderately complicated conversion while >>holding the connection to the receiver SMTP open, then send the >>reconstructed message, hoping that the receiver does not time >>out in the interval. >> >>In at least one case, it was implemented in a different way, one >>that is permitted by the specification but that may not be >>desirable. In this alternate method, the mail transaction was >>terminated (a QUIT or RSET command sent) as soon after the EHLO >>response appeared without the needed capabilities and it was >>discovered that the capability was needed. The original message >>was then dropped into a special queue for >>conversation/downgrading and subsequent queueing for a second >>attempt without holding the TCP connection open. That is fairly >>efficient from the standpoint of the SMTP sending server, but >>standard retry intervals could then result in a delay of some >>hours before an attempt was made to deliver the downgraded mail. >>>From the standpoint of the sending user, it might have been >>preferred that the message be bounced so that it could be >>immediately resent in compatible/ downgraded form, rather than >>having it delayed in transit that way. >> >>regards, >> john >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>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 Thu Sep 01 10:24:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EApzc-00063N-HM; Thu, 01 Sep 2005 10:24:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EApza-00062g-16 for ima@megatron.ietf.org; Thu, 01 Sep 2005 10:24:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07483 for ; Thu, 1 Sep 2005 10:24:36 -0400 (EDT) Received: from mail00.afilias.info ([170.224.17.215] helo=ns01.afilias.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAq1W-0008T0-LI for ima@ietf.org; Thu, 01 Sep 2005 10:26:40 -0400 Received: from edmontr3 (vgateway.libertyrms.info [207.219.45.62]) (authenticated bits=0) by ns01.afilias.info (8.12.8/8.12.8) with ESMTP id j81EO35C005190 for ; Thu, 1 Sep 2005 10:24:15 -0400 Message-ID: <036d01c5af00$cda635d0$f903010a@edmontr3> From: "Edmon Chung" To: References: <325469707.29749@cnnic.cn>, <01d201c5adf4$fba2e7b0$1206e29f@cnnicyaojk> <325473531.15517@cnnic.cn><325559485.28630@cnnic.cn> <4316B389.7030105@icu.ac.kr> Subject: Re: [IMA] re: JET IMA meeting memo Date: Thu, 1 Sep 2005 08:19:29 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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="===============1392431512==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1392431512== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VG8gYWRkIGEgYml0IHRvIHRoYXQsIGlmIEkgYW0gY29ycmVjdCwgSSB0aGluayB0aGUgYmVzdCB3 YXkgdG8gdGhpbmsgYWJvdXQgaXQgaXMgdGhhdCB0aGUgc2VuZGluZyBTTVRQIGF0IHRoYXQgcG9p bnQgYWN0cyBhcyB0aGUgRE5TIGNsaWVudCAoaS5lLiBhcHBsaWNhdGlvbikgYW5kIGRvZXMgdGhl IFRvQUNFIGFuZCBETlMgbG9va3VwIGFzIHNwZWNpZmllZCBieSBJRE5BLiAgT3RoZXIgSUROIGF3 YXJlICJkb21haW4gc2xvdHMiIGNhbiByZW1haW4gaW4gVVRGOC4NCkVkbW9uDQoNCg0KDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogInlhbmd3b28ga28iIDxuZXdjYXRAaWN1 LmFjLmtyPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDAx LCAyMDA1IDM6NTMgQU0NClN1YmplY3Q6IFJlOiBbSU1BXSByZTogSkVUIElNQSBtZWV0aW5nIG1l bW8NCg0KDQo+IA0KPiBZQU8gSmlhbmthbmcgd3JvdGU6DQo+PiBpZiB1dGYtOEB1dGYtOCBpcyB1 c2VkLCB3aGVuIHRoZSB1dGYtOCBmb3IgIHRoZSBkb21haW4gcGFydCBpcyB1c2VkIHRvIGxvb2sg aW50byBETlMgdG8gZmluZCB0aGUgcmVsYXRpdmUgSVAgYWRkcmVzcywgZG9lcyB0aGUgZG9tYWlu IHBhcnQgaGF2ZSB0byBiZSB0dXJuZWQgaW50byBBQ0U/DQo+IA0KPiBJbiBteSB1bmRlcnN0YWRp bmcsIHRoZSBzdGVwICgxKSBvZiBKb2huJ3MgZmxvdyBpbmNsdWRlczsNCj4gKiBjb252ZXJ0aW5n IGRvbWFpbiBwYXJ0IHVzaW5nIEFDRQ0KPiAqIGZpbmRpbmcgTVggcmVjb3JkIHVzaW5nIHRoZSBB Q0UgdmVyc2lvbiBvZiBkb21haW4NCj4gKiBuYW1lIHJlc29sdXRpb24gd2l0aCByZXR1cm5lZCBt YWlsIHNlcnZlciBuYW1lL2FkZHJlc3MNCj4gKiBvcGVuIGNvbm5lY3Rpb24gd2l0aCB0aGUgcmV0 dXJuZWQgSVAgYWRkcmVzcw0KPiANCj4gUmVnYXJkcw0KPiANCj4+IA0KPj4gIFlhbyBKaWFua2Fu Zw0KPj4gQ05OSUMgIA0KPj4gDQo+PiANCj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQo+PiBGcm9tOiAiSm9obiBDIEtsZW5zaW4iIDxrbGVuc2luQGpjay5jb20+DQo+PiBUbzogIllB TyBKaWFua2FuZyIgPHlhb2prQGNubmljLmNuPjsgPGltYUBpZXRmLm9yZz4NCj4+IFNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDMxLCAyMDA1IDM6MzIgUE0NCj4+IFN1YmplY3Q6IFJlOiBbSU1BXSBy ZTogSkVUIElNQSBtZWV0aW5nIG1lbW8NCj4+IA0KPj4gDQo+PiANCj4+Pg0KPj4+LS1PbiBXZWRu ZXNkYXksIDMxIEF1Z3VzdCwgMjAwNSAxNDoyNiArMDgwMCBZQU8gSmlhbmthbmcNCj4+Pjx5YW9q a0Bjbm5pYy5jbj4gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+PmFjY29yZGluZyB0byB0aGUgcHJvcG9z YWxzIHdlIGRpc2N1c3NlZCwNCj4+Pj4tIHByb3MgYW5kIGNvbnMgb2YgMyBwcm9wb3NhbHMNCj4+ Pj4gICgxKSBKRVQgQUNFQEFDRQ0KPj4+PiAgKDIpIEpvaG4rQ0ROQyBVVEY4QFVURjggKG5vIGRv d25ncmFkZSkNCj4+Pj4gICgzKSBKb2huK0NETkMgVVRGOEBVVEY4ICh3LyBkb3duZ3JhZGUpDQo+ Pj4+DQo+Pj4+aWYgcHJvcG9zYWwgMiBpcyB1c2VkIHdpdGggbm8gZG93bmdyYWRlLCBpZiBzZW5k ZXIgc210cA0KPj4+PnN1cHBvcnRzIElNQSwgYnV0IHJlY2VpdmVyIHNtdHAgZG9lc24ndCBzdXBw b3J0IElNQSwgdGhlIElNQQ0KPj4+PmFkZHJlc3MgaXMgYm91bmNlZCBieSByZWNlaXZlciBTTVRQ Pw0KPj4+DQo+Pj5ObywgYWN0dWFsbHksIGl0IGlzIGJvdW5jZWQgYnkgdGhlIHNlbmRlciBTTVRQ LiAgU2luY2UgaXQgaXMNCj4+PnZlcnkgaW1wb3J0YW50IHRoYXQgZXZlcnlvbmUgdW5kZXJzdGFu ZCBob3cgU01UUCBhbmQgdGhlDQo+Pj5leHRlbnNpb24gbWVjaGFuaXNtIGFjdHVhbGx5IHdvcmtz IGluIHRoaXMgZW52aXJvbm1lbnQsIGxldCBtZQ0KPj4+cmV2aWV3IHRoZSB0cmFuc2FjdGlvbiBm bG93LCBhc3N1bWluZyB0aGF0IHRoZSByZWxldmFudCBvcHRpb24NCj4+PmlzIGNhbGxlZCAiSU1B Ii4gICJTOiIgcmVwcmVzZW50cyB0aGUgc2VuZGVyIFNNVFAsICJSOiIgdGhlDQo+Pj5yZWNlaXZl ci4gIA0KPj4+DQo+Pj4oMSkgUzogb3BlbnMgY29ubmVjdGlvbg0KPj4+KDIpIFI6IDIyMCBPaw0K Pj4+KDMpIFM6IEVITE8gc2VuZGVyLWhvc3QuZG9tYWluLm5hbWUNCj4+Pig0KSBSOiAyNTAtcmVj ZWl2ZXItaG9zdC5yZWNlaXZlci1kb21haW4ubmFtZQ0KPj4+KDUpIFI6IDI1MC04QklUTUlNRQ0K Pj4+KDYpIFI6IDI1MC1FWFBODQo+Pj4oNykgUjogMjUwIFNJWkUNCj4+Pig4KSBTOiBNQUlMIEZS T006PHNvbWV1c2VyQHNvbWUuZG9tYWluPg0KPj4+KDkpIFI6IDI1MCBPSw0KPj4+KDEwKSBTOiBS Q1BUIFRPOjxhLW1haWxib3hAcmVjZWl2ZXItaG9zdC5yZWNlaXZlci1kb21haW4ubmFtZT4NCj4+ Pg0KPj4+DQo+Pj4NCj4+Pk5vdGVzOg0KPj4+KDIpIFZpcnR1YWxseSBhbnkgdGV4dCBjYW4gZm9s bG93IHRoZSAiMjIwICIsIGJ1dCB0aGUgc2VuZGVyDQo+Pj53aWxsIHR5cGljYWxseSBpZ25vcmUg aXQuDQo+Pj4NCj4+Pig1KS0oNykgaW5kaWNhdGUgdGhhdCA4QklUTUlNRSwgRVhQTiwgYW5kIFNJ WkUgYXJlIHN1cHBvcnRlZCwNCj4+PmJ1dCBJTUEgaXMgbm90IChzaW5jZSBpdCBpcyBub3QgbGlz dGVkKQ0KPj4+DQo+Pj4oOCkgU2luY2UgSU1BIGlzIG5vdCBhZHZlcnRpc2VkIGJ5IHRoZSByZWNl aXZlciwgdGhlIHNlbmRlciBNVVNUDQo+Pj5OT1Qgc2VuZCBhbnkgbm9uLUFTQ0lJIGFkZHJlc3Nl cyBpbiBlaXRoZXIgTUFJTCBvciBSQ1BUDQo+Pj5jb21tYW5kcywgbm9yIG1heSB0aGUgbWFpbCBo ZWFkZXJzIGNvbnRhaW4gYW55IGludGVybmF0aW9uYWxpemVkDQo+Pj5pbmZvcm1hdGlvbiBleGNl cHQgaW4gZW5jb2RlZCB3b3JkcyB3aGVyZSB0aG9zZSBhcmUgcGVybWl0dGVkLg0KPj4+Tm90ZSB0 aGF0IHRoZSBhcmd1bWVudCB0byB0aGUgTUFJTCBjb21tYW5kIGNvdWxkLCB1bmRlciBwcm9wb3Nh bA0KPj4+KDEpLCBiZSBhbiBBQ0U6IHRoZSBzZW5kaW5nIGhvc3Qgd2lsbCB1bmRlcnN0YW5kIGl0 cyBvd24gbmFtaW5nDQo+Pj5zdHJ1Y3R1cmUuICBIb3dldmVyLA0KPj4+DQo+Pj4oMTApIE1heSBu b3QgZXZlbiBjb250YWluIGFuIEFDRSB1bmxlc3MgdGhlIEFDRSB3YXMgcHJvdmlkZWQgYnkNCj4+ PnRoZSBzZW5kaW5nIHVzZXIgYW5kIG9idGFpbmVkIGluIHNvbWUgb3V0IG9mIGJhbmQgd2F5Lg0K Pj4+T3RoZXJ3aXNlLCB5b3UgaGF2ZSBubyB3YXkgdG8gYmUgYXNzdXJlZCB0aGF0IHRoZSByZWNl aXZpbmcgaG9zdA0KPj4+d2lsbCBkZWNvZGUgaXQsIHRoYXQgaXQgdW5kZXJzdGFuZHMgdGhlIEFD RSBjb252ZW50aW9ucywgYW5kDQo+Pj50aGF0IHRoZSBhcHBhcmVudCBBQ0Ugc3ludGF4IGlzIG5v dCByZWFsbHkgYSBzcGVjaWFsIGNvbW1hbmQgaW4NCj4+PmRpc2d1aXNlLg0KPj4+DQo+Pj5Tbywg aWYgdGhlIFNNVFAtc2VuZGVyIGRvZXMgbm90IGhhdmUgQVNDSUkgcmV2ZXJzZSBhbmQgZm9yd2Fy ZA0KPj4+cGF0aCBhZGRyZXNzZXMgYXZhaWxhYmxlIGZvciB1c2UgaW4gc3RlcHMgOCBhbmQgMTAs IGl0IFNIT1VMRA0KPj4+c2VuZCBRVUlUIG9yIFJTRVQgaW5zdGVhZCBvZiBzdGVwICg4KSBhYm92 ZSBhbmQgbm90aWZ5IHRoZSB1c2VyDQo+Pj4ob3IgdGhlIFNNVFAgdGhhdCBzZW50IHRoZSBtZXNz YWdlIHRvIGl0KSBhbmQgTVVTVCBkbyBzbyBiZWZvcmUNCj4+PnNlbmRpbmcgYW55IGkxOG4gaW5m b3JtYXRpb24uDQo+Pj4NCj4+PldpdGhpbiB0aGUgbm9ybWFsIGRlZmluaXRpb25zIG9mIEludGVy bmV0IG1haWwsIHRoYXQgaXMgYQ0KPj4+c3VjY2VzczogdGhlIG1lc3NhZ2UgaGFzIG5vdCBnb3R0 ZW4gbG9zdCBidXQgaGFzIGJlZW4gcHJvcGVybHkNCj4+PmFjY291bnRlZCBmb3IgdG8gdGhlIHNl bmRlci4gIEl0IHdhcyBqdXN0IG5vdCBkZWxpdmVyYWJsZSB0byBhDQo+Pj5ob3N0IHRoYXQgZGlk IG5vdCBzdXBwb3J0IHRoZSBhZGRyZXNzaW5nIHN5bnRheC4NCj4+Pg0KPj4+DQo+Pj4+b3IgUHJv cG9zYWwgMiBjYW4gb25seSBiZQ0KPj4+PnVzZWQgaW4gdGhlIHNjZW5hcmlvIHdoZXJlIGJvdGgg c2VuZGVyIHNtdHAgYW5kIGJvdGggcmVjZWl2ZXINCj4+Pj5zbXRwIHN1cHBvcnRzIElNQT8NCj4+ Pg0KPj4+RGVwZW5kcyBvbiB3aGF0IHlvdSBtZWFuIGJ5ICJjYW4gb25seSBiZSB1c2VkIi4gIEV4 YW1pbmUgaG93IHRoZQ0KPj4+YWJvdmUgd291bGQgd29yayB3aXRoIElNQSBzdXBwb3J0ZWQuICBX ZSB3b3VsZCB0aGVuIGhhdmUuLi4NCj4+Pg0KPj4+KDEpIFM6IG9wZW5zIGNvbm5lY3Rpb24NCj4+ PigyKSBSOiAyMjAgT2sNCj4+PigzKSBTOiBFSExPIHNlbmRlci1ob3N0LmRvbWFpbi5uYW1lDQo+ Pj4oNCkgUjogMjUwLXJlY2VpdmVyLWhvc3QucmVjZWl2ZXItZG9tYWluLm5hbWUNCj4+Pig1KSBS OiAyNTAtOEJJVE1JTUUNCj4+Pig2KSBSOiAyNTAtRVhQTg0KPj4+KDcpIFI6IDI1MC1TSVpFDQo+ Pj4oN2EpOiBSOiAyNTAgSU1BDQo+Pj4oOCkgUzogTUFJTCBGUk9NOjxzb21ldXNlckBzb21lLmRv bWFpbj4NCj4+Pig5KSBSOiAyNTAgT0sNCj4+PigxMCkgUzogUkNQVCBUTzo8YS1tYWlsYm94QHJl Y2VpdmVyLWhvc3QucmVjZWl2ZXItZG9tYWluLm5hbWU+DQo+Pj4oMTEpIFI6IDI1MCBhZGRyZXNz IG9rDQo+Pj4oMTIpIFM6IERBVEENCj4+PigxMykgUjogMzU0IFNlbmQgZGF0YSwgOGJpdCBwZXJt aXR0ZWQNCj4+PigxNCkgUzogRnJvbTogc29tZXVzZXJAc29tZS5kb21haW4NCj4+PiAgICAgUzog VG86IGEtbWFpbGJveEByZWNlaXZlci1ob3N0LnJlY2VpdmVyLWRvbWFpbi5uYW1lDQo+Pj4gICAg IFM6IERhdGU6IFdlZCwgMzEgQXVnIDIwMDUgMTQ6MjY6NTUgKzA4MDANCj4+PiAgICAgUzogTUlN RS1WZXJzaW9uOiAxLjANCj4+PiAgICAgUzogQ29udGVudC10eXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PXV0ZjgNCj4+PiAgICAgUzogICAgWy4uLl0NCj4+PiAgICAgUzogDQo+Pj4oMTUpIFM6IE1l c3NhZ2UgdGV4dA0KPj4+ICAgICBTOiBtb3JlIHRleHQNCj4+PigxNikgUzogLg0KPj4+KDE3KSBS OiAyNTAgTWVzc2FnZSByZWNlaXZlZA0KPj4+KDE4KSBTOiBRVUlUDQo+Pj4oMTkpIFI6IDI1MCBP aywgcXVpdHRpbmcNCj4+PigyMCkgUjogKGNsb3NlcyBjb25uZWN0aW9uKQ0KPj4+DQo+Pj5BbmQs IHdpdGggdGhlIElNQSBvcHRpb24gYWR2ZXJ0aXNlZCBhcyBhIHNlcnZlciBjYXBhYmlsaXR5IGlu DQo+Pj5saW5lIDdhLCB0aGUgc2VuZGVyIHdvdWxkIGJlIGZyZWUgdG8gdXNlIFVURi04IGFkZHJl c3NlcyBpbg0KPj4+bGluZXMgOCBhbmQvb3IgMTAuICBJZiB3ZSBkbyB0aGlzIGFzIHdlIGhhdmUg ZGlzY3Vzc2VkLCBhbnkgb2YNCj4+PnRoZSBoZWFkZXIgZmllbGRzIGluICgxNCkgY291bGQgYmUg c3BlY2lmaWVkIGFzIGJlaW5nIGluIFVURi04DQo+Pj5hbmQsIHNpbmNlIGFuIGFwcHJvcHJpYXRl IGNvbnRlbnQgdHlwZSBpcyBzcGVjaWZpZWQsIHNvIGNvdWxkDQo+Pj50aGUgbWVzc2FnZSB0ZXh0 IGluICgxNSkuDQo+Pj4NCj4+PkRvZXMgdGhhdCBoZWxwPw0KPj4+DQo+Pj4NCj4+Pj5pZiB3ZSBj b25zaWRlciB0aGUgc2VjZW5hcmlvIHRoYXQgd2UgY2FuIG5vdCB1cGdyYWRlIGFsbCBzbXRwDQo+ Pj4+c2VydmVycyB0byBzdXBwb3J0IElNQSwgcHJvcG9zYWwgMyB3aXRoIGRvd25ncmFkZSBtYXkg YmUNCj4+Pj5iZXR0ZXIuDQo+Pj4NCj4+Pk5vdGUgdGhhdCBwcm9wb3NhbCAzIGRvZXMgbm90IGNo YW5nZSB0aGUgYWJvdmUgYXQgYWxsLiAgICBJZiB3ZQ0KPj4+aGF2ZSB0aGUgZmlyc3Qgc2NlbmFy aW8gKHdpdGggSU1BIG5vdCBhZHZlcnRpc2VkKSwgdGhlIHNlbmRpbmcNCj4+PlNNVFAgc2VydmVy IGNhbiBnZXQgdG8gdGhlIGVuZCBvZiBzdGVwIDcgYW5kIHRoZW4sIHJhdGhlciB0aGFuDQo+Pj5z ZW5kaW5nIHRoZSBvcmlnaW5hbCBub24tQVNDSUkgYWRkcmVzcyBpbmZvcm1hdGlvbiB0aGF0IHdv dWxkIGJlDQo+Pj5jb250ZW1wbGF0ZWQgaW4gc3RlcCA4LCBpdCBtdXN0IHRoZW4gdHJhbnNmb3Jt IHRoZSBhZGRyZXNzZXMgYW5kDQo+Pj5oZWFkZXJzIGludG8gc3RhbmRhcmQgZm9ybSBhbmQgdGhl biBzZW5kIHRoZW0gYXMgaWYgaXQgaGFkIG5ldmVyDQo+Pj5oZWFyZCBvZiBJTUEuICAgDQo+Pj4N Cj4+PlRoYXQgInN0b3AgaW4gdGhlIG1pZGRsZSBvZiB0aGUgdHJhbnNhY3Rpb24gYW5kIGNvbnZl cnQiDQo+Pj5wcm9wZXJ0eSBpcywgaW5jaWRlbnRhbGx5LCBhIG1ham9yIHJlYXNvbiB3aHkgOEJJ VE1JTUUNCj4+PmRvd25ncmFkaW5nIHdhcyBuZXZlciB3aWRlbHkgc3VwcG9ydGVkLiAgTW9zdCBn b29kLXF1YWxpdHkgU01UUA0KPj4+c2VydmVycyBhcmUgZGVzaWduZWQgdG8gImdldCByaWQgb2Yi IG1lc3NhZ2VzIGFzIHF1aWNrbHkgYXMNCj4+PnBvc3NpYmxlIG9uY2UgdGhlIHJlbGV2YW50IFRD UCBjb25uZWN0aW9uIGlzIG9wZW5lZC4gIEhlcmUsIGlmDQo+Pj5JTUEgKGFuZCA4QklUTUlNRSkg YXJlIG5vdCBzdXBwb3J0ZWQsIHdlIGV4cGVjdCB0aGUgc2VuZGluZyBTTVRQDQo+Pj5zZXJ2ZXIg dG8gc3RvcCB3aGF0IGl0IGlzIGRvaW5nIGFmdGVyIHJlY2VpdmluZyB0aGUgRUhMTw0KPj4+cmVz cG9uc2UsIHBlcmZvcm0gYSBtb2RlcmF0ZWx5IGNvbXBsaWNhdGVkIGNvbnZlcnNpb24gd2hpbGUN Cj4+PmhvbGRpbmcgdGhlIGNvbm5lY3Rpb24gdG8gdGhlIHJlY2VpdmVyIFNNVFAgb3BlbiwgdGhl biBzZW5kIHRoZQ0KPj4+cmVjb25zdHJ1Y3RlZCBtZXNzYWdlLCBob3BpbmcgdGhhdCB0aGUgcmVj ZWl2ZXIgZG9lcyBub3QgdGltZQ0KPj4+b3V0IGluIHRoZSBpbnRlcnZhbC4NCj4+Pg0KPj4+SW4g YXQgbGVhc3Qgb25lIGNhc2UsIGl0IHdhcyBpbXBsZW1lbnRlZCBpbiBhIGRpZmZlcmVudCB3YXks IG9uZQ0KPj4+dGhhdCBpcyBwZXJtaXR0ZWQgYnkgdGhlIHNwZWNpZmljYXRpb24gYnV0IHRoYXQg bWF5IG5vdCBiZQ0KPj4+ZGVzaXJhYmxlLiAgIEluIHRoaXMgYWx0ZXJuYXRlIG1ldGhvZCwgdGhl IG1haWwgdHJhbnNhY3Rpb24gd2FzDQo+Pj50ZXJtaW5hdGVkIChhIFFVSVQgb3IgUlNFVCBjb21t YW5kIHNlbnQpIGFzIHNvb24gYWZ0ZXIgdGhlIEVITE8NCj4+PnJlc3BvbnNlIGFwcGVhcmVkIHdp dGhvdXQgdGhlIG5lZWRlZCBjYXBhYmlsaXRpZXMgYW5kIGl0IHdhcw0KPj4+ZGlzY292ZXJlZCB0 aGF0IHRoZSBjYXBhYmlsaXR5IHdhcyBuZWVkZWQuICBUaGUgb3JpZ2luYWwgbWVzc2FnZQ0KPj4+ d2FzIHRoZW4gZHJvcHBlZCBpbnRvIGEgc3BlY2lhbCBxdWV1ZSBmb3INCj4+PmNvbnZlcnNhdGlv bi9kb3duZ3JhZGluZyBhbmQgc3Vic2VxdWVudCBxdWV1ZWluZyBmb3IgYSBzZWNvbmQNCj4+PmF0 dGVtcHQgd2l0aG91dCBob2xkaW5nIHRoZSBUQ1AgY29ubmVjdGlvbiBvcGVuLiAgVGhhdCBpcyBm YWlybHkNCj4+PmVmZmljaWVudCBmcm9tIHRoZSBzdGFuZHBvaW50IG9mIHRoZSBTTVRQIHNlbmRp bmcgc2VydmVyLCBidXQNCj4+PnN0YW5kYXJkIHJldHJ5IGludGVydmFscyBjb3VsZCB0aGVuIHJl c3VsdCBpbiBhIGRlbGF5IG9mIHNvbWUNCj4+PmhvdXJzIGJlZm9yZSBhbiBhdHRlbXB0IHdhcyBt YWRlIHRvIGRlbGl2ZXIgdGhlIGRvd25ncmFkZWQgbWFpbC4NCj4+Pj5Gcm9tIHRoZSBzdGFuZHBv aW50IG9mIHRoZSBzZW5kaW5nIHVzZXIsIGl0IG1pZ2h0IGhhdmUgYmVlbg0KPj4+cHJlZmVycmVk IHRoYXQgdGhlIG1lc3NhZ2UgYmUgYm91bmNlZCBzbyB0aGF0IGl0IGNvdWxkIGJlDQo+Pj5pbW1l ZGlhdGVseSByZXNlbnQgaW4gY29tcGF0aWJsZS8gZG93bmdyYWRlZCBmb3JtLCByYXRoZXIgdGhh bg0KPj4+aGF2aW5nIGl0IGRlbGF5ZWQgaW4gdHJhbnNpdCB0aGF0IHdheS4NCj4+Pg0KPj4+cmVn YXJkcywNCj4+PiAgICBqb2huDQo+Pj4NCj4+Pg0KPj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+ Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5JTUEg bWFpbGluZyBsaXN0DQo+Pj5JTUFAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ltYQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPiANCj4= --===============1392431512== 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 --===============1392431512==-- From ima-bounces@ietf.org Thu Sep 01 14:52:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuBH-0005rc-Lk; Thu, 01 Sep 2005 14:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuBG-0005rU-Sm for ima@megatron.ietf.org; Thu, 01 Sep 2005 14:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22701 for ; Thu, 1 Sep 2005 14:52:55 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAuDG-0000t1-6e for ima@ietf.org; Thu, 01 Sep 2005 14:55:03 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EAuB1-000DEt-0Z; Thu, 01 Sep 2005 14:52:43 -0400 Date: Thu, 01 Sep 2005 14:52:42 -0400 From: John C Klensin To: yangwoo ko , ima@ietf.org Subject: Re: [IMA] re: JET IMA meeting memo Message-ID: <07723402F0505B4DB0C10930@scan.jck.com> In-Reply-To: <4316B389.7030105@icu.ac.kr> References: <325469707.29749@cnnic.cn> , <01d201c5adf4$fba2e7b0$1206e29f@cnnicyaojk> <325473531.15517@cnnic.cn> <325559485.28630@cnnic.cn> <4316B389.7030105@icu.ac.kr> X-Mailer: Mulberry/4.0.3 (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: 9182cfff02fae4f1b6e9349e01d62f32 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, 01 September, 2005 16:53 +0900 yangwoo ko wrote: > YAO Jiankang wrote: >> if utf-8@utf-8 is used, when the utf-8 for the domain part >> is used to look into DNS to find the relative IP address, >> does the domain part have to be turned into ACE? > > In my understading, the step (1) of John's flow includes; > * converting domain part using ACE > * finding MX record using the ACE version of domain > * name resolution with returned mail server name/address > * open connection with the returned IP address Yes, exactly. More generally, this work cannot change IDNA in any way. So, at any point at which a DNS query is required --such as for an SMTP client to do an MX lookup to determine the IP address to which a mail connection is to be opened -- any internationalized domain must be converted to punycode as IDNA specifies and then the punycode used in the DNS query. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 01 21:29:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0Mw-0002IA-Vc; Thu, 01 Sep 2005 21:29:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0Mu-0002I0-PW for ima@megatron.ietf.org; Thu, 01 Sep 2005 21:29:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11154 for ; Thu, 1 Sep 2005 21:29:20 -0400 (EDT) Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB0Ox-000449-Op for ima@ietf.org; Thu, 01 Sep 2005 21:31:32 -0400 Received: from jeffnb (pc090.twnic.net.tw [211.72.211.90]) by twnic.net.tw (8.13.4/8.13.4) with ESMTP id j821T7Ip032047; Fri, 2 Sep 2005 09:29:07 +0800 Message-Id: <200509020129.j821T7Ip032047@twnic.net.tw> From: "Jeff Yeh" To: "'YAO Jiankang'" , Subject: RE: [IMA] re: JET IMA meeting memo Date: Fri, 2 Sep 2005 09:33:17 +0800 Organization: TWNIC MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: AcWt9XO4BlOcjIuMTiGlVAoyyZUiTgAAQhTAAFnDHeA= X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Just found I was blocked by the mailinglist because I'm subscribed with tech@twnic.net.tw. :P Re-sent the message I post on Wednesday. > -----Original Message----- > From: Jeff Yeh [mailto:jeff@twnic.net.tw] > Sent: Wednesday, August 31, 2005 3:31 PM > To: 'YAO Jiankang'; 'ima@ietf.org' > Subject: RE: [IMA] re: JET IMA meeting memo > > If my understanding is correct. > Since option 2 don't have down-grade mechnism, it might > bounce with a error like "IMA not supported" when the email > meet a non-IMA enabled SMTP. > That means all the SMTP servers on the delivery path needs to > upgrade to make it work. > > Actually option 2 is very much close to option 3. > What diffent is option 3 provide a ALT address (or convert to > ACE, in that case we have the same problem like option 1 have > to solve) as downgrade mechnism. > I think this is very flexible to have a ALT address because > we can define it as a optional field. > If one can make sure all the SMTP on his delivery path is IMA > enabled, he may skip the ALT address. > > Jeff Yeh > > > > -----Original Message----- > > From: ima-bounces@ietf.org [mailto:ima-bounces@ietf.org] On > Behalf Of > > YAO Jiankang > > Sent: Wednesday, August 31, 2005 2:27 PM > > To: ima@ietf.org > > Subject: [IMA] re: JET IMA meeting memo > > > > according to the proposals we discussed, > > - pros and cons of 3 proposals > > (1) JET ACE@ACE > > (2) John+CDNC UTF8@UTF8 (no downgrade) > > (3) John+CDNC UTF8@UTF8 (w/ downgrade) > > > > if proposal 2 is used with no downgrade, if sender smtp > supports IMA, > > but receiver smtp doesn't support IMA, the IMA address is > bounced by > > receiver SMTP? or Proposal 2 can only be used in the scenario where > > both sender smtp and both receiver smtp supports IMA? > > > > if we consider the secenario that we can not upgrade all > smtp servers > > to support IMA, proposal 3 with downgrade may be better. > > > > YAO Jiankang > > Best Regards > > Tel:86-10-58813007 > > Fax:86-10-62559892 > > -------------------------------------------------- > > China Internet Network Information Center (CNNIC) 4, South > 4th Street, > > Zhongguancun, Haidian district, Beijing 100080, China > > POB: Beijing 349, Branch 6 > > http://www.cnnic.cn > > Email: yaojk@cnnic.cn > > healthyao@163.com > > > > > > > > > > ----- Original Message ----- > > From: "Yoshiro YONEYA" > > To: > > Sent: Monday, August 22, 2005 6:22 PM > > Subject: JET IMA meeting memo > > > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 01 21:48:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0fH-0002Wc-CL; Thu, 01 Sep 2005 21:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB0fD-0002Ty-QL for ima@megatron.ietf.org; Thu, 01 Sep 2005 21:48:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11829 for ; Thu, 1 Sep 2005 21:48:15 -0400 (EDT) Received: from ironport.cnnic.cn ([159.226.6.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB0hA-0004bB-V7 for ima@ietf.org; Thu, 01 Sep 2005 21:50:27 -0400 Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by ironport.cnnic.cn with ESMTP; 02 Sep 2005 09:47:41 +0800 Message-ID: <010301c5af60$184d5690$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "Jeff Yeh" , References: <325624544.08637@cnnic.cn> Subject: Re: [IMA] re: JET IMA meeting memo Date: Fri, 2 Sep 2005 09:46:09 +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: 2.2 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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="===============1682855808==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1682855808== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCmlmIGFsbCBTTVRQIHNlcnZlcnMgY2FuIHN1cHBvcnQgSU1BIGluIG9uZSBuaWdodCwgdGhh dCBpcyBiZXR0ZXIuIGJ1dCBpdCBzZWVtIGltcG9zc2lsYmUuDQpzbyB3aGVuIFVURi04QFVURi04 IGlzIHVzZWQsIHNvbWUgdHJhbnNpdGlvbiBzdHJhdGVneSBzaG91bGQgYmUgbmVlZGVkIGluIG9y ZGVyIHRvIGJlIGVhc3kgZGVwbG95YWJsZSBmb3IgSU1BLg0Kd2hlbiBzb21lIHNtdHAgc2VydmVy cyBpbmNsdWRpbmcgc29tZSBpbnRlcm5hbCBzZXJ2ZXJzIGNhbiBub3Qgc3VwcG9ydCBJTUEsIGFu IGFsdC1hZGRyZXNzIG1heSBiZSBhIGdvb2QgY2hvaWNlIHdoZXRoZXIgIG9yIG5vdCB0aGUgYWx0 LWFkZHJlc3MgaXMgQUNFIG9yIG90aGVycy4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCkZyb206ICJKZWZmIFllaCIgPGplZmZAdHduaWMubmV0LnR3Pg0KVG86ICInWUFPIEppYW5r YW5nJyIgPHlhb2prQGNubmljLmNuPjsgPGltYUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgU2Vw dGVtYmVyIDAyLCAyMDA1IDk6MzMgQU0NClN1YmplY3Q6IFJFOiBbSU1BXSByZTogSkVUIElNQSBt ZWV0aW5nIG1lbW8NCg0KDQo+ID4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0Lg0KPiA+ IFNpbmNlIG9wdGlvbiAyIGRvbid0IGhhdmUgZG93bi1ncmFkZSBtZWNobmlzbSwgaXQgbWlnaHQg DQo+ID4gYm91bmNlIHdpdGggYSBlcnJvciBsaWtlICJJTUEgbm90IHN1cHBvcnRlZCIgd2hlbiB0 aGUgZW1haWwgDQo+ID4gbWVldCAgYSBub24tSU1BIGVuYWJsZWQgU01UUC4NCj4gPiBUaGF0IG1l YW5zIGFsbCB0aGUgU01UUCBzZXJ2ZXJzIG9uIHRoZSBkZWxpdmVyeSBwYXRoIG5lZWRzIHRvIA0K PiA+IHVwZ3JhZGUgdG8gbWFrZSBpdCB3b3JrLg0KPiA+IA0KPiA+IEFjdHVhbGx5IG9wdGlvbiAy IGlzIHZlcnkgbXVjaCBjbG9zZSB0byBvcHRpb24gMy4gDQo+ID4gV2hhdCBkaWZmZW50IGlzIG9w dGlvbiAzIHByb3ZpZGUgYSBBTFQgYWRkcmVzcyAob3IgY29udmVydCB0byANCj4gPiBBQ0UsIGlu IHRoYXQgY2FzZSB3ZSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gbGlrZSBvcHRpb24gMSBoYXZlIA0K PiA+IHRvIHNvbHZlKSBhcyBkb3duZ3JhZGUgbWVjaG5pc20uDQo+ID4gSSB0aGluayB0aGlzIGlz IHZlcnkgZmxleGlibGUgdG8gaGF2ZSBhIEFMVCBhZGRyZXNzIGJlY2F1c2UgDQo+ID4gd2UgY2Fu IGRlZmluZSBpdCBhcyBhIG9wdGlvbmFsIGZpZWxkLg0KPiA+IElmIG9uZSBjYW4gbWFrZSBzdXJl IGFsbCB0aGUgU01UUCBvbiBoaXMgZGVsaXZlcnkgcGF0aCBpcyBJTUEgDQo+ID4gZW5hYmxlZCwg aGUgbWF5IHNraXAgdGhlIEFMVCBhZGRyZXNzLg0KPiA+IA0KPiA+IEplZmYgWWVoDQo+ID4gDQo+ ID4gDQo= --===============1682855808== 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 --===============1682855808==-- From ima-bounces@ietf.org Thu Sep 01 22:35:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1Ox-0007Rq-4j; Thu, 01 Sep 2005 22:35:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1Ou-0007RX-Jo for ima@megatron.ietf.org; Thu, 01 Sep 2005 22:35:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25049 for ; Thu, 1 Sep 2005 22:35:30 -0400 (EDT) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EB1Qu-0005yb-9b for ima@ietf.org; Thu, 01 Sep 2005 22:37:41 -0400 Received: (snipe 1324 invoked by uid 0); 2 Sep 2005 11:36:21 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.94 (Processed in 0.109540 secs); Received: from unknown (HELO ?220.69.185.75?) (Z???own@220.69.185.75) by unknown with SMTP; 2 Sep 2005 11:36:21 +0900 X-RCPTTO: yaojk@cnnic.cn, jeff@twnic.net.tw, ima@ietf.org Message-ID: <4317BA59.7090701@icu.ac.kr> Date: Fri, 02 Sep 2005 11:35:05 +0900 From: yangwoo ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: YAO Jiankang Subject: Re: [IMA] re: JET IMA meeting memo References: <325624544.08637@cnnic.cn> <010301c5af60$184d5690$1206e29f@cnnicyaojk> In-Reply-To: <010301c5af60$184d5690$1206e29f@cnnicyaojk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Yao and Jeff, YAO Jiankang wrote: > > if all SMTP servers can support IMA in one night, that is better. but it seem impossilbe. We do not necessarily have "ALL" of them support IMA. Only servers involved in a transport of an email with IMA in address fileds are required to do so. My guess is that if we have IMA standard, then most of big email account providers (e.g. Daum in Korea having millions of "Korean" email users) will start to support it very soon. (Or, as a NIC, we may start a promotion program far in advance.) Then there will be a period during which more and more servers are upgraded. Then we will see a point at which server upgrading saturates. From this point on, still many mail servers would not be IMA compliant. But most of users do not know/care of this fact and are hardly affected by them. Still there are many people using very old style email client that lacks many features we commonly have. But who cares? > so when UTF-8@UTF-8 is used, some transition strategy should be needed in order to be easy deployable for IMA. Well, easy come easy go. As far as easiness of deployment in introduction phase is concerned, ACE@ACE is the best. Deployment for UTF8 with downgrade can be considered easier than ACE@ACE. Because, it will work even none of servers is upgraded. After that, who will want to upgrade servers? Mail system operators will be far less interested in upgrading because most of mails are using the "old plain downgraded" addresses. > when some smtp servers including some internal servers can not support IMA, an alt-address may be a good choice whether or not the alt-address is ACE or others. > > ----- Original Message ----- > From: "Jeff Yeh" > To: "'YAO Jiankang'" ; > Sent: Friday, September 02, 2005 9:33 AM > Subject: RE: [IMA] re: JET IMA meeting memo > > > >>>If my understanding is correct. >>>Since option 2 don't have down-grade mechnism, it might >>>bounce with a error like "IMA not supported" when the email >>>meet a non-IMA enabled SMTP. >>>That means all the SMTP servers on the delivery path needs to >>>upgrade to make it work. Severs are regarded as "working correctly" if they bounce mails that they cannot handle. s/work/be delivered/ >>> >>>Actually option 2 is very much close to option 3. >>>What diffent is option 3 provide a ALT address (or convert to >>>ACE, in that case we have the same problem like option 1 have >>>to solve) as downgrade mechnism. >>>I think this is very flexible to have a ALT address because >>>we can define it as a optional field. >>>If one can make sure all the SMTP on his delivery path is IMA >>>enabled, he may skip the ALT address. If one is not sure then what will he/she/it do? He/she/it will put ASCII-only address in address fields and send. This is the way that option 3 works in the introduction phase. Difference is that the action of "alternating" is done by SMTP servers or by human/mail-generating-software. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 01 22:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1lk-00017v-Ln; Thu, 01 Sep 2005 22:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB1lj-00017p-P9 for ima@megatron.ietf.org; Thu, 01 Sep 2005 22:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25733 for ; Thu, 1 Sep 2005 22:59:05 -0400 (EDT) Received: from ironport.cnnic.cn ([159.226.6.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB1ng-0006eM-9r for ima@ietf.org; Thu, 01 Sep 2005 23:01:16 -0400 Received: from unknown (HELO cnnicyaojk) (159.226.6.18) by ironport.cnnic.cn with ESMTP; 02 Sep 2005 10:58:19 +0800 Message-ID: <020901c5af69$f6a78dd0$1206e29f@cnnicyaojk> From: "YAO Jiankang" To: "yangwoo ko" References: <325624544.08637@cnnic.cn> <010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn> Subject: Re: [IMA] re: JET IMA meeting memo Date: Fri, 2 Sep 2005 10:56:49 +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: 2.2 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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="===============0070474933==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0070474933== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogInlhbmd3b28ga28iIDxuZXdj YXRAaWN1LmFjLmtyPg0KVG86ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj4NCkNjOiAi SmVmZiBZZWgiIDxqZWZmQHR3bmljLm5ldC50dz47IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBGcmlk YXksIFNlcHRlbWJlciAwMiwgMjAwNSAxMDozNSBBTQ0KU3ViamVjdDogUmU6IFtJTUFdIHJlOiBK RVQgSU1BIG1lZXRpbmcgbWVtbw0KDQo+IFlBTyBKaWFua2FuZyB3cm90ZToNCj4gPiANCj4gPiBp ZiBhbGwgU01UUCBzZXJ2ZXJzIGNhbiBzdXBwb3J0IElNQSBpbiBvbmUgbmlnaHQsIHRoYXQgaXMg YmV0dGVyLiBidXQgaXQgc2VlbSBpbXBvc3NpbGJlLg0KPiANCj4gV2UgZG8gbm90IG5lY2Vzc2Fy aWx5IGhhdmUgIkFMTCIgb2YgdGhlbSBzdXBwb3J0IElNQS4gT25seQ0KPiBzZXJ2ZXJzIGludm9s dmVkIGluIGEgdHJhbnNwb3J0IG9mIGFuIGVtYWlsIHdpdGggSU1BIGluDQo+IGFkZHJlc3MgZmls ZWRzIGFyZSByZXF1aXJlZCB0byBkbyBzby4NCj4gDQo+IE15IGd1ZXNzIGlzIHRoYXQgaWYgd2Ug aGF2ZSBJTUEgc3RhbmRhcmQsIHRoZW4gbW9zdA0KPiBvZiBiaWcgZW1haWwgYWNjb3VudCBwcm92 aWRlcnMgKGUuZy4gRGF1bSBpbiBLb3JlYSBoYXZpbmcNCj4gbWlsbGlvbnMgb2YgIktvcmVhbiIg ZW1haWwgdXNlcnMpIHdpbGwgc3RhcnQgdG8gc3VwcG9ydCBpdA0KPiB2ZXJ5IHNvb24uIChPciwg YXMgYSBOSUMsIHdlIG1heSBzdGFydCBhIHByb21vdGlvbiBwcm9ncmFtDQo+IGZhciBpbiBhZHZh bmNlLikgVGhlbiB0aGVyZSB3aWxsIGJlIGEgcGVyaW9kIGR1cmluZyB3aGljaA0KPiBtb3JlIGFu ZCBtb3JlIHNlcnZlcnMgYXJlIHVwZ3JhZGVkLiBUaGVuIHdlIHdpbGwgc2VlIGENCj4gcG9pbnQg YXQgd2hpY2ggc2VydmVyIHVwZ3JhZGluZyBzYXR1cmF0ZXMuIEZyb20gdGhpcyBwb2ludA0KPiBv biwgc3RpbGwgbWFueSBtYWlsIHNlcnZlcnMgd291bGQgbm90IGJlIElNQSBjb21wbGlhbnQuIEJ1 dA0KPiBtb3N0IG9mIHVzZXJzIGRvIG5vdCBrbm93L2NhcmUgb2YgdGhpcyBmYWN0IGFuZCBhcmUg aGFyZGx5DQo+IGFmZmVjdGVkIGJ5IHRoZW0uIFN0aWxsIHRoZXJlIGFyZSBtYW55IHBlb3BsZSB1 c2luZyB2ZXJ5DQo+IG9sZCBzdHlsZSBlbWFpbCBjbGllbnQgdGhhdCBsYWNrcyBtYW55IGZlYXR1 cmVzIHdlIGNvbW1vbmx5DQo+IGhhdmUuIEJ1dCB3aG8gY2FyZXM/DQoNCg0KaXQgc2VlbXMgYSB2 ZXJ5IGdvb2QgYXJndW1lbnQuDQpjb25zaWRlciB0aGUgc2l0dWF0aW9uIHRoYXQgSU1BIHdpbGwg b25seSBiZSB1c2VkIGFuZCBzZW50IGFuZCByZWNlaXZlZCAgYnkgdGhvc2Ugd2hvIGNhbiByZWFk IG9yIGJlIGludGVyZXN0ZWQgaW4gSU1BLiB0aG9zZSB3aG8gY2FuIG5vdCByZWFkIE11bHRpLUxh bmd1YWdlIHdpbGwgbm90IHVzZSBJTUEgYXQgYWxsLiBzbyB3ZSBkb24ndCBjYXJlIGZvciB3aGV0 aGVyIG9yIG5vdCB0aG9zZSBzbXRwIHNlcnZlcnMgaW4gd2hoaWMgYWxsIHRoZSByZWdpc3RlcmVk IGVtYWlsIHVzZXJzIGhhdmUgbm90IGludGVyZXN0ZWQgaW4gSU1BIGF0IGFsbCBhcmUgdXBnYXJh ZGVkIHRvIHN1cHBvcnQgSU1BLiBpZiBzb21lIGVtYWlsIHVzZXIgaW4gc29tZSBjb21wYW55IGFy ZSBpbnRlcmVzdGVkIGluIElNQSB3aWxsIHVyZ2UgdGhlIGVtYWlsIHJ1bm5pbmcgY29tcGFueSB0 byBmb2xsb3cgSU1BIHN0YW5kYXJkLg0KDQp0aGUgcGF0aCB5b3Ugc2FpZCBzZWVtcyBhIHdvcmth YmxlIHBhdGguDQpJTUEtc3RhbmRhcmQtLS0tPnByb21vdGlvbi0tLS0tPmEgbG90IG9mIElNQSBz dXBwb3J0ZWQgU01UUCBzZXJ2ZXJzLg0KDQpZYW8gSmlhbmthbmcNCkNOTklDDQo= --===============0070474933== 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 --===============0070474933==-- From ima-bounces@ietf.org Thu Sep 01 23:58:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB2gk-0001vq-Fz; Thu, 01 Sep 2005 23:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB2gh-0001vi-V5 for ima@megatron.ietf.org; Thu, 01 Sep 2005 23:58:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27666 for ; Thu, 1 Sep 2005 23:57:57 -0400 (EDT) Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB2im-0008MK-Fv for ima@ietf.org; Fri, 02 Sep 2005 00:00:09 -0400 Received: from jeffnb (pc090.twnic.net.tw [211.72.211.90]) by twnic.net.tw (8.13.4/8.13.4) with ESMTP id j823vTuE008353; Fri, 2 Sep 2005 11:57:29 +0800 Message-Id: <200509020357.j823vTuE008353@twnic.net.tw> From: "Jeff Yeh" To: "'yangwoo ko'" , "'YAO Jiankang'" Subject: RE: [IMA] re: JET IMA meeting memo Date: Fri, 2 Sep 2005 12:01:14 +0800 Organization: TWNIC MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <4317BA59.7090701@icu.ac.kr> Thread-Index: AcWvZvdFN6yX0MnxR/2WfEnIO9CaFgAAlVbA X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 > > We do not necessarily have "ALL" of them support IMA. Only > servers involved in a transport of an email with IMA in > address fileds are required to do so. > > My guess is that if we have IMA standard, then most of big > email account providers (e.g. Daum in Korea having millions > of "Korean" email users) will start to support it very soon. > (Or, as a NIC, we may start a promotion program far in > advance.) Then there will be a period during which more and > more servers are upgraded. Then we will see a point at which > server upgrading saturates. From this point on, still many > mail servers would not be IMA compliant. But most of users do > not know/care of this fact and are hardly affected by them. > Still there are many people using very old style email client > that lacks many features we commonly have. But who cares? Yes, that really be a good approach either we adopt UTF8 with downgrade or without downgrade. > > Well, easy come easy go. As far as easiness of deployment in > introduction phase is concerned, ACE@ACE is the best. > > Deployment for UTF8 with downgrade can be considered easier > than ACE@ACE. Because, it will work even none of servers is > upgraded. After that, who will want to upgrade servers? > Mail system operators will be far less interested in > upgrading because most of mails are using the "old plain > downgraded" addresses. In my stand point of view, I think to use pure chineses email address is pretty cool itself. To able to use this feature will motivate people (in IDN communtiy) to upgrade their system. And also, I believe there are also a lot of people are interesting in using I-Email (John for instance). If UTF8@UTF8 without downgrade is adopted, there will be some barrier for them. In addition, to have a optional ALT address will do no harm. > > Severs are regarded as "working correctly" if they bounce > mails that they cannot handle. > > s/work/be delivered/ Agree. But the email still can't go to receiver end. > > > If one is not sure then what will he/she/it do? He/she/it > will put ASCII-only address in address fields and send. This > is the way that option 3 works in the introduction phase. > > Difference is that the action of "alternating" is done by > SMTP servers or by human/mail-generating-software. > Agree. That's the problem we have to define. Does alt-address MUST goes to the same mailbox with I-Email? I believe there is reason not to forece them the same. I put some discuess you have with john eailer. ====quote======== > (3) Are they same? > > Your draft allows an I-email-address and an ALT-address may be > designated to different mailboxes. However, we think that those two > boxes are for the (logically) same user. I think they usually will be. Perhaps even "almost always". But, given other constraints imposed by the email system, there is no reason to make that a protocol requirement and, I believe, several reasons not to. One example has to do with some of the "additional processing" mentioned in the draft and an earlier note. Let me take a far-fetched example, just to illustrate what might happen here. Suppose you told me that it would be very convenient for you if I provided a mailbox name in Hangul. Ok, by patching or configuring my MTA to disable its ASCII-only checks and getting it to support the relevant SMTP option, I could presumably arrange that, making an alias that points to my standard mailbox. So far, one user, one mailbox. But the nature of these things is such that, if I support a Hangul address for myself, sooner or later you or someone else in Korea will accidentally send a message whose body is in Hangul to me. Remember I can't read such message bodies, even to pronounce the syllables without understanding the vocabulary. But, if that happens several times and I can find a decent automatic translation program that can handle Korean in Hangul-> English, I'm going to have a lot of incentive to attach my Hangul address to an agent that will inspect the message body looking for Unicode character ranges that correspond to Hangul and, if it finds them, send the text off for translation before depositing the message in my mailbox. Still the same mailbox, of course, but the processing for one address is different from the processing for another. For those of us who have been using email intensely for many years, the idea of "one user - one mailbox" is, itself, too narrow. Offhand, I don't know how many different mailboxes I have set up at the moment, but it is more than five or six. All sorts of routing occurs among mailboxes and folders, different processing occurs at different addresses, and so on. And I use domains to receive mail that it is likely that you have not heard of. This should not be relevant, but it might be. > There is no algorithmic way to uniquely generate an ALT-address from a > given I-email-address. Thus, there is no way to verify that an > I-email-address and an ALt-address are destined to the same user. That is correct. Given other elements of the email system, there is, of course, no way to verify that an ASCII email address will go to the user you expect. That is why, when things are important, we have mechanisms for encrypting messages and various "deliver URL rather than message text" techniques are popular in some cases. > What if an I-email-address and an ALT-address in an email designate > different users? The mail will be delivered to different users > depending on the status of I-email capability on the route. This may > happen due to errors of sending users or even attacks by malicious > users. I have not yet found any possible attack through this > discrepancy. > But, there could be ... Of course. But either the sending user has to be deceived or something has to tamper with the message en route. In the first case, the deception could occur with the ASCII address today. In the second, anything that can do that sort of tampering can do so more generally. Again, suppose I ask you to send me a piece of mail addressed to john@bogus.domain.name for some reason of convenience. Since this message is not digitally signed and you haven't verified the signature through some mechanism you trust, you cannot be certain that the request to use that address instead is valid and coming from me. Assuming it is a valid request from me, you still have no way to know where that address is going, to whom it is being forwarded, etc. All of those issues are matters for the mail server that answers to addresses at bogus.domain.name, and it is fairly secretive. If you want to be sure that only I can read the mail, we know how to provide that protection. But, if you want to be sure the mail is, in fact, going to a destination which you can guarantee and over which you have control... well, not with SMTP. So, yes, there is an attack in this area, but neither i18n addresses nor Alt-Addresses change the properties of that attack at all. =====end of quote===== Jeff Yeh _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 02 02:28:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB526-0008Qf-K7; Fri, 02 Sep 2005 02:28:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB523-0008Pb-Hz for ima@megatron.ietf.org; Fri, 02 Sep 2005 02:28:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17197 for ; Fri, 2 Sep 2005 02:28:10 -0400 (EDT) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EB546-0004fc-79 for ima@ietf.org; Fri, 02 Sep 2005 02:30:21 -0400 Received: (snipe 21161 invoked by uid 0); 2 Sep 2005 15:29:12 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.94 (Processed in 0.069077 secs); Received: from unknown (HELO ?220.69.185.75?) (Z2??own@220.69.185.75) by unknown with SMTP; 2 Sep 2005 15:29:12 +0900 X-RCPTTO: jeff@twnic.net.tw, yaojk@cnnic.cn, ima@ietf.org Message-ID: <4317F0EA.4000605@icu.ac.kr> Date: Fri, 02 Sep 2005 15:27:54 +0900 From: yangwoo ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Yeh Subject: Re: [IMA] re: JET IMA meeting memo References: <200509020357.j823vTuE008353@twnic.net.tw> In-Reply-To: <200509020357.j823vTuE008353@twnic.net.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Jeff Yeh wrote: > (snip) >>Well, easy come easy go. As far as easiness of deployment in >>introduction phase is concerned, ACE@ACE is the best. >> >>Deployment for UTF8 with downgrade can be considered easier >>than ACE@ACE. Because, it will work even none of servers is >>upgraded. After that, who will want to upgrade servers? >>Mail system operators will be far less interested in >>upgrading because most of mails are using the "old plain >>downgraded" addresses. > > > In my stand point of view, I think to use pure chineses email address is > pretty cool itself. > To able to use this feature will motivate people (in IDN communtiy) to > upgrade their system. > And also, I believe there are also a lot of people are interesting in using > I-Email (John for instance). > If UTF8@UTF8 without downgrade is adopted, there will be some barrier for > them. What barriers do you have in your mind? Entering Chinese email addresses by the people who cannot even read those characters? Yes, it is a barrier. But how does the downgrade feature mitigate the problem? Still they need to handle Chinese email addresses as primary addresses for Chinese friends. > In addition, to have a optional ALT address will do no harm. Well, it is too bold to say that. We need consider many cases including; (1) which address should be recorded in header fields (2) which address should be used for spam protection measures (3) maybe more... >>Severs are regarded as "working correctly" if they bounce >>mails that they cannot handle. >> >>s/work/be delivered/ > > > Agree. > But the email still can't go to receiver end. Yes. >>If one is not sure then what will he/she/it do? He/she/it >>will put ASCII-only address in address fields and send. This >>is the way that option 3 works in the introduction phase. >> >>Difference is that the action of "alternating" is done by >>SMTP servers or by human/mail-generating-software. >> > > > Agree. > That's the problem we have to define. My argument is that we don't need to define it. Just let users do whatever they want. > (snip) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 02 04:06:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB6Zb-0000Oc-Oi; Fri, 02 Sep 2005 04:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB6ZZ-0000OT-JR for ima@megatron.ietf.org; Fri, 02 Sep 2005 04:06:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21595 for ; Fri, 2 Sep 2005 04:06:52 -0400 (EDT) Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB6bf-0008Bl-IL for ima@ietf.org; Fri, 02 Sep 2005 04:09:05 -0400 Received: from jeffnb (pc090.twnic.net.tw [211.72.211.90]) by twnic.net.tw (8.13.4/8.13.4) with ESMTP id j8286Xr1010355; Fri, 2 Sep 2005 16:06:34 +0800 Message-Id: <200509020806.j8286Xr1010355@twnic.net.tw> From: "Jeff Yeh" To: "'yangwoo ko'" Subject: RE: [IMA] re: JET IMA meeting memo Date: Fri, 2 Sep 2005 16:10:45 +0800 Organization: TWNIC MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <4317F0EA.4000605@icu.ac.kr> Thread-Index: AcWvh3uo4Q4r9LmDTTy0+mYoAuY35wAC6Ttw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 >(snip) > > > > > > In my stand point of view, I think to use pure chineses > email address is > > pretty cool itself. > > To able to use this feature will motivate people (in IDN > communtiy) to > > upgrade their system. > > And also, I believe there are also a lot of people are > interesting in using > > I-Email (John for instance). > > If UTF8@UTF8 without downgrade is adopted, there will be > some barrier for > > them. > > What barriers do you have in your mind? Entering Chinese > email addresses by the people who cannot even read those > characters? Yes, it is a barrier. But how does the > downgrade feature mitigate the problem? Still they need > to handle Chinese email addresses as primary addresses > for Chinese friends. One solution is when a IMA SMTP talking to a non IMA SMTP. The IMA SMTP can put a additional header like "IMA-address: xxx@xxxx". Thus, even if the delivery SMTP does not support IMA but receiving client does. He can still found the IMA address in the mail header. > > > In addition, to have a optional ALT address will do no harm. > > Well, it is too bold to say that. We need consider many cases > including; > (1) which address should be recorded in header fields > (2) which address should be used for spam protection measures > (3) maybe more... ALT address itself doesn't raise any new problem. Some problem is already happing in our current email environment. Such as sending email address (mail from) between reply address. And also some SPAM mail use different email within SMTP communciating (RFC2821) and mail header (RFC2822). I think it is necessary to put both IMA address and ALT address on the header. Mail server administrators can filter by one of the address or both the addresses. It depends on the local management policy. > (snip) Jeff Yeh _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 02 14:02:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFrv-0004aZ-Ga; Fri, 02 Sep 2005 14:02:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFrs-0004aR-Vj for ima@megatron.ietf.org; Fri, 02 Sep 2005 14:02:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20596 for ; Fri, 2 Sep 2005 14:02:24 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBFu4-0004C7-Fc for ima@ietf.org; Fri, 02 Sep 2005 14:04:41 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D6C76320095; Fri, 2 Sep 2005 20:01:54 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05792-05; Fri, 2 Sep 2005 20:01:50 +0200 (CEST) Received: from [192.168.1.145] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id D4482320082; Fri, 2 Sep 2005 20:01:49 +0200 (CEST) Date: Fri, 02 Sep 2005 20:02:07 +0200 From: Harald Tveit Alvestrand To: YAO Jiankang , yangwoo ko Subject: Re: [IMA] re: JET IMA meeting memo Message-ID: <341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> In-Reply-To: <020901c5af69$f6a78dd0$1206e29f@cnnicyaojk> References: <325624544.08637@cnnic.cn> <010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn> <020901c5af69$f6a78dd0$1206e29f@cnnicyaojk> 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: 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 Think of it this way.... with ace@ace, you are adding a kluge to the existing mail system, and praying that it does not interfere with the other kluges. with UTF8@UTF8, you are building a new mail system. Any new system that's successful will have gateways built to/from the old; if you don't define them, entrepreneurs will make "something that works". With UTF8@UTF8 + Downgrade, you are trying to design in the gateways. They're still gateways, and as Einar Stefferud used to say: "All gateways lose information. Some of them are better at it than others." People will still have reason to prefer the un-gatewayed environment. That's my thinking, after listening to this conversation.... Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 02 16:07:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBHp4-0000Hy-8e; Fri, 02 Sep 2005 16:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBHp2-0000Hp-Lt for ima@megatron.ietf.org; Fri, 02 Sep 2005 16:07:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00036 for ; Fri, 2 Sep 2005 16:07:34 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBHrF-0000wj-Ls for ima@ietf.org; Fri, 02 Sep 2005 16:09:54 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EBHol-0006r2-BY; Fri, 02 Sep 2005 16:07:19 -0400 Date: Fri, 02 Sep 2005 16:07:19 -0400 From: John C Klensin To: Jeff Yeh , "'yangwoo ko'" Subject: RE: [IMA] re: JET IMA meeting memo Message-ID: In-Reply-To: <200509020806.j8286Xr1010355@twnic.net.tw> References: <200509020806.j8286Xr1010355@twnic.net.tw> X-Mailer: Mulberry/4.0.3 (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: fb6060cb60c0cea16e3f7219e40a0a81 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 --On Friday, 02 September, 2005 16:10 +0800 Jeff Yeh wrote: > >> (snip) >> > >> > >> > In my stand point of view, I think to use pure chineses >> email address is >> > pretty cool itself. >> > To able to use this feature will motivate people (in IDN >> communtiy) to >> > upgrade their system. >> > And also, I believe there are also a lot of people are >> interesting in using >> > I-Email (John for instance). >> > If UTF8@UTF8 without downgrade is adopted, there will be >> some barrier for >> > them. >> >> What barriers do you have in your mind? Entering Chinese >> email addresses by the people who cannot even read those >> characters? Yes, it is a barrier. But how does the >> downgrade feature mitigate the problem? Still they need >> to handle Chinese email addresses as primary addresses >> for Chinese friends. > > One solution is when a IMA SMTP talking to a non IMA SMTP. > The IMA SMTP can put a additional header like "IMA-address: > xxx@xxxx". Thus, even if the delivery SMTP does not support > IMA but receiving client does. > He can still found the IMA address in the mail header. Not unless you also extend the mail header syntax in a way that makes such a header valid (at present, it must be all-ASCII). You also need to be prepared for the header to get "lost": many gateways and firewall SMTP implementations will drop any unrecognized headers in the interest of security and reliability of interpretation and the IMAP header abstraction will not pass this header through to clients. I believe that something like that header is the right thing to do, but we should not overestimate how effective it will be, nor how easy it is to get propagated. Also, the idea of MTAs adding mail headers is high-risk. For example, some spam-detectors will reject any message whose headers intermix trace (Received and Return-path) fields with other fields. >> > In addition, to have a optional ALT address will do no harm. >> >> Well, it is too bold to say that. We need consider many cases >> including; >> (1) which address should be recorded in header fields >> (2) which address should be used for spam protection measures >> (3) maybe more... > > ALT address itself doesn't raise any new problem. > Some problem is already happing in our current email > environment. Such as sending email address (mail from) between > reply address. And also some SPAM mail use different email > within SMTP communciating (RFC2821) and mail header (RFC2822). > I think it is necessary to put both IMA address and ALT > address on the header. > Mail server administrators can filter by one of the address or > both the addresses. > It depends on the local management policy. I think this is right, but we need to fill in the details. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 07 01:04:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECs6g-0005MQ-8k; Wed, 07 Sep 2005 01:04:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECs6d-0005La-Vn for ima@megatron.ietf.org; Wed, 07 Sep 2005 01:04:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29023 for ; Wed, 7 Sep 2005 01:04:19 -0400 (EDT) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECs9e-0000au-4P for ima@ietf.org; Wed, 07 Sep 2005 01:07:33 -0400 Received: (snipe 3114 invoked by uid 0); 7 Sep 2005 14:05:53 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.023410 secs); Received: from unknown (HELO ?220.69.185.75?) (Zd/?own@220.69.185.75) by unknown with SMTP; 7 Sep 2005 14:05:53 +0900 X-RCPTTO: ima@ietf.org Message-ID: <431E74B6.8010509@icu.ac.kr> Date: Wed, 07 Sep 2005 14:03:50 +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 Subject: Re: [IMA] re: JET IMA meeting memo References: <325624544.08637@cnnic.cn> <010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn> <020901c5af69$f6a78dd0$1206e29f@cnnicyaojk> <341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> In-Reply-To: <341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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 Please help me understand Harald's comment correctly. Following Harald's comment, I come to a conclusion that we will see several different gateways regardless of having a gateway standard. If so, why do we need to define it in the standard? Harald Tveit Alvestrand wrote: > > Think of it this way.... > > with ace@ace, you are adding a kluge to the existing mail system, and > praying that it does not interfere with the other kluges. > > with UTF8@UTF8, you are building a new mail system. > > Any new system that's successful will have gateways built to/from the > old; if you don't define them, entrepreneurs will make "something that > works". > > With UTF8@UTF8 + Downgrade, you are trying to design in the gateways. > They're still gateways, and as Einar Stefferud used to say: "All > gateways lose information. Some of them are better at it than others." > People will still have reason to prefer the un-gatewayed environment. > > That's my thinking, after listening to this conversation.... > > Harald > > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 07 05:03:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvqC-0003ma-AX; Wed, 07 Sep 2005 05:03:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvq8-0003lY-VE for ima@megatron.ietf.org; Wed, 07 Sep 2005 05:03:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05811 for ; Wed, 7 Sep 2005 05:03:31 -0400 (EDT) Received: from ns01.afilias.info ([170.224.17.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECvtF-0006md-Vz for ima@ietf.org; Wed, 07 Sep 2005 05:06:48 -0400 Received: from edmontr3 (vgateway.libertyrms.info [207.219.45.62]) (authenticated bits=0) by ns01.afilias.info (8.12.8/8.12.8) with ESMTP id j8793HLr029712 for ; Wed, 7 Sep 2005 05:03:19 -0400 Message-ID: <026701c5b38a$fc2a0c40$bf01a8c0@edmontr3> From: "Edmon Chung" To: References: <325624544.08637@cnnic.cn><010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn><020901c5af69$f6a78dd0$1206e29f@cnnicyaojk><341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> <431E74B6.8010509@icu.ac.kr> Subject: Re: [IMA] re: JET IMA meeting memo Date: Wed, 7 Sep 2005 05:01:57 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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="===============0467302510==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0467302510== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SWYgSSB1bmRlcnN0b29kIGl0IGNvcnJlY3RseSwgSSB0aGluayB3aGF0IEhhcmFsZCBtZWFucyBp cyB0aGF0IGVhY2ggU01UUCB0aGF0IGltcGxlbWVudHMgdGhlICJkb3duZ3JhZGUiIHNwZWNpZmll ZCBieSB0aGUgcHJvdG9jb2wgaXMgaW4gZmFjdCBhIGdhdGV3YXkgdG8gdGhlIG5vbi1JTUEtYXdh cmUgc3lzdGVtIChoZW5jZSB0aGUgcGx1cmFsKS4NCg0KVGhhdCBiZWluZyBzYWlkLCBpdCBpcyBw b3NzaWJsZSB0aGF0IHBlb3BsZSB3aWxsIGhhdmUgb3RoZXIgImdhdGV3YXlzIiwgdG9kYXkgc29t ZSBtYWlsZXJzIHN0aWxsIHNlbmQgZG91YmxlIGJ5dGUgY2hhcnMgYXMgaXMuLi4NCg0KQW55d2F5 LCBIYXJhbGQgcGxlYXNlIGNvcnJlY3QgbWUsIGJ1dCBJIHRoaW5rIHRoZSBwb2ludCBoZXJlIGlz IHRoYXQgd2Ugc2hvdWxkIHZpZXcgdGhlICJkb3duZ3JhZGUiIGFzIGEgImdhdGV3YXkiIGZvciB0 aGUgbmV3IElNQS1hd2FyZSBtYWlsIHN5c3RlbSB0byBjb25uZWN0IGJhY2sgdG8gdGhlIGV4aXN0 aW5nIG1haWwgc3lzdGVtIChsaWtlIHR1bm5lbGluZyksIGFuZCB0aGVyZWZvcmUgdGhlcmUgY291 bGQgYmUgaW5mb3JtYXRpb24gbG9zcyAoYW5kIG5vdCB0aGF0IHJlZ2FyZGxlc3Mgb2Ygc3BlY2lm eWluZyBhIHByb3RvY29sIHN0YW5kYXJkIHRoZXJlIHdpbGwgYmUgZGlmZmVyZW50IGdhdGV3YXlz KS4NCg0KRWRtb24NCg0KDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206 ICJ5YW5nd29vIGtvIiA8bmV3Y2F0QGljdS5hYy5rcj4NClRvOiA8aW1hQGlldGYub3JnPg0KU2Vu dDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDcsIDIwMDUgMTowMyBBTQ0KU3ViamVjdDogUmU6IFtJ TUFdIHJlOiBKRVQgSU1BIG1lZXRpbmcgbWVtbw0KDQoNCj4gDQo+IFBsZWFzZSBoZWxwIG1lIHVu ZGVyc3RhbmQgSGFyYWxkJ3MgY29tbWVudCBjb3JyZWN0bHkuDQo+IA0KPiBGb2xsb3dpbmcgSGFy YWxkJ3MgY29tbWVudCwgSSBjb21lIHRvIGEgY29uY2x1c2lvbiB0aGF0IHdlIHdpbGwNCj4gc2Vl IHNldmVyYWwgZGlmZmVyZW50IGdhdGV3YXlzIHJlZ2FyZGxlc3Mgb2YgaGF2aW5nIGEgZ2F0ZXdh eQ0KPiBzdGFuZGFyZC4gSWYgc28sIHdoeSBkbyB3ZSBuZWVkIHRvIGRlZmluZSBpdCBpbiB0aGUg c3RhbmRhcmQ/DQo+IA0KPiBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCB3cm90ZToNCj4+IA0KPj4g VGhpbmsgb2YgaXQgdGhpcyB3YXkuLi4uDQo+PiANCj4+IHdpdGggYWNlQGFjZSwgeW91IGFyZSBh ZGRpbmcgYSBrbHVnZSB0byB0aGUgZXhpc3RpbmcgbWFpbCBzeXN0ZW0sIGFuZCANCj4+IHByYXlp bmcgdGhhdCBpdCBkb2VzIG5vdCBpbnRlcmZlcmUgd2l0aCB0aGUgb3RoZXIga2x1Z2VzLg0KPj4g DQo+PiB3aXRoIFVURjhAVVRGOCwgeW91IGFyZSBidWlsZGluZyBhIG5ldyBtYWlsIHN5c3RlbS4N Cj4+IA0KPj4gQW55IG5ldyBzeXN0ZW0gdGhhdCdzIHN1Y2Nlc3NmdWwgd2lsbCBoYXZlIGdhdGV3 YXlzIGJ1aWx0IHRvL2Zyb20gdGhlIA0KPj4gb2xkOyBpZiB5b3UgZG9uJ3QgZGVmaW5lIHRoZW0s IGVudHJlcHJlbmV1cnMgd2lsbCBtYWtlICJzb21ldGhpbmcgdGhhdCANCj4+IHdvcmtzIi4NCj4+ IA0KPj4gV2l0aCBVVEY4QFVURjggKyBEb3duZ3JhZGUsIHlvdSBhcmUgdHJ5aW5nIHRvIGRlc2ln biBpbiB0aGUgZ2F0ZXdheXMuIA0KPj4gVGhleSdyZSBzdGlsbCBnYXRld2F5cywgYW5kIGFzIEVp bmFyIFN0ZWZmZXJ1ZCB1c2VkIHRvIHNheTogIkFsbCANCj4+IGdhdGV3YXlzIGxvc2UgaW5mb3Jt YXRpb24uIFNvbWUgb2YgdGhlbSBhcmUgYmV0dGVyIGF0IGl0IHRoYW4gb3RoZXJzLiIgDQo+PiBQ ZW9wbGUgd2lsbCBzdGlsbCBoYXZlIHJlYXNvbiB0byBwcmVmZXIgdGhlIHVuLWdhdGV3YXllZCBl bnZpcm9ubWVudC4NCj4+IA0KPj4gVGhhdCdzIG15IHRoaW5raW5nLCBhZnRlciBsaXN0ZW5pbmcg dG8gdGhpcyBjb252ZXJzYXRpb24uLi4uDQo+PiANCj4+ICAgICAgICAgICAgICAgICAgICAgIEhh cmFsZA0KPj4gDQo+PiANCj4+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPiANCj4= --===============0467302510== 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 --===============0467302510==-- From ima-bounces@ietf.org Wed Sep 07 05:09:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvw2-00054W-RR; Wed, 07 Sep 2005 05:09:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECvw1-00053n-Ac for ima@megatron.ietf.org; Wed, 07 Sep 2005 05:09:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06019 for ; Wed, 7 Sep 2005 05:09:35 -0400 (EDT) Received: from ns01.afilias.info ([170.224.17.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECvz9-0006wG-13 for ima@ietf.org; Wed, 07 Sep 2005 05:12:52 -0400 Received: from edmontr3 (vgateway.libertyrms.info [207.219.45.62]) (authenticated bits=0) by ns01.afilias.info (8.12.8/8.12.8) with ESMTP id j8799OLr029908 for ; Wed, 7 Sep 2005 05:09:25 -0400 Message-ID: <027401c5b38b$d72b1c80$bf01a8c0@edmontr3> From: "Edmon Chung" To: References: <325624544.08637@cnnic.cn><010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn><020901c5af69$f6a78dd0$1206e29f@cnnicyaojk><341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no><431E74B6.8010509@icu.ac.kr> <026701c5b38a$fc2a0c40$bf01a8c0@edmontr3> Subject: Re: [IMA] re: JET IMA meeting memo Date: Wed, 7 Sep 2005 05:07:49 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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="===============1063305215==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============1063305215== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVkbW9uIENodW5nIiA8ZWRt b25AYWZpbGlhcy5pbmZvPg0KPiBJZiBJIHVuZGVyc3Rvb2QgaXQgY29ycmVjdGx5LCBJIHRoaW5r IHdoYXQgSGFyYWxkIG1lYW5zIGlzIHRoYXQgZWFjaCBTTVRQIChzb3JyeSwgc2hvdWxkIHByb2Jh Ymx5IHNheSBtYWlsZXIpIHRoYXQgaW1wbGVtZW50cyB0aGUgImRvd25ncmFkZSIgc3BlY2lmaWVk IGJ5IHRoZSBwcm90b2NvbCBpcyBpbiBmYWN0IGEgZ2F0ZXdheSB0byB0aGUgbm9uLUlNQS1hd2Fy ZSBzeXN0ZW0gKGhlbmNlIHRoZSBwbHVyYWwpLg0KPiANCj4gVGhhdCBiZWluZyBzYWlkLCBpdCBp cyBwb3NzaWJsZSB0aGF0IHBlb3BsZSB3aWxsIGhhdmUgb3RoZXIgImdhdGV3YXlzIiwgdG9kYXkg c29tZSBtYWlsZXJzIHN0aWxsIHNlbmQgZG91YmxlIGJ5dGUgY2hhcnMgYXMgaXMuLi4NCj4gDQo+ IEFueXdheSwgSGFyYWxkIHBsZWFzZSBjb3JyZWN0IG1lLCBidXQgSSB0aGluayB0aGUgcG9pbnQg aGVyZSBpcyB0aGF0IHdlIHNob3VsZCB2aWV3IHRoZSAiZG93bmdyYWRlIiBhcyBhICJnYXRld2F5 IiBmb3IgdGhlIG5ldyBJTUEtYXdhcmUgbWFpbCBzeXN0ZW0gdG8gY29ubmVjdCBiYWNrIHRvIHRo ZSBleGlzdGluZyBtYWlsIHN5c3RlbSAobGlrZSB0dW5uZWxpbmcpLCBhbmQgdGhlcmVmb3JlIHRo ZXJlIGNvdWxkIGJlIGluZm9ybWF0aW9uIGxvc3MgKGFuZCBub3QgdGhhdCByZWdhcmRsZXNzIG9m IHNwZWNpZnlpbmcgYSBwcm90b2NvbCBzdGFuZGFyZCB0aGVyZSB3aWxsIGJlIGRpZmZlcmVudCBn YXRld2F5cykuDQo+IA0KPiBFZG1vbg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCj4gRnJvbTogInlhbmd3b28ga28iIDxuZXdjYXRAaWN1LmFjLmtyPg0K PiBUbzogPGltYUBpZXRmLm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDcsIDIw MDUgMTowMyBBTQ0KPiBTdWJqZWN0OiBSZTogW0lNQV0gcmU6IEpFVCBJTUEgbWVldGluZyBtZW1v DQo+IA0KPiANCj4+IA0KPj4gUGxlYXNlIGhlbHAgbWUgdW5kZXJzdGFuZCBIYXJhbGQncyBjb21t ZW50IGNvcnJlY3RseS4NCj4+IA0KPj4gRm9sbG93aW5nIEhhcmFsZCdzIGNvbW1lbnQsIEkgY29t ZSB0byBhIGNvbmNsdXNpb24gdGhhdCB3ZSB3aWxsDQo+PiBzZWUgc2V2ZXJhbCBkaWZmZXJlbnQg Z2F0ZXdheXMgcmVnYXJkbGVzcyBvZiBoYXZpbmcgYSBnYXRld2F5DQo+PiBzdGFuZGFyZC4gSWYg c28sIHdoeSBkbyB3ZSBuZWVkIHRvIGRlZmluZSBpdCBpbiB0aGUgc3RhbmRhcmQ/DQo+PiANCj4+ IEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kIHdyb3RlOg0KPj4+IA0KPj4+IFRoaW5rIG9mIGl0IHRo aXMgd2F5Li4uLg0KPj4+IA0KPj4+IHdpdGggYWNlQGFjZSwgeW91IGFyZSBhZGRpbmcgYSBrbHVn ZSB0byB0aGUgZXhpc3RpbmcgbWFpbCBzeXN0ZW0sIGFuZCANCj4+PiBwcmF5aW5nIHRoYXQgaXQg ZG9lcyBub3QgaW50ZXJmZXJlIHdpdGggdGhlIG90aGVyIGtsdWdlcy4NCj4+PiANCj4+PiB3aXRo IFVURjhAVVRGOCwgeW91IGFyZSBidWlsZGluZyBhIG5ldyBtYWlsIHN5c3RlbS4NCj4+PiANCj4+ PiBBbnkgbmV3IHN5c3RlbSB0aGF0J3Mgc3VjY2Vzc2Z1bCB3aWxsIGhhdmUgZ2F0ZXdheXMgYnVp bHQgdG8vZnJvbSB0aGUgDQo+Pj4gb2xkOyBpZiB5b3UgZG9uJ3QgZGVmaW5lIHRoZW0sIGVudHJl cHJlbmV1cnMgd2lsbCBtYWtlICJzb21ldGhpbmcgdGhhdCANCj4+PiB3b3JrcyIuDQo+Pj4gDQo+ Pj4gV2l0aCBVVEY4QFVURjggKyBEb3duZ3JhZGUsIHlvdSBhcmUgdHJ5aW5nIHRvIGRlc2lnbiBp biB0aGUgZ2F0ZXdheXMuIA0KPj4+IFRoZXkncmUgc3RpbGwgZ2F0ZXdheXMsIGFuZCBhcyBFaW5h ciBTdGVmZmVydWQgdXNlZCB0byBzYXk6ICJBbGwgDQo+Pj4gZ2F0ZXdheXMgbG9zZSBpbmZvcm1h dGlvbi4gU29tZSBvZiB0aGVtIGFyZSBiZXR0ZXIgYXQgaXQgdGhhbiBvdGhlcnMuIiANCj4+PiBQ ZW9wbGUgd2lsbCBzdGlsbCBoYXZlIHJlYXNvbiB0byBwcmVmZXIgdGhlIHVuLWdhdGV3YXllZCBl bnZpcm9ubWVudC4NCj4+PiANCj4+PiBUaGF0J3MgbXkgdGhpbmtpbmcsIGFmdGVyIGxpc3Rlbmlu ZyB0byB0aGlzIGNvbnZlcnNhdGlvbi4uLi4NCj4+PiANCj4+PiAgICAgICAgICAgICAgICAgICAg ICBIYXJhbGQNCj4+PiANCj4+PiANCj4+PiANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSU1BIG1haWxpbmcgbGlzdA0KPj4g SU1BQGlldGYub3JnDQo+PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p bWENCj4+IA0KPj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlz dA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaW1hDQo+ --===============1063305215== 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 --===============1063305215==-- From ima-bounces@ietf.org Wed Sep 07 05:58:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwhC-00065j-7H; Wed, 07 Sep 2005 05:58:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwhA-00065e-V1 for ima@megatron.ietf.org; Wed, 07 Sep 2005 05:58:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07817 for ; Wed, 7 Sep 2005 05:58:18 -0400 (EDT) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECwkE-000891-MO for ima@ietf.org; Wed, 07 Sep 2005 06:01:36 -0400 Received: (snipe 6125 invoked by uid 0); 7 Sep 2005 18:59:55 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.026327 secs); Received: from unknown (HELO ?220.69.185.75?) (Z?H?own@220.69.185.75) by unknown with SMTP; 7 Sep 2005 18:59:55 +0900 X-RCPTTO: edmon@afilias.info, ima@ietf.org Message-ID: <431EB99F.5070602@icu.ac.kr> Date: Wed, 07 Sep 2005 18:57:51 +0900 From: yangwoo ko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edmon Chung Subject: Re: [IMA] re: JET IMA meeting memo References: <325624544.08637@cnnic.cn><010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn><020901c5af69$f6a78dd0$1206e29f@cnnicyaojk><341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> <431E74B6.8010509@icu.ac.kr> <026701c5b38a$fc2a0c40$bf01a8c0@edmontr3> In-Reply-To: <026701c5b38a$fc2a0c40$bf01a8c0@edmontr3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Following Edmon's interpretation, it is unavoidable for utf8@ based solution to suffer from loss of information while downgrading. (That is really what "down grade" means...) Then questions we need to investigate are; (1) how large the information loss is when we use either (1)-1 utf8@ with downgrade OR (1)-2 utf8@ without downgrade (or non-IETF standard downgrade) (2) whether the information loss is significant or not (3) maybe more... Regards Edmon Chung wrote: > If I understood it correctly, I think what Harald means is that each SMTP that implements the "downgrade" specified by the protocol is in fact a gateway to the non-IMA-aware system (hence the plural). > > That being said, it is possible that people will have other "gateways", today some mailers still send double byte chars as is... > > Anyway, Harald please correct me, but I think the point here is that we should view the "downgrade" as a "gateway" for the new IMA-aware mail system to connect back to the existing mail system (like tunneling), and therefore there could be information loss (and not that regardless of specifying a protocol standard there will be different gateways). > > Edmon > > > > > ----- Original Message ----- > From: "yangwoo ko" > To: > Sent: Wednesday, September 07, 2005 1:03 AM > Subject: Re: [IMA] re: JET IMA meeting memo > > > >>Please help me understand Harald's comment correctly. >> >>Following Harald's comment, I come to a conclusion that we will >>see several different gateways regardless of having a gateway >>standard. If so, why do we need to define it in the standard? >> >>Harald Tveit Alvestrand wrote: >> >>>Think of it this way.... >>> >>>with ace@ace, you are adding a kluge to the existing mail system, and >>>praying that it does not interfere with the other kluges. >>> >>>with UTF8@UTF8, you are building a new mail system. >>> >>>Any new system that's successful will have gateways built to/from the >>>old; if you don't define them, entrepreneurs will make "something that >>>works". >>> >>>With UTF8@UTF8 + Downgrade, you are trying to design in the gateways. >>>They're still gateways, and as Einar Stefferud used to say: "All >>>gateways lose information. Some of them are better at it than others." >>>People will still have reason to prefer the un-gatewayed environment. >>> >>>That's my thinking, after listening to this conversation.... >>> >>> Harald >>> >>> >>> >> >> >>_______________________________________________ >>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 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 07 06:03:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwmV-0006x1-MQ; Wed, 07 Sep 2005 06:03:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECwmT-0006ww-U4 for ima@megatron.ietf.org; Wed, 07 Sep 2005 06:03:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07999 for ; Wed, 7 Sep 2005 06:03:47 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECwpa-0008IX-Fu for ima@ietf.org; Wed, 07 Sep 2005 06:07:05 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCAA9320099; Wed, 7 Sep 2005 12:03:14 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27413-10; Wed, 7 Sep 2005 12:03:09 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08819320097; Wed, 7 Sep 2005 12:03:08 +0200 (CEST) Date: Wed, 07 Sep 2005 09:32:37 +0200 From: Harald Tveit Alvestrand To: yangwoo ko , ima@ietf.org Subject: Re: [IMA] re: JET IMA meeting memo Message-ID: <9816ED1F3038F97277A6C7DF@B50854F0A9192E8EC6CDA126> In-Reply-To: <431E74B6.8010509@icu.ac.kr> References: <325624544.08637@cnnic.cn> <010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn> <020901c5af69$f6a78dd0$1206e29f@cnnicyaojk> <341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> <431E74B6.8010509@icu.ac.kr> 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: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============0962634147==" Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org --===============0962634147== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========B90C389148E5D83B7F36==========" --==========B90C389148E5D83B7F36========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 7. september 2005 14:03 +0900 yangwoo ko wrote: > > Please help me understand Harald's comment correctly. > > Following Harald's comment, I come to a conclusion that we will > see several different gateways regardless of having a gateway > standard. If so, why do we need to define it in the standard? Experience from X.400 to SMTP gatewaying says that multiple gateways that=20 make different decisions on how to reformat data makes the user experience=20 much more painful than having most gateways perform the same way. My point was mainly that you will have gateways whether you want them or=20 not, so having UTF8@UTF8 + no downgrade just means that you will have no=20 chance to define how gateways should behave before they start appearing. --==========B90C389148E5D83B7F36========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) iD8DBQFDHpeWOMj+2+WY0F4RAoKpAJ9fw4NzIJogkmeh69uAyqCi7eqNbACfX+co SO3jKB4ADJ9/gCr4MnO1RcE= =vPdi -----END PGP SIGNATURE----- --==========B90C389148E5D83B7F36==========-- --===============0962634147== 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 --===============0962634147==-- From ima-bounces@ietf.org Wed Sep 07 08:19:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECytS-0001NE-SX; Wed, 07 Sep 2005 08:19:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECytQ-0001Jv-Sf for ima@megatron.ietf.org; Wed, 07 Sep 2005 08:19:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15264 for ; Wed, 7 Sep 2005 08:19:07 -0400 (EDT) Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ECywa-0003dN-7w for ima@ietf.org; Wed, 07 Sep 2005 08:22:25 -0400 Received: (snipe 6305 invoked by uid 0); 7 Sep 2005 21:20:57 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.024617 secs); Received: from unknown (HELO ?220.69.185.75?) (ZV??own@220.69.185.75) by unknown with SMTP; 7 Sep 2005 21:20:57 +0900 X-RCPTTO: harald@alvestrand.no, ima@ietf.org Message-ID: <431EDAAD.4090906@icu.ac.kr> Date: Wed, 07 Sep 2005 21:18:53 +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] re: JET IMA meeting memo References: <325624544.08637@cnnic.cn> <010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn> <020901c5af69$f6a78dd0$1206e29f@cnnicyaojk> <341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> <431E74B6.8010509@icu.ac.kr> <9816ED1F3038F97277A6C7DF@B50854F0A9192E8EC6CDA126> In-Reply-To: <9816ED1F3038F97277A6C7DF@B50854F0A9192E8EC6CDA126> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Thanks for clarification. More comments are in-line below. Harald Tveit Alvestrand wrote: > > > --On 7. september 2005 14:03 +0900 yangwoo ko wrote: > >> >> Please help me understand Harald's comment correctly. >> >> Following Harald's comment, I come to a conclusion that we will >> see several different gateways regardless of having a gateway >> standard. If so, why do we need to define it in the standard? > > > Experience from X.400 to SMTP gatewaying says that multiple gateways > that make different decisions on how to reformat data makes the user > experience much more painful than having most gateways perform the same > way. New mail system should work with several legacy mail systems. In order to provide downgrading in "the same way", we should define the least common denominator as the downgrade scheme. I guess falling back to ASCII-only address known to sender SMTP server can be the L.C.D. However I still do not understand why the downgrading should be defined as a function in the network rather than letting end points (email client or human/non-human user) handle it. If a packet cannot find a path to which it is routed, it should be dropped rather than trying to get it through via roundabout. > My point was mainly that you will have gateways whether you want them or > not, so having UTF8@UTF8 + no downgrade just means that you will have no > chance to define how gateways should behave before they start appearing. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 07 15:15:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5Ny-0002es-LM; Wed, 07 Sep 2005 15:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED5Nx-0002ei-MK for ima@megatron.ietf.org; Wed, 07 Sep 2005 15:15:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10386 for ; Wed, 7 Sep 2005 15:15:04 -0400 (EDT) Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED5R7-0007ZY-OH for ima@ietf.org; Wed, 07 Sep 2005 15:18:26 -0400 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1ED5Ng-0009rV-V1; Wed, 07 Sep 2005 15:14:49 -0400 Date: Wed, 07 Sep 2005 15:14:48 -0400 From: John C Klensin To: Harald Tveit Alvestrand , yangwoo ko , ima@ietf.org Subject: Re: [IMA] re: JET IMA meeting memo Message-ID: <6CF8377C46957FA72D3FB092@scan.jck.com> In-Reply-To: <9816ED1F3038F97277A6C7DF@B50854F0A9192E8EC6CDA126> References: <325624544.08637@cnnic.cn> <010301c5af60$184d5690$1206e29f@cnnicyaojk> <325628498.27261@cnnic.cn> <020901c5af69$f6a78dd0$1206e29f@cnnicyaojk> <341F2EECF596CDE5288EE6EA@gloppen.hjemme.alvestrand.no> <431E74B6.8010509@icu.ac.kr> <9816ED1F3038F97277A6C7DF@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.3 (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: 14582b0692e7f70ce7111d04db3781c8 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, 07 September, 2005 09:32 +0200 Harald Tveit Alvestrand wrote: > --On 7. september 2005 14:03 +0900 yangwoo ko > wrote: > >> Please help me understand Harald's comment correctly. >> >> Following Harald's comment, I come to a conclusion that we >> will see several different gateways regardless of having a >> gateway standard. If so, why do we need to define it in the >> standard? > > Experience from X.400 to SMTP gatewaying says that multiple > gateways that make different decisions on how to reformat data > makes the user experience much more painful than having most > gateways perform the same way. > > My point was mainly that you will have gateways whether you > want them or not, so having UTF8@UTF8 + no downgrade just > means that you will have no chance to define how gateways > should behave before they start appearing. For whatever it is worth, and while I would have explained it differently, this is the reason I've said before that there is essentially no difference between "UTF-8@UTF-8 with downgrade strategy" and "UTF-8@UTF-8 with no downgrade". In both cases, the protocol will need to identify what should happen when a client trying to send a message that contains non-ASCII address material tries to send to a server that is not IMA-capable. The issue cannot simply be ignored. Now, to me, there are three possible classes of answer to the "what happens" question: (i) A specific translate-and-downgrade procedure is specified and required. As Harald, Edmon, and others have pointed out in different ways, this will inevitably result in some information loss. But predictable information loss is better than unpredictable behavior. Unfortunately, if the translation procedure is at all complex or subject to local options or variations, some implementers will get it wrong and we may have unpredictable behavior anyway. Conversely, whatever we say about requirements, some servers will choose to reject IMA traffic rather than provide the downgrade procedure -- they will just be non-conforming. (ii) A "must bounce" model is specified. As Harald points out, this will result in some servers trying to invent and do downgrades of their own as a means of getting commercial advantage. They will mess it up, and they won't do it the same way, which will result in further problems. The only defense against this is a very careful analysis of why downgrades are impractical and drop too much information and that analysis just about requires designing the downgrade mechanism (see below). (iii) An optional downgrade mechanism, with the tools to carry sufficient information to make it possible, but with the provision that a client, confronted with a non-upgraded server, may either bounce or implement and apply the downgrade. Now, (i) and (iii) will turn out to be exactly the same in practice. Some servers will bounce and some will downgrade. If the downgrade procedure is easy and clear enough and is seen to have marketplace value, more servers will implement it. If it fails on any of those three criteria, either more servers will bounce (even if it makes them non-conforming) or some will get the downgrade wrong, causing interoperability problems. By contrast, (ii) without a standard downgrade procedure, will result in some implementers generating their own, incompatible, versions of how to do downgrades. I think we have no other choice other than to try to sort out and specify a downgrade procedure and, for the reasons above, make it optional. If we succeed, then we basically have case (iii). If we convince ourselves that downgrades are basically unworkable, we have either a version of (iii) in which no one will implement the downgrade or a version of (ii) in which we say "should not attempt to downgrade" and supplement it with an informational RFC that explains why attempts to do IMA downgrading are harmful. Debating "downgrade or not" as a philosophical issue is probably not useful. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima